UML精准入门指南2-电子发烧友网

五、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）
关系：是整体与部分的关系，但部分不能离开整体而单独存在。同生同灭。如公司和部门是组合关系，没有公司就不存在部门。
箭头和连线：带实心(黑色实心：要死一起死，良心是黑的)菱形的实线，菱形指向整体。
适用场景：类图。