3 统一建模语言（UML）（下）

3.3.5 对象图

类图（Class Diagram）用于描述系统内各个对象的相关类及这些类之间的静态关系，是软件的整体蓝图。对象图（Object Diagram）则用于描述系统运行时各类对象的静态结构和行为以及它们之间的关系。图3-22给出了档案管理系统中教师归档时的对象图。

图3-22 对象图

对象和类的图形化表示类似，其区别在于对象图需要通过"++对象名:类名++"的形式表达出对象归属的类，注意要带下划线，根据实际表达的场景可选择是否定义对象名。

3.3.6 包图

包图（Package Diagram）用于描述系统中模块或组件的层次结构及其依赖关系。它通过"包"（Package）这一容器元素组织模型中的类、接口、用例等元素，展示系统的模块化设计。包图常用于软件架构设计阶段，帮助开发团队理解系统的高层结构。

包图由包和包之间的关系构成。

1、包（Package）：表示一组逻辑相关的模型元素（如类、接口、子包等），图3-23给出了包的几种图形化表示，包用带标签的文件夹图标（上下两个连接在一起的矩形）表示。包的内容包括包名和所包含的模块（类、接口、用例、其他包或图等）。

包名用于唯一标识当前包，可以放在上面（如图3-23（1））也可以放在下面（如图3-23（2））；
包含的模块可以是类、接口、用例、其他包或图等。
模块名称前面的符号用于表示该模块的可见性（对于外部的可访问特性），其含义与类图中属性或方法的可见性定义相同。

图3-23 包的图形化表示

2、包之间的关系主要包括合并、依赖和泛化，而依赖关系又可分为默认依赖（<<use>>）、导入依赖（<<import>>）、访问依赖（<<access>>）和跟踪依赖（<<trace>>）。表3-3对比说明了这些关系。

表3-3 包之间的关系

|----|------|----------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 关系类型 || 图形化表示 | 说明 |
| 合并 || | UML2中新增的一种有向关系，表示源包的内容作为目标包的扩展，具体特点包括： * 功能扩展：目标包通过合并源包的内容获得更完整的功能或结构； * 单向性：关系方向从源包指向目标包； * 覆盖机制：若存在同名元素，优先使用目标包中的元素。 |
| 泛化 || | 表示一个包继承了另一个包的内容，同时又补充自己增加的内容。箭头指向被继承的一方。 |
| 依赖 | 默认依赖 | | 表示客户包中的元素以某种方式使用提供者的公共元素。箭头指向提供者包。 |
| 依赖 | 导入依赖 | | 表示提供者包的命名空间将被添加到客户包的命名空间中，客户包中的元素也能够访问提供者包的所有公共元素。箭头指向提供者包。 **注：**导入依赖关系是最普遍的包依赖类型，它将使命名空间合并，当提供者包中的元素具有与客户包中的元素相同的名称时，将会导致命名空间的冲突。这也意味着，当客户包的元素引用提供者包的元素时，将无需使用全称，只需使用元素名称即可。 |
| 依赖 | 访问依赖 | | 客户包通过使用完整的路径名来访问提供者包的公共元素。箭头指向提供者包。 |
| 依赖 | 跟踪依赖 | | 表示一个包到另一个包的历史演变关系，常用于体现系统架构的演化过程，帮助理解不同版本或迭代中的包结构变化。继承关系可理解为一种特殊的跟踪依赖。箭头指向历史包。 |

如图3-24所示，包图可用于展示软件系统的分层结构。在档案管理系统中，系统高层分为3层,其中界面层负责用户交互；数据访问层负责访问底层信息；业务逻辑层负责协调界面层和数据访问层间的访问逻辑。此外，对于数据访问层内部，又可以采用分包的方式进行逻辑划分。

图3-24 包图

3.3.7 构件图

构件图（Component Diagram）用于描述系统内部构件的组织结构、依赖关系以及接口交互。它展示系统的物理或逻辑构件，以及它们之间的连接方式，属于软件架构设计工具。构件图的核心要素包括：

1、构件（Component）：表示系统的可替换模块，通常对应一个功能单元（如库、文件、服务等）。如图3-25（1）所示，在UML 1.x中构件用一个带有两个小矩形的矩形框表示，矩形框内标注构件的名称。

2、接口（Interface）：用于定义构件对外提供的服务或依赖的服务。在UML2中对构件进行了扩展，引入了供给接口（provided interfaces）和需求接口（required interfaces）的概念，分别使用圆形连接线和半圆形连接线，如图3-25（2）和（3）所示。在UML1.x中已经引入接口的概念，但并没有做这样的区分，而是特指供给接口。

3-25 构件的图形化表示

3、端口（Port）：为构件指定一个交互点，通过该交互点，构件可以与环境、其他构件或其内部构件进行通信，通信通过由端口支持的接口来描述。一个构件可以有多个端口。如图3-26所示， "档案管理"构件提供了3个端口，用跨立在构件边界上的小方块来表示，每个端口都可以有一个名字。

图3-26 构件的端口

注：（1）端口无法独立存在，必须依附于构件；（2）简单端口是具有一个需求或供给接口的端口；而一个复杂端口，可以有几个需求或供给接口。

4、连接器（Connector）：构件之间通过端口进行连接，而连接器用于描述端口之间的连接形式。具体包括：

直接连接器：两个构件通过端口直接连接；
接口连接器：两个构件通过端口包含的接口进行连接；
委派连接器：构件的外部端口与构件内部的子构件端口进行连接。

以"档案管理"构件为例，图3-27给出了各类端口连接器。

图3-27 连接器

5、依赖关系（Dependency）：用虚线箭头表示一个构件需要另一个构件的功能。图3-28给出了档案管理系统内部构件之间的依赖关系。

图3-28 构件的依赖关系

3.3.8 部署图

部署图（Deployment Diagram），也称为实施图，它用于描述系统硬件的物理拓扑结构及在此结构上执行的软件。部署图可以显示计算节点的拓扑结构和通信路径、节点上运行的软件组件。

在UML中，部署图显示了系统的硬件和安装在硬件上的软件，以及用于连接异构计算机之间的中间件。部署图通常被认为是一个网络图或者物理架构图。

表3-4给出了部署图的主要建模元素。

表3-4 部署图的主要建模元素

|---------------------------------|----------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 元素 | 图形符号 | 备注 |
| 节点（Node） | | 节点是代表计算机资源的物理元素，可以是硬件也可以是运行其上的软件系统。常见的节点类型包括：（1）<<device>>：设备，如数据库服务器（Database Server）、WEB服务器（Web Server）等；（2）<<excutionEnvironment>>：执行环境，如操作系统、数据库管理系统、J2EE开发环境等。执行环境可以部署到指定设备节点上。 |
| 通信路径（Communication Path） | | 节点之间的连线表示系统之间进行交互的通信路径。 |
| 制品/工件（Artifact） | | 用于表示可以独立部署的软件单元，需要部署到物理节点上进行运行。一般是以文件的形式存在的，如模型文件、源文件、编译文件、可执行文件、脚本文件、数据库文件等。 |
| 部署规范（Deployment Specification） | | 是对部署的说明，作为一种特殊的制品，表示的是被部署的制品的依赖关系。 |
| 部署（Deploy） | | 部署指的是把各个制品放置到运行节点上工作的过程。通常把部署作为制品与节点间的一种依赖关系，虚线指向节点。也可以采用下面两种方式来表示部署过程：（1）把制品直接放置到要部署的节点中；（2）以列表的形式将制品的名字写到节点内，表示制品将部署到该节点上。 |
| 依赖（Dependency） | | 用于表示制品之间的使用关系，箭头指向被使用的制品。 **注：**制品之间除了依赖关系外，还有包含、关联关系，其表示方法与类之间的关系（参见3.3.4.4）类似。 |
| 承载（Manifestation） | | 用于表示制品和模型之间的关系，一般表示制品来自哪个构件。箭头指向承载该制品的模型（构件）。 |

图3-29给出了档案管理系统的部署图。

图3-29 部署图

3.3.9 顺序图

顺序图（Sequence Diagram）是一种详细描述对象之间动态交互过程的图形文档，它关注对象之间消息传递的时间顺序。如图3-30所示，顺序图将交互关系表示为一张二维图。

横轴代表了参与交互的各个独立的对象；
纵轴是时间轴，以生命线的形式从各个对象出发向下延伸；
沿时间方向按时间递增顺序列出各个对象所发出和接收的消息。

（续）

图3-30 顺序图

顺序图的核心要素还包括：

（1）对象（Object）：顺序图中对象的符号和对象图中对象所用的符号一样。图3-30给出的顺序图中，在对象名称的上方给出了对象类型的图形化表示。通常情况下，我们采用图3-31所示的形式来表示对象。

图3-31 顺序图中对象的表示形式及示例

类型标识符用于标识对象的类型，其中actor表示参与者、boundary表示边界类、control表示控制类、entity表示实体类。对象名可以省略。

（2）生命线（LifeLine）：每个对象都有自己的生命线，生命线在顺序图中表示为从对象图标向下延伸的一条虚线，表示对象在特定时间内的存在，如果对象生命期结束，则用注销符号表示。

（3）消息（Message）：消息是对象之间某种形式的通信，它可以激发某个操作、发送信号或导致目标对象的创建或撤销。如表3-5所示，在UML中，消息使用箭头来表示，箭头的类型表示了消息的类型。

表3-5 顺序图中的消息类型

|--------|----------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------|
| 类型 | 图形符号 | 备注 |
| 同步消息 | | 调用消息的发送者把控制传递给消息的接收者，然后停止活动，等待消息接收者执行其某种操作后返回控制。由于发送者等待接收者，这种消息被称作同步消息。通常，同步消息会隐含包含来自接收者的一个返回消息。 |
| 异步消息 | | 消息发送后，发送者继续操作，不等待，常用于并发。 |
| 返回消息 | | 表示消息的返回。一般同步消息的返回不需画出，直接隐含，而异步返回则需要明确表示出来。 |
| 自反消息 | | 一个对象将一个消息发送给它本身。在自反消息里，消息的发送方和接收方是同一个对象。自反消息一般是同步消息 |

（4）对象的激活（Activation）与去激活：通常来说，对象的初始状态为去激活状态，即空闲状态，不做什么事情，但它是存在的，等待新的消息激活它。当有消息将对象激活时，该对象的生命线被拓宽为用矩形表示的激活条（也被称为控制期），对象在激活条的顶部被激活，在完成自己的工作后被去激活。

（5）交互片段（Interaction Frame）: 是UML2.x中新增的顺序图建模元素，用一个边框包围顺序图中的部分交互，并在其左上角添加一个间隔区。间隔区中，有操作符来描述交互片段的类型。图3-30就包含了一个"alt"类型的交互片段。表3-6给出了常用的交互片段类型。

表3-6 常用的交互片段类型

|--------------|----------------------------------------------------------------------------------------------------------------------------------------------|
| 类型（操作符） | 作用 |
| 引用（ref） | 用于引用另一张顺序图，片段内容标注要引用的顺序图名称（代号），如图3-32所示。 |
| 循环（loop） | 循环执行片段内的交互过程，直至满足结束条件。结束条件通过loop操作符规定的循环次数及监护条件决定，即：loop(最小次数，最大次数)+监护条件。loop操作符的最大次数可以不定义；如果不定义最小次数和最大次数，则表示无限次循环；如果定义了监护条件，则当监护条件不满足时结束循环。 |
| 单分支（opt） | 包含在此片段中的交互只有在判断条件为真时才执行。 |
| 多分支（alt） | 包含多个区域，不同的区域用虚线分割，每一个区域设置一个监护条件，代表一个分支。根据判断条件，选择片段中的一个区域中的交互执行。 |
| 并发（par） | 包含多个区域，不同的区域用虚线分割，各个区域的交互并发执行。 |
| 中断（break） | 定义一个含有监护条件的子片段。如果监护条件为"真"则执行子片段，而且不执行子片段后面的其他交互；如果监护条件为"假"，那么就按正常流程执行。 |
| 临界（critical） | 类似于操作系统中的加锁，以防止死锁的产生。处于"临界区域"的子片段，不能与生命线上的其它区域中的任何事件交错。 |

**注：**上表给出了常见的片段类型，在实际应用中，片段之间可以嵌套使用。如一个单分支（opt）片段中可以包含循环（loop）片段。

图3-32 顺序图中的引用（ref）片段

3.3.10 状态机图

状态机图（State Machine Diagram），即UML1.x中的状态图（Statechart Diagram），用于描述了一个对象在其生命周期内所经历的各种状态，以及引起对象状态变化的原因。状态机图的主要建模元素如表3-7所示。

表3-7 状态机图的主要建模元素

图3-33给出了"档案"对象在归档过程中的状态变化过程。

图3-33 状态机图

**注：**状态机图强调的是状态的变化，在实际使用过程中切勿和流程图相混淆。

3.3.11 活动图

活动图（Activity Diagram）主要用于描述某一方法、机制或用例的内部行为，它将业务流程或其他计算的结构展示为一系列的控制流和数据流。活动图的主要作用包括：

描述一个操作执行过程中所完成的工作，说明角色、工作流、组织和对象是如何工作的；
对用例的工作流进行建模，说明用例的实例是如何执行动作以及如何改变对象状态；
帮助相关人员理解业务处理过程；
描述复杂过程的算法。

活动图的主要建模元素如表3-8所示。

表3-8 活动图的主要建模元素

|--------|----------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 元素 | 图形符号 | 备注 |
| 起点 | | 活动图的起始点。 |
| 终点 | | 表示活动图的结束。 |
| 动作状态 | | 也被称为简单活动，是构造活动图的最小单位，它用于表示原子动作或操作的执行状态。 * 动作的原子性决定了动作状态不能被分解为更小的部分，且动作一旦开始就不能被中断，直到执行完毕； * 动作状态没有内部转换或内部活动，不能由事件触发，但可以有转入，转入可以是对象流或动作流； * 动作状态包含至少一个转出； * 与状态机图中的状态不同，它不能有入口动作和出口动作。 |
| 活动状态 | | 活动状态可以理解为软件中的一个子过程，它可以分解成其它子活动或动作状态，也可以被中断。如果只包括一个动作，则它就是动作状态。因此，可以认为动作状态是活动状态的一种特殊情形。对于较为复杂的活动状态，可以为其单独绘制活动图。 |
| 控制流 | | 用于表示活动之间的先后顺序。 |
| 对象流 | | 将对象（状态）作为输入或输出的控制流。在UML1.x中为虚线箭头。 * 如果箭头从活动指向对象流状态，则表示输出，即动作对对象施加了影响，影响包括创建、修改、撤销等； * 如果箭头从对象流状态指向活动，则表示输入，即动作使用了对象流所指向的对象流状态。 |
| 对象 | | 活动图中的对象表示的不仅仅是对象自身，还表示了对象作为过程中的一个状态存在，因此也可以将这种对象称为对象流状态，用以和普通对象相区分。 * 在活动图中，一个对象可以由多个动作操作。对象可以是一个转换的目的，以及一个互动完成转换的源。同一个对象可以不止一次地出现，它的每一次出现都表明该对象处于生存期的不同时间点； * 一个对象流状态必须与它所表示的参数和结果的类型匹配。如果它是一个操作的输入，则必须与参数的类型匹配。反之，如果它是一个操作的输出，则必须与结果的类型匹配； * 对象名称下方的中括号中为状态名，表明对象此时的状态，可以省略。 |
| 决策点 | | 用于根据监护条件选择不同的控制流（执行路径）。 |
| 分叉与汇合 | | 用于表示在同一时刻，有两个或两个以上的并发控制流的情况。分叉把一个控制流分解成两个或多个并发的控制流。汇合表示两个或多个并发控制流在此取得同步。 |
| 泳道/分区 | | 将活动或动作按执行的对象进行分组，每一组使用泳道来隔开。在描述活动或动作的控制流转移情况的同时，说明这些活动或动作是由谁来完成的。 * 每个泳道都以对象的名称或活动者的名称来命名，这些名称在一个活动图中是唯一的； * 活动或动作位于泳道内，不可以跨越泳道，而活动的转移可以跨越泳道。 |

注：（1）活动图与状态机图：活动图可以算是状态机图的一个变种，并且活动图的符号与状态机图的符号非常相似，有时会让人混淆。活动图的主要目的是描述动作及对象的改变结果，而状态机图则是以状态的概念描述对象、子系统、系统在生命周期中的各种行为。活动图中的状态转换不需要任何触发事件。活动图中的动作可以放在泳道中，而状态机图则不可以。

（2）活动图与流程图：读者在初看活动图的时候可能会认为这只是流程图的一种，但活动图包括了逻辑判断、分支甚至并发，其表达能力远高于流程图；流程图仅仅展示一个固定的过程，而活动图可以展示并发和控制分支，并且可以对活动与活动之间信息的流动进行建模。

图3-34给出了活动图的例子。

图3-34 活动图

参考资料：

UML组件图/构件图-CSDN博客
- https://zhuanlan.zhihu.com/p/680701842
- 理解UML部署图：软件部署与环境配置-CSDN博客
- UML学习笔记------顺序图（时序图）-CSDN博客
- UML-状态机图（状态图）_uml状态图-CSDN博客
- UML-活动图（转） - 奋斗终生 - 博客园
- ++https://blog.csdn.net/zhousenshan/article/details/142290714++