浅谈UML中常用的几种图
1 UML简介
2 UML常见图分类
3 用况图（用例）
4 类图
简单类图使用 举例
5 其他辅助用图
时序图(顺序图)
协作图（Collaboration Diagram/communication Diagram）/通信图
状态图
活动图(Activity Diagram)
6 组件图(ComponentDiagram)、配置图(Deployment Diagram)


Update Time:2020年1月5日20:17:47    Author:要你命三千又 三千      type：笔记整理


做一个简单的UML总结

学习UML 的各个用图；

如果详细学习每一个部分，是看一篇总结是远远不够的。

1 UML简介

统一建模语言（Unified Modeling Language，UML）又称标准建模语言，是始于1997年的一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。‘UML感兴趣的可以阅读UML 1规 范，包含了UML 的所有知识内容。

注：OMG, Object Management Group 对象管理组织

2 UML常见图分类
UML从考虑系统的不同角度出发，定义了用况图、类图、对象图、包图、状态图、活动图、序列图、通信图、构件图、部署图等10种图。
分类：

面向对象动态建模，用于建立行为的实体间行为交互的四种图：状态图(Stage Diagram)，序列图(Sequence Diagram)，协作图(Communication Diagram)，活动图(Activity Diagram) 。

“序列图”与“协作图”表述的是相似的消息，“活动图”是“状态图”的一种。

静态结构图Static Structure Diagram

类图Class Diagram

对象图Object Diagram

用况图Use Case Diagram
交互图Interaction Diagram

顺序图Sequence Diagram

协作图Collaboration Diagram

状态图State chart Diagrams

活动图Activity Diagrams
实现图Implementation Diagrams

构件图Component Diagram

部署图Deployment Diagram

3 用况图（用例）
用例图，展现了一组用例、参与者（actor）以及它们之间的关系。

用例图从用户角度描述系统的静态使用情况，用于建立需求模型。(用于需求分析)

参与者（Actor）

　　在系统外部与系统直接交互的人或事物。需要注意以下两点：

　　1）参与者是角色而不是具体的人（可以是外部系统），它代表了参与者在与系统打交道的过程中所扮演的角色。所以在系统的实际运作中，一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应于一个参与者，从而代表同一参与者的不同实例。

　　2）参与者作为外部用户（而不是内部）与系统发生交互作用，是它的主要特征。

在UML中，参与者使用如图所示的一个小人表示：



用例（Use Case）用况

系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用椭圆表示，椭圆中的文字简述系统的功能：



子系统(Subsystem)

用来展示系统的一部分功能，这部分功能联系紧密。



关系（Relationship）

　　常见关系类型有关联、泛化、包含和扩展。

　　以上各关系在uml图中的表示方式，如下表所示：

　　



　　a. 关联(Association)

　　表示参与者与用例之间的通信，任何一方都可发送或接受消息。

　　【箭头指向】：指向消息接收方



　　b. 泛化(Inheritance)

　　就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。

　　【箭头指向】：指向父用例



　　c. 包含(Include)

包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。

　　【箭头指向】：指向分解出来的功能用例



　　d. 扩展(Extend)

　　扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。

　　【箭头指向】：指向基础用例



包含(include)、扩展(extend)、泛化(Inheritance) 的区别：

　　条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；

　　直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。

　　对extend（扩展）而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。

　　对Inheritance（泛化）而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；
4 类图
在UML类图中，常见的有以下几种关系: 泛化（Generalization）,  实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)

泛化（Generalization）

【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。例如：老虎是动物的一种，即有老虎的特性也有动物的共性。

【箭头指向】：带三角箭头的实线，箭头指向父类


实现类的继承关系



实现（Realization）

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

【箭头指向】：带三角箭头的虚线，箭头指向接口


注意可以理解类的继承的关系的另外一种表现形式。



关联（Association)

【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。

【代码体现】：成员变量

【箭头及指向】：带普通箭头的实心线，指向被拥有者



上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。下图为自身关联：



聚合（Aggregation）

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

聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

【代码体现】：成员变量

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




组合(Composition)

【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系，没有公司就不存在部门。组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

【代码体现】：成员变量

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


依赖(Dependency)

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

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

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




各种关系的强弱顺序：

泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖

下面这张UML图，比较形象地展示了各种类图关系：



图片转自：http://blog.csdn.net/tianhai110/article/details/6339565

注意这里的雁群和大雁的关系画反了。

简单类图使用 举例


根据下面的陈述画出类图

1)学生包括本科生、研究生两种。

2)研究生的一部分利用课余时间担任助教。

3)教师包括讲师和教授两种。

4)一名助教可以为一位讲师或一位教授助课,一位讲师只能有一名助教,一位教授可以有5名助教。


按如下描述画出一个自治机器人的类图。

这张图的焦点是聚集在那些让机器人在路上行走的机制所对应的类上。你可以发现一个虚类Motor和两个从它派生出来的类: SteeringMotor和MainMotor。这两个类都从它的父亲Motor继承了五个方法:move()、stop()、resetCounter()、statues()、distance()。这两个类又是另一个类Driver的一部分。类PathAgent 和Driver有一个1对1的关系,和CollisionSensor有1对n的关系。


【问题:】综上所述请你用UML来绘制分析类图。

参考答案:


5 其他辅助用图
时序图(顺序图)

时序图别称为顺序图、序列图，在我的大致印象中时序图是以时间为主线，有生命线的动态视图，主要描述的对象是对象。是交互图的一种。主要的作用是表达设计者心中对于未来程序在运作时的对象协作建模，验证软件领域模型的正确性，为程序员提供编码的蓝图。

（一）概念

定义：

时序图是以时间为序的表示方法，主要用来描述对象之间的时间顺序。将交互关系表示为二维图的。纵轴为时间，横轴为在协作中各个独立的对象。对象存在时用一条虚线表示，当对象的过程处于激活状态是，生命线是一个双道线。消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。如下图：


四个元素（对象，生命线，消息，激活）

（1）对象

对象的概念就不多说了，就是类的实例化，在系统中随便都可以找到一个对象，因为我们使用的是基于OO编程的VB。

（2）生命线

表示对象的存在存在多久的时间

（3）消息

对象之间的单路通信，人有人的语言，机器有机器的语言，人和机器都是靠消息传递信息和指令的。

消息的类型大致有：同步与异步，返回、阻止和超时。

（4）激活

表示这个时间，对象实现操作。时序图是将交互关系表示为二维图的。纵轴为时间，横轴为在协作中各个独立的对象。对象存在时用一条虚线表示，当对象的过程处于激活状态，生命线是一个双道线。消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。

（二）建模

主要是按时间顺序对控制流建模
（三）实例

首先要分析用例的正常流

，学生刷卡上机

，系统记录学生上机时间，同时显示学生的基本信息

，此时的学生信息时系统更新

，系统根据学生上机时长和类别计算上机费用

，系统保存学上上机信息。

，学生下机

，系统记录时间，跟新数据库

，数据库更新，反馈学生信息

，系统根据学生上机和下机时间、类别计算上机费用

，系统保存学生上机费用

然后开始画图：

）创建时序图

）添加对象并设置对象属性，持续性

）添加消息（消息的编号，显示或取消激活显示）

如图：（图片有错，不提供参考）


版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/tsj11514oo/article/details/38179121

协作图（Collaboration Diagram/communication Diagram）/通信图

协作图(Collaboration Diagram /Communication Diagram，也叫合作图)是一种交互图（interaction diagram），强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。使用协作图来说明系统的动态情况。

下面这张图介绍协作图的基本内容：


下面一张图是一个协作图的实例，创建课程的协作图：

由于协作图和时序图在语意上是相通的，所以可以互相转换，下面是利用ROSE把上面的协作图转换成的时序图的实例，可以直接使用功能进行转换：


由于协作图和时序图在作用上可以替代的，在使用中，一般有了时序图就没有必要使用协作图。

状态图
1.概述：

状态图（Statechart Diagram）主要用于描述一个特定的对象的所有可能状态以及由于各种事件的发生而引起的状态之间的转换。

2.构成要素：

状态图由状态、转移和事件组成。联合使用状态和转移可以更好地建模它们，有时需要包含决策点和同步条来显示更高层次的细节信息。

2.1状态（States）：

在对象的生命周期中满足某些条件、执行某些活动或等待某些事件的一个条件或状况。所有的对象都有状态，状态是对象执行了一系列活动的结果，当某个事件发生后，对象的状态将发生变化。



状态图中可以包含0个多个开始状态，也可以包含多个结束状态。模型不必同时具有开始和结束状态，因为模型可以总是运行，从不停止。

2.2转移（Transitions）：

两个状态之间的一种关系，表示对象将在第一个状态中执行一定的动作并在某个特定事件发生或某个特定条件满足时进入第二个状态。



2.3事件：

使状态发生变化的某时刻发生的动作或活动，用来指示是什么触发了转移从而导致状态发生了改变。事件通常在从一个状态到另一个状态的转移路径上直接指定。

2.4判断：

判断点通过对事件判断分组转移到各自方向，提高了状态图的可视性。



2.4同步：

使用同步和活动图一样是为了说明并发工作流的分叉与联合。



3.机房实例（注册部分）：总结：状态图重点在与描述对象的状态及其状态之间的转移，与活动图区别在于状态图注重的是行为的结果，活动图更注重是行为的动作。
活动图(Activity Diagram)
“活动图”可通过一系列操作将业务流程或软件进程以工作流的形式显示出来。这些操作可以由人、软件组件或计算机来执行。

使用活动图可以描述多种类型的流程，如下：

1、用户和您的系统之间的业务流程或工作流。

2、某一用例中执行的步骤。

3、软件协议，即允许在组件间进行的交互序列。

4、软件算法。

下面用一张图来介绍活动图的基本内容



下面是用rose 和 onenote结合画的一张活动图的实例，基本囊括了活动图的重要元素。


6 组件图(ComponentDiagram)、配置图(Deployment Diagram)

组件（构件图）和配置图（部署图）是面向对象系统的物理建模时使用的两种图。



组件图：描述软件组件以及组件之间的关系。

组件图元素：组件、接口、依赖关系

组件：是定义良好接口的物理实现单元，遵从同一组接口，提供实现物理的可替换的部分。

接口：一个类提供另一个类的一组操作。

依赖关系：一种使用关系（这里不做详解）


构件与结构之间关系：

构件与构件之间关系：依赖

构件与其对应接口之间关系：实现

导出接口：组件实现的接口，由提供操作的组件提供

导入接口：访问服务的组件使用导入接口


机房收费系统构件图：机房收费系统引用控件与报表生成器，导出EXcel，打印报表，通过代码与数据库连接实时更新数据。



配置图：描述系统硬件的物理结构以及如何将软件部署在硬件上。用于对系统的实现视图建模，主要是为了描述系统各个物理组成部分的分布、提交、安装过程。

组成元素：节点、关系

机房收费系统部署图：



github上的地址

补充：UML是不断修订的 在UML 中，主要是使用了9 张图，到了UML 2 中有新增了几张图；概览




注意：UML 1.0中协作图改为了UML 2 通信图。

  
我们知道任何一款软件从0到1的过程中都需要将用户口头的需求转化成类图、用例图等图形，通过画类图、用例图等可以和用户形成良好的沟通，通过使用这些图来表示抽象概念或各个概念之间的联系，这就是UML（Unified Modeling Language，统一建模语言）承担的工作，需要注意的是UML并不是OOA（Object Oriented Analysis，面向对象分析）、OOD（Object  Oriented  Design，面向对象设计 ），它只是一种表示方法，方便我们在概念层面和别人交流。


UML图有用例图、类图、顺序图、协作图、构建图、部署图等，它大体上可以划分为两类，一类是专门描述结构，即描述静态特性，最典型代表是类图、包图、部署图、主件图、对象图，另一类是描述的是行为（动态特性），最典型代表是顺序图、用例图、状态图、活动图。本期我们只介绍最常用的三种图：类图、顺序图和用例图。



类图（Class Diagram）

类（Class）封装了数据和行为，它具有相同的属性、操作、关系的对象集合。类之间的关系包含两类，一类是静态关系，另一类是动态关系。而静态关系通常以类图展示，动态关系依靠顺序图表现。

类图展示了类和类之间的静态关系，它和具体实现和语言无关。它主要包含三方面，其一是类名，其二是属性部分，其三是方法部分。需要注意的是减号表示private，加号表示public，井号表示protected，下划线表示static。具体如下图所示。



类之间主要有以下三种关系：关联关系（Has a）、继承关系（Is a）和 依赖关系。其中，关联关系又包含聚合关系和组合关系这两种特殊的关联关系，三者关系如下图所示。



关联关系（Association）

当一个类中的属性指向另一个类时，那么这两个类的关系就是关联关系。关联关系通过实线连接，三角箭头指向的是被拥有的对象。举个栗子吧，一台打印机需要一个文档，Printer对象持有Document的实例。




聚合关系（Aggregation）


聚合也是一种关联关系，它表示整体和部分的关系，但是这两个类具有独立的什么周期，例如汽车和轮子的关系，汽车不存在的时候，轮子可以存在，它们之间的类图如下，聚合关系图除了实线和箭头之外，整体部分还有一个空心菱形。




组合关系（Composition）


组合关系是比聚合关系更强的关联，也表示整体和部分的关系，但是这两部分的生命周期存在”同生共死”的特性，即整体和部分对象一起创建，一起灭亡。例如：Document由Page组合而成，Page是由Document创建。



继承关系

继承是面向对象三大特性之一，这里就不做过多介绍了。



依赖关系

依赖关系体现为局部变量、方法的参数或者静态方法的调用。类之间用虚线相连，箭头指向被关联对象。



注意事项：1. 要关注关键的概念和类，不要事无巨细，画出所有的类；2. 不要只关注结构而忘了行为，类需要行为来验证。



顺序图/时序图（Sequence Diagram）

顺序图描述的是对象之间传递消息的时间顺序，它主要包含以下4中元素： 对象（参与者）、时间线、消息、激活。举例说明，:Employer 和：Activity表示的是对象，虚线表示时间线，1：applyExpense()表示消息，白色长方形表示的是激活状态。





用例图（Use case Diagram）


用例（Use case） 

在介绍什么是用例图之前我们先来看一下什么是用例，下面摘录于Wikipedia对用例的定义。




a use case is a list of actions or event steps,typically defining the interactions between a actor and a system, to achieve a goal

Use case 把系统当作黑盒子，只考虑和系统的交互，不考虑内部的实现，它是一种有效地需求分析技术。 

- 用例图 

用例图试图回答这几个问题，1.  软件系统是为谁建立的？2. 软件系统必须做什么事情？用例图描述了用户的各种需求，向用户展示了其所需要的系统的整体结构及其边界。它包含了3个重要概念：Actor、Use Case、Relation。

Actor（参与者）

Actor是指向软件系统发出请求，或享受系统服务的事物。Actor可以是人，也可以是系统：定时器、时钟、硬件设备。 



Use case（用例） 

用例是指系统的一个功能模块，并以” 动词+名称 ” 进行命名管理。 



Relation 

用例图的关系包含include（包含）和extend（扩展）。以ATM存取款为例，当我们需要取钱或存钱时，系统都需要我们先登录系统，登录之后取钱或存钱，因此取钱和存钱包含登录。 





当用户在注册时，有两个扩展点，一个是注册帮助，另一个是签署用户协议，当点击其中任意一个扩展点，对应扩展的Use case会被执行。 

 



实例-图书管理系统 

Actor是学生，Use case有借书、还书和浏览书，Actor和Use case之间的实线表示它们之间的关联关系。从这个实例更能证明用例图展示的是高层概念，不关注细节。 

最近在开发的过程当中，对于已有的代码，想将相关类绘制成UML类图，虽然现在有很多UML类图的优秀软件，比如ProcessOn（可视化编辑）、draw.io（可视化编辑）、PlantUML(代码生成)，其实看到这里我就想IDEA中有没有像PlantUML一样的自动生成的插件，本着怀疑的态度百度了一下，果然IDEA还是很强大的，这个插件都是自带的，接下稍微讲述如何利用IDEA生成UML类图的教程。

说之前先说一下Diagram这个单词，意思是图表; 示意图; 图解; [数] 线图的意思。

打开设置 File->Setting或windows下按Ctrl+Alt+S
	
在搜索框中输入Diagram，如下图：


如上所示，我们主要关心的只有Java Class Diagrams下面的几个单选框，分别对应红字部分，一般的UML类图只需要知道成员变量、构造器和方法（前面三个），其他的随意，设置好了之后我们就来演示一下，

选择需要的类文件，在编辑器中打开它
	
按Ctrl + Shift + Alt + U或Ctrl + Alt + U或右键选择，生成类Uml关联图，如下图：
	





上面的是类的UML图，下面的support包的UML图：



局限性：虽然这个很是方便，但是也有他自己的局限性，首先这个功能只能是根据类来自动生成的，所以对于设计类的时候就不行了，还是需要正规的UML图软件，还有就是对于专业的UML软件来说，这种自动生成的东西可能表达并不是非常的准确直观，特别是对于UML图有严格要求的人来说，显得格外重要。

1.1 UML基础知识扫盲

UML这三个字母的全称是Unified Modeling Language，直接翻译就是统一建模语言，简单地说就是一种有特殊用途的语言。

你可能会问：这明明是一种图形，为什么说是语言呢?伟大的汉字还不是从图形(象形文字)开始的吗?语言是包括文字和图形的!其实有很多内容文字是无法表达的，你见过建筑设计图纸吗?里面还不是很多图形，光用文字能表达清楚建筑设计吗?在建筑界，有一套标准来描述设计，同样道理，在软件开发界，我们也需要一套标准来帮助我们做好软件开发的工作。UML就是其中的一种标准，注意这可不是唯一标准，只是UML是大家比较推崇的一种标准而已，说不定以后有一个更好的标准可能会取代她呢!UML并不是强制性标准，没有法律规定你在软件开发中一定要用UML，不能用其它的，我们的目标是善用包括UML在内的各种标准，来提高我们软件开发的水平。

UML由1.0版发展到1.1、1.2、...，到现在的2.0、2.x，本书将会以2.x版本为基础开展讨论。网络上、书籍、还有各种UML工具软件，各自基于的UML版本可能会不一样，大家在学习过程中可能会有一些困惑，不过没关系，本课程在某些关键地方会描述1.x与2.x的差异。

UML有什么用?

有很多人认为，UML的主要用途就是软件设计!也有人认为，如果你不是开发人员，是难以理解UML的。

然而我第一次在实际工作中应用UML的却不是软件设计，而是软件需求分析!当时我们和客户面对面沟通调研需求的时候，直接用类图、顺序图、活动图、用例图等UML。我们并没有因此和客户无法沟通，反而是沟通得更加顺畅。客户在我们的引导下，很快就会读懂这些UML图，因为UML图，让我们和客户的沟通效率和效果更好!你可能觉得很神奇，在后续章节中，我将会为你逐一揭开神奇背后的“秘密”。

UML可帮助我们做软件需求分析和软件设计的工作，在我工作中大概各占了50%的比例，当然在你的实际工作中不一定是这样的比例。UML会让你的需求分析或者软件设计工作更上一层楼，本书将会介绍UML在需求分析方面的最佳实践。

告诉你一个秘密，UML应用于软件需求分析时，其学习门槛将会大大降低!语法复杂度会降低，而且你基本不需要掌握软件开发的知识。只要你对软件需求分析感兴趣，认真学习和应用UML，就很有机会成为软件需求分析高手。

UML的分类

结构型的图(Structure Diagram)

类图(Class Diagram)

对象图(Object Diagram)

构件图(Component Diagram)

部署图(Deployment Diagram)

包图(Package Diagram)

行为型的图(Behavior Diagram)

活动图(Activity Diagram)

状态机图(State Machine Diagram)

顺序图(Sequence Diagram)

通信图(Communication Diagram)

用例图(Use Case Diagram)  

时序图(Timing Diagram)

本书所描述的UML的各种图的名字，以上述的为准。

UML各种图的中文译名，因为翻译的原因可能会有所不一样，如：Sequence Diagram和Timing Diagram有时候都会被译成“时序图”，这是最让人困扰的地方!Sequence Diagram 除了被译为顺序图，还有序列图的译法。

中国软件行业协会(CSIA)与日本UML建模推进协会(UMTP)共同在中国推动的UML专家认证，两个协会共同颁发认证证书、两国互认，CSIA与UMTP共同推出了UML中文术语标准，该标准全称为：CSIA-UMTP UML中文术语标准v1.0(本书后文将会简称为UML中文术语标准)。本书将会遵循UML中文术语标准，并且我们会同时给出中文译名和英文原名，大家要留意看英文名字噢，这样能帮助你不会被众多的中文译名混淆。

UML图为什么会分为结构型和行为型两种呢?

顾名思义，结构型的图描述的是某种结构，这种结构在某段时间内应该是稳定的，“静态”的;而结构型的图描述的是某种行为，是“动态”的。

分析系统需求时，我们会面对很多业务概念，它们之间会有某些关系，这些内容可以看成是“静态”的，我们可以利用UML的结构性的图来分析。同时，业务会涉及大量的流程、过程等，这些内容是“动态”的，我们可以用行为型的UML图来分析。

在我们软件设计时，我们需要考虑需要那些类、哪些构件、系统最后怎样部署等，这些内容可以看成是“静态”的，我们可以利用UML的结构型的图来设计。同时，我们也需要考虑软件如何和用户交互，类、构件、模块之间如何联系等“动态”内容，我们可以利用行为型的图来设计。

所谓“静态”和“动态”不是绝对的，下文我们将会进一步介绍结构型的UML和行为型的UML。通过下面的学习，你将会初步认识UML的各种图，你可能还会有很多问题，本章的主要目的是让你对UML有一个宏观的认识，带着你的问题继续阅读后面的章节吧!

1.2 结构型的UML(Structure Diagram)

类图(Class Diagram)

请看下面这个类图：



图 1.1 某模具系统类图

此图截取自某模具管理系统的业务概念分析图，图中一个一个的矩形就是类，这些类之间有各种线条连接，这些线条表示类之间的关系。类图是分析业务概念的首选，类图可能是使用率最高的UML图。

再看下面这个Person类图，这时软件设计时用到的一个图：



图 1.2 Person类图

该Person类有以下属性(Attribute)：Name(姓名),Sex(性别),Department(部门)等，有以下操作(Operation)：Work(工作)等。类有属性和操作，但用类图分析业务模型时，往往不需要使用操作，如图1.1中的类就只有属性。

Attribute有特性、特征等译法，Operation也称作方法，但本书遵循UML中文术语标准，即Attribute为属性，Operation为操作。

对象图(Object Diagram)

一般情况下只有在软件开发中才会使用到对象图，下面的内容以开发的角度来说明对象图，如果你没有开发经验，阅读起来可能有一点难度。

图1.2中的Person类，用代码实例化如下：

Person person = new Person();

……

类(Class)实例化后就是对象(Object)，对象person是类Person的实例，上述代码可以用对象图表示如下：



图 1.3 Person类的对象图

对象图和类图的样子很相似，对象是类的实例化，“person : Person”表示对象person是类Person的实例。对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象，该图只画了一个对象，其目的是尽量简化以便读者的理解什么是对象图。

在需求分析工作中基本上不需要使用对象图，从严谨的角度来看某些情况下应该使用对象图，但我往往还是会用类图来处理，这样更加简便而且容易理解。我们将在类图一章再次讲解对象图。

构件图(Component Diagram)

构件图也叫组件图，两个名字均符合UML中文术语标准。

一辆汽车由轮子、发动机等物理部件组成，一个软件往往也是由很多“物理部件”(如：控件、重用构件等)组成的，构件图就是用来描述软件内部物理组成的一种图。下图是某权限构件设计图：



图 1.4 某权限构件设计图

图1.4右上方有这样标志 的矩形表示一个构件，构件可以再包含构件。

软件需求分析工作中，需要用到构件图的情况不是很多，以下情况除外：

1. 待开发的系统需要与第三方的系统、原有系统、某些老系统等交互，这时可用构件图描述交互要求。

2. 客户对软件设计有某些特殊要求，这时可用构件图来描述要求。

构件图有时不会单独使用，还会和部署图一起结合使用。

部署图(Deployment Diagram)

部署图是用来描述系统如何部署、本系统与其他系统是怎样的关系的一种图，如下图：



图 1.5 某24小时便利店的管理系统部署图

图中一个个立体的矩形是部署图的“节点”，一个节点表示一个物理的设备，节点之间的线条表示节点间的物理连接关系。

大部分客户都会具备一定的IT基础环境(如具备局域网、一些服务器、某些软件平台等)，软件系统需要基于当前的IT基础环境来规划，这时我们可以使用部署图来做这个规划。

分析系统的需求，不能忽略系统架构、部署、IT架构等方面的要求，我们要基于客户当前的IT基础环境，做一个最符合客户利益的规划。

要活用构件图、部署图来分析需求，需要具备一定的IT基础架构知识和软件设计知识，如果你还不具备相关知识，那么可以考虑抓紧补充相关知识。不过需求分析工作更多的还是分析业务，提炼功能性需求，这部分工作能做好是相当不容易的事情。对于技术方面的非功能性需求分析，可交由有技术背景的专业人士负责。

包图(Package Diagram)

Package有“打包”的意思，包图的主要用途是“打包”类图。用类图描述业务概念时，很多时候会因为业务类太多，而导致类图非常庞大，不利于阅读，这时可以将某些类放入“包”中，通过包图来组织业务概念图。

下图是包图的一个示例：



图 1.6 包图

图中好像文件夹样子的就是一个“包”，包之间的线条表示包之间的关系。

1.3 行为型的UML(Behavior Diagram)

活动图、状态机图、顺序图处于三种不同的角度来描述流程，是分析业务流程的三种不同利器，下面将会逐一说明。

活动图(Activity Diagram)

我们将起床到出门上班这个过程画成活动图，可能是这样的：



图 1.7 起床到出门上班的活动图

活动图中的一个圆边框框表示一个“活动”，多个活动之间的带箭头线条表示活动的先后顺序，该图只是表达了一个顺序流程，活动图还可以表达分支结构。如果你以前曾学过流程图的话，你会发现活动图和流程图很相似。活动图可能是三种能表示流程的UML图中最接近我们思维习惯的一种，下面来学习另外两种能表达流程的图。

状态机图(State Machine Diagram)

状态机图又叫状态图，但状态图这个译名并没有译出Machine的意思。

状态机图从某个物品的状态是如何变化的角度来展示流程，下图某请假条审批流程：



图 1.8 请假处理流程

整个请假审批流程是围绕“请假条”这个物体进行的，随着不同的审批阶段，请假条具备不同的状态。我们分析业务流程时会发现很多流程其实是围绕某个物品进行的，这时可考虑使用状态机图。

顺序图(Sequence Diagram)

你去餐厅吃饭，向服务员点餐到服务员送菜上来，这个过程用顺序图可表示如下：



图 1.9 点菜的顺序图

该图有三个“小人”，每个“小人”下面的文字说明(如：顾客)表示其代表的角色。角色与角色之间有一些线条链接，表示角色之间是如何交互的。该图表示的意思是：顾客向服务员点菜后，服务员将点菜信息传递给厨师，然后厨师做菜，最后再由服务员送菜给你。

点菜过程涉及几个环节，每个环节均由不同的角色来负责，如果遇到类似的情况，你可以考虑使用顺序图来分析。用顺序图来分析的好处是能清晰表达整个过程所参与的角色，角色与角色之间的关系，各角色是如何被卷入这个过程当中的。

通信图(Communication Diagram)

UML1.1时，该图英文名为Collaboration Diagram;UML2.x时，英文名为Communication Diagram。将英文名字直接翻译，原来的英文名字可译为协作图，而新的英文名字译为通信图。

通信图是顺序图的另外一种画法，点菜的顺序图，如果用通信图来画可表示如下：



图 1.10 点菜的通信图

三个“小人”分表表示三种角色：顾客、服务员、厨师;角色之间有直线联系表示他们之间有关系;带序号的文字和箭头，表示角色之间传递的信息。

顺序图更强调先后顺序，通信图更强调相互之间的关系。我觉得顺序图实用性更好一点，比通信图能表达更多的信息，更容易读懂，在需求分析工作中我基本不会使用通信图。

用例图(Use Case Diagram)

下图是用例图的示意图：



图 1.11 用例图

用例图表达的是什么角色通过软件系统能做什么事情，我们可以使用用例图系统地表达软件系统的绝大部分需求。

时序图(Timing Diagram)

时序图也叫时间图，时序图是UML中文术语标准的说法，而时间图不是标准的说法。

时序图是表示某东西的状态随时间变化而变化的一种图，参见下图：



图 1.12 灯的开关状态随时间变化图

此图表示在0秒到30秒，灯的状态是关的，30-60秒灯的状态为开，60秒后状态为关。

在实际工作中我基本上没有试用过时间图。

下面通过这个表格来总结一下我在需求分析工作中应用各种UML图的情况：



表 1.1 各种UML图实际应用情况

上表是根据我的工作经验总结的，相信会适用于很多情况。但每个人的工作经历、情况、环境等不太一样，上表仅作参考。

1.4 如何学好UML?

UML的认识误区

误区一：认为UML主要用于软件设计。

前面的文章你可以看到，UML除了用于软件设计，还能用于需求分析，而本书就是专门来说明如何在需求分析工作中活用UML的。

误区二：客户无法理解UML，在需求分析中应用UML实际意义不大。

我还不熟悉UML时，确实也有这样的怀疑，而实际工作中发现UML恰恰成为与客户沟通的良好桥梁!UML其实不难读懂，只要稍加解释客户马上就能读懂。我在所有的项目需求分析工作中，都直接使用UML图与客户沟通，并且给客户签署的需求规格说明书中含有大量的UML图。

UML能直观、形象、严谨地描述出业务概念、业务流程、客户的期望和需求，只要稍加引导客户，客户将会很容易读懂UML，甚至会主动使用UML与项目组交流。我曾经遇到过客户向我们索要画UML图的工具，客户见识过UML的威力后，也想在自己实际工作中使用。

误区三：认为UML语法繁杂，难以学习和应用。

某些UML资料和书籍可能将UML说得过于复杂了，官方的UML标准资料也确实是枯燥难懂、人见人晕。我刚开始学习UML时，也看过一些UML书籍，觉得UML的语法太多、太复杂、太容易混淆了!

在实际工作中，其实经常需要用到的UML语法并不多，而且很容易掌握。当我们在需求分析方面应用UML时，需要掌握的语法更少(在软件设计方面应用UML时需要掌握稍多一点的语法)。“二八原则”在这里完全适用，我们经常用到的UML语法，其实只占全部语法的20%，而本书将会重点介绍实用性强的UML语法。

误区四：UML用途不大。

很多人推崇UML，但也有不少人士不太认可UML。不认可的原因主要是因为一些人士学习UML后，发现在实际工作中发挥的作用并不是很大，有时候不用UML效果更好。

我不敢说UML能帮助我们解决所有问题，至少从我的多年使用经验上来说，UML对于提升我的需求分析能力帮助还是很大的。有人之所以感觉UML不太好用，我觉得原因还是只掌握了UML的形而没有领会UML的神。UML的常用语法可能几天就能学会了，而要真正做到“thinking in UML”却没有这么容易，需要长期的锻炼。

我的学习经历

我读大学时没有听说过UML，出来工作两三年后才开始接触UML，当时的感觉就好像找到了新大陆，很想好好发掘一番!而我当时的运气还是相当不错的，我的上司是UML达人，他带领我参加了项目的需求分析工作。我很快就见识了UML威力，在他的言传身教之下，迅速掌握了UML。

在那个项目以后，我便独立担当了多个项目管理及需求分析工作，没有一个项目不应用UML，而且我毫不保留地传授UML知识给项目组的其他成员。多年的工作进一步磨练了自己，对UML在实际工作中的应用有了更深刻的认识，形成自己的一套方法。

我的UML知识绝大部分来自于工作实践，期间虽然也看过一些书籍，但对我的帮助很少。当然我最大的得益还是来自我的UML启蒙老师，他在实际工作中教会了我UML，帮助我踏上自我成长的道路。

我的UML学习最大体会就是：实践太重要了!如果有名师指导则会让你事半功倍!希望本书能成为你在实际工作中学习和应用UML的好帮手!

UML学习难点

学UML之难，不在于学习语法，关键是要改变思维习惯。UML是一种新的工具，但同时也是代表了一种新的先进的思考方法，如果不能掌握这样的方法，只能学到了UML的形，而没有掌握其神髓。

要用好UML，你需要在平时多多培养下面的能力：

1. 书面表达能力。

2. 归纳总结能力。

3. “面向对象”的思维能力和抽象能力。

平时你可以利用各种机会来提升第1和第2种能力，如多写写项目文档、写写日记或博客等，多思考和总结平时自己的工作得失等。

第3种能力说起来有点虚，大家在大学中可能也学过相关知识。训练这种能力的最好方法就是多应用类图，我们将会在类图的章节再重点介绍，通过实例来体会什么才叫“面向对象”!

本书将会重点培养你的这三种能力，只要你有进步之心，多练习、多实践、多思考、多总结，一定会取得长足进步!

1.5 小结

本章的主要目标是让你不需要阅读全书的情况下，就可以了解到UML的全貌，大概知道UML各种图的用途，同时给你说明学习UML的难点，为最终活用UML做好准备。下面我们一起来复习一下本章的主要内容：

UML是Unified Modeling Language的简称，是软件开发界的一套标准，UML不仅可用于软件设计，也可以用于软件需求分析。但UML并不是强制标准，我们应该善用包括UML在内的各种标准来提高我们的水平。

UML可分为两类：结构型、行为型，结构性的UML有：类图、对象图、构件图、部署图、包图，行为型的图有活动图、状态机图、顺序图、通信图、用例图、时间图。

类图是业务概念模型分析的有利武器，也是面向对象分析能力的强有力训练工具。

对象图在需求分析工作中并不常用。

构件图、部署图是分析IT基础架构、软件架构等方面需求的有利分析工具，但需要你具备IT基础架构、软件设计方面的知识和经验。

包图可用来组织类图，在需求分析工作中应用的机会不是很大。

活动图、状态机图、顺序图是分析业务流程的强力武器。活动图的表达思路与流程图很类似，很容易掌握，而且大部分情况下都可以使用活动图来分析业务流程;某流程如果是围绕某个物品进行，该物品在流程中转换多种状态，那么使用状态机图来分析是首选;用顺序图来分析的好处是能清晰表达整个过程所参与的角色，角色与角色之间的关系，各角色是如何被卷入这个过程当中的。

通信图可以看作是顺序图的另外一种表达形式，顺序图更强调先后顺序，通信图更强调相互之间的关系。而从我的工作经验看，顺序图更加实用一点。

有人会将用例图称作“公仔图”，用例图表达的是什么角色通过软件系统能做什么事情，我们可以使用用例图系统地表达软件系统的绝大部分需求。

时间图是表示某东西的状态随时间变化而变化的一种图，我在实际工作中很少有机会能用到这种图。

学UML之难，不在于学习语法，避免陷入UML的认识误区，多练习、多实践，培养良好的“think in UML”思想，锻炼面向对象分析的能力，成为活用UML的需求分析高手不远矣!

用例图实践：https://edu.csdn.net/course/play/2086/32567

活动图实践：https://edu.csdn.net/course/play/2086/32569

状态图实践：https://edu.csdn.net/course/play/2086/195362

软件工程实践者的研究方法视频教程： https://edu.csdn.net/course/detail/2086