《2022年需求的面向对象描述方法 .pdf》由会员分享，可在线阅读，更多相关《2022年需求的面向对象描述方法 .pdf（22页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、第 7 章需求的面向对象描述方法本章目录第 7 章需求的面向对象描述方法. 1 学习目标 . 1 本章要点 . 1 无限电子公司：供应链一体化. 1 概述 . 2 7.1 统一建模语言和对象管理组织. 3 7.2 面向对象的需求 . 3 7.3 系统活动：面向对象的用例/场景视图 . 4 7.3.1 用例和参与者 . 5 7.3.2 用例图 . 5 7.3.3 开发用例图 . 8 7.3.4 用例详细描述 . 9 7.4 确定输入和输出系统顺序图. 13 7.4.1 系统顺序图符号 . 13 7.4.2 开发系统顺序图 . 15 7.5 问题域建模域模型类图. 18 7.6 面向对象模型的集成
2、 . 20 小结 . 21 关键术语. 21 学习目标阅读本章后，你应具备如下能力：开发用例图撰写用例和场景描述开发活动图和顺序图改进和提高域模型类图解释如何用UML 图表协同工作来为面向对象的方法定义功能需求本章要点统一建模语言(UML) 与对象管理组织面向对象的需求系统活动：面向对象的用例/场景视图确定输入和输出：系统顺序图问题域建模：域模型类图面向对象模型的集成无限电子公司：供应链一体化无限电子公司是一家仓储式销售商，他们从不同的供应商手中买来电子设备，然后再卖给遍及整个美国和加拿大的零售商们。他们在洛杉矶、 休斯顿、 巴尔的摩、 亚特兰大、 纽约、丹佛和明尼阿波利斯都有办事处和仓库。他
3、们的客户既包括像Target公司这样的全国范围的大型零售商，同时也有中等规模的独立的电子商店。目前， 许多大的零售商们正致力于供应链一体化。信息系统过去只关注内部数据的处理，名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 22 页 - - - - - - - - - 然而， 如今的零售连锁希望他们的供应者成为完整的供应链系统的一部分。换句话说， 信息系统现在必须在公司之间进行沟通，以使供应链更有效率。为了保持它的批发销售商的领导地位，无限电子公司对其系统进行了调整，使之能
4、够协调电子设备制造商、用户，以及零售商之问的关系。为了实现这个目标，他们利用面向对象技术开发了一个全新的系统。面向对象技术使系统与系统之间的接口连接变得容易了。公司使用预先定义好的组件和对象将加快开发过程。幸运的是， 许多系统开发人员已经开始学习面向对象的开发方法并且他们热衷于为系统开发项目应用这种技术和模型。William Jones正在给一批系统分析员讲解面向对象的开发(这些人是被安排来接受这种新方法的培训的)： “我们将使用面向对象的原理开发新系统的绝大部分。新系统的复杂性，以及它的交互功能使面向对象方法成为开发需求的自然之选。这与你过去的思维过程不同，但是面向对象的模型和新的面向对象的
5、程序语言十分相似。”William 继续说： “从对象的角度来考虑一个系统是很有趣的，这也和你们在编程课上学到的面向对象的编程技术是一致的。当你开发用户界面时，你可能会首先学着去考虑对象。界面上的所有控件，例如按钮、 文本框和下拉框都是对象。每个对象都有自己一系的触发事件能够激活程序功能。 ”“现在，你们只要将这种思维过程拓展开来，把像订单、雇员这样的事物都想像成象。我们可以称之为商业对象以便把它们和像窗口、按钮这样的屏幕对象区分开。在分过程中，我们要找到每个商业对象的全部触发事件和方法。”“那我们怎样做呢？”一个分析员问到。“你继续你的事实发现活动并且为每一个商业过程制作一个说明书。在说明书
6、中的商业对象之间的交互方式决定了你是如何识别触发事件的，我们把这些触发事件看成在对象间相互传递的消息。 关键的技巧是你需要依据对象而不是过程来考虑。这样有时使我们假设自己就是一个对象。 我会说我是一个订单对象，其他的对象将会要求我有什么样的功能和服务呢？ 一旦你掌握诀窍，以面向对象的角度工作，将会工作得很顺手，在开发图表时也很容易看清楚系统需求是如何展现的。”概述需求定义的基本目标在于理解用户的需求、理解商业过程如何运行，并且理解系统如何用于支持这些商业过程。如同我们在第2 章中指出的一样， 系统开发者使用一套工具技术来发现和理解一个新系统的需求。这种行为是系统开发生命周期中系统分析阶段的重要
7、组成部分。在面向对象的开发中，这类行为特指为面向对象的分析(OOA) 。此过程首要的一步在于深入理解这一过程，需要用到第4 章中关于事实发现的技术。事实发现行为称做发现活动，显而易见，发现必须先于理解。在本章，你将学习发现的下一个阶段：建立理解。作为一种定义和记录系统需求的方法，第 5 章介绍了模型和建模活动的概念。第 5章介绍模型的过程中， 我们把注意力集中在系统需求的两个主要方面，包含在用户工作中的事件和事物。 正如你所学到的，事件发生在系统必须响应的商业环境中。事件被定义和记录在事件表中。 新系统必须能够通过运行系统活动(也称为用例 )来响应商业事件。一个新系统同时也需要记录和存储包含在
8、商业过程中的事物信息。在手工系统中， 信息记录在纸上并存储到档案柜中。在自动化系统中，信息存储在电子文件或数据库中。系统的信息存储需求或者用传统方法中的实体-联系图 (ERDs)进行记录，或者用面向对象方法中的类图进行记录。在本章，你将学会如何使用面向对象的分析模型和技术来理解和定义新系统的需求。你应该理解： 面向对象的分析和面向对象设计之间的界限并不明显，因为系统的设计就是对分析阶段中用于定义需求的模型进行改进和扩展得到的。回想一下， 我们曾提到面向对象方名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - -
9、 - - - - 第 2 页，共 22 页 - - - - - - - - - 法使用迭代的方法进行开发，这种方法首先定义一些需求，然后进行一些初步的设并实施，然后反复迭代需求、设计和实施的过程。所以，尽管我们不关心这里提到的需求定义的迭代特性， 但它仍然是面向对象方法的组成部分。第 11 章和第 12 章把需求扩展到完整地面向对象的设计中，以便作为新系统程序设计的基础。7.1 统一建模语言和对象管理组织本书所涉及的面向对象建模符号就是统一建模语言(UML) 。 UML 是以下建模技术的继：Gradv Booctl 的对象技术、 James Rumbaugh的对象建模技术(OMT) 、Ivar
10、 Jacobson 的面向对象的软件工程，以及其他的一些方法。1995 年， UML的最初版本在OOPSLA 。ObiectOrientecl Programming ，Systems，Languages，antl Applical ：iOIlS) 会议上发布。到1997 年 1月，UML 已经经历了几次根据大众的反馈由原作者完成的修正。1997 年 1 月，为了响应标准化建模技术提出的要求，UML 被呈交给对象管理组织(OMG) 。OMG 是一个由 800 多个软件销售商、开发商和组织组成的共同体，他们致力于发展和传播面向对象系统。它成立于1989 年。 OMG 的使命就是在分布式计算系统的
11、开发中提高应用对象技术的理论和实践水平。它的目标是为基于广泛接口规格的面向对象的应用程序提供一个通用的体系框架。自 1997 年 1 月起，人们修订了UML 并交给了OMG 想使其成为OO 建模中可广泛接受的标准。OMG 保留了 OO 建模组织，以审核面向对象建模标准的何变化。因此， UML标准能够得到持续发展，但是他们仍将从系统开发人员(和学生 )利益出发 保 留 标 准 化 的 部 分 。 关 于UML和OMG更 多 详 细 信 息 请 参 见OMG的 网 站http:/WWW.omg.org 。7.2 面向对象的需求和第5 章讨论的一样，使用模型来记录需求的一个最大的好处在于它能帮助系统
12、开发员仔细和清楚地考虑处理的细节，以及系统相关人员的信息需求。在阅读本章并进行相关练习的过程中， 你应该 密切注意模型如何需要你来发现和理解用户需求。 开发模型有很多好处，在整个建模的过程中面向对象的系统需求就确定并记录下来了。如图 7-1 所示，系统开发过程开始于确定事件和事物。事件是新系统所必须考虑的商业事物是包含在商业过程中的问题域对象。问题域对象在新系统的开发和数据库的设计中都是至关重要的。 新开发人员经常会问这样的问题：是先定义过程和还是先定义对象的类。事实上，这两个方面是紧密联系在一起的，它们 通常一起定义。有经验的开发人员经常在确定类和商业过程之间不断切换，在完成一套需求之前他们
13、通常要做几次这种操作。在你定义需求的时候，如果发现需要改变图和模型，请不要气馁。图 7-1 传统和 OO 的需求图面向对象的方法需要几个相关的模型来创建一套完整的说明。尽管在开始的时候因为名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 22 页 - - - - - - - - - 有许多不同图的种类而显得有些复杂，但是在你使用它们的过程中，你将会学到如何把它们像拼图一样组合在一起来生成完整的说明。特别地，面向对象的方法“区分和克服”复杂系统的中的一些问题。每个模型描述了系
14、统的不同方面，所以你只需在一段时间拒三意力集中在一个方面就可以了。但是你必须学会所有不同的模型和它们组合在一起的方式。在本章的最后，我们将讨论如何把所有的图结合在一起形成一个完整系统功能需求图。作为一个刚开始学习 UML 的人员来说， 你应该集中学习每一个新的模型并且理解在定整个系统的过程中它所扮演的角色。本章主要讨论一个关于模型的集合，它根据面向对象方法中的用例来捕获系统需求四种模型用例图、用例描述、活动图(第 4 章讨论的 )和系统顺序图，用来从不同的观点描述系统用例。系统顺序图是交互图的一种。类图(第 5 章讨论的 )是另外一种类型图，它被用来定义问题域中对象的类。在许多实例中， 分析员
15、使用所有模型完整地定义统需求。然而有时候只要使用两或三种方法就可以准确地确定需求。用例图的目的是识别新系统的“用法”或用例，换句话说，就是识别如何使用系统用例图本质上是事件表的延伸。用例图是用于记录系统必须支持的所有功能的一种简便法。有时可以用一个综合的用例图来描述整个系统。在其他情况下， 一些小型的用例图可组成用例模型。用例图 ：一种用以显示不同的用户角色和这些用户角色如何使用系统的图。每个用例都必须详细描述。一种方法是详细记录下用户和系统共同完成用例的步骤：每个用例还可以用图表来定义。正如第 4 章中所介绍的， 活动图可以用来描述由组织中主人完成的任何商业过程。另一方面， 也可以用来描述包
16、括手动和自动系统活动的过程，以活动图可以用来定义用例。系统顺序图(SSD)用来定义一个用例的输入和输出，以及在用户和系统之间交互的顺序。他们用于联系详细描述或活动图。在顺序图中，这些出入系统的信息流被称为消息：还要标识用户，描述消息的细节信息。系统顺序图 ：在用例或场景中，用于显示外部参与者和系统之间的消息顺序的图。消息 ：用例内部对象之间的通信。在第 5 章你学到了关于对象的类和类图的知识。类图用来标识真实世界的“事物”，这些事物决定了编写程序类的结构(以及数据库结构)。在系统的面向对象视图中，每个事物都被认为是一个对象。在第 5 章，我们解释了所确定的对象属于问题域类，并且这些类具体的事物
17、 (如用户 )和更抽象的事物(例如：订单和航线)组成。构造一个类图有助于确定真实世界对象的信息，这些真实世界的对象将是新系统的组成部分。图 7-1 中所标识的另一种图是状态图。状态图表(简称状态图 )描述了每个对象状态的集合。 类图中所标识的一些对象有些状态情形需要跟踪，这些状态直接决定了对象的处理过程。客户订单有几个比较重要的状态条件，它们控制订单的处理过程，例如， 订单只有在完成后才会发货。 状态图标识这些状态条件并且标明允许的处理过程。同时， 状态图也可用于设计过程， 以确定系统本身的各种状态，以及能够处理的可允许的事件上。因此，状态图既可以看做是分析工具，也可以看做是设计工具。我们到第
18、12 章的时候才讨论状态图，那里我们将讨论面向对象分析和设计的更高级的主题。状态图 ：一种用以显示对象在各阶段中的生命和转换的情况的图。7.3 系统活动：面向对象的用例/场景视图用例分析的目标用来标识和定义系统必须支持的所有商业过程。分析员在综合等级和详细等级两个层次上定义用例。事件表和用例图为一个系统提供了所有用例的综合。关于每个用例的详细信息使用用例描述、活动图和系统顺序图，或者这些模型的组合进行说明。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 22 页 - -
19、- - - - - - - 7.3.1用例和参与者用例是系统运行的活动，通常由系统用户来响应需求。你可以把用例看成是系统中的特定情形，此时系统必须完成一定的用户目标，如RMO 系统。 RMO 系统必须执行的一个处理是处理新客户订单。所以，该系统的一个用例就是“产生新订单”。注意，焦点在自动系统上， 也就是说， 用例的焦点是放在自动化系统上的，即系统必须完成创建一份订单的活动上。所有的用例中都蕴涵了使用系统的人。在 UML 中人被称为参与者。参与者通常处于自动化系统边界之外，但是它也有可能是系统手动部分的成员。这里参与者的概念和我们在事件表中所定义的事件的“源”在内涵上略有不同。事件的源是指事件
20、的发起者，例如一个用户，并且它通常在系统(包括手动系统 )的外部。 在用例分析中的参与者实际上亲自和计算机系统进行交互的人。通过这样的方法来定义参与者(即那些和系统进行交互的人)，你可以更加准确地定义那些自动化系统所必须响应的交互。这种紧密的关系有助于定义自动化系统自身的一些特殊需求，并且当我们从事件表中移出用例详细信息的时候我们能够重新提炼它们。有一种方法能够标识参与者出于正确的等级，这就要假设参与者都有手。认为参与者都有手， 这将有助于我们将那些能够接触自动系统的人定义为参与者。但是要记住， 有些参与者并不是人，他们可能是其他的系统或者从系统接受服务的设备。另一种考虑参与者的方式是把它看成
21、一个角色。举个例子，在RMO 案例中，用例“产生新订单的情况可能会涉及一个销售代表在电话里与一名客户进行交谈。另一方面， 如果这位客户直接在Internet 上订货，那他也是个参与者。最后一种方式考虑参与者和用例，认为用例是参与者想要完成的目标。一种标志这一目标的方法是：订单职员使用系统来生成新订单。注意，这句话中的参与者(订单职员 )和用例 (产生新订单 )都被标识了。事实上，这种用语句的格式声明用例的技术对于理解用例和参与者之间的关系是非常方便的。7.3.2用例图图 7-2 显示了如何在一个用例图中记录一个用例。一个简单的棒状小人图表示参与者。这个小人图取了一个可以表示其扮演角色的名字。用
22、例用一个在里面标有名称的椭圆所代表，参与者与用例之间的连线表示了有哪些参与者参与哪种用例。虽然手不是标准UML 符号的组成部分， 但是在这个图中的参与者被画出了手，这样有助于读者掌握参与者必须能够直接访问自动系统。用例图是概括有关参与者和用例信息的一个图形化的模型。为了对用例进行分析，我们把系统作为一个整体，并设法识别系统中所有主要的使用。图 7-2 有一个参与者的简单用例自动化边界和组织图 7-3 对图 7-2 进行了扩展，它增加了一些参与者和用例。在这个实例中，订单员和用户都可以直接访问系统。正像有关系线连接表示的那样，每个参与者可以操作所有的用例。在全套的用例上画了一条边界线。这个边界是
23、自动化边界。它表示了环境(参与者的居住地)和自动系统的内部功能之问的边界。有很多方法可以用来组织用例图，以便描述不同的观点。一种方法是使用子系统。如名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 22 页 - - - - - - - - - 图 7-3 所示的是一个订单输入子系统。图7-4 用相关联的用例扩展了原图以显示RMO 客户支持系统的所有子系统。另一个方法是包含涉及一个特定参与者的所有用例。图 7-5 表示了与一个客户参与者相关的所有用例。这个图在表明所有通过In
24、ternet 访问的活动时非常有用。分析员可以选择绘制基于项目团队需要的用例图。如果计划与市场部门经理会面讨论所有涉及直接客户交互的用例，那么图7-5 中的用例图将会非常有用。图 7-3 订单输入子系统的用例图，显示了系统边界图 7.4 各中文系统的用例图(子系统 ) 包含关系通常在用例图的开发过程中，一个用例需要用到通用子程序所提供的服务。例如，“订单输入子系统”的两个用例是“产生新订单”、 “更新订单” ，这两个用例均须检查客户的账号是否正确。 因此， 可以定义一个通用的子程序来完成这个功能，并且它变成了一个附加用例。图 7-6 展示了一个名为“核查客户账号”的用例，它被刚才的两个用例调用
25、。在这些用例之间的关系由带箭头的连接线表示。这种关系可以读做“产生新订单核查客户账号” 。有时这种包含关系也称为包括关系或者使用关系。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 22 页 - - - - - - - - - 图 7-5 与客户相关的所有用例图 7-6 也表明了“查找可用条目”可能是包含关系的一部分。所以，分析员可以定义两种类型的包含关系：一种是通用内部子程序，如“核查客户账号”，它不被外部参与者直接引用；另外一种是能被外部参与者直接引用，如“查询可用条
26、目”。图 7-6 有关系用例的订单输入子系统的例子用例图与事件表的比较先前已经说明了用例图和事件表包含了许多同样的信息。你或许会问自己一个问题： “ 如果它们是一样的，那么我需要开发两个模型吗？”事实上，给出的项目中，你都不必开发两个模型。 一些分析员更倾向于以列举用例作为开始，而不是以事件作为开始，并且分析员会直接建立用例图(正如下面一节将要讨论的)。事件表可用做传统结构化开发的基础，也可用做面向对象开发的基础。作为一个具有良好教育和专业技术的人员，你必须精通两种技术。然而， 在两个模型之间存在着差异。首先，每一个模型的观点有些细微的不同。事件表通常注意商业过程。它通过标识商业事件，以及这些
27、事件的外部、初始化源的信息来关注商业过程。 外部的源是引起商业事件初始化的原因，并且它们能从自动系统中轻松的移除。另一方面， 用例图强调了自动系统。因为它只与自动系统相连，所以参与者与自动系统有联系并且不一定是商业事件的发起者。两种模型之间的另一点差别体现在标识临时事件和状态事件时。由于用例通常被外部参与者初始化， 所以如果分析员不仔细标识每一个事件，那么临时事件和状态事件经常被忽略。如果用例定义的太窄，那么这将成为用例建模的一个缺陷。如第14 章中所讨论的那样，在线系统菜单常常包括用于表示事件表中临时事件的菜单选项，以便这样的事件能够被用户触发并且作为纯粹的临时事件。因此，建议为每个临时事件
28、和状态事件创建用例以确保这些需名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 22 页 - - - - - - - - - 求不被忽略。需要记住很重要的一点：分析员会同时完成事件表和用例图，并会不断更新事件和用例。这种精炼的过程发生在调整每个用例范围的平衡中。例如， 在开发事件表的过程中，添加新用户和更新用户信息两个事件已经被标识出来。从系统的观点出发，这两个商业事件的用例几乎是一样的， 因为它们都包含了更新用户文件。可以定义一个单独的用例来支持这两个商业事件， 这个用例
29、可以命名为维护客户账户信息。如果满足如下3 个标准， 则定义一个用例来支持多个商业事件是很常见的。首先，本质上相同的处理发生在自动系统内部；第二，本质上相同的信息被更新；第三，本质上相同的信息从事件中输入和输出。在商业事件对单一、简单的数据文件或表进行基本的文件维护时，这些条件常常能够满足。有时单一事件可以触发非常复杂的处理需求，这将使系统活动分解为两个用例以更好地管理系统复杂性，使其变得更加有意义。在所有的这些观点中，必须修改事件表和用例图以使模型保持同步。7.3.3开发用例图如前所述， 开发用例图有两个切入点。如果分析员分析了商业过程并创建了事件表，那么他 (她)就会用事件表标识用例。仔细
30、分析表中的每一个事件以确定系统为了支持这事件、发起这个事件的参与者，以及由于这个事件而触发的其他用例所执行的处理。当一个模型转向另一个更详细的模型的时候通常需要不断的精炼，所以仔细分析事件和事表是非常重要的。在额外地分析过后，开发人员可以将一个单一的事件标识为用例，如所需的处理很相似，可以把几个事件组合成一个单独的用例；或者如果处理很复杂，也以标识多个用例。多个用例的标识通常发生在它们有关系和两个用例从一个大用例分解得到的时候，或者发生在一个附加用例按照通用子程序的方式被定义的时候，前面已经讨论过这种情况了。如图 7-4 显示的客户支持子系统就是使用这种方法进行开发的。你会注意到， 图中定义的
31、绝大多数用例直接来自图5-15 的事件表。事实上，图7-4 中用例的名称来自事件表的活动/用例栏中的描述。这一部分有两个例外。由于临时事件通常可以手动发起，所以我们要为每个临时用例使用标识外部参与者的选项。另一个例外是事件号为13 的“客户修改账户信息”事件。在这个实例中，用例定义扩展到和所有维护客户信息相关的场景中。同样，这个用例被命名为维护客户账户信息，这指的是添加、 更新和删除。 这些都是用例对事件表进行提炼更新的例子。如果没有创建事件表，那么开发用例图的另一个切入点是标识使用系统的参与者和它们执行的功能。为了做到这一点，你必须记住两个前提条件。首先，为一个自动系统创建自动化边界，这样你
32、标识的参与者就能和这个系统进行联系(通过手 )。第二，你必须假定拥有完美的技术，确定用例是基于商业事件而不是像登录系统一样的技术活动。只有给出这些前提，你才 可以通过以下两步的迭代来开发用例图。1标识系统的参与者。注意，参与者通常由用户扮演。不能把参与者列成如Bob，或Hendricks 先生这样的形式，而应该标识出这些人所处的特定的角色。记住，在一个系统中同一个人可以有多个特定的角色。这些角色可以是订单职员、部门经理、审计员等。理解和辨识系统所有可能使用的角色是重要的。其他的系统也可以成为系统的参与者。2一旦确定了参与者的角色，下一步就要开发在使用自动系统中这些角色的目标表。目标指参与者执行
33、完成一些商业功能的任务。目标通常是类似营销、接受用户反馈或者订单发货这样的任务。这些目标是能够被标识和描述的工作单元。在目标完成时， 系统数据在一段时间内是不会改变的。这两个步骤常常应用于项目组成员和用户的集体讨论中，并没什么捷径可以用来发或标名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 22 页 - - - - - - - - - 识用例。 即使所关注的是自动系统，还是需要对商业过程进行细致的分析，以理解参与者使用系统的所有方式。在标识事件表中的事件或者直接开发用例图
34、的时候，还会用到另外一种很重要的技术，称为 CRUD 分析，这种分析方法将标识后的用例与域模型类图进行比较。分析员在初始化用例图之后做CRUD 分析，这主要是为了复查他们的工作。CRUD 代表创 (Create)、 读取(Read或报告 Report)、更新 (Update)和删除 (Delete)。CRUD 分析在 6 章里首次被提及，它是一种和信息工程 (IE)紧密联系的技术。CRUD 分析需要类图中每个类都有足够的用例来支持创建新对象实例、 读取或者报告这些对象、更新这些对象产且在许多例子中删除对象实例。用例不应该命名为创建或者更新，但是潜在的处理可以添加新的实例或者更新已存在的实例。例
35、如，一个名为“记录支付情况”的用例并没有清楚地指出一个新的支付对象被创建，但是用例的详细描述却指出这个对象被创建了。用例“产生新订单” 可以创建订单条目对象和更新库存条目对象。 在其他的案例中，许多用例以维护两字开头命名，以覆盖常规的添加、更新、读取和删除操作。为了做 CRUD 分析，只须看一下在域模型类图中的每个类并确定在用例图中有用例来支持所有适合该应用的CRUD 功能。但是，切记在集成系统中，一个系统可能负责创建对象，而另外的系统可以只更新它们。CRUD 分析方法提供了一种交叉检验方法(不是最终的解决方案 )，并且提供了确认重要的系统集成需求的机会，这些需求如果不用这种方法逆行分析可能就
36、不是明显了。7.3.4用例详细描述先前已经指出，创建用例图只是用例分析的一个组成部分。用例图帮助标识各种处理，这些处理由用户执行并且要得到新系统的支持。精细的系统开发往往需要我们了解较低层的细节。 为了创建易于理解的能满足用户需要的系统，我们必须理解所有详细描述的步骤。内部，为了完成商业过程，用例要包括完整的步骤顺序。例如： 通常商业步骤的变化存在于单一用例中。“产生新订单”用例，根据哪些参与者调用用例，将有不同的活动流。订单职员通过电话来建立新订单的过程与用户通过Internet 建立订单的过程是非常不同的。对“产生新订单”用例， 每个活动流都是一个有效的顺序。这些 不同的活动流称为场景，或
37、者有时也称为 用例实例 。所以，场景是对在一个用例中的一套内部活动的识别和描述。它代表通过用例的惟一路径。场景或者用例实例：用例中步骤的一个特定顺序。一个用例可以有几个不同的场景。用例可以使用各种图表和描述来精心制作。一个比较有用的记录用例的绘图技术是活动图(在以后讨论 )。活动图最开始是在第4 章介绍的。许多分析员更喜欢写出叙述性的用例描述，这样就可以根据需求在不同的细节层次上进行描述。通常可以按三个独立的详细描述等级进行用例描述：简单描述、中间描述和完全展开描述。根据分析员的需求不同，书写描述和活动图可以用于任何组合。简单描述简单描述被用于非常简单的用例，特别是当要开发的系统是一个很小并且
38、易于理解的应用时。一个简单的用例通常有单一的场景和即使有也很少的异常条件。用于和活动图进行连接的简单描述为简单用例提供了可靠的描述。图 7-7 提供了“产生新订单” 用例的简单描述。通常， 像“产生新订单”这样的用例是很复杂的，它们可以用中间或者完全展开描述进行描述。我们将举例说明这些描述。图 7-7 创建新订单的简单描述中间描述名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 9 页，共 22 页 - - - - - - - - - 中间等级的用例描述扩展了简单描述，它包括了用例的内
39、部活动流。如果有多个场景，那么其中的每个活动流都被单独的进行描述。如果它们需要，还可以记录下其他条件。图7-8 和图 7-9 显示了记录两个场景的中间描述，这两个场景分别是订单职员创建电单和客户建立网上订单。这两个场景在先前是作为“产生新订单”用例的工作流而被。注意，每个场景都描述了用户和系统所需要执行的处理，同时还列出了异常条件。每一步都进行了标号，以方便阅读。在许多方法中，这种描述都是结构化英语，它包括了字、决策和循环体。图 7-8 产生新订单电话订购场景的中间描述图 7-9 产生新订单Web 订购场景的中间描述完全展开描述完全展开描述是记录用例的最正式的方法。虽然它要花费较多的工作在这个
40、层次上定义所有的组件， 但它仍然是描述用例内部活动流的首选方法。软件开发人员面临的一个主要困难是开发人员要不断理解用户的需要。但是如果你创建了一个完全展开用例描述，那么你就更有可能完全理解商业过程和系统支持它们的方式。图7-10 是“产生新订单”用例的电话订购场景的完全展开用例描述，图7-11 显示了同一用例的Web 订购场景。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 10 页，共 22 页 - - - - - - - - - 图 7-10 产生新订单电话订购场景的完全展开描述
41、图 7-11 创建新订单的网上订购场景的完全展开图图 7-10 和图 7-11 也可以记录其他场景和用例的完全展开描述的标准模板。第1 行和第行用于标识所记录用例的内部用例和场景。在较大或较正式的项目中，还可以给用例添加带有扩展名的惟一标识符，以标识特定的场景。有时候还会加上制作该表格的系统开发人员的姓名。第 3 行标识了发起该用例的触发器。这个触发器和第5 章介绍的事件表中的描述完全一样。可以从两个角度描述触发器。一方面是标识触发处理的商业事件。例如：在图7-10 产生新订单的过程开始于客户致电给RMO 。这个角度是以外部世界为中心。另一个角是引起名师资料总结 - - -精品资料欢迎下载 -
42、 - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 11 页，共 22 页 - - - - - - - - - 自动系统首先认识到用例已经开始运作的活动。从第二个角度来看，触发器可以述为 “职员输入新订单请求” 。由于新系统开发过程中该阶段的目标是理解用户需要，因此较好的角度是第一个标识触发整个处理的外部事件。第 4 行是用例和场景的简单描述。分析员只须复制他们先前建立的简单描述。第 5行标识了一个或多个参与者。这一行复制了用例图本身所包含的一些信息。第 6 行标识了其他用例和它们与该用例相关联的方式，例如：我们前面讨论的关系。另
43、外，还可以确定一些更复杂的关系。但重要的一点是，给其他用例添加交叉引用，以更全面地理解用户需求的各个方面。系统相关者一行标识了相关的人员，而不是特定的参与者。他们可以是那些没有调用但是对用例结果感兴趣的用户。例如，在图7-10 和图 7-11 中，没有人在市场部创建新单，但是他们要对输入的订单做统计分析。所以， 市场部人员对获取和存储在产生新订单中的数据非常感兴趣。 对系统开发人员来说，考虑所有的系统相关者是确保他们能充分理善系统需求的至关重要的一步。下面两行提供了用例执行前后系统状态的临界信息，分别称为前提条件和后续条件。前提条件表明在用例开始之前什么条件必须为真。换句话说，它标识了用例开始
44、执行前系状态，包括必须已经存在什么样的对象、哪些信息必须可用，甚至用例开始之前参与是什么样的状况等。前提条件 ：在用例初始化之前必须为真的一组条件。后续条件 ：在用例执行完成时必须为真的一组条件。后续条件标识了在用例结束的时候什么必须为真。描述前提条件的同样条款也适用于描述后续条件。例如，在更新各种财务账目的用例处理中，一些账目是收支不平衡的。所这种用例的后续条件就是更新所有账目并使收支平衡。模板中的最后两行描述了用例活动流的详细信息。在这个例子中， 我们采用了两列的形式，这些说明标识了参与者运行的步骤和系统需要的响应。项目编号有助于标步骤的顺序。有些开发人员更喜欢用一列说明，和中间等级类似。
45、最后一行描述了可动和异常情况。异常情况的编号同样有助于将异常与用例描述中的特定步骤联系在一起 。活动图描述记录用例场景的另外一种方式是使用活动图。第 4 章中已经介绍了作为工作流图的一种形式的活动图。你可以很容易理解活动图用于记录商业过程工作流。活动图是一个标准的UML 图。在这个实例中，活动图将作为一种有效的技术用于记录每个用例场景的活动流。图 7-12 和图 7-13 是记录了图7-10 和图 7-11 两个场景的活动图。在图7-12 中，客户和订单职员交互，轮流使用系统。由于用例的目的是说明参与者(带有手 )和系统之间的相互作用，所以图中包含了订单职员和计算机系统的活动图矩形区。然而，
46、为了帮助理解场景的所有活动流，触发这一步骤的客户也要包括进来。注意，在图7-12 中客户矩形区是一个可选的附加项， 它有助于理解整个工作流。在图 7-13 中用户是与计算机系统相互作用的参与者，所以只需要两个矩形区来描述场景中的步骤。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 12 页，共 22 页 - - - - - - - - - 图 7-12 电话订购场景的活动图活动图可以用来支持任何等级的用例描述。和你看到的一样，活动图和完全展开描述中的两列描述非常相似。创建活动图的好处
47、在于它更加形象，并且有助于用户和开发人员 一起工作来完整地记录用例。快速浏览图7-12 和图 7-13， “产生新订单” 的两个场景截然不同。尽管这些场景执行可样的基本功能， 但是界面和选项集合完全不同。活动图还有助于开发系统顺序图，这些在 下一节将会介绍。图 7-13 Web 订购场景的活动图7.4 确定输入和输出系统顺序图在面向对象方法中，信息流是通过向参与者或者内部对象来回发送消息而形成的。系统顺序图 (SSD)用于描述进出自动系统的信息流，所以一个系统顺序流记录输入和输出并且标识了参与者和系统之间的交互。系统顺序图是交互图的一种。在接下来的章节及实际的工业实践中，我们常常互换地使用术语
48、交互和消息。交互图 ：用于显示对象间的相互作用的协作图或顺序图。7.4.1系统顺序图符号图 7-14 显示了一个普通的系统顺序图。和用例图一样，用线条画代表和系统交互的参与者人 (或角色 )。在用例图中，参与者“使用”系统，但是在系统顺序图中参与者如何通过输入数据和获得输出数据来和系统进行交互才是重点。这两个图有着相同的思想，不同的描述等级。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 13 页，共 22 页 - - - - - - - - - 标记为：系统的方框是一个代表整个自动
49、系统的对象。在系统顺序图和所有的交互图中，分析员使用对象符号代替类符号。对象符号表明方框指的是一个独立的对象而不是所有类似对象的类。 这个符号很简单，它由带下划线的对象名称和一个矩形框组成。带下划 线的对象名称前面的冒号是可选的，但习惯上常常使用，它是对象符号的一部分。在一个交互图中，消息通过独立的对象(而不是类 )进行发送和接收。在一个系统顺序图中，只有代表整个系统的对象才会被 包括进来 。处在参与者和 :系统下面竖直的虚线称为生命线。在整个系统顺序图期间内，生命线 或者对象生命线仅仅是这个对象(参与者或对象 )的扩展。在代表消息的生命线之间的箭头代表了参与者和系统的发送和接收。每个箭头都有
50、一个起点和终点。消息的起点就是箭头尾部的生命线所指示的发送它的参与者或对象。同样的， 消息的目标参与者或对象是由箭头所指向的生命线指示的。 生命线的目的就是指示参与者和对象发送和接收消息的顺序。 在这个图中，消息的读取顺序是从顶部到底部的。生命线或者对象生命线：在顺序图中的一个对象下面的竖线，用以显示这个对象的时间阶段。标有记号的消息用来描述消息的目的，以及被发送的任何输入数据。消息标记的语法有几个选项，图7-14 显示了最简单的形式。记住，箭头用来代表消息和输入数据。但是术语消息 在这里到底是什么意思？在顺序图中， 消息被认为是在目的对象上调用的一种活动，它更像一条命令语句。注意，在图7-1