面向對象分析.docVIP

业务用例与系统用例 一个业务用例描述的是业务过程——而不是软件系统过程。 业务用例：业务过程是描述这个业务的具体工作流的；一次涉众与实现业务目标的业务之间的交互。它可能包含手工和自动化的过程，也可能发生在一个长期的时间段中。系统用例的设计范围就是这个计算机系统设计的范围。它是一个系统参与者，与计算机系统一起实现一个目标。系统用例就是参与者如何与计算机技术相联系，而不是业务过程。业务用例着重于业务操作。它们表示实现业务目标的业务中的具体工作流。业务过程可能涉及手工和自动过程，并且在一段长期的时间内进行。 系统用例着重于要设计的软件系统。参与者如何与软件系统进行交互？我们在系统用例说明中书写的事件流应该足够详细，从而用作编写系统测试脚本的出发点。 UML 业务模型包括两个模型：用例视图（Use-Case View）中的业务用例模型和逻辑视图（Logical View）中的业务分析模型。 1 业务用例模型中的主图是业务用例图。您还可以随意加入表示单个业务用例的 UML 活动图，来图形化地显示工作流过程。业务分析模型描述了通过业务角色和业务实体的交互来实现业务用例。它用作业务角色和业务实体需要如何相关联，以及它们需要如何协作，来执行业务用例的抽象。业务分析模型中有三种类型的 UML 图，如图 3 所示：类（Class）、时序（Sequence）和通信（Communication）图。 图 3：业务分析模型图 业务分析模型中的主要的图是时序图。您手工地创建显示出业务参与者、业务角色，和业务实体如何交互执行业务用例的时序图。时序图显示出以时间时序安排的对象交互。特别是，它显示出参与交互的对象，以及消息交换的顺序。 通信图是以前在 UML 1.x 中所称的协作图（Collaboration diagram），它描述了对象之间交互的模式，通过对象间的链接和发送给对方的消息来展示参与交互的对象。通信图和时序图都显示出交互，但它们强调了不同的方面。时序图清楚地显示出时间顺序，但没有明确地显示出对象关系。通信图清楚地显示出对象关系，但必须从顺序号那儿获得时间顺序。 两个图都显示出同样的行为，但方式不同。我个人喜欢时序图，因为它通常比较容易读懂。您还可以使用参与类的视图（View of Participating Classes，VOPC）来显示协作执行业务用例的业务参与者、业务角色和业务实体的静态视图。 用例模型往往描述的是用户对整个项目提出的所有功能的集合。对于每个功能，我们通常使用用例，并在用例描述中描述该用例的主要流程。因此用例模型描述的通常是需求分析中动态的部分。 领域模型往往描述的是用户提出的整个问题空间中的各种事物及它们的相互关系，因此领域模型描述的是需求分析中静态部分。领域模型虽然不是完全，但却是以此为基础，形成软件系统中的软件类。为什么不是“完全”呢？因为软件系统中需要什么类，是软件系统功能的要求。假如在领域模型中的某个对象，它的确是用户问题空间中的事物，但是它在软件系统功能的要求中使用不到它，那么在软件系统中它同样不能成为一个软件类。当我们设计好了软件类以后，我们就将根据用例模型，为所有的软件类分配职责，确定它们各自应具有的行为及相互的协作。每个软件类应当如何分配它们的职责，也就是说用例模型中描述的各个功能应当交给哪个或哪些软件类去实现，这个工作就是对软件类的职责分配。完成这个工作的阶段主要在对象分析的中前期。 第1章 UML简介1.1 什么是UML1.1.1 UML是如何诞生的1.1.2 UML是专有产品吗1.1.3 UML是否只适用于面向对象的开发1.1.4 UML是一种方法学吗1.1.5 UML当前的进展状况如何1.2 什么是模型1.2.1 为什么要建模1.2.2 为什么要使用UML建模1.2.3 用UML可以建立什么模型1.2.4谁应该建模1.3 什么是图1.3.1 UML中包括哪些图1.3.2 图和模型有什么区别1.4 术语1.5 小结1.6 复习题1.7 参考文献第2章 业务模型2.1 什么是业务模型2.2 为什么要对业务建模2.3 是否应该对全部业务建模2.4 UML如何帮助我改进业务2.5 如何使用UML对业务建模2.6 UML业务用例模型2.6.1 业务用例图2.6.2 活动图2.7 业务分析模型2.8 进一步考虑的主题2.9 术语2.10 小结2.11 复习题2.12 参考文献第3章 需求建模3.1 什么是需求3.2 需求为什么令人费神3.3 需求有哪些类型3.4 如何使用UML对需求建模3.4.1 用例的回顾3.4.2 用例的更多知识3.4.3 顺序图的回顾3.4.4 顺序图的更多知识3.5 进一步考虑的主题3