软考知识点——UML（文末红包福利）

Posted 2021-04-23 Persimmon NGP 项目

7.2 UML（及Plant UML使用）

面向对象分析强调的是对一个系统中对象的特征和行为的定义。目前，国际上已经出现了多种面向对象的方法，例如Peter Coad和Edward Yourdon的OOA和OOD方法、Booch的OOD方法、OMT（Object Modeling Technique，面向对象建模技术）方法及UML（Unified Modeling Language，统一建模语言）。本文将对目前业界普遍接受的UML方法进行简要介绍。

统一建模语言是面向对象软件的标准化建模语言。由于其简单、统一，又能够表达软件设计中的动态和静态信息，目前已经成为可视化建模语言事实上的工业标准，当前版本为2.5.1。

从企业信息系统到基于web的分布式应用，甚至严格的实时嵌入式系统都适合用UML来建模。它是一种富有表达力的语言，可以描述开发所需要的各种视图，然后以此为基础装配系统。UML由3个要素构成：UML的基本构造块、支配这些构造块如何放置在一起的规则和运用与整个语言的一些公共机制。限于篇幅，下面仅对UML中的基本构造块进行讨论。

UML的词汇表包含3种构造块：事物、关系和图。事物是对模型中最具有代表性的成分的抽象：关系把事物结合在一起；图聚集了相关的事物。

事物 From Persimmon NGP 项目 00:00 05:16

7.2.1 事物

UML中有4种事物：结构事物、行为事物、分组事物和注释事物。

（1）结构事物（Structural Thing），结构事物是UML模型中的名词。它们通常是模型的静态部分，描述概念或物理元素。结构事物包括类（Class）、接口（Interface）、协作（Collaboration）、用例（Use Case）、主动类（Active Class）、构件（Component）、制品（Artifact）和结点（Node）。各种结构事物的图形化表示如下图所示。

（2）行为事物（Behavior thing）。行为事物是UML模型的动态部分。它们是模型中的动词，描述了跨越时间和空间的行为。行为事物包括交互（Interaction）、状态机（State Machine）和活动（Activity）。各种行为事物的图形化表示如下图所示。

交互由在特定语境中共同完成一定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作序列（由一个消息所引起的行为）和链（对象间的连接）。在图形上，把一个消息表示为一条有向直线，通常在表示消息的线段上总有操作名。

状态机描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。单个类或一组类之间协作的行为可以用状态机来描述。一个状态机涉及到一些其他元素，包括状态、转换（从一个状态到另一个状态的流）、事件（触发转换的事物）和活动（对一个转换的响应）。在图形上，把状态表示为一个圆角矩形，通常在圆角矩形中含有状态的名称及其子状态。活动是描述计算机过程执行的步骤序列，注重步骤之间的流而不关心哪个对象执行哪个步骤。活动的一个步骤称为一个动作。在图形上，把动作画成一个圆角矩形，在其中含有指明其用途的名字。状态和动作靠不同的语境得以区别。交互、状态机和活动是可以包含在模型中的基本行为事物。在语义上，这些元素通常与各种结构元素（主要是类、协作和对象）相关。

（3）分组事物（Grouping Thing）。分组事物是UML模型的组织部分，是一些由模型分解成的“盒子”。在所有的分组事物中，最主要的分组事物是包（Package）。包是把元素组织成组的机制，这种机制具有多种用途。结构事物、行为事物甚至其他分组事物都可放进包内。包与构件（仅在运行时存在）不同，它纯粹是概念上的（即它仅在开发时存在）。包的图形化表示如下图所示。

（4）注释事物（Annotational Thing）。注释事物是UML模型的解释部分。这些注释事物用来描述、说明和标注模型的任何元素。注解（Note）是一种主要的注释事物。注解是一个依附于一个元素或者一组元素之上，对它进行约束或解释的简单符号。注解的图形化表示如下图所示。

关系 From Persimmon NGP 项目 00:00 01:46

7.2.2 关系

UML中有4种关系：依赖、关联、泛化和实现。

（1）依赖（Dependency），依赖是两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。在图形上，把一个依赖画成一条可能有方向的虚线，如下图所示。

（2）关联（Association）。关联是一种结构关系，它描述了一组链，链是对象之间的连接。聚集（Aggregation）是一种特殊类型的关联，它描述了整体和部分间的结构关系。关联和聚集的图形化表示如下图所示。

在关联上以标注重复度（Multiplicity）和角色（Role）。

（3）泛化（Generalization）。泛化是一种特殊/一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象。用这种方法，子元素共享了父元素的结构和行为。在图形上，把一个泛化关系画成一条带有空心箭头的实线，它指向父元素，如下图所示。

（4）实现（Realization）。实现是类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约。在两种情况下会使用实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用例和实现它们的协作之间。在图形上，把一个实现关系画成一条带有空心箭头的虚线，如下图所示。

这4种关系是UML模型中可以包含的基本关系事物。它们也有变体，例如，依赖的变体有精化、跟踪、包含和延伸。

UML中的图 From Persimmon NGP 项目 00:00 18:52

7.2.3 UML中的图

图（Diagram）是一组元素的图形表示，大多数情况下把图画成顶点（代表事物）和弧（代表关系）的连通图。为了对系统进行可视化，可以从不同的角度画图，这样图是对系统的投影。

UML 2.0提供了13种图，分别是类图、对象图、用例图、序列图、通信图、状态图、活动图、构件图、组合结构图、部署图、包图、交互概览图和计时图。序列图、通信图、交互概览图和计时图均被称为交互图。

1. 类图

类图（Class Diagram）展现了一组对象、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图。包含主动类的类图给出了系统的静态进程视图。

类图中通常包括下述内容（如下图所示)。

（1）类。
（2）接口。
（3）协作。
（4）依赖、泛化和关联关系。

类图中也可以包含注解和约束。类图还可以含有包或子系统，二者都用于把模型元素聚集成更大的组块。

类图用于对系统的静态设计视图建模。这种视图主要支持系统的功能需求，即系统要提供给最终用户的服务。当对系统的静态设计视图建模时，通常以下述3种方式之一使用类图。

（1）对系统的词汇建模。对系统的词汇建模涉及做出这样的决定：哪些抽象是考虑中的系统的一部分，哪些抽象处于系统边界之外。用类图详细描述这些抽象和它们的职责。
（2）对简单的协作建模。协作是一些共同工作的类、接口和其他元素的群体，该群体提供的一些合作行为强于所有这些元素的行为之和。例如，当对分布式系统的事务语义建模时，不能仅仅盯着一个单独的类来推断要发生什么，而要有相互协作的一组类来实现这些语义。用类图对这组类以及它们之间的关系进行可视化和详述。
（3）对逻辑数据库模式建模。将模式看作为数据库的概念设计的蓝图。在很多领域中，要在关系数据库或面向对象数据库中存储永久信息，可以用类图对这些数据库的模式建模。

PlantUML 绘制类图

hide empty members /' 如果没有成员，不显示类下面的框 '/

interface "使用 interface 定义接口" as 接口 #66ccff
note right #ccffff
 使用 note left/right 添加注释
 使用 #color 设定颜色（天依蓝）
end note

abstract "使用 abstarct 定义抽象类" as 抽象
class "使用 class 定义普通类" as 类 <泛型参数 implements 接口> << (S, #ff7700) Singleton >>
enum "使用 enum 定义枚举" as 枚举
annotation "使用 annotation 定义注解" as 注解
entity "使用 entity 定义实体" as 实体

接口 <|..[#green] 抽象 : 说明
note on link
 使用 <|.. 表示实现
 在关系上使用 : 添加说明
 使用 note on link添加注释
 使用 #color 设定颜色
end note

抽象 <|-- 类
note on link : 使用 <|-- 表示扩展

<> diamond
类 -- diamond
diamond "1" o-- "1" 枚举
note on link : 使用 o-- 表示聚合
diamond "1" o-- "*" 枚举实体 "1" *-- "*" 类
note on link
 使用 *-- 表示组合
 使用 "" 标注映射关系
end note

实体 - 注解 : 有若干个 >
note on link
 使用 <> 表示关系的方向
end note

类 : #属性 : 类型
类 : +方法(参数 : 类型) : 返回值
note right
 <泛型参数>
 <<模板>>
 使用 : 定义属性、方法（- # ~ + 表示可访问性）
 -() 接口
end note

类 -() 接口

note left of 类::属性
 使用 note left/right of 类::属性 添加注释
end note

note left of 类::方法
 使用 note left/right of 类::方法(参数 : 类型) 添加注释
end note

'CENTER

2. 对象图

对象图（Object Diagram）展现了某一时刻一组对象以及它们之间的关系，描述了在类图中所建立的事物的实例的静态快照。对象图一般包括对象和链，如下图所示。

和类图一样，对象图给出系统的静态设计视图或静态进程视图，但它们是从真实的或原型实例的角度建立的。这种视图主要支持系统的功能需求，即系统应该提供给最终用户的服务。利用对象图可以对静态数据结构建模。

在对系统的静态设计视图或静态进程视图建模时，主要是使用对象图对对象结构进行建模。对象结构建模涉及在给定时刻抓取系统中对象的快照。对象图表示了交互图表示的动态场景的一个静态画面，可以使用对象图可视化、详述、构造和文档化系统中存在的实例以及它们之间的相互关系。

PlantUML 绘制对象图

object "使用 object 定义对象" as 对象 {
 属性1 = 值1
}
对象 : 属性2 = 值2
note right
 使用 花括号 声明属性值
 使用 : 声明属性值
end note

对象 <|-- Object1 : 扩展
note on link : 使用 <|-- 表示扩展

对象 *-- Object2 : 组合
note on link : 使用 *-- 表示组合

对象 o-- Object3 : 聚合
note on link : 使用 o-- 表示聚合

'CENTER

3. 用例图

用例图（Use Case Diagram）展现了一组用例、参与者（Actor）以及它们之间的关系。

用例图通常包括以下内容（如下图所示）。

（1）用例。
（2）参与者。
（3）用例之间的扩展关系（<<extend>>）和包含关系（<<include>>），参与者和用例之间的关联关系，用例与用例以及参与者与参与者之间的泛化关系。

用例图用于对系统的静态用例视图进行建模。这个视图主要支持系统的行为，即该系统在它的周边环境的语境中所提供的外部可见服务。

当对系统的静态用例视图建模时，可以用下列两种方式来使用用例图。

（1）对系统的语境建模。对一个系统的语境进行建模，包括围绕整个系统画一条线，并声明有哪些参与者位于系统之外并与系统进行交互。在这里，用例图说明了参与者以及它们所扮演的角色的含义。
（2）对系统的需求建模。对一个系统的需求进行建模，包括说明这个系统应该做什么（从系统外部的一个视点出发），而不考虑系统应该怎样做。在这里，用例图说明了系统想要的行为。通过这种方式，用例图使我们能够把整个系统看作一个黑盒子，采用矩形框表示系统边界；可以观察到系统外部有什么，系统怎样与哪些外部事物相互作用，但却看不到系统内部是如何工作的。

PlantUML 绘制用例图

package "使用 package 定义包" {
 (usecase 用例\n可以使用 圆括号 定义) as 用例
 usecase 用例1 as "
 分隔符
 --四个减号--
 ==四个等号==
 ..四个圆点..
 或者两个一组中间写字
 "
}

:actor 角色\n可以使用 冒号 定义: as 角色

角色 --> 用例
角色 --> 用例1

用例 <|- 用例1 : 继承
note on link : 使用 <|-- 表示继承

'CENTER

4. 交互图

交互图用于对系统的动态方面进行建模。一张交互图表现的是一个交互，由一组对象和它们之间的关系组成，包含它们之间可能传递的消息。交互图表现为序列图、通信图、交互概览图和计时图，每种针对不同的目的，能适用于不同的情况。序列图是强调消息时间顺序的交互图；通信图是强调接收和发送消息的对象的结构组织的交互图；交互概览图强调控制流的交互图。

交互图用于对一个系统的动态方面建模。在多数情况下，它包括对类、接口、构件和结点的具体的或原型化的实例以及它们之间传递的消息进行建模，所有这些都位于一个表达行为的脚本的语境中。交互图可以单独使用，来可视化、详述、构造和文档化一个特定的对象群体的动态方面，也可以用来对一个用例的特定的控制流进行建模。

交互图一般包含对象、链和消息。

1）序列图

序列图（Sequence Diagram）是场景（Scenario）的图形化表示，描述了以时间顺序组织的对象之间的交互活动。如下图所示，形成序列图时，首先把参加交互的对象放在图的上方，沿水平方向排列。通常把发起交互的对象放在左边，下级对象依次放在右边。然后，把这些对象发送和接收的消息沿垂直方向按时间顺序从上到下放置。这样，就提供了控制流随时间推移的清晰的可视化轨迹。

序列图有两个不同于通信图的特征。

（1）序列图有对象生命线。对象生命线是一条垂直的虚线，表示一个对象在一段时间内存在。在交互图中出现的大多数对象存在于整个交互过程中，所以这些对象全都排列在图的顶部，其生命线从图的顶部画到图的底部。但对象也可以在交互过程中创建，它们的生命线从接收到构造型为create的消息时开始。对象也可以在交互过程中撤销，它们的生命线在接收到构造型为destroy的消息时结束（并且给出一个大X的标记表明生命的结束）。
（2）序列图有控制焦点。控制焦点是一个瘦高的矩形，表示一个对象执行一个动作所经历的时间段，既可以是直接执行，也可以是通过下级过程执行。矩形的顶部表示动作的开始，底部表示动作的结束（可以由一个返回消息来标记）。还可以通过将另一个控制焦点放在它的父控制焦点的右边来显示（由循环、自身操作调用或从另一个对象的回调所引起的）控制焦点的嵌套（其嵌套深度可以任意）。如果想特别精确地表示控制焦点在哪里，也可以在对象的方法被实际执行（并且控制还没传给另一个对象）期间将那段矩形区域阴影化。

PlantUML 绘制序列图

hide footbox /' 移除脚注 '/

header header 页眉
footer footer 页脚
title title **星星** //斜杠// ""双引号"" --短横线-- __下划线__ ~~波浪号~~ 标题

box "box 包裹，end box"

participant "使用 participant 定义参与者" as 参与者 <<使用《》指定构造类型>>
hnote left of 参与者 : 使用 note left/right of\n给参与者写注释（hnote 六边形）

actor "使用 actor 定义角色" as 角色/ hnote over 角色 : 使用 / 对齐注释

autonumber /' 自动编号 '/

[-> 参与者 : [-> 进入消息

参与者 -> 参与者 : 给自己发消息

参与者 -> 角色 : 说明
rnote left : 在消息上使用 : 添加说明\n使用 note left/right 添加注释\n（rnote 长方形）

create boundary 边界参与者 -> 边界 ** : 使用 create 创建参与者\n或者使用 ** 自动创建

end box

control "使用 control 定义控制" as 控制
entity "使用 entity 定义实体" as 实体
database "使用 database 定义数据库" as 数据库
collections 集合

参与者 -> 边界 ++ : 使用 activate 激活（++）\ndeactivate 撤销（—）生命线（或者—++）
activate 边界

ref over 参与者, 角色 : 使用 note over（\\n换行）\n给多个参与者写注释（ref 引用）

边界 ->x 参与者 -- : x，在箭头末尾加叉
deactivate 边界

== 使用 == 表示分隔 ==

参与者 ->o 控制 : o，在箭头末尾加圈
return 使用 return 返回信息

... 使用 ... 表示延迟 ...

参与者 ->> 实体 : >>，细箭头

||| /' 增加空间 '/

参与者 --> 数据库 : --，虚箭头

参与者 <-> 集合 : 双箭头

[<- 参与者 : [<- 发出消息

'CENTER

Alice -> Bob : 认证请求
alt 成功情况
 Bob -> Alice : 认证接受
else 某种失败情况
 Bob -> Alice : 认证失败
 group 我自己的标签
 Alice -> Log : 开始记录攻击日志
 loop 1000次
 Alice -> Bob : DNS 攻击
 end
 Alice -> Log : 结束记录攻击日志
end
else 另一种失败
 Bob -> Alice : 请重复
end

'CENTER

2）通信图

通信图（Communication Diagram）强调收发消息的对象的结构组织，在早期的版本中也被称作协作图。通信图强调参加交互的对象的组织。产生一张通信图，如下图所示，首先要将参加交互的对象作为图的顶点，然后把连接这些对象的链表示为图的弧，最后用对象发送和接收的消息来修饰这些链。这就提供了在协作对象的结构组织的语境中观察控制流的一个清晰的可视化轨迹。

通信图有两个不同于序列图的特性。

（1）通信有路径。为了指出一个对象如何与另一个对象链接，可以在链的末端附上一个路径构造型（如构造型<<local>>，表示指定对象对发送者而言是局部的）。通常只需要显式地表示以下几种链的路径：local（局部）、parameter（参数）、global（全局）以及self（自身），但不必表示association（关联）。
（2）通信图有顺序号。为表示一个消息的时间顺序，可以给消息加一个数字前缀（从1号消息开始），在控制流中，每个新消息的顺序号单调增加（如2、3等）。为了显示嵌套，可使用带小数点的号码（1表示第一个消息；1.1表示嵌套在消息1中的第一个消息，1.2表示嵌套在消息1中的第二个消息，等等）。嵌套可为任意深度。还要注意的是，沿同一个链可以显示许多消息（可能发自不同的方向），并且每个消息都有唯一的一个顺序号。

序列图和通信图是同构的，它们之间可以相互转换。

3）交互概览图

交互概览图（Interaction Overview Diagram）是UML2.0新增的交互图之一，它是活动图的变体，描述业务过程中的控制流概览，软件过程中的详细逻辑概览，以及将多个图进行连接，抽象掉了消息和生命线。它使用活动图的表示法，如下图所示。纯粹的交互概览图中所有的活动都是交互发生。

4）计时图

计时图（Timing Diagram）是另一种新增的、特别适合实时和嵌入式系统建模的交互图，关注沿着线性时间轴、生命线内部和生命线之间的条件改变。它描述对象状态着时间改变的情况，很像示波器，如下图所示，适合分析周期和非周期性任务。

5. 状态图

状态图（State Diagram）展现了一个状态机，它由状态、转换、事件和活动组成。状态图关注系统的动态视图，对于接口、类和协作的行为建模尤为重要，强调对象行为的事件顺序。

状态图通常包括简单状态和组合状态、转换（事件和动作），如下图所示。状态是指对象的生命周期中某个条件或者状态，在此期间对象将满足某些条件、执行某些活动或等待某些事件，是对象执行了一系列活动的结果，当某个事件发生后，对象的状态将发生变化。嵌套在另外一个状态中的状态称为子状态，含有子状态的状态称为组合状态。转换是两个状态之间的一种关系，表示对象将在状态中执行一定的动作，并在某个特定事件发生而且某个特定的警界（监护）条件满足时进入目标状态。动作是一个可执行的原子操作，是不可中断的，其执行时间是可忽略不计的。直接通过进入节点进入状态，通过退出节点可以结束状态。使用历史状态记住从组合状态中退出时所处的子状态，作用是当再次进入组合状态时，可以直接进入这个子状态，而不是再次从组合状态的初态开始。状态图可以分为区域，而区域又包括退出或者当前执行的子状态，说明组合状态可以在某一时刻同时到达多个子状态，此时通常在其前后使用fork和join标识。

可以用状态图对系统的动态方面建模。这些动态方面可以包括出现在系统体系结构的任何视图中的任何一种对象的按事件排序的行为，这些对象包括类（各主动类）、接口、构件和结点。

当对系统、类或用例的动态方面建模时，通常是对反应型对象建模。

一个反应型或事件驱动的对象是这样一个对象，其行为通常是由对来自语境外部的事件做出反应来刻画的。反应型对象在接收到一个事件之前通常处于空闲状态。当它接收到一个事件时，它的反应常常依赖于以前的事件。在这个对象对事件做出反应后，它就又变成闲状态，等待下一个事件。对于这种对象，将着眼于对象的稳定状态、能够触发从状态到状态的转换的事件，以及当每个状态改变时所发生的动作。

PlantUML 绘制状态图

hide empty description /' 没有说明时，不显示说明框 '/

[*] --> 合成状态 : 状态图以[*]\n开始/结束

state 合成状态 {
 state 分支 {
 state "关键字 as 用于重命名状态" as 状态1
 [*] --> 状态1 : 写冒号然后写说明
 状态1 : 写冒号然后写说明
 状态1 : 可以有多个说明
 note right : 使用 note left/right\n给状态写注释

 state fork <<fork>>
 状态1 --> fork : 使用<<fork>>创建分支节点
 note on link
 使用 note on link
 end note 给转移写注释
 end note

 state 状态2
 fork -> 状态2 : 一个减号是横线
 fork --> 状态3 : 二个减号是竖线

 state join <<join>>
 状态2 --> join : 二个减号是竖线
 状态3 -> join : 一个减号是横线

 join --> 状态4 : 使用<<join>>创建合并节点
 }

 ||

 state 分隔符 {
 [*] -> 状态5 : 使用 || 创建分隔符
 --
 [*] -> 状态6 : 使用 — 创建分隔符
 }

 state 条件 {
 state "使用<<entryPoint>>创建入口" as entry <<entryPoint>>
 state "使用<<exitPoint>>创建出口" as exit1 <<exitPoint>>
 state "I" as exit2 <<exitPoint>>

 state choice <<choice>>
 entry --> choice : 使用<<fork>>创建条件节点

 choice --> 条件状态1 : [条件1]
 choice --> 条件状态2 : [条件2]
 条件状态1 --> exit1
 条件状态2 --> exit2

 exit1 --> 分隔符
 exit2 --> 分隔符
 }
}

'CENTER

6. 活动图

活动图（Activity Diagram）是一种特殊的状态图，它展现了在系统内从一个活动至另一个活动的流程，如下图所示。活动图专注于系统的动态视图，它对于系统的功能建模特别重要，并强调对象间的控制流程。

活动图一般包括活动状态和动作状态、转换和对象。

用活动图建模的控制流中，会发生一些事情。可能要对一个设置属性值或返回一些值的表达式求值；也可能要调用对象上的操作，发送一个消息给对象，甚至创建或销毁对象，这些可执行的原子计算被称作动作状态，因为它们是该系统的状态，每个原子计算都代表一个动作的执行。动作状态不能被分解。动作状态是原子的，也就是说事件可以发生，但动作状态的工作不能被中断。最后，动作状态的工作所占用的执行时间一般被看作是可忽略的。

活动状态能够进一步被分解，它们的活动由其他的活动图表示活动状态不是原子的，它们可以被中断。并且，一般来说，还要考虑到它需要花费一段时间来完成。可以把一个动作状态看作一个活动状态的特例。类似地，可以把一个活动状态看作一个组合，它的控制流由其他的活动状态和动作状态组成。

活动图可以表示分支、合并、分岔和汇合。分支描述基于布尔表达式的可选择路径，可有一个入流和两个或多个出流，在每个出流上放置一个布尔表达式条件，每个出流的条件不应该重叠，但需要覆盖所有可能性。合并描述当两条控制路径重新合并时，不需要监护条件，只有一个出流。分岔描述把一个控制流分成两个或多个并发控制流，可以有一个进入转移和两个或多个离去转移，每个离去的转移表示一个独立的控制流，这些流可以并行的进行。汇合表示两个或多个并发控制流的同步，可以有两个或多个进入转移和一个离去转移，意味着每个进入流都等待，直到所有进入流都达到这个汇合处。

当对一个系统的动态方面建模时，通常有两种使用活动图的方式。

（1）对工作流建模。此时所关注的是与系统进行协作的参与者所观察到的活动。工作流常常位于软件系统的边缘，用于可视化、详述、构造和文档化开发系统所涉及的业务过程。在活动图的这种胤法中，对对象流的建模是特别重要的，常采用泳道将活动图中的活动状态分组。
（2）对操作建模。此时是把活动图作为流程图，使用，对一个计算的细节部分建模。在活动图的这种用法中，对分支、合并、分岔和汇合状态的建模是特别重要的。用于这种方式的活动图语境包括该操作的参数和它的局部对象。

PlantUML 绘制活动图

note right
 如果想给开始点添加注释，
 只需把注释的定义放在活动图
 最开始的地方即可。
 也可以用end note 定义多行注释。
end note

(*) -->[活动图以(*)\n开始/结束] 活动1
note right : 使用 note left/right\n给活动写注释

活动1 -->[使用 === 建立同步条] ===同步条1===

===同步条1=== ->[一个减号是横线] 活动2
--> ===同步条2===

===同步条1=== -->[两个减号是竖线] 活动3
-> ===同步条2===

partition 使用partition进行分区 {

if 分支条件 then
 ->[true] 真活动
 --> (*)
else
 if 嵌套分支条件 then
 ->[true] 真活动
 else
 -->[false] 假活动
 endif
 -> (*)
endif

}

'CENTER

7. 构件图

构件图（Component Diagram）展现了一组构件之间的组织和依赖。构件图专注于系统的静态实现视图，如下图所示。它与类图相关，通常把构件映射为一个或多个类、接口或协作。

PlantUML 绘制构件图

package "使用 package 定义包" {

 [使用方括号直接定义组件] as 组件0
 note left : 使用 note left/right\n给组件写注释

 component [使用 component 定义组件\n as 用于重命名组件] as 组件1
 note "使用note单独定义注释，然后使用虚线(..) 将其连接到组件" as Note
 组件1 .. Note

 () "使用圆括号直接创建接口" as 接口0
 interface "使用 interface 定义接口\n as 用于重命名接口" as 接口1

 组件0 - 接口0 : 一个减号是横线
 组件1 - 接口1 : 一个减号是横线
 组件1 ..> 接口0 : 两个减号是竖线
 组件0 ..> 接口1 : 两个减号是竖线

 node "使用 node 定义节点" as Node

 folder "使用 folder 定义目录" as Folder

 frame "使用 frame 定义窗体" as Frame

 cloud "使用 cloud 定义云" as Cloud

 database "使用 database 定义数据库" as Database

 组件1 -- Node
 Node -- Folder
 Folder - Frame
 Folder -- Cloud
 Cloud - Database
}

'CENTER

8. 组合结构图

组合结构图（Composite Structure Diagram）用于描述一个分类器（如类、构件或用例）的内部结构，分类器与系统中其他组成部分之间的交互端口，展示一组相互协作的实例如何完成特定的任务，描述设计、架构模式或策略。组合结构图的内部结构和协作使用图分别如下两图所示。

9. 部署图

部署图（Deployment Diagram）是用来对面向对象系统的物理方面建模的方法，展现了运行时处理结点以及其中构件（制品）的配置。部署图对系统的静态部署视图进行建模，它与构件图相关。通常，一个结点是一个在运行时存在并代表一项计算资源的物理元素，至少拥有一些内容，常常具有处理能力，包含一个或多个构件。部署图如下图所示，其中，<<artifact>>表示制品。

PlantUML 绘制部署图

:actor 角色\n可以使用冒号定义: as 角色
agent 代理 [
 使用方括号
 写跨行长说明]
artifact 制品
boundary 边界
card 卡片
cloud 云 {
 [component 组件\n可以使用方括号定义] as 组件
 control 控制
 database 数据库
 entity 实体
 file 文件
 folder 目录 [
 分隔符
 --四个减号--
 ==四个等号==
 ..四个圆点..
 或者两个一组中间写字
 ]
 frame 窗体
 () "interface 接口\n可以使用前置圆括号定义"
 node 节点
 package 包
 queue 队列
 rectangle 长方形
 storage 存储
 (usecase 用例\n可以使用圆括号定义)
}

角色 - 代理
note on link : - 是横线角色 -- 制品
note on link : -- 是竖线制品 . 边界
note on link : .. 是虚线边界 ~ 卡片
note on link : ~~ 是点划线制品 == 云
note on link : == 是粗实线

'CENTER

10. 包图

包图（Package Diagram）是用于把模型本身组织成层次结构的通用机制，不能执行，展现由模型本身分解而成的组织单元以及其间的依赖关系。

包可以拥有其他元素，可以是类、接口、构件、结点、协作、用例和图，甚至是嵌套的其他包，如下图所示拥有是一种组成关系，是一种按规模来处理问题的重要机制，也意味着元素被声明在包中，一个元素只能被一个包所拥有，拥有关系的包形成了一个命名空间，其中同一种元素的名称必须唯一。

交易担保 抽奖助手 本期将抽出三位幸运读者瓜分0.66元现金红包 Mini Program