学姐告诉我她用 UML 写了个冒泡排序，我当场掏出电脑给她画图

今天在餐厅偶遇学姐，我厚着脸皮的坐在她旁边，期间和她聊到了很多技术。直到学姐说她昨天用 UML 写了个冒泡排序，我直接人傻了，当场掏出书包里的笔记本给她画起图来。

第零章 UML概念模型

UML的概念模型包括构造块、运用于构造块的通用机制和用于组织UML视图的架构。

通过学习UML概念模型，我们可以很快地掌握UML图的内容与建模思想。

一、构造块

构造块是UML中的基本建模元素，包括事物、关系和图。其中，事物是对模型元素的抽象体现，如用例图中的用例、状态机图中的状态以及组件图中的组件等；关系是事物和事物间联系的方式，如用例间的依赖关系、包之间的泛化关系等；图是相关的事物及其关系的聚合到的表现，如用例图、顺序图、部署图等。

（一）事物

1. 结构事物

通常作为UML模型的静态部分，用于描述概念元素或物理元素。常见的结构事务有用例、类、协作、接口、组件、节点等。

2. 行为事物

亦称为动作事物，是UML模型的动态部分，用于描述UML模型中的动态元素。常见的行为事物有交互、状态机、活动等。

3. 分组事物

亦称为组织事物，用来组织系统设计的事物。主要的分组事物是包。

4. 注释事物

亦称为辅助事物。最主要的注释事物是注解。

（二）关系

UML中的四种基本关系：

• 依赖关系
• 关联关系
• 泛化关系
• 实现关系

（三）图

本篇文章主要是UML 2 版本。

• UML 2 中可以把图分为两大类：结构图和行为图；

  结构图用来构建静态模型，行为图用来构建动态模型。

• 结构图包括：类图、对象图、包图、组件图和部署图等；

  行为图包括：用例图、顺序图、通信图、状态机图和活动图等。

二、通用机制

通用机制有四种类型，修饰、扩展机制、规格说明和通用划分。

（一）规格说明

UML 的规格说明用来对系统的细节进行描述，例如类图中，我们对属性和操作进行泉面膜描述。

（二）修饰

修饰是对规格说明的文字或图形的表示，如类图中的protected用 # 来表示，这就是一种修饰。

（三）通用划分

主要的两种划分：

• 类型-实例
• 接口-实现

（四）扩展机制

为了扩充在某些细节方面的描述能力，UML允许建模者在不改变整体语言风格的基础上定义一些通用性的扩展。扩展机制包括构造型、标记值和约束。

1. 构造型

构造型是将一个已有的元素模型进行修饰或精化，创造出一种新的模型元素。如下图所示，是一个《interface》构造型（表示接口）。

2. 标记值

标记值用来对一个元属性定义。标记可以用来存储元素的任意信息，它是一个名称-值的组合。如下图所示，“author = ztypl”就是一个标记值。

3. 约束

约束是使用某种文本语言中的陈述句表达的语义条件或者限制。

三、“4 + 1”架构

见下面思维导图中有关内容。

四、UML概念模型思维导图

总结：UML 不是一种编程语言，而是一种建模规范，利用 UML 模型，我们可以分析出系统的功能需求等。

第一章 用例模型

一、 用例图

找出参与者是构建用例图的首要任务

用例图的要素包括：参与者、用例和关系。

（一）参与者

1. 表示

习惯用图标表示法来代表人，用类符号表示法来表示事物。

2. 参与者具备的基本特征

（1）位于系统边界之外；

（2）直接且主动的向系统发出动作并获得反馈。

举个栗子：

（二）用例

1. 表示

用例用一个包含名称的椭圆形表示，名称可以显示在椭圆内部或椭圆下方。

2. 用例的特征

（1）必须位于系统边界内部。

（2）用例以动宾短语形式出现：如取款、选课等。但取款单、课程表、选择等不是用例。

（3）用例是相对独立的，指的是用例在功能上是完备的。如：到车库“取车”可以作为一个用例，而“打开车库门” 不能完整地实现参与者的目的，仅仅是取车的一个步骤而已，因此它不是一个用例。

（4）用例的执行结果对参与者来说是可观测且有意义的 ：① 用例描述参与者与系统之间的交互行为，而非内在系统活动。如，用户在银行系统取钱，取钱可以是一个用例，但银行系统的“核对金额”对用户来说是不可见的，因此不能作为一个用例。② 用例不是处理过程，如用户“输入密码”只是“取钱”的一个过程，它不能作为一个用例。

（5）用例是由参与者启动的：用例不应自动启动，也不应主动启动另一个用例。

3. 用例的粒度

举个栗子：假设某系统允许用户修改自己的用户名、密码、联系电话和地址等信息。我们可以由这些信息画出两个用例图，如图所示：

注：b 的粒度比 a 的粒度细。由此可知，粒度越细，表示的内容越多。但并不是粒度越细越好。

（三）关系

1. 参与者间的泛化关系

将具有共同行为的一般角色抽象为父参与者，子参与者可以继承父参与者的行为和含义，并能拥有自己特有的行为和含义。如付费会员拥有普通会员的权限，也拥有一些普通会员没有的权限，如图所示：

2. 用例与参与者间的关联关系

关联关系使用实线箭头表示，如图所示。如果箭头指向用例，则表明参与者发起用例，即用例的主参与者；如果没有箭头或箭头指向参与者，则表示用例与参与者没有交互，即用例的次参与者。

3. 用例之间的关系

（1）泛化关系

用例间的泛化关系同参与者间的泛化关系，是一种继承关系。

举个栗子：学校要“评价教职工”，但教师评价与清洁工人评价的标准不同，它们属于两个用例，但都可与“评价教职工”构成泛化关系，如图所示：

（2）依赖关系

包含关系：

包含指的是一个用例（基用例）可以包含其他用例（包含用例）具有的行为。

注：

• 基用例可以看到包含用例，但它对包含用例的内部结构没有了解。
• 基用例一定会要求包含用例执行。
• 箭头由基用例指向包含用例。

举个栗子：用户在某宝购物创建订单的行为一定包含选择商品的行为，用例图表示如下。

扩展关系：

① 扩展是指一个用例（扩展用例）对另一个用例（基用例）行为的增强。

注：

• 基用例对扩展用例的存在毫不知情。
• 箭头由扩展用例指向基用例。

举个栗子：对于系统的“注册”用例而言，用户可以填写实名信息从而获得系统较高的信任等级，这就需要引入一个“检查实名信息”的用例。但该用例相对“注册”而言并不是必需的，因为只有填写实名信息后，才会执行“检查实名信息”。用例图表示如下。

② 扩展用例的使用包括四个部分

• 基用例

• 扩展用例

• 扩展关系：使用虚线箭头表示，箭头指向基用例。

• 扩展点：Ⅰ. 扩展点实际上是一个决定是否执行扩展用例的分支条件；Ⅱ. 扩展用例是否被执行取决于扩展点的条件，如果条件不满足则不执行扩展用例；Ⅲ. 在基用例的执行过程中，可以通过扩展点的数量和位置来使同一个扩展用例执行多次。

二、用例规约

用例规约包括：用例名称、用例编号、参与者、用例描述、触发器、前置条件、后置条件、基本事件流、扩展事件流、结论和补充约束，其中补充约束又包括数据需求、业务规则、非功能性需求和设计约束。直接上例子，下面是一个“少儿兴趣班管理系统”的系统描述，根据此描述，完成了管理会员信息用例的用例规约。

系统描述：

1. 用户可以注册账号，并且可以上传个人头像、设置昵称、设置密码等。注册成功后，用户即可获得会员身份。游客可以浏览兴趣班课程信息，但不能购买课程，同时也无法观看课程。

2. 会员购买课程时，可以使用使用支付宝或者微信支付，购买成功后，在自己的信息页面可以观看已经购买的兴趣班课程视频，且视频有效期一年。

3. 会员可以发表对已买兴趣班课程的评论，并且可以使用留言功能。另外，会员可以每天登录系统进行日常打卡，发表个人动态，修改个人信息等。

4. 管理员登录系统后能够对兴趣班会员名单进行修改，查看和删除会员的基本资料，可以给会员更改密码。管理员可以对兴趣班课程进行添加、删除，对课程的价格进行调整。管理员可以发布公告，通知会员有关兴趣班的相关事宜。管理员可以回复会员的留言。管理员可以查看会员消费记录，打印会员消费账单。

用例名称	管理会员信息
用例编号	SUP001
参与者	管理员
用例描述	该用例描述了一个系统管理员管理会员信息的行为
触发器	当管理员管理会员信息时，用例触发
前置条件	管理员需要登录系统
后置条件	系统存储系统管理员的操作记录，保存会员权限状态，存储会员基本信息
基本事件流	1. 管理员输入账号、密码，验证通过，显示登录成功，并在数据库日志中记录用户登录成功，进入管理员界面；2. 管理员修改会员信息；3. 管理员将修改后的会员信息提交至界面；4. 界面将修改后的会员信息保存到数据库；5. 数据库日志将存储结果返回给界面；6管理员退出系统
扩展事件流	1A. 如果验证未通过，提示用户登录失败，并在数据库日志中记录用户登录失败；1A-1. 如果用户选择重新登陆，可以重复步骤，重新进行登录。如果用户连续登录失败3次， 则锁定账号，系统提示用户“连续错误3次，账号被锁定”
结论	当管理员修改会员信息被系统确认，用例结束
数据需求	D-2个人信息包括昵称、头像、地址以及密码
业务规则	B-1系统管理员已授权且被系统识别

三、用例模型思维导图

第二章 类图与对象图

三、类图思维导图

四、对象图思维导图

第三章 顺序图

一、作用

• 展示消息按时间顺序发送。
• 细化用例的表达。

二、表示

• 顺序图采用二维的布局结构；

• 纵向是时间轴，时间沿竖线向下延伸；

• 横向代表在协作中各独立对象的角色。

三、基本组成

顺序图的组成元素包括：对象、生命线、激活和消息。

（一）对象

• 顺序图中对象的符号与对象图中对象所用的符号一致。

• 顺序图中的对象，可以是系统的参与者或任何有效的系统对象。

• 对象置于顺序图的顶部，意味着交互开始时对象就已经存在了；对象不置于顶部，意味着对象是在交互过程中创建的。

• 一般来说，从左到右，按照参与者对象 → 边界对象 → 控制对象 → 实体对象的顺序排列。

顺序图中经常使用的分析类对象：

1. 边界类
   如系统界面等，负责输入信息或展示输出。
2. 控制类
   （1）负责对界面输入的数据进行计算；
   （2）如果计算的结果需要保存，则传递给实体类；
   （3）如果计算的结果需要输出，则传递给边界类。
3. 实体类
   如数据库等，负责存储计算结果。

• 对象的命名形式：

（二）生命线

• 是一条垂直的虚线，用于表示对象在一段时间内的存在。
• 生命线的长度取决于交互持续的时间。

（三）激活（或控制焦点）

• 在对象的生命线上的矩形。
• 矩形的顶部表示动作的开始，底部表示动作的结束（可以由一个返回消息来标记）。

（四）消息

1. 组成

• 编号（顺序编号、嵌套编号）

• 名称

• 类型

2. 分类

• 简单消息：表示控制流，可以参与任何交互。一般在不关心消息类型或不确定消息类型时使用。

• 调用消息：表示发送者调用某个对象的一个操作。可以是对象之间的调用，也可以是对象本身的调用。
• 返回消息：表示接受者向发送者返回一个值。

• 同步消息：发送者通过消息把信号传递给接受者后，必须等到接受者返回消息，才能继续后续活动。
• 异步消息：发送者通过消息把信号传递给接受者后，就继续自己的活动，不等待接受者返回消息。

• 阻止消息：发送者发出消息给接受者，如果接受者无法立即接受这个消息，则发送者放弃这个消息。
• 超时消息：发送者发出消息给接受者，并按指定时间等待，若接受者无法在指定时间内接受这个消息，则发送者放弃这个消息。

• 对象创建消息：创建对象的消息被称为对象创建消息，表示对象在交互过程中被创

  建，可以通过构造型<>来表示。

• 对象销毁消息：一个对象可以通过对象销毁消息销毁另一个对象，也可以销毁它本身。在UML中用构造型<>表示，同时在对象生命线的结束部分画一个 “×” 来表示该对象被销毁。

• 无触发对象消息： 用实心球加箭头来表示，它表示消息的发送者没有被详细指明，或者是一个未知的发送者，或者该消息来自于一个随机的消息源。
• 无接收对象消息：用箭头加实心球来表示，它表示消息的接收者没有被详细指明，或者是一个未知的接收者，或者该消息在某一时刻未被收到。

四、循环和分支

（一）分支

• 分支是指从同一点发出的多条消息指向不同的对象。

• 根据消息是否互斥，可将分支分为条件和并行。

（二）片段

1. 组成

• 操作符
• 区域
• 监护条件

2. 操作符

• 选择片段alt：表示一种多条件分支，根据监护条件，最多选择片段中的一个交互执行，类似于“if……else”语句。

• 可选片段opt：表示一种单条件分支，包含在此片段中的交互只有在监护条件为真时才执行。

• 循环片段loop：片段将被执行多次，具体的执行次数由方括号内的循环次数和监护条件表达式说明。

• 中断片段break：若监护条件为“真”则执行子片段，不执行片段后面的其他交互；否则，就跳过子片段，按正常流程继续执行其他交互。

• 引用片段ref：用于在一个交互图中，引用其他的交互图。（在区域内注明引用的交互图的名称）

• 并行片段par：表示片段中的各个交互并行执行。（需要为每个分支建立交互区域，每个区域无需监护条件）

五、顺序图绘制步骤

绘制交互图分四个步骤：

Step 1：找出交互对象并确认对象的排列顺序；

Step 2：确定对象之间交互的具体消息格式和流程；

Step 3：利用交互片段或循环标志及监护条件来表示循环和分支结构；

Step 4：通过一些构造型来完善整个交互图。

六、顺序图思维导图

第四章 通信图

一、定义

用于描述一组对象在协作过程中如何互相通信。

二、组成

通信图的组成元素包括：对象、消息和链。

（一）对象

与顺序图中的对象相同，都是类的实例。

（二）消息

• 与顺序图中的消息相同。
• 消息必须要有编号，且该编号必须是唯一的。
• 常用消息包括：简单消息、调用消息和返回消息。

（三）链

• 与对象图中的链相同，是关联关系的实例。

• 若两个对象需要发生交互，必须先建立链。

• 消息要附着在链上。

三、顺序图与通信图在组成上的异同

（一）相同点：

主要元素相同。两种图中的主要元素都是对象与消息，且都支持所有的消息类型。

（二）不同点

1. 顺序图不同于通信图的特征

• 各个对象在顺序图中的顶部从左到右依次排列，也就是说对象的位置有限制。
• 对象有生命线和激活，可以表示出对象的激活与去激活状态，也可以表示出对象创建和销毁的相对时间。
• 消息的编号可以不显示。

2. 通信图不同于顺序图的特征

• 对象在通信图中的位置没有限制。
• 通信图有关联关系的实例——链。
• 通信图必须显示消息编号。

四、通信图思维导图

第五章 状态机图

一、状态机图的概念

（一）状态机

• 由对象的各个状态和连接这些状态的转换组成，是展示状态与状态转换的模型。
• 状态机图本质上就是一个状态机，或者是状态机的特殊情况，它包含状态机的所有特征。

（二）UML不同版本的名称

UML 1 中称为状态图，UML 2 中称为状态机图。虽然名称不同，但两者的组成、用法基本相同。

二、状态机图的组成

状态机图由状态和转换组成，可由下面公式表示：

状态机图 = 状态 + 转换（或State Diagram = State + Transitions）

（一） 状态的表示

1. 初始状态

初始状态代表状态图的起始位置，只能作为转换的源，而不能作为转换的目标。初始状态在一个状态图中只允许有一个，它用一个实心的圆表示。

2. 终止状态

终止状态是对象的最后状态，是一个状态图的终止点。终止状态只能作为转换的目标，而不能作为转换的源。终止状态在一个状态图中可以有多个，它用一个套有一个实心圆的空心圆表示。

附：初始状态和终止状态都是状态的特殊形式。

3. 状态

（1）状态名

​ 在一个图中名字应该是唯一的。状态名在第一栏。

（2）活动

​ 包括入口动作、出口动作、内部活动、内部转换、延迟事件、子状态和子状态机等。

• 入口动作：在任何状态的内部活动之前执行；常用来进行状态所需的内部初始化。

• 出口动作：在任何内部活动完成后、任何离开转换的动作之前执行

• 内部活动：指对象处于某个状态时一直执行的活动。一直持续到某个外部事件的到来才中断工作，或者活动结束、状态完成、触发转换。

• 内部转换：见下文。

• 延迟事件：是状态中被延迟处理的事件，直到另一个状态被激活才对其进行处理。

（二）状态的分类

状态机图中的状态分为简单状态和复合状态。

1. 简单状态

简单状态是指不包含其他状态的状态。但是，简单状态可以具有内部转换、入口动作和出口动作等。

2. 复合状态(组合状态)

（1）复合状态是指状态本身包含一到多个子状态机的状态。

（2）复合状态中包含的多个子状态之间的关系有两种：一种是并发关系，另一种是互斥关系。

​ 如果子状态是并发关系，称为并发子状态；如果子状态是互斥关系，称为顺序子状态。

（3）复合状态为父状态，每个子状态继承了父状态的全部转换。

（1）顺序子状态

复合状态包含的多个子状态中，只能有一个子状态处于活动状态。复合状态只包含一个状态机。

（2）并发子状态

如果复合状态包含两个或者多个并发的子状态机，此时称复合状态的子状态为并发子状态。

3. 历史状态

​ 当离开一个复合状态，然后重新进入复合状态时，并不希望从复合状态包含的子状态机的初始状态开始执行，而是希望直接进入上次离开复合状态时的最后一个活动子状态。

​ 用一个包含字母“H”的小圆圈表示最后一个活动子状态，即称为历史状态。每当转换到复合状态的历史状态时，对象的状态便恢复到上次离开该复合状态时的最后一个活动子状态，并执行入口动作。

​ 如下图所示，表示一个音乐播放器的几种状态之间的转换。假设在听音乐时因为有事需要外出，回来时继续播放，那么“播放”就可以作为一个历史状态。

（三）转换的表示

转换用带箭头的直线表示

转换的内容包括：源状态、目标状态、事件触发器、监护条件和执行的动作。

1. 源状态

对于一个转换来说，转换前对象所处的状态，就是源状态。源状态是个相对的概念，即相对当前状态而言，它的前一个状态就是源状态。

2. 目标状态

转换完成后，对象所处的状态就是目标状态。当前状态相对它的前一个状态而言，当前状态就是目标状态。

3. 事件触发器

事件是外部作用于一个对象，能够触发对象状态改变的一种现象。事件可以分为调用、改变、信号、时间四类事件。

• 信号事件：对象之间通过发送信号和接收信号实现通信。信号是一种异步机制。对于一个信号而言，对象一般都有相应的事件处理器。
• 调用事件：调用某个对象的成员方法就是调用事件，它是一种同步的机制。
• 改变事件：是指某个指定属性值为真时，事件得到触发。它与监护条件不同，在对象生命周期内，一直在计算改变事件中的属性值，当属性值为真时，事件触发，计算停止。
• 时间事件：当时间流逝到某个时刻，触发事件对对象起作用。

4. 监护条件

只有在触发事件发生时，才计算一次监护条件的值，当监护条件的值为真时，转换才发生。

5. 动作

当转换被激活后，如果定义了相应的动作，那么就将执行这个动作。

动作分为入口动作和出口动作。

入口动作和出口动作都标识在状态图的第二栏中。

6. 活动

活动用来描述对象处于某个状态时，对象进行的一序列动作。

（四）转换的分类

1. 转换表示当一个外部事件作用于对象，在监护条件得到满足时，对象在源状态下执行一序列的动作后，转向目标状态。

2. 转换进入的状态称为活动状态，转换离开的状态变为非活动状态。

3. 转换分为外部转换、内部转换、自动转换、复合转换。

1. 外部转换

一种改变对象状态的转换，是最常见的一种转换。外部转换用从源状态到目标状态的箭头表示。

2. 内部转换

内部转换有一个源状态但是没有目标状态。

它转换后的状态仍旧是它本身。

内部转换自始至终都不离开源状态，没有入口动作和出口动作。

3. 自动转换

在没有外部事件的作用下，对象执行了某些活动后，自然而然地完成的转换。

4. 自转换

状态被激活后离开当前状态，又回到当前状态。自转换不改变对象的状态，但会中断当前状态。

附：自转换与内部转换的区别：

自转换会触发入口动作和出口动作，而内部转换不会。

5. 复合转换

复合转换由简单转换组成，通过分支判定，把多个简单转换组合在一起。

（五）分支的表示

根据监护条件的真假可以触发不同的分支转换。分支用空心小菱形表示。

五、状态机图的绘制

（一）寻找主要状态

（二）确定状态间的转换

（三）详细描述每个状态和转换

（四）把简单状态图转换为复合状态图

六、状态机图思维导图

第六章 活动图

一、活动图建模对象

活动图可以用来对业务过程、工作流建模，也可以对用例实现，甚至是对程序实现进行建模。

二、活动图和流程图的区别

活动图与流程图的最主要的区别在于，活动图能够标识活动的并行行为。

三、活动图的组成元素

• 动作是活动中的一个步骤，但是动作并不是组成活动的最小单位，每个动作只是相对它的活动而言。如果把一个动作作为一个活动，那么，这个动作又可分为更多个组成这个活动的动作。
• 在UML活动图中，活动和动作都用圆角矩形来表示，在圆角矩形中书写动作或活动的名字。

• 当活动边连接的是两个动作时，这种活动边称为控制流。

• 当活动边连接动作与对象节点时，称这类活动边为对象流。

• UML 2.0 用参数节点(Parameter Nodes)来表示一个参数进入一个活动或者一个参数从一个活动中输出。参数节点用一个直角的长方形来表示

• 对象节点用矩形框表示，对象节点名可以加在矩形框内或外部，框内标明数据的名称

对象节点与参数节点的差别是：对象节点与动作相连，参数节点是在活动框上的数据。

四、活动图分类

按照活动图表示的信息不同将活动图分为：简单活动图、标识泳道的活动图、标识对象流的活动图、复合活动图。

1. 简单活动图

简单活动图既没有标识活动的执行者，也没有标识活动执行过程中创建了哪些对象。

2. 标识泳道的活动图

每个活动节点，分支必须只属于一个泳道，而转换、分叉与结合是可以跨泳道的。通过泳道，不仅体现了整个活动控制流，还体现出了每个活动的实施者。

3. 标识对象流的活动图

4. 标识信号的活动图

信号是表示两个对象之间进行异步通讯的方式，当一个对象接收到一个信号时将触发信号事件。利用“信号”可以增加活动图的可读性。

在活动中标识信号

5. 标识参数的活动图

一个活动节点可以带有多个参数。在绝大多数情况下，并不需要在活动图上标明参数信息，如果打算标明每个活动节点执行前，需要输入哪些参数，活动节点执行后，需要输出哪些参数，以及活动节点执行后，要进行的错误处理。这时，在活动图中标明参数，使活动图表示更多的信息。

参数分三种：输入参数，输出参数，错误参数。

第七章 包图

一、组成元素

包图 = 包 + 关系

系统中的每个元素都只能为一个包所有，一个包可嵌套在另一个包中。

二、包图的表示

（一）包的表示

UML使用一个左上部带有标签的矩形表示包。

（二）包的名称

• 简单名
• 全名（路径名）

每个包必须有一个与其他包相区别的名称。

（三）包的元素

• 包中可以拥有各种其他元素，包括类、接口、构件、节点、协作、用例，甚至是其他包或图。

• 每一个包就意味着一个独立的命名空间。因此，两个不同的包，可以具有相同的元素名，但由于所位于的包名不同，因此其全名仍然是不同的。

• 在包中表示元素时，有两种方法：一种是在第二栏中列出所属元素名，一种是在第二栏中画出所属元素的图形表示。

（四）包的可见性

包中元素的可见性主要有下面三种：

+ ：公共的可见性(public)，这类元素可以被包外部的所有元素访问。

- ：私有可见性(private），这类元素不能被包外部的元素访问 。

# ：受保护的可见性(protected)，包中的元素仅可被继承自该包的子包中的元素访问。

三、包图中的关系

UML用带箭头的虚线来表示包之间的关系。

（一）《use》关系

《use》关系是一种默认的依赖关系。说明客户包（箭尾端的包）中的元素以某种方式使用提供者包（箭头端的包）的公共元素。

（二）《import》关系

说明提供者包（箭头端的包）的命名空间将被添加到客户包（箭尾端的包）的命名空间中，客户包中的元素能够访问提供者包的所有公共元素。

附：客户包的元素引用提供者包的元素时，将无需使用全称，只需使用元素名称即可。

（三）《access》关系

只使用提供者包（箭头端的包）中的元素，而不会将两个包合并。

附：在客户包（箭尾端的包）中必须使用路径名，才能访问提供者包中的所有公共元素。

（四）泛化关系

包间的泛化关系类似于类间的泛化关系，使用一般包的地方，可以用特殊包代替。

附：

（1）中的Client包中的元素可以看到GUI包中的元素，即GUI包中的元素对Client包中的元素来说，可见性为public；

（2）中的Client包中的元素看不到GUI包中的元素，即GUI包中的元素对Client包中的元素来说，可见性为private。

四、绘制包图

第一：寻找包；

第二：确定包之间的关系；

第三：标出包内元素的可见性。

附：

• 最大限度减少包之间的依赖，封装包时，避免包之间的循环依赖；

• 最小化每个包中的public、protected元素的个数，最大化每个包中private元素的个数。

五、包图思维导图

第八章 组件图

一、组件的概念

• 组件是系统的可替代的物理部分，它表示的是实际的事物。

• 良好定义的组件不直接依赖于其它组件，而是依赖于其它组件所支持的接口，在这种情况下，系统中的一个组件可以被支持相同的接口的其它组件所替代。

二、组件的分类

按照组件在系统中的角色，把组件分为3种类型：配置组件、工作产品组件、执行组件。

配置组件：组成系统的基础组件，是执行其它组件的基础平台。如操作系统、Java 虚拟机 、数据库管理系统都属于配置组件。

工作产品组件：这类组件主要是开发过程的中间产物。如创建组件时的源代码文件及数据文件都属于工作产品组件，这些组件并不是直接地参与系统运行。

执行组件：在运行时创建的组件。例如由DLL实例化形成的COM+对象、Servlets、XML文档都属于执行组件

三、组件与类的相同和不同

（一）相同点：

• 二者都有名称
• 都可以实现一组接口
• 都可以参与依赖、泛化和关联关系
• 都可以被嵌套
• 都可以有实例
• 都可以参与交互。

（二）不同点：

• 类是逻辑抽象，不能单独存在于计算机；而组件是物理抽象。也就是说，组件是可以部署的，而类不能部署。
• 组件属于软件模块，而非逻辑模块。甚至可以说，组件就是由一组类通过协作完成的。
• 类可以直接拥有操作和属性，而组件仅拥有可以通过其接口访问的操作。

四、组件的表示

（一）接口的类型

组件有两种接口：供给接口和需求接口

供给接口为其它组件提供服务；需求接口使用其它组件提供的服务。如下图所示，是 UML 2 规范中的球窝表示法。

（二）组件的表示方法

1. 没有标识接口的组件

没有标识接口的组件的图形表示方法又分三种

（1）标有构造型《component》的矩形

（2）在矩形的右上角放置一个组件图标（常用）

（3）直接使用组件图标

2. 标识了接口的组件。

（1）使用接口分栏表示

​ 将供给接口和需求接口直接显示在矩形的分栏中，将构造型《provided》和 《required》放在每个接口名之 前。

（2）（常用）

​ 供给接口表示为通过一条实线链接到矩形上的圆圈；而需求接口则表示为一条实线链接到矩形上的上半圆。

（3）显示表示法

​ 组件和其供给接口之间是实现关系，而组件和其需求接口之间是使用《use》关系。

五、组件图的作用

• 组件图的基本目的是使系统人员和开发人员能够从整体上了解系统的所有物理部件。
• 同时，也使我们知道如何对组件进行打包，以便交付给最终客户。
• 最后，组件图显示了被开发系统所包含的组件之间的依赖关系。

附：使用组件图可以清楚地看出系统的结构和功能。

六、组件图的组成

（一）组件

• 有接口
• 没有接口

（二）接口

• 供给接口
• 需求接口

（三）关系

组件图中的关系主要包括依赖关系和实现关系。

1. 用法一：组件与接口之间的关系

组件与供给接口之间建立实现关系；组件与需求接口之间建立依赖关系。

2. 用法二：组件与组件之间的关系

组件之间的关系就是依赖关系。我们把提供服务的组件称为提供者，把使用服务的组件称为客户。

（四）端口（在嵌套的组件图中使用）

1. 什么是端口

端口可以理解为组件的入口与出口，组件通过端口与外部元素相互协作。另外，端口上可以添加供给接口或需求接口来使组件得以扩展。

2. 连接件

连接件：两个端口之间的连线被称作连接件。

• 委派连接件：内部端口连接到整体组件的外部端口上。任何传到外部端口的消息被立即传送到内部端口。
• 接口连接件
• 直接连接件

组件与组件之间通过端口连接，而端口与端口之间通过连接件相连，连接件分为接口连接件、委派连接件、直接连接件。

七、组件图的分类

（一）简单组件图

（二）嵌套的组件图

八、组件图应用

常采用组件图来描述：

• 可执行程序的结构
• 源代码
• 物理数据库组成和结构。

九、组件图思维导图

第九章 部署图

一、部署图的概念

• 也称配置图、实施图。
• 从部署图中，可以了解软件和硬件组件之间的物理关系以及软件组件在处理节点上的分布情况。
• 一般一个系统仅有一个部署图。
• 部署图的组成元素包括节点、节点间的连接。

二、部署图的表示

（一）节点

• 节点通常拥有一些内存，并具有处理能力。
• 它可以是物理设备及运行在该设备上的软件系统。

1. 节点的表示

节点用一个立方体表示

节点名称：

• 简单名称
• 带路径的名称：在简单名字前加上节点所属的包名。

附：UML 2.0 中多采用“节点类型 : 节点名称”的方式。

2. 节点的分类

按照节点是否有计算能力，把节点分为两种类型：

• 处理器是能够执行软件、具有计算能力的节点。如服务器、工作站。

• 设备是没有计算能力的节点，通常情况下都是通过其接口为外部提供某种服务。如打印机、扫描仪。

  

3. 节点中的组件

在节点上描述组件有四种方式：

• 直接描述：不是由开发团队生成的制品。

• 《artifact》构造型：表示文件、组件等由开发团队生成的制品

• 《database》构造型：用来表示一个实际的数据库

• 《deploymentSpec》构造型：用来表示部署描述，通常对关键的配置文件进行建模，还可以在构造块中直接指出具体参数的值。

4. 节点属性

类一样，可以为一个节点提供属性描述处理器速度、内存容量、网卡数量等属性。

附：节点、组件的相同与不同

相同：

• 二者都有名称
• 都可以参与依赖、泛化和关联关系
• 都可以被嵌套
• 都可以有实例
• 都可以参与交互

不同：

• 组件是软件系统执行的主体，而节点是执行组件的平台；
• 组件是逻辑部件，而节点表示是物理部件，在物理部件上部署组件。

（二）连接

• 连接用一条实线表示。

• 描述节点间的关系一般不使用名称，而是使用构造型描述。

三、部署图的应用

• 部署图主要用在设计和实现两个阶段。
• 部署图主要用来对嵌入式系统、客户机/服务器系统、分布式系统进行建模。

四、部署图思维导图

我刚画完用例图，学姐却头也不回的走了。等到晚上聊天时，学姐也不回我。我问学姐的室友，她们都说我是大直男。嗯嗯嗯？发生了什么？有没有小伙伴解释一下。