UML图

一、基本概念

如下图所示，UML楷书图片 图分为用例视图、设计视图、进程视图、实现视图和拓扑视图，又

可以静动分为静态视图和动态视图。静态图分为：用例图，类图，对象图，包图，构件图，

部署图。动态图分为：状态图，活动图，协作图，序列图。

1、用例图（UCa Diagrams）：

用例图主要回答了两个问题：1、是谁用软件。2、软件的功能。从用户的角度描述了

系统的功能，并指出各个功能的执行者，强调用户的使用者，系统为执行者完成哪些功能。

那么用例图都有哪几种元素组成呢？

角色（Actor）

角色用一个小人，但这并不代表角色只能是人，而不能是其它的物。角色可以是人、也

可以是物。

那么怎样分析一个系统所涉及到的角色呢？下面是几种常用来确定系统角色的方法：

1)、直接使用系统的人

2)、系统的维护人员

3)、从系统被动接受信息的人

4)、系统使用的外设

5)、需要与此系统相连的防伪标 其它系统

1)-3)是人，4)、5)是物。所以一定不要认为角色只能是人。

用例（U Ca）

用例就是系统的功能需求，就是待开天堂的父亲 发系统将要完成的功能，所以用例一般都用动词表

示

用例的粒度有粗有细，按照用例的粒度可以将其划分为以下几个粒度

(1)、概述级

此图中用户使用收费系统，“使用收费系统（UChargeSystem）”就是一个比较粗

的概述级的用例（简单的表示了人和系统之间的关系）

(2)、昆虫的作文 用户目标级

此图中用户查询余额，“查询余额（QueryRemainCash）”就是一个相对比较具体的

功能”，是我们最常用的一种用例粒度

(3)、子功能级

此图中用户在查询余额和查询使用金额之前都要先登录系统，登录系统（Login）是在

完成其他基本用例时必须要执行的一个子过程，这一用例的粒度相对较细。子功能级的用例

常用来被其它用例包含（include）、细化（refine）其他用例。

关系：歌颂祖国的作文 包括角色和用例之间的关系、用例和用例之间的关系、角色和角色之间的关系

角色和用例之间的关系通常为关联（表示某一角色和某一用例有关系）：

角色和角色之间的关系通常为继承：

角色Administrator继承了角色Ur，那么Adm王馨 inistrator也就具有QueryRemainCash

和QueryUCash的权限了。继承的最大好处就是实现复用，同使用角色之间的继承关系，

可以大大减少角色和用例之间的“连线”。

用例和用例之间的关系就比较复杂了，下面我为大家一一介绍：

①、包含关系（include）：

上面在讲用例粒度时讲到的查询余额（QueryRemainCash）和登录（Login）之间的关

系就是包含关系。

包含关系用一个虚箭头另加版型（stereotype）《include》表示，从包含用例指向被包

含用例，如下图所示

包含关系可以基于以下理由：

1)、从基本用例中分解出这样的行为：它对于了解基本用例的主要目的并不是必须的，

但是它必须在执行基本用例前先执行，只有它的结果才是比较重要的。如上图所示：对于用

户来说，他在了解系统的功能时，“查询余额”是主要的，对于登录，只有它的结果才是重

要的，但草字头加倍 是用户在查询余额前必须先登录。

2)、分解出两个或更多用例所共有的行为，这样可以实现用例的复用，简化用例图。如

上图所示："查询余额"闻名什么 和“查询消费金额”都能抽出一个“登录”用例。

举一个大家最常见的例子：你去银行办业务，无论你办什么业务，都需要你输入账号的

密码。假如有人问你：你去银行干什么呀？你的回答可能是取钱，但是绝对没有人回答我去

银行输密码和取钱。因为输入密码对于用户了解基本用例的目的不是必须的，只有输入密码

的结果才是重要的（但它是取钱时必须执行的步骤），所以取钱和输入密码之间就是包含关

系：

②、扩展关系（extend）

扩展关系用一个虚箭头外加版型《extend》表示，由扩展用例指向被扩展用例

扩展关系可以基于以下理由：

1)、表明用例的某一部分是可选的系统行为，这样就可以将用例图中的可选行为和必选

行为分开。

2)、表明只在特定条件下才执行的特定分支用例

3)、表明多个基本用例中都有可能触发的某个可选用例

extend关系和include关系最明显的区别就是：扩展用例是可选的，包含用例是必选的。

如上图所示：手机用户在用自动缴费机充值之后，可以打印小票，也可以不打印，这完全取

决于用户的意愿，并不是必须要执行的。

③、实现关系（realize）

大家可能很少听说在用例模型中使用realize关系，用例模型中实现关系用于连接用例

和用例实现，说明基本用例的一个实现方式。

实现在用例模型中的含义是：基本用例描述了一个业务目标，但是该业务目标有多种实

现途径，每一种实现途径都可以用一个实现用例来表示。这样实现用例和基本用例之间就构

成了实现关系。

类与对象基本概念：

类是现实世界或思维世界中的实体在计算机中的反映，它将数据以及这些数据上的操作

封装在一十九用英语怎么说 起。

对象是具有类类型的变量。类和对象是面向对象编程技术中的最基本的概念。

类与对象关系：

类是对象的抽象，而对象是类的具体实例。类是抽象的，不占用内存，而对象是具体的，

占用存储空间。类是用于创建对象的蓝图，它是一个定义包括在特定类型的对象中的方法和

变量的软件模板

2、类图（Class Diagrams）：

用户根据用例图抽象成类，描述类的内部结构和类与类之间的关系，是一种静态结构图。

在UML类图中，常见的有以下几种关系：泛化（Generalization），实现（Realization），

关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)。

各种关系的强弱顺序：泛化=实现>组合>聚合>关联>依赖

2.1.泛化

【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何继承父类

的所有特征和行为。例如：老虎是动物的一种，即有老虎的特性也有动物的共性。

2.2.实现

【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现。

2.3.关联

【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师

与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者

没有箭头，单向的关联有一个箭头。

【代码体现】：成员变量

2.4.聚合

【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎

是整体和部分的关系，轮胎离开车仍然可以存在。

聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须

考察具体的逻辑关系。

【代码体现】：成员变量

【箭头及指向】：带空心菱形的实线，菱形指向整体

2.5.组合

【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部

门是整体和部分的关系，没有公司就不存在部门。

组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中

代表整体的对象负责代表部分的对象的生命周期。

【代码体现】：成员变量

【箭头及指向】：带实心菱形的实线，菱形指向整体

2.6.依赖

【依赖关系】：是一种使用的关系，即一个类的实现需要另一个类的协助，所以要尽量

不使用双向的互相依赖.

【代码表现】：局部变量、方法的参数或者对静态方法的调用

【箭头及指向】：带箭头的虚线，指向被使用者

2.7 各种类图关系

3、对象图（Object Diagrams）:

描述的是参与交互的各个对象在交互过程中某一时刻的状态。对象图可以被看作是类

图在某一时刻的实例。

4、状态图（Statechart Diagrams）：

是一种由状态、变迁、事件和活动组成的状态机，用来描述类的对象所有可能的状态以

及时间发生时状态的转移条件。

5、活动图（Activity Diagrams）：

是状态图的一种特殊情况，这些状态大都处于活动状态。本质是一种流程图，它描述了

活动到活动的控制流。

交互图强调的是对象到对象的控制流，而活动图则强调的是从活动到活动的控制流。

活动图是一种表述过程基理、业务过程以及工作流的技术。

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

5.1带泳道的活动图

泳道表明每个活动是由哪些人或哪些部门负责完成。

5.2带对象流的活动图

用活动图描述某个对象时，可以把涉及到的对象放置在活动图中，并用一个依赖将其连

接到进行创建、修改和撤销的动作状态或者活动状态上，对象的这种使用方法就构成了对象

流。对象流用带有箭头的虚线表示。

6、序列图-时序图（Sequence Diagrams）：

交互图的一种，又称顺序图，描述了对象之间消息发送的先后顺序，强调时间顺序。

序列图的主要用途是把用例表达的需求，转化为进一步、更加正式层次的精细表达。用

例常常被细化为一个或者更多的序列图。同时序列图更有效地描述如何分配各个类的职责以

及各类具有相应职责的原因。

消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从

上到下排列。

序列图中涉及的元素：

6.1 生命线

生命线名称可带下划线。当使用下划线时，意味着序列图中的生命线代表一个类的特定

实例。

6.2 同步消息

同步等待消息

6.3 异步消息

异步发送消息，不需等待

6.4 注释

6.5 约束

6.6 组合

组合片段用来解决交互执行的条件及方式。它允许在序列图中直接表示逻辑组件，用

于通过指定条件或子进程的应用区域，为任何生命线的任何部分定义特殊条件和子进程。常

用的组合片段有：抉择、选项、循环、并行。

7、协作图（Collaboration Diagrams）：

交互图的一种，又称为通信图，描述了收发消息的对象的组织关系，强调对象之间的合

作关系。时序图按照时间顺序布图，而协作图按照空间结构布图

8、构件图（Component Diagrams）：

构件图，又称组合结构图，是用来表示系统中构件与构件之间，类或接口与构件之间的

关系图。其中，构建图之间的关系表现为依赖关系，定义的类或接口与类之间的关系表现为

依赖关系或实现关系。

9、部署图（Deployment Diagrams）：

描述了系统运行时进行处理教围棋 的结点以及在结点上活动的构件的配置。强调了物理设备以

及之间的连接关系。

部署模型的目的：

描述一个具体应用的主要部署结构，通过对各种硬件，在硬件中的软件以及各种连接协

议的显示，可以很好的描述系统是如何部署的；平衡系统运行时的计算资源分布；可以通过

连接描述组织的硬件网络结构或者是嵌入式系统等具有多种硬件和软件相关的系统运行模

型。

二、图的差异比较

1.序列图(时序图)VS协作图

序列图和协作图都是交互图。二者在语义上等价，可以相互转化。但是侧重点不同：序

列图侧重时间顺序，协作图侧重对象间的关系。

共同点：时序图与协作图均显示了对象间的交互。

不同点：时序图强调交互的时间次序。

协作图强调交互的空间结构。

2.状态图VS活动图

状态图和活动图都是行为图。状态图侧重从行为的结果来描述，活动图侧重从行为的动

作来描述。状态图描述了一个具体对象的可能状态以及他们之间的转换。在实际的项目中，

活动图并不是必须的，需要满足以下条件：1、出现并行过程&行为；2、描述算法；3、跨

越多个用例的活动图。

3.活动图VS交互图

二者都涉及到对象和他们之间传递的关系。区别在于交互图观察的是传送消息的对象，

而活动图观察的是对象之间传递的消息。看似语义相同，但是他们是从不同的角度来观察整

个系统的。

三、UML与软件工程

UML图是软件工程的组成部分，软件工程从宏观的角度保证了软件开发的各个过程的

质量。而UML作为一种建模语言，更加有效的实现了软件工程的要求。

如下图，在软件的各个开发阶段需要的UML图。

下表是UML使用人员图示：