软件设计：UML 模型图总结

1. 相关链接

参考教程：

https://sparxsystems.com/resources/tutorials/

https://sparxsystems.com/enterprise_architect_user_guide/15.2/model_domains/whatisuml.html

Unified Modeling Language (UML) description, UML diagram examples, tutorials and reference for all types of UML diagrams, etc.

绘图网站 presson：ProcessOn思维导图流程图-在线画思维导图流程图_在线作图实时协作

2. 软件建模基本概念

在不同的领域和场景下有不同的软件建模方法，其各自的建模思想和采用的建模工具也不尽相同，如：结构化方法 (Structured Method)，面向对象方法（Object Oriented Method），基于构件方法（Component Based Development），面向服务方法（Service Oriented Method），面向方面方法（Aspect Oriented Method），模型驱动方法（Model Driven Development），形式化方法 (Formal Method)。本文主要关注面向对象方法建模。

面向对象建模是一种软件设计方法，它将现实世界中的事物抽象成为对象，通过定义对象的属性和行为来描述它们。面向对象建模的目的是为了更好地理解和描述软件系统中的各种对象之间的关系和交互。

面向对象建模是在软件开发前，通过对问题领域进行分析和抽象，将问题领域中的实体、属性、关系等抽象成类、属性、方法等概念，建立起面向对象的模型。这个过程是软件开发的前置工作，它为面向对象开发（Object-Oriented Programming，简称OOP）提供了基础。面向对象开发是在面向对象建模的基础上，根据模型设计和实现软件系统。面向对象开发是一种程序设计范式，它以对象作为程序的基本单元，通过封装、继承和多态等机制来组织和管理代码。在面向对象的程序设计中，每个对象都有自己的属性和方法，对象之间可以互相交互和调用对方的方法，从而实现程序的功能。

面向对象建模的主要工具是 UML（Unified Modeling Language 统一建模语言），它是面向对象开发中一种通用的图形化建模语言，它提供了一组符号和标准化的图形表示法，用于描述软件系统的各个方面，包括对象、类、接口、关系等等。UML 具有面向对象，可视化，表示能力强，独立于过程，独立于程序设计语言，易于掌握使用的特点。

UML 图一般分为 9 种，每一种图都有它的特定的应用场景，根据其用途和性质可分为静态和动态两大类，静态图包括：用例图、类图、对象图、组件图和部署图，用于描述软件系统的静态结构组成；动态图包括：顺序图、状态图、活动图和通信图，用于描述软件系统的动态活动过程。

软件建模基本概念包括以下几个方面：

需求分析：确定软件系统的需求，包括功能需求、性能需求、安全需求等。
概念设计：在需求分析的基础上，设计软件系统基本构架，含架构模式、组件设计等。
详细设计：在概念设计的基础上，进一步细化软件系统设计，含类设计、接口设计等。
编码实现：根据详细设计，编写软件代码实现功能。
测试与验证：对软件进行测试和验证，包括单元测试、集成测试、系统测试等。
部署与维护：将软件部署到目标环境中，并进行维护和升级。

模型是对系统某个特征进行的抽象的、简化的表示，就好比一个三维物体在二维平面上的投影，每一面只能描述这个三维物体一面的特征，因此，需要从不同的视角，使用不同的模型去表示一个系统。

软件开发过程中，不同的阶段需要用到不同的 UML 图：

3. 常用 UML 模型图

通过使用 UML 模型图，开发人员可以更好地理解和描述系统的不同方面，从而更好地设计和开发软件系统。以一个图书馆系统为例，在这个系统中，借书者需要进行查询个人信息、查询图书信息、借阅图书和返还图书等操作；图书管理员负责借书处理和还书处理等操作；系统管理员涉及读者信息管理，图书信息管理，系统状态维护等操作。构建这个系统时，可以应用不同视角建立软件模型：从结构化视角建立类图，从行为视角建立顺序图、活动图、状态图等。

3.1 用例图 Use Case Diagrams：展示系统的核心功能以及与其交互的用户

用例图是一种静态模型，用来描述谁要使用系统，以及使用该系统可以做什么。用例图是需求分析的产物，能够帮助开发人员可视化地了解系统的功能。

3.1.1 参与者 Actors

参与者不特指人，是指系统以外，提供或接收系统信息的人或系统，是与系统有交互的人或事物。通常将参与者绘制为一个命名的火柴人，或者一个带有«actor»关键字的类矩形。

参与者可以继承自其他参与者（父类），如下图所示：

3.1.2 用例 Use Case

用例是系统中的一个功能单元。用例需要从参与者希望系统提供的功能中提取，而不是从系统自身的角度来提取，满足参与者的需求的用例才是好用例。用例图中，通常用椭圆表示用例。

用例与参与者可以用一条带有箭头【可选】的实线连接，箭头对应信息传递的方向。如下图，表示参与者 “Customer” 使用 “Withdraw” 用例。

用例规约 Use Case Definition

用例图只是在总体上大致描述了系统所能提供的各种服务，让开发者对系统的功能有一个总体的认识，除此之外，还需要描述每一个用例的详细信息，这些信息包含在用例规约中。应该避免这样一种误解：认为由参与者和用例构成的用例图就是用例模型，用例模型是由用例图和每一个用例的详细描述（用例规约）组成的。对于用例规约的内容，通常没有硬性规定的格式，但一些重要的内容是必须要写进去的，包括：

命令和描述 Name and description：用例通常被命名为动词短语，并给出简短的非正式的文本描述。
需求 Requirements：需求指用例必须提供给用户的功能，是一个契约或承诺，表示用例将执行某些操作或为系统提供一些价值。
约束 Constraints：约束是用例操作的条件或限制，包括前置条件、后置条件和不变条件。前提条件指用例执行前需要满足的条件，后置条件指用例执行之后系统应满足的条件，不变条件指在整个用例执行过程中为真的条件。
场景 Scenarios & 场景流程图 Scenario diagrams：场景是对用例执行期间发生的事件流（一系列活动步骤）的正式描述，包括正常场景（基本流）和异常场景（备选流），通常以文本形式描述，为了更加清晰地描述事件流，也可以选择使用状态图、活动图等来辅助说明。

3.1.3 元素之间的关系

元素之间的关系

参与者之间或

用例之间

泛化 Generalization

用一个三角箭头的实线表示，箭头指向父用例（父参与者）

参与者间的泛化关系：可以把某些角色的共同行为提取出来作为通用的行为。角色实质上也是类，拥有与类相同的关系描述，角色之间的泛化关系就是通常理解的继承关系。

用例间的泛化关系：子用例继承了父用例所有的结果、行为和关系，子用例是父用例的一种特殊形式，子用例还可以添加、覆盖、改变继承的行为。

参与者与用例

关联 Association

用带有可选箭头的连接线表示

表示参与者与用例之间的交互，通信途径，任何一方都可发送或接受消息。箭头指向：指向消息接收方。

用例之间

包含 Include

用带箭头的虚线段 + << include >>字样来表示，箭头指向被包含的用例

用例可能包含其他用例的功能，作为其正常执行过程的一部分，包含关系通常假设每次运行基本路径时都会调用任何包含的用例。例如，银行系统中，提款用例 <Withdraw> 需要包含识别卡信息用例 <Card Identification>。

1. 如果多个用例用到同一段的行为，则可以把这段共同的行为抽象成一个用例，然后让其他用例来包含这一用例。

2. 当某一个用例的功能过多、事件流过于复杂时，可以把某一段事件流抽象成一个被包含的用例，以达到简化描述的目的。

用例之间

扩展 Extend

用带箭头的虚线段 + << extend >> 字样来表示，箭头指向基础用例

在特殊条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例（Extension）。原有的用例叫做基础用例（Base），从扩展用例到基础用例的关系就是扩展关系。

例如，如果在修改特定类型的客户订单之前，用户必须获得更高权限的批准，那么 <get approval> 用例可以选择性地扩展常规的 <Modify order> 用例。

1. 一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使用。

扩展关系与包含关系的区别：

在包含关系中，当基础用例执行完后，被包含用例是一定会被执行的；在扩展关系中，基础用例的执行并不一定会涉及到扩展用例，扩展用例只有在满足一定条件下才会被执行。
对于包含关系，基础用例在没有被包含用例的情况下是不完整的；对于扩展关系，即使没有扩展用例，基础用例本身也是完整的。。

基础用例是“身份验证”，扩展用例是”修改密码“。在一般情况下，只需要执行”身份验证“用例即可。但是如果登录用户想修改密码，这时不能执行用例的常规动作，这时，不必直接修改”身份验证“用例的代码，可以在基础用例”身份验证“中增加插入点，登录用户想修改密码时，就执行扩展用例”修改密码“。

3.1.4 系统的边界

边界内表示系统的组成部分，边界外表示系统外部。在用例图中，系统边界用方框+系统名称来表示，通常将用例显示为系统内部，而参与者显示为系统外部。

3.1.5 总结：用例图示例

3.2 类图 Class Diagrams：描述系统中各个类的内部结构，以及类间的关系（继承、实现、依赖、关联、聚合、组合）

3.2.1 类 Class

类通常表示为一个分三格的长方形，第一格是类名，第二格是成员变量（属性），第三格是成员函数（方法）。

属性格式： 可见性名称:类型 [ = 缺省值]
行为格式： 可见性名词（参数列表） [ : 返回类型]
可见性： + public，- private，# protected

Visibility Notation

Visibility notations indicate the access level of attributes and methods. Common visibility notations include:

+ for public (visible to all classes)
- for private (visible only within the class)
# for protected (visible to subclasses)
~ for package or default visibility (visible to classes in the same package)

3.2.2 类与类的关系

类与类的关系

关联关系

Association

关联关系表示一类对象与另一类对象之间有联系，体现在程序中，例如，类A的实例是类B的属性。

一般关联关系又可以分为单向关联，双向关联，自关联。

单向关联用一个带箭头的实线表示；

双向关联用一个不带箭头的实线表示；

自关联用一个带有箭头且指向自身的实线表示。

多重性关联（Multiolicity）表示两个关联对象在数量上的对应关系，在关联直线上用一个数字或一个数字范围表示。

聚合关系

Aggregation

聚合关系用于描述某个对象由更小的组件组成 (Aggregations are used to depict elements which are made up of smaller components.) 。

聚合关系是关联关系的一种，是强关联关系，是整体和部分之间的关系。

聚合关系常通过成员对象来实现，成员对象是整体对象的一部分，但成员对象可以脱离整体对象而独立存在。程序中整体的类往往在加载的时候实例化部分的类。

整体和部分并不止是针对1对多，1对1的场景，如果表示整体包含部分，也可以用聚合描述。

聚合关系用带空心菱形的实线表示，菱形指向整体。

组合关系

Composition

组合关系是一种更强烈的聚合关系。

在组合关系中，整体对象可以控制部分对象的生命周期，一旦整体对象不存在，部分对象也将不存在，部分对象不能脱离整体对象而存在。

组合关系用带实心菱形的实线表示，菱形指向整体。

依赖关系

Dependence

依赖关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。

在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。

关联、聚合、组合、依赖，这4种关系的强弱程度依次为：

组合 > 聚合 > 关联 > 依赖

依赖关系使用带箭头的虚线来表示。

泛化（继承）关系

Inheritance

泛化（继承）关系是对象之间引用耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类的关系，即继承关系。

泛化关系用带空心三角箭头的实线表示，箭头指向父类。

实现关系

Realisation

实现关系是接口与实现类之间的关系。

类中的操作实现了接口中所生命的所有抽象操作。

实现关系用带空心三角箭头的虚线表示，箭头指向接口。

关联、聚合、组合，三种关系最大的区别：

1. 关联关系：对象之间不存在从属关系。

2. 聚合关系：整体和部分是可以分离的，整体和部分都可以拥有自己的生命周期。

3. 组合关系：整体和部分是不可以分离的，整体的生命周期结束，意味着部分的生命周期结束。

下图说明了聚合关系和组合关系的区别：地址簿由多个联系人和联系人分组组成，联系人分组是联系人的虚拟分组，一个联系人可以包含在多个分组中。如果删除通讯录，所有的联系人和联系人分组也会被删除，但如果删除一个联系人分组，不会删除任何联系人。

3.2.3 总结：类图示例

3.3 对象图 object diagram：对象图可以看作是类图的一个实例，是系统在某个时间点的详细状态的快照。

对象是是类的实例。对象图是系统在特定时刻的静态视图，可以将其想象为运行的系统在特定时刻的快照。

对象图对理解类图很有用，对象图与类图在架构上是一致的，但类图表示由类以及类间关系组成的抽象模型，而对象图表示特定时刻的实例和实例间关系，对象图更接近实际的系统行为。

3.3.1 对象 Objects

对象使用一个长方形来表示，对象名称中带有下划线，以此说明是系统中类的实例，对象名称中的实例名和类名用冒号分隔。与类类似，可在单独的分区中列出实例属性，不过与类不同的是，对象中的属性有具体的值。

3.3.2 链接

同 3.2.2

3.3.3 总结：对象图示例

动态图用于描述系统的对象交互、活动流程、状态变迁等动态行为模型，通常在完成静态图建模之后进行相应的动态图建模。

3.4 顺序图 Sequence Diagrams：描述一段时间范围内多个对象之间的交互信息，强调消息交互的时间顺序

顺序图是交互图的一种形式，描述了系统各成员之间的交互，这里的系统成员包括参与者、系统中的各个对象等，序列图不是用来显示复杂的过程逻辑的。

顺序图通过时间轴的方式将这些交互联系起来，同时以时间轴的方式描述各个对象交互的先后次序。顺序图从上往下表示时间的进行，每一步行为可以使用序号表达执行顺序。

序列图通常用作开发团队开始编程之前的规划工具，是用例需求过渡到下一个更细化的级别的工具。一个用例通常会细化为一个或多个顺序图，顺序图作用于单用例多对象。

3.4.1 参与者 Actors

同 3.1.1

3.4.2 对象 Objects

同 3.3.1

3.4.3 有版型对象 Stereotyped Object

UML中类可分为三种：边界类 Boundary、控制类 Control 和实体类 Entity。

边界类：参与者使用边界类来同系统交互，边界类通常包含窗口，屏幕，对话框和菜单等，识别边界类可以帮助开发人员识别出用户对界面的需求。
实体类：来自对业务中的实体对象的归纳和抽象，用于记录系统所需要维护的数据和对这些数据的处理行为。与边界类和控制类不同，实体类通常并不是某个用例实现所特有的，它可能跨越多个用例，甚至可能跨越多个系统。对实体类的常见描述：实体类保存要放进持久存储体的信息，持久存储体就是数据库、文件等可以永久存储数据的介质。
控制类：将边界类和实体类关联起来，包含了大部分应用逻辑，在用户和存储的数据之间架起一座桥梁。将控制类抽象出来可以降低界面和数据库之间的耦合度，控制类中包含经常修改的业务规则和策略，修改只需要在这些类中进行，而不会涉及到用户界面和数据库。

针对参与者和用例之间的每一个关联关系（即每一对 Actor-UseCase），可以定义一个边界类，每一个用例可以定义一个控制类，从一个用例可以识别出若干个实体类。

三种类对应的对象图标如下，顺序图中可以使用这种有造型的对象图标，达到在视觉效果上体现元素作用的效果。

3.4.4 生命线 Lifelines

生命线用于表示一个对象在系统中存在的时间段，是一条从对象或者参与者出发的垂直线。

在序列图中，生命线表示对象在时间轴上的存在，并与消息交互相关联。在通信图中，生命线表示对象的存在，并与消息交互相关联。在时序图中，生命线表示对象在时间轴上的存在，并与状态和事件相关联。

激活矩形（Execution Occurrence）

用沿生命线向下延伸的细长方形（激活矩形）表示执行事件。激活矩形显示对象进程的开始时间和执行时间，有助于理解对象何时处于运行状态、何时处于空闲状态。系统外部对象不需要激活框，例如参与者。

一个对象可以有多个来自它的生命线（部分分解 Part Decomposition），这样可以在一张图上同时显示对象间和对象内部的消息（inter- and intra-object messages）。

3.4.5 消息 Messages

在顺序图中，消息使用带箭头的直线来表示，由一个对象的生命线指向另一个对象的生命线，并在上面写上操作名（可选填序号和参数）。

序号是对消息的一个补充，将顺序图中所有的消息使用连续的序号进行修饰，能够使读者根据消息的序号看出消息发出的顺序。消息中的序号并不是简单地根据消息的发生顺序从 1 开始向后排序。对于同步消息来说，同步消息和异步消息的传递是不可分割的，是同一个过程，因此需要放在同一个步骤中。此外，如果一个步骤需要多个消息的交互，需要将消息的序号分级表示。

消息的表示

Synchronous Call

同步消息

a filled arrowhead

Asynchronous Call

异步消息

an open arrowhead

Reply Message

返回消息

a dotted line with an open arrowhead

发送消息的对象需要等待接收消息的对象执行完所有操作后才能继续执行自己的操作。

发送消息的对象发送消息后，无需等待可以继续执行自己的操作。

对象间返回的信息消息

Create Message

Delete Message

发送创建消息，创建另一条生命线。

表示方式类似于reply message。

发送删除消息(在以前的UML版本中称为stop)，终止另一条生命线。

Lost Message	Found Message
发送消息的对象需要等待接收消息的对象执行完所有操作后才能继续执行自己的操作。	接收方已知，但没有(已知的)发送方的消息。可以理解为消息的来源在描述的范围之外，例如，噪音或其他我们不想详细描述的对象。

Self Message (No Recursive)	Self Message (Recursive)	Duration Message
自己发送消息给自己，比如，一个对象调用了类中的函数，这个函数不调用其他函数，也不发送任何消息(或者实际上做了，但不想体现这一点)。	如果想对类的内部函数与其他生命线的交互进行建模，需要使用递归调用来显示这一点，否则读者无法知道消息是从内部函数发送/接收的。	显示消息传递的时间差。

3.4.6 片段 Fragment

UML 中的 fragment（片段）用于描述一个交互或者状态机中的一部分行为，它可以表示条件、循环、并行、异常等情况。应用“片段” 机制能够使图形得以表达更加复杂的内容，而且更加清晰和易于理解。

使用 fragment 时，需要在交互或状态机的图示中使用矩形框来标识 fragment 的范围，并在框内使用 fragment 的关键字和条件来描述具体的行为。例如，使用Alt fragment 时，需要在框内使用关键字 “alt” 和条件来描述分支的情况。

Operator	Fragment Type
alt	表示一组可选的交互片段，只有其中一个片段会被执行。 Alternative multiple fragments: only the one whose condition is true will execute.
opt	表示一个可选的交互片段，可能会被执行也可能不会被执行。 Optional: the fragment executes only if the supplied condition is true. Equivalent to an alt only with one trace.
par	表示一组并行执行的交互片段，它们可以同时执行。 Parallel: each fragment is run in parallel.
Seq	表示一组按顺序执行的交互片段。 Sequence: a set of interactive fragments that are executed sequentially.
loop	表示一个循环交互片段，可以重复执行多次。 Loop: the fragment may execute multiple times, and the guard indicates the basis of iteration.
ref	表示一个引用其他片段的片段。 Reference: refers to an interaction defined on another diagram. The frame is drawn to cover the lifelines involved in the interaction. You can define parameters and a return value.

3.4.7 总结：顺序图示例

3.5 活动图 Activity Diagrams：描述用例模型，强调复杂流程处理中活动单元的分支处理

活动图用于详细描述业务活动中涉及的流程。

3.5.1 对象 Object

同 3.3.1

3.5.2 活动 Activity、开始节点 Initial Node、结束节点 Final Node

Activity

Initial Node

开始节点

Final Node

结束节点 (活动结束节点、控制流结束节点)

活动是对参数化的行为序列的详细说明。

活动图中，活动呈现为圆角矩形，活动名称位于左上角，用粗体显示（如需体现活动参数，标记在活动名称下面）

用实心的圆点表示

The Activity final node

活动结束节点

用圆圈+内部实心圆点表示

The flow final node

控制流结束节点

用圆圈+交叉斜线表示

3.5.3 动作 Action、分区 Partiton

Action

Action Constraints

Partition

动作表示活动中的单个步骤。

表示为圆角矩形。

约束可以附加到操作上。

下图显示了一个带有局部前置和后置条件的操作。

活动分区是用于具有某些共同特征的操作的活动组。

表示为水平或垂直泳道。

3.5.4 关系：Control Flow (Activity Edge)、Object Flow (Object Edge)、Interrupt Flow (Interrupting Edge)

活动边是活动图中的关系元素，包括控制流和对象流，用一条带箭头的实线表示。
Activity Edge	控制流（控制边）是活动图中用于标识控制路径的符号，描述活动与活动之间的关系。
	如果活动边有名称，在箭头附近标记。
	守卫条件：边能执行的条件。右图示例表示：priority为1时，Fill Order。
	为避免绘制过长的边，可以使用连接器，连接器是一个小圆圈，里面有一个名称。使用时，一个连接器必须恰好有一个输入边，另一个恰好有一个输出边，每个具有给定标签的连接器都须能与同一活动图上另一个具有相同标签的连接器配对。
Object Flow Edge	对象流（活动边）是将对象结点作为输入或输出的控制流，描述对象与活动之间的关系。
Object Flow Edge	Weight：沿边传递的最小 token 数。右图示例表示：当“警告”个数达到6时，发送“通知”。
Interrupting Edge	在右图示例中：如果收到“Cancel Request”，“Process Order”操作将中断执行，并将控制传递给“Cancel Order”操作；否则保持运行直到运行完毕，然后将控制传递给“Close Order”。

3.5.5 决策 Decision、合并 Merge

决策节点和合并节点具有相同的符号：菱形。

决策节点：当活动图中的某个节点需要根据一定的条件来决定接下来的操作时，就可以使用决策节点。决策节点通常会与其他节点相连，表示不同的决策路径。在活动图的执行过程中，当遇到决策节点时，系统会根据决策节点所连接的节点和边的情况（守卫条件 Guard Conditions）来决定接下来的操作路径。

合并节点: 用于表示系统或软件中的合并点。当活动图中的某个节点需要将多个分支合并为一个分支时，就可以使用合并节点。合并节点通常会与其他节点相连，表示不同的合并路径。在活动图的执行过程中，当遇到合并节点时，系统会将合并节点所连接的多个分支合并为一个分支，然后继续执行合并节点之后的节点。

下图显示了决策节点和合并节点的使用。

3.5.6 Fork/Join

Fork 和 Join 表示并发控制线程的开始和结束，Fork 和 Join 之间的活动是并行执行的，最终执行完成所有的活动后，统一重新进入下一个活动。Fork 和 Join 必须组合使用，Fork表示一个活动完成后产生多个后续并行的活动，Join表示多个活动在进行下一个活动之前全部完成。

3.5.7 总结：活动图示例

3.6 状态图 State Diagrams：特定对象的不同状态变迁，强调特定对象在不同事件发生后的状态变化

状态图用于表示系统或系统的一部分在有限时间内的状态。状态图是一个行为图，用有限状态转换来表示行为，换句话说，状态机专门用于描述依赖于状态的行为，或者根据模型元素所处的状态而变化的行为，行为不随元素状态变化的模型元素不需要状态机来描述它们的行为 (这些元素通常是被动类，其主要职责是管理数据)。

状态机用于对模型元素的动态行为进行建模，从事件驱动角度描述系统行为。通常情况下，状态机对活动类的行为进行建模，这些活动类使用事件和信号来实现其操作 (类状态机中的转换)，状态图可用于类、用例或者整个系统。

3.6.1 简单状态 State 和复合状态 Composite State

State

Composite State / Substates

简单状态是没有子状态的状态。

状态具有如下属性：

名称：文本字符串，用来区分这个状态和其他状态，状态也可以是匿名的（没有名称）。

内部动作：如进入/退出动作：在进入和退出状态时执行的动作；持续动作：；延迟动作：在该状态下不处理，但被延迟并排队等待对象在另一状态下处理的事件列表。

内部转换：在不引起状态更改的情况下处理的转换。

复合状态是具有子状态(嵌套状态)的状态（Generally, composite state is defined as state that has substates (nested states).）。

子状态可以是简单状态或复合状态，子状态可以嵌套到任何级别，嵌套状态最多只能有一个初始状态和一个最终状态；子状态可以是顺序的(不相交的)或并发的(正交的)。复合状态提供了一种将状态机设计分层的方法，将复杂行为分解为更小、更易于理解和管理的部分，以便更好地组织和管理状态机的行为。

复合状态之外的源，可以转换到复合状态，也可以转换到子状态；从复合状态引出的转换，可以将复合状态作为其源，也可以将子状态作为源。

复合状态的另一种表示方法：

下述两图中，右下角的复合符号（类似于）表示：子状态的详细信息显示在单独的图表中。

3.6.2 转换 Transition

从一个状态到下一个状态的转换用带箭头的线条表示。转移符号上可以标记一些内容：触发 triggers，守卫 guard 和行为 behavior-expression。“触发”是转换的原因，它可以是一个信号、一个事件、某种条件的变化或时间的流逝。“守卫”是一个必须为真的条件，以便触发引起转换。“行为” 是一个动作，它将直接作用在拥有状态机的对象上，达到转换的效果。

transition ::= [triggers] [guard] ['/' behavior-expression]

triggers ::= trigger [ ',' trigger ]*

guard ::= '[' constraint ']'

3.6.3 结束状态 Final State，初始伪状态 Initial Pseudostate，进入点 Entry Point，退出点 Exit Point

伪状态是指表示状态转换过程中的中间状态，它本身并不代表一个真正的状态。

伪状态通常用于表示状态之间的过渡状态，它们不是状态图中的正式状态，而是一种辅助工具，帮助我们更好地理解状态之间的转换，伪状态通常用来表示状态图中的控制流程，通常用特殊的符号来表示。

初始点、结束点、进入点、退出点：

Initial Pseudostate

Final State

Entry Point

Exit Point

Initial Pseudostate 表示状态图的起始点，用一个黑色的实心圆圈表示，通常位于状态图的顶部，表示系统在启动时的初始状态。

它没有任何传入的转换，只有一个传出的转换，指向系统的下一个状态。在系统启动时，它会自动转移到下一个状态。

初始伪态不是真正的状态，是一个用于标识状态图的起始点的标记，在状态图中只能有一个初始伪态。

Final State 是一种真正的状态，它表示状态机已经结束。当状态机运行到 Final State 时，状态机将停止运行，并且不会返回到任何其他状态。Final State 通常用于表示状态机的正常结束流程。

Entry Point 表示状态图中的一个特定状态，该状态可以被多个状态图的不同状态所共享，通常表示为一个黑色的空心圆圈，可以有多个传入的转换和一个或多个传出的转换。

当进入一个状态图时，系统会转移到 Entry Point 所在的状态，然后再根据传出的转移进入下一个状态。

Exit Point 表示状态机的一个分支结束，Exit Point并不会导致状态机的停止执行。

在状态机运行到 Exit Point 时，状态机将退出当前分支，然后返回到状态机的上一个状态。Exit Point 常用于表示状态机的异常处理流程。

3.6.4 终止伪状态 Terminate Pseudostate

进入终止伪状态表示状态机的生命线已经结束。

终止伪状态意味着通过其上下文对象终止此状态机的执行。状态机不退出任何状态，也不执行任何退出操作，进入终止伪状态相当于调用 DestroyObjectAction。

3.6.5 历史伪状态 History Pseudostate

历史状态用于记住状态机在中断时的先前状态，通常用一个圆圈加上一个字母 “H” 表示。

下图状态机中，洗衣机运行时，会从 “Washing” 到 “Rinsing” 再到 “Spinning”。如果停电，洗衣机将停止运行并进入“关机” 状态；当电源恢复时，在 “历史状态” 处进入运行状态，这意味着它应该恢复到上次离开的位置。

3.6.7 其他

Choice、Fork、Join 参考 3.5

3.6.6 总结：状态图示例

下图显示了门在其生命周期中所经历的状态。门可以处于三种状态之一：“打开”、“关闭”或“锁定”。它可以响应事件 Open, Close, Lock 和 Unlock。注意，并非所有事件在所有状态下都有效，例如，如果一扇门被打开了，你无法锁上它，除非关上了它。还要注意，状态转换可以附加一个保护条件：如果门是打开的，则只有在条件 doorWay->isEmpty 满足时，才能响应 Close事件。