UML学习（一）：基础概念入门

前言

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

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

为什么要将UML类图划分为结构型的图和行为型的图

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

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

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

结构型的UML(Structure Diagram)

类图(Class Diagram)

请看下面的类图：

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

我们以鸟这个类为例子：

羽毛和有角质喙没有牙齿是鸟的属性，而下蛋是他的操作。

如我们设定一个Person类：

该Person类有以下属性(Attribute)：Name(姓名),Sex(性别),Department(部门)等，有以下操作(Operation)：Work(工作)等。类有属性和操作，但用类图分析业务模型时，往往不需要使用操作。
Attribute有特性、特征等译法，Operation也称作方法，但本文遵循UML中文术语标准，即Attribute为属性，Operation为操作。

对象图

一般情况下只有在软件开发中才会使用到对象图。
对上文中提到的Person类，用代码实例化如下：

Person person = new Person();

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

对象图和类图的样子很相似，对象是类的实例化，“person : Person”表示对象person是类Person的实例。对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象，该图只画了一个对象，其目的是尽量简化以便读者的理解什么是对象图。在需求分析工作中基本上不需要使用对象图，从严谨的角度来看某些情况下应该使用对象图，但我往往还是会用类图来处理，这样更加简便而且容易理解。

构件图(Component Diagram)

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

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

上图是某点餐系统的组件图。
右上方有这样标志 的矩形表示一个组件，组件可以再包含组件。
软件需求分析工作中，需要用到构件图的情况不是很多，以下情况除外：

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

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

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

部署图(Deployment Diagram)

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

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

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

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

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

包图(Package Diagram)

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

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

行为型的UML(Behavior Diagram)

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

活动图(Activity Diagram)

我们将学生从进入考场到开始考试的过程画成活动图，可能是这样的：

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

状态机图(State Machine Diagram)

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

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

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

顺序图(Sequence Diagram)

赤壁之战，这个过程用顺序图可表示如下：

该图有六个“三国人物”，每个“三国人物”对应其历史作用。人物与人物之间有一些线条链接，表示角色之间是如何交互的。该图表示的意思是：因曹操大军压境，刘备迎战，将拟定策略的任务交给孔明（其实这里可以再下面画个虚线表示完成拟定策略的任务回给刘备），刘备根据策略将防守荆州的任务交给关羽，关羽将防守荆州前线的任务交给张飞，刘备再将联合孙权的任务交给孔明，孔明请求孙权的援兵相助，最后孔明借东风火攻曹操。

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

通信图(Communication Diagram)

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

用例图(Use Case Diagram)

下图是用例图的示意图：

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

时间图(Timing Diagram)

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

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

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

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

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

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

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

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

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

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

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

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

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

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