正版新书]UML2面向对象分析与设计(第2版)/谭火彬谭火彬97873025

第1章 上升到面向对象
1.1 从素数问题看面向对象
1.1.1 问题的提出
1.1.2 传统的结构化解决方案
1.1.3 面向对象的解决方案
1.1.4 从结构化到面向对象
1.2 面向对象技术基础
1.2.1 面向对象技术的发展历史
1.2.2 面向对象技术的优势
1.3 对象和类
1.3.1 对象
1.3.2 类
1.4 面向对象技术的相关原则
1.4.1 抽象
1.4.2 封装
1.4.3 分解
1.4.4 泛化
1.4.5 多态
1.4.6 分层
1.4.7 复用
1.5 建立面向对象思维
1.5.1 引入案例
1.5.2 用面向对象思维分析案例
1.5.3 利用UML表达分析结果
1.6 练习题
第2章 可视化建模技术
2.1 可视化建模基础
2.1.1 建模的目的
2.1.2 建模的基本原则
2.2 统一建模语言
2.2.1 选择UML
2.2.2 UML统一历程
2.3 UML 2组成结构
2.3.1 UML语法结构
2.3.2 UML语义结构
2.4 UML 2概念模型
2.4.1 构造块
2.4.2 通用机制
2.4.3 架构
2.5 应用UML 2建模
2.5.1 用例图
2.5.2 活动图
2.5.3 类图、对象图、包图和组合结构图
2.5.4 顺序图
2.5.5 交互概览图
2.5.6 通信图
2.5.7 时间图
2.5.8 状态机图
2.5.9 构件图和部署图
2.6 练习题

第3章业务建模软件开发的最终目标是为了满足业务需求，以帮助用户解决业务中的问题。早期的软件开发方法并没有充分意识到业务的重要性，而随着RUP中将业务建模作为软件开发的第一个工作流，业务建模的重要性也日益被人们所认识；良好的业务建模可以为软件的成功开发奠定坚实的基础。UML主要用于软件系统的分析和设计，但是其强大的扩展机制使得利用UML进行业务建模成为可能。本章从基本的业务建模概念入手，重点介绍利用UML进行业务建模的全过程。
本章目标业务建模是项目的起源，是描述项目开发的依据，还是后续需求建模的基础。通过对本章的学习，读者能够了解业务建模的概念，掌握利用用例技术进行业务建模的方法和实践过程，并对从业务模型转换到系统模型的过程有一定的了解。
主要内容（1）UML与软件工程过程的区别和联系。
（2）业务建模的基本概念：业务参与者、业务用例、业务工人、业务实体和业务用例实现。
（3）基于用例技术的业务建模方法和实践：业务用例图和业务活动图。
（4）从业务模型到系统模型的映射。
3.1分析设计过程简介为了能够有效地进行软件系统的分析和设计，需要将各个技术层次合理地、适时地结合在一起，这就需要遵循一定的过程，也就是软件工程过程所要求的内容。虽然UML提供了有效地表达分析和设计思想的手段，但是如何合理地、适时地利用这些手段去进行分析和设计是UML所不能提供的。因此，从本质上来讲，UML仅仅是一种标准的表达形式，它提供了统一的符号体系，使人们摆脱了符号之间的困扰，从而可以专心面对业务问题。而用好UML除了需要掌握面向对象分析和设计的基本原则和方法外，还需要借助一定的软件开发过程。
与UML配套的软件工程过程很多，其中应用最广的还是与UML同出一门的Rational统一过程（RationalUnifiedProcess，RUP）。Rational统一过程是一个庞大的、应用于企业应用开发的工程过程，它提供了如何在开发组织中严格分配任务和职责的方法，其目标是按照预先制定的时间计划和经费预算，开发高质量的软件产品以满足用户的需求，其核心思想是用例驱动、以架构为中心的迭代增量开发。本书并不是一本介绍过程的书，但是为了能够有效地进行分析和设计，还必须采纳一定的过程，而RUP过程本身过于复杂，并不符合本书的学习要求。因此本书在借鉴RUP思想的基础上，定义了重点关注分析和设计的简化过程，这样既保证能够按照有效的过程进行分析和设计，又不会因为过于复杂的过程而影响到对分析和设计方法的学习。
3.1.1UML分析设计过程解析本书所讨论的UML分析设计过程起始于业务建模，接下来是需求建模、用例分析、架构设计和构件设计，最后终止于代码实现。本书的后续内容将按照这个过程展开。当然，这个过程并不是完整的软件开发过程（如缺少计划、管理、测试、维护等方面的内容），这里重点关注的是分析和设计。此外，书中对于这些阶段的描述是线性的，但在实际应用过程中它应该是一个迭代增量的过程。这个过程如图31所示，框内的图示是相关阶段所要使用的主要的UML图例。
图31UML分析设计过程（1）业务建模：采用软件建模方法分析和理解待开发的业务，描述业务流程；其目标是认识业务本质，该业务本质是后续用例建模的基础。此部分内容对应本书第3章。
（2）用例建模：采用UML用例建模技术描述软件需求，该需求模型将为后续用例分析提供输入。此部分内容对应本书第4章。
（3）用例分析：采用UML用例分析技术分析软件需求，建立软件系统的分析模型。此部分内容对应本书第5章。
（4）架构设计：在系统的全局范围内，以分析模型为基础，设计系统的架构。此部分内容对应本书第8章（第6章和第7章是设计的基础理论）。
（5）构件设计：根据架构设计的成果，将分析模型细化，设计系统构件的实现细节。此部分内容对应本书第9章。
（6）代码实现：将系统构件映射到目标语言上。此部分内容对应本书第10章。
3.1.2结合过程应用UMLUML和过程本身并不存在严格的对应关系，它们之间是一种多对多的关系；不同的过程、不同的阶段对UML使用有不同的要求。如RUP方法中提供了4个阶段9个工作流的二维过程模式，但是在某个特定的阶段、对于特定的工作流采用何种UML模型进行建模，这些在RUP中并没有做强制的规定。不过RUP却提供了很多最佳实践，这些最佳实践提醒用户只有合理地利用UML，才能发挥RUP方法的特点。
关于UML和过程的关系可以采用一个形象的比喻：过程是一种“战术”，它决定了项目团队如何去合理地安排资源、进度或人员；而UML则是一种“作战技能”，是团队成员的使能技术，再好的战术缺少合适的人去执行也是空谈。这两者之间是相辅相成的。
本书在定义UML分析设计过程时，给读者提供了一些可参考的最佳实践。正如图31所示，每个阶段都有不同的UML模型去支撑。在业务阶段，采用扩展的业务用例模型进行业务建模，采用活动模型进行业务流程的细化。在用例建模阶段，采用用例模型进行需求建模，采用用例文档来详述需求。在用例分析阶段，采用扩展的类模型表示静态关系，采用交互模型表示动态交互。在设计阶段则采用包、构件、部署等模型表示软件架构，采用静态类图、动态交互图、状态模型来进行详细的类设计。在代码实现阶段，则根据设计类图、设计交互图生成代码。这些模型的细节和使用方式将在本书的后续章节中详细展开讨论。
图31给出的是一个相对完整的在系统开发过程中使用UML的示意图。在项目实践过程中，团队可以根据自身的实际情况逐步引入不同的UML模型。早期，可以只在需求阶段采用用例建模技术，后续过程仍沿用以前传统的方式进行分析和设计。在此基础上，下一步可以利用UML类图进行静态分析和设计。最后，可以更进一步使用UML交互模型进行动态分析和设计，从而使用UML模型覆盖项目的全生命周期。 3.2业务建模基础
与以前大多数软件应用程序是由程序设计奇才设计出来的不同，现在的软件系统正日益成为人们日常生活中的基本工具。这些软件系统是按照实际业务中的工作方式去设计和运行的，而不是按照程序员规定的模式去工作。这就要求应用程序能非常直观地适合于使用它的组织或个人，为了更好地达到这一需求，新的方法则要求在进行软件系统开发之前或者同时要力图了解业务领域，而这个过程就是业务建模所要达到的目标。
业务建模是一种建模方法的集合，目的是对现有业务进行分析和理解，从而建立相应的业务模型。这一过程不仅有助于开发人员理解业务本质，而且这些模型将作为后续软件系统模型的输入。具体的工作包括对业务流程建模、对业务组织建模、改进业务流程、领域建模等方面。
业务建模的基本思想是使用软件建模技术来描述企业管理和业务所涉及的对象和要素，以及它们的属性、行为和彼此关系。这有助于理解在业务领域中描述的事物是如何与软件领域中的事物相联系的，从而建立业务模型和系统模型之间的对应关系，以保证系统模型是能够满足业务需求的。
当然，对于一个软件工程师来说，业务建模只是辅助环节，并不是每个项目、每个软件人员都需要去实施该过程。当开发人员对所要处理的业务非常熟悉，而且业务本身没有改进的必要时，就没有必要进行业务建模。当然，在很多软件项目开发的初期，通过业务建模可以帮助开发团队理解业务现状，从而能够更好地发现软件需求，因此业务建模在软件开发中还是具有非常重要的意义的。RUP中是这样描述业务建模目标的。
◆理解将要实施系统的目标组织结构和动态特性。
◆理解当前目标组织中的问题，并明确改进的潜力。
◆确保客户、最终用户和开发人员就目标组织有统一的理解。
◆获取用于支持目标组织的系统需求。
为了达到这些目标，业务建模的主要任务就是：拟定目标组织对新系统的远景（Vision），并根据该远景来定义业务模型中组织的过程、角色和职责。而该业务模型包括业务用例模型和业务对象模型。
3.3业务用例模型业务用例模型（BusinessUseCaseModel）是说明业务预期功能的模型，是业务建模阶段的核心模型，用于确定组织的各个角色和可交付工件。业务用例模型由业务用例和业务参与者构成，主要目的是说明客户和合作伙伴是如何开展业务的。为了完成业务用例模型的建模，需要从以下3个方面来实施。
（1）识别业务参与者（BusinessActor）：为了充分理解业务目的，必须了解业务与谁进行交互，即业务为谁提供服务；而这个“谁”就是业务参与者，是业务活动的服务对象。
（2）识别业务用例（BusinessUseCase）：业务用例是对组织内部业务流程的说明，它定义一组业务用例实例，其中每个实例都是业务执行的一个操作序列，对于特定的业务参与者来说，这些操作序列所产生的结果是可见的。
（3）描述业务用例：作为业务流程的封装体，业务用例是一个抽象的表示，业务建模过程还需要详细描述业务用例的内部流程，并将它用软件建模的方法表示出来。
3.3.1识别业务参与者业务参与者代表了与业务有关的角色，此角色由业务环境中的某个人或物扮演。识别业务参与者的关键在于明确业务边界：业务参与者是在业务边界之外的、与业务进行交互的人或组织，它接受业务所提供的服务，并关注业务所产生的结果。
在实际业务建模过程中，业务参与者可以是与业务进行交互的任何个人、组织、公司或计算机，我们可以从以下类别中查找参与者。
（1）客户：接受目标业务所提供服务的客户，这是最常见的一类业务参与者。例如在银行业务中，储户接受银行所提供的存款、取款等服务，他们即为银行业务的业务参与者。
（2）供应商：为目标业务提供资源和服务的第三方组织。例如在银行业务中，为银行提供安保服务的保安公司。
（3）合作伙伴：与目标业务存在各种合作关系的第三方组织。
（4）潜在客户（“市场”）：目前还没有接受业务所提供的服务、但将来可能会接受服务的用户，业务可能需要面向这类用户提供一些“市场”方面的服务，以将潜在客户发展为最终客户。
（5）政府：目标业务可能会受到地方政府或法律、政策等约束，这些约束将会对业务本身造成影响，此时这些约束也可能会成为业务参与者。
（6）在业务中未建模部分的人或组织：业务建模可以针对整个业务，也可以只针对某部分关键业务，当那些没有建模的部分与已建模部分之间存在交互时，它们也会成为目标业务模型的业务参与者。
可以看出，虽然业务参与者通常都是由某个人类角色（如客户、潜在客户）来承担的，但是在某些情况下，组织或其他事物（如供应商、未建模部分）也可以担任业务参与者的角色。例如对于某公司工资管理业务的建模，由于工资的最终发放需要通过银行来完成，因此，此时发放工资业务与“银行”之间存在交互，而“银行”作为合作伙伴也成为该业务用例的业务参与者。
此外，还需要注意的是，业务参与者表示的是特定类型的业务用户，而不是实际的某个用户。在现实业务中，某个业务参与者可由该业务的多个实际用户来担任，即他们充当同一个角色的不同实例。此外，对于某个特定的用户也可能承担多个不同的角色，这意味着同一个人可以代表不同业务参与者的实例。
关于业务参与者的命名也需要注意，业务参与者应该有一个能反映其在业务中所承担角色的名称，这个名称应该适用于承担该角色的任何个人或外部事物。
识别业务参与者并不是一个单一的过程，很多情况下可能还需要与后续的识别业务用例、业务对象建模结合起来综合考虑，可以从以下几个方面来评判本阶段是否成功地完成。
（1）所有业务参与者都已找到。业务与外部环境交互时所涉及的一切（包括人员、外部事物等）都用业务参与者进行了建模。需要注意的是，该动作需要在找到并详细说明每一个业务用例后，才能得到确认。
（2）每个业务参与者都代表了某个业务外的实体，即是对业务外的某些对象进行建模。
（3）每个人类业务参与者都代表一个角色，而与具体的某个人无关，不同的人均可承担该角色。因此，一般情况下，能为每个角色指定至少两个可担任该角色的人员；否则，就有可能是为某个人（而非角色）进行了建模。当然，在某些情况下，只能找到一个可以担任某个角色的人员。
（4）每个业务参与者都至少要涉及一个业务用例。如果某个业务参与者没有和任何一个业务用例进行交互，则它就是多余的，没有任何存在的价值，应将其删除。
（5）一个特定的业务参与者不会以多种完全不同的方式与业务进行交互。如果某个业务参与者以多种完全不同的方式进行交互，那么很可能需要将该业务参与者按照角色进行分解，定义多个不同的业务参与者，让每个业务参与者只代表一种不同的角色。
（6）每个业务参与者都有一个明确的名称和简要的说明。业务参与者的名称应该代表其在业务中所承担的角色，并能被业务建模团队之外的人员理解。