2.1.3 如何使用UML

使用UML建模通常被作为软件开发过程的重要组成部分。在软件开发过程中，可以使用适当的UML建模工具来定义目标系统中的需求、交互和各种元素。

下面，给出一个比较常见的UML开发过程。

（1）建立系统的业务流程模型

业务流程模型可用于定义业务系统中发生的高层次的业务活动和流程，并为用例模型提供基础。在通常情况下，业务流程模型包含的内容往往多于目标软件系统将要实现的内容。业务流程建模可以有效地确定和控制系统的目标和范围，从而避免需求不足或过多的情况发生。

（2）建立用例模型，并明确用例模型到业务流程模型之间的链接

建立用例模型可以确切地定义系统应提供的功能，但还需要进一步明确这些功能所实现的业务需求。当添加一个用例时，都要创建一个从适当的业务流程到这个用例的可追溯的链接。这个链接可清楚地说明新系统提供的功能满足了业务流程模型中描述的哪一项业务需求。它还可以确保用例模型中的每一个用例都是符合明确的业务需求。

（3）细化用例——包括每个用例的需求、约束、复杂度、注释和场景

细化用例是为了准确地描述用例的作用、执行方式以及执行时需要遵守的约束，确保用例能够满足业务流程需求。包括定义每个用例的系统测试以及每个用例的合格标准，还包括定义一些用户验收测试脚本，还要定义用户将如何测试这个功能及其验收标准。

（4）构建系统的领域模型

领域模型是描述业务用例实现的对象模型，它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。从业务流程模型的输入和输出以及用例的细节出发，构建系统的领域模型（高层业务对象模型）。这些模型描述了新系统的构成元素、元素之间交互的方式以及用户执行用例场景所需要的接口。

通过领域模型建模，可以帮助我们获得目标系统的概念模型，为下一步的系统设计奠定基础。

（5）由领域模型、用户界面模型和场景图（Scenarios Diagram）构建系统的类模型

类模型是对系统中对象的状态和行为的精确描述（Specification）。建模时，可以使用继承和聚合将模型中的类抽象为类（或对象）的层次结构，将场景中对象之间的消息映射成类的操作。对于每个类，还可以定义单元测试和集成测试以测试类的功能以及类与其相关类和组件的之间的交互。

（6）组件模型建模

随着建模过程的继续，类模型还有可能被分解成一些离散的包和组件。组件表示一个可部署的软件块，它收集一个或多个类的行为和数据，并向其服务的其他用户公开严格的接口。因此，建立组件模型可以定义类的逻辑包装。

还可以为每个组件定义集成测试确定组件的接口是否满足规范或与其他软件元素的关系。

（7）记录额外需求

与开发过程同步，对于那些在分析或设计过程中发现的额外的系统需求也应该捕获并记录下来。例如，系统的非功能需求、性能要求、安全性要求、与职责有关的需求和新发布的计划等。在模型中收集这些信息，并随着模型的成熟而不断更新系统的需求。

（8）建立部署模型

部署模型是一种专门用于定义系统的物理体系结构的UML模型。部署模型的建模工作可以在项目的早期就开始进行，而不必等到项目的后期。部署模型中，与物理部署相关的内容包括构成系统的硬件、操作系统、网络功能、接口和支持软件等元素的技术指标相关的设计决策，它们将对新系统在可靠性、灾难恢复、备份与支持等方面产生重要的影响。

（9）将模型的离散部分分配给一个或多个开发人员，以构建整个系统

在用例驱动的开发方法中，用例会分配给开发团队，让开发团队构建用于执行该用例所需的边界对象、业务逻辑对象、实体对象（数据库表）和相关组件。同时，当每个用例被构建完成之后，应该伴随完成的内容还应包括相关的单元测试、集成测试和系统测试。

（10）跟踪测试中出现的缺陷

在软件开发过程中，要及时跟踪测试过程中发现的各种缺陷，不同的测试缺陷往往针对不同的模型元素。例如，系统测试缺陷所针对的模型元素通常是对应的用例，单元测试缺陷针对的模型元素可能是用例中的某个角色，例如用例中的某个类、接口或类中的某个方法等。跟踪这些缺陷，有利于跟踪和控制相关模型元素的变更，以便控制和管理项目中可能出现的“范围蠕变”。

（11）随着工作进展不断更新和完善模型

在开发过程中，需要不断评估变更和模型改进对后续工作的影响。使用迭代方法完成在离散块中进行的设计，评估当前的构建、下一步的需求和在开发过程的任何发现。

（12）提交经过测试的软件，生成产品环境

对于分阶段交付的项目来说，提交可能会分成多个阶段进行。

上述过程只是一个概括性的过程，实际的开发过程可能会有所不同，但这个描述仅仅说明一个应用UML开发软件的基本过程。