五、UML 的适用场景

UML 既可以描述某个问题领域，也可以表达构思中的软件设计，还可以描述已经完成的软件实现。

它适用于面向对象分析设计的整个过程。这个过程可以分为三个阶段，如下图。

第一个阶段是通过建模将现实世界转为业务模型。业务模型真实映射了参与者（业务活动的驱动者）在现实世界的行为。

从图里可以看到，现实世界映射到业务模型后，是使用 参与者 和 用例 这两个 UML 的核心元素表达的。参与者作为一个特定事件的驱动者，用例则描述了这个驱动者的业务目标。文章后边也会提到这两个元素。

第二个阶段是对业务模型概念化，建立适合计算机理解和实现的模型，也就是概念模型，或者叫分析模型。分析模型向上映射了原始需求，向下为计算机实现规定了一种高层次的抽象，是一种过渡模型。

现实世界千差万别的业务，都用 边界、控制和实体这几个核心元素来描述，同时也引入了 包、组件 这些与现实世界毫不相干的概念做包装。

第三个阶段是对概念模型实例化，得到相对详细的设计模型。

在设计模型中，概念模型中的边界类可以被转化为操作界面或者系统接口；控制类可以被转化为计算程序或控制程序，例如工作流、算法体等；实体类可以转化为数据库表、XML 文档或者其他带有持久化特征的类。

同样的概念模型会因为选择不同而得到不同的设计模型。比如技术选型上使用不同的编程语言，不同的中间件就会得到不同的设计。

为什么需要这一道转换呢？

因为“边界”、“控制”、“实体”这些对象化的概念，虽然是计算机可以理解的，但它并不是真正的对象实例，也就是说它们并不是可执行代码，概念模型只是纸上谈兵。真正的对象世界行为是由 Java 类、C++ 类、JSP 等这些可执行代码构成的。

换句话说，设计模型是概念模型在特定环境和条件下的实例化，实例化后的对象行为执行了概念模型描述的那些信息。

以下是面向对象分析设计的完整过程，它表达了现实世界是怎么通过 UML 映射到对象世界的。

六、UML 的组成结构

前面花了比较大的篇幅分析了 UML 的定位和适用场景，目的是帮助读者建立对 UML 整体系统性的认知，而不是过早的陷入 UML 的使用细节里。我们要应用一项技术或工具，不能单纯的因为它的酷炫或者说业界都在用所以我们要用，而应该结合自己的使用场景以及技术或工具的特点，来确认这项技术或工具究竟是不是我们需要的。

在读者了解 UML 在面向对象分析设计领域优秀的特性之后，我们再来看看 UML 的一些细节。

凡是语言，都会存在基本词汇和语法。

那么对应到 UML 里，基本词汇就是核心元素，语法就是核心视图。

UML 的组成结构如下图：

6.1 核心元素

我们先介绍核心元素，下图是大纲。

6.1.1 版型

版型：也称「类型」或「构造型」。是对 UML 元素基础定义的扩展，在元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。

比如，我们前边提到的「边界类」、「实体类」、「控制类」都是类的版型。

6.1.2 参与者

参与者定位：事件的第一驱动者，也是系统的服务方。比如你在电商网站购物，你就是参与者。

6.1.3 用例

用例定位：系统执行的一系列操作，并生成参与者可以观察的值。比如你在电商网站交易，会生成在线订单，用户下单就是一个用例。

用例版型：

• 业务用例：用于需求阶段业务领域建模。与计算机系统建模无关，比如下单可以不依赖在线服务，而只是线下签署协议。业务建模的目标是让需求人员和客户能够达成共识。
• 业务用例实现：业务用例的一种实现方式，一个业务用例可以有多种实现方式。比如下单后的支付，可以用现金，也可以银行卡转账，还可以第三方支付。

• 概念用例：用于获取业务模型中的关键概念，分析出核心业务结构。业务架构就是概念建模阶段产生，同时为系统建模阶段提供重要指导。比如用户下单这个用例，可以从实现过程中获得一些核心业务，并把它们展现出来。

• 系统用例：用于定义系统范围、获取功能性需求。也就是我们常挂在嘴边的用例。像业务用例中提到的线下签约的方式，就不会纳入到系统用例中，但如果是电子签约的话，就可以成为系统用例了。
• 系统用例实现：系统用例的一种实现方式，一个系统用例可以有多种实现方式。比如下单后的支付，可以接入微信支付接口，也可以接入支付宝支付接口。

你会发现，同是用例的版型，业务用例与系统用例的区别就在于业务用例是客户业务视角，系统用例是系统视角。

6.1.4 边界

边界定位：用于业务建模和系统建模阶段的分析，保证分析粒度在一定的范围内，不会扩散。

比如一个电商网站按领域职责作为边界，会有店铺域、商品域、会员域、交易域、支付域和营销域等。各域只负责域内的事情，就能够减少混乱紧耦合的局面。

一个好的分析和设计如同一筐带壳的鸡蛋，清清爽爽；一个差的设计如同一堆打碎了壳的鸡蛋，粘粘糊糊。壳，是好坏的关键。

6.1.5 业务实体

业务实体定位：它代表参与者执行业务用例时所处理或使用的事物，特别用于在业务建模阶段建立领域模型。业务实体是类（class）的一种版型。

业务实体的结构：包含属性和方法。属性用来保存业务实体特征，方法用来访问业务实体。比如一台电视，把它看成一个业务实体的话，它的属性有运行状态和音量，它的方法就是遥控器，我们可以开、关、调声音，但是我们不可以试图让它飞起来——因为它没有这样的方法。

6.1.6 包

包定位：容纳并为其他 UML 元素分类。比如 Java 后端经常会提供 jar 包给接入方使用。

6.1.7 分析类

分析类定位：用于代表系统中主要的职责簇，由此产生系统的设计类和子系统。

• 边界类：用于对系统外部环境和内部运作之间的交互进行建模。比如现实世界的窗户，计算机世界的网页。
• 控制类：用于对用例特有的控制行为进行建模。比如显示逻辑和业务逻辑通过控制层分离的 MVC 架构。
• 实体类：用于对需要存储的信息和相关行为进行建模。源于业务模型中的业务实体。

分析类的抽象层次较高，比设计和实现要稳定很多，因此方便维护，也更容易获得一个稳定架构来指导整个软件的开发。

6.1.8 设计类

设计类定位：是系统实施中一个或多个对象的抽象，由此映射到实现代码，依赖于实施语言。

设计类结构：

• 类型：对对象某一方面特征的归纳和抽象。映射到编码中的 class。
• 属性：对象特征。映射到编码中的 field。
• 方法：访问对象属性的唯一途径。映射到编码中的 method。

6.1.9 关系

关系定位：抽象出对象之间的联系，让对象构成某个特定的结构。

关系分为以下几种：

• 关联（association）
• 关系：是一种拥有的关系，即一个类知道另一个类的属性和方法；比如老师与学生可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
• 箭头和连线：带普通箭头的实心线，指向被拥有者。
• 适用场景：类图。
• 依赖（dependency）
• 关系：是一种使用的关系，即一个类的实现需要另一个类的协助，是一种弱关系，随运行场景变化。比如削苹果时，人依赖于刀，脱离了这个场景，依赖关系就不存在了。
• 箭头和连线：带箭头的虚线，指向被使用者。
• 适用场景：类图。
• 泛化（generalization）
• 关系：是一种继承的关系，比如猫是动物的一种。
• 箭头和连线：带三角的实线，箭头指向父类。
• 适用场景：类图。
• 实现（realization）
• 关系：是一种实现的关系，比如用例和用例实现的关系，接口与实现类的关系。
• 箭头和连线：带三角的虚线，箭头指向用例实现或接口类。
• 适用场景：用例图，类图。
• 聚合（aggregation）
• 关系：是整体与部分的关系，且部分可以离开整体而单独存在。生命周期各自独立。如车和轮胎是聚合关系，轮胎离开车仍然可以存在。
• 箭头和连线：带空心菱形的实线，菱形指向整体。
• 适用场景：类图。
• 组合（composition）
• 关系：是整体与部分的关系，但部分不能离开整体而单独存在。同生同灭。如公司和部门是组合关系，没有公司就不存在部门。
• 箭头和连线：带实心(黑色实心：要死一起死，良心是黑的)菱形的实线，菱形指向整体。
• 适用场景：类图。

关联关系和依赖关系的区别：

• 关联关系是静态天然的联系，依赖关系是动态临时的联系。

此外还有只用于用例中的关系：

• 扩展（extends）
• 关系：用于在用例模型中说明向基本用例中的某个扩展点插入扩展用例。
• 箭头和连线：带箭头的虚线加版型<>。
• 特点：用例可选。
• 包含（include）
• 关系：用于在用例模型中说明在执行基本用例的用例实例过程中插入的行为段。
• 箭头和连线：带箭头的虚线加版型<>。
• 特点：用例必需。

6.1.10 组件

组件定位：实现特定功能的逻辑代码模块。比如分布式应用架构下，将业务目标拆成多个功能，每个功能作为组件独立部署。这样这些组件也能被其他场景复用。

6.1.11 节点

节点定位：表示应用程序的部署单元。比如分布式应用的环境中，服务器或设备会有很多，就需要通过节点来体现物理部署的情况。