参考：

UML 是统一建模语言的简称，它是一种由一整套图表组成的标准化建模语言。

UML是一种可视化、可用于详细描述、文档化的语言。UML就像数学中的数字和加减符号一样，为所有软件开发的人员提供了一种图形化表达、标准化的语言。通过UML，软件开发人员可以描述软件结构和建模，并通过UML建立整个系统架构和详细文档。

UML图包括两个范畴：结构图和行为图。

结构图的目的是显示建模系统的静态结构。它包括类、组件和对象。例如UML静态结构图。

行为图的目的是显示系统中对象的动态行为。它包括对象的方法、协作和活动之类的内容。例如UML示例图、UML活动图、UML序列图。

UML类图学习(一)

UML类图的组成

UML是OO方法（面向对象设计分析方法）的核心。类图包含了：类和对象、类之间的关系、类之间的多重性。

类和对象

对象是描述客观世界中某个具体的实体，而类是对一类具有相同特征的对象的描述。对象是类的实例。在UML中类可表示为一个划分为三个格子的长方形，第一个格子包含类名，中间的格子包含类的属性，最后个格子包含类的操作。如下图：
CatUML
第一个方格，猫是这个类的类名。

第二个方格包含了两个部分，左边的+、-、# 表示了属性的可见性，分表表示public、private、protected
右边表示类的属性。

第三个方格同属性一样，包含了两部分，前面的符号表示了方法的可见性，后面表示类的方法。

类之间的关系

建立模型时，类不可能是单独存在的。比如猫咪的抓如果没有其他对象，抓这个方法显得毫无意义。UML类图中类之间的关系主要包括：依赖关系、泛化关系、关联关系、实现关系。关联关系包含了聚合关系、组合关系。

依赖关系

定义：有两个元素X、Y,如果修改X的定义可能会引起对Y的定义修改，则称Y依赖与元素X

产生依赖的原因有很多，通常表现为：一个类向另一个类发送信息；一个类是另一个类的数据成员；一个类是另一个类的操作参数等。如下图：

银行作为用户贷款操作的参数，用户依赖与银行，UML类图中用带箭头的虚线表示依赖关系。

泛化关系

泛化关系描述了一般事物与该事物中的特殊种类之间的关系。Java中的继承关系，父类就是子类泛化。
在UML中，泛化关系有三个条件：

父类所具有的关联、属性和操作，子类都应该具有
子类除了与父类一致的信息外还包含额外的信息
可以使用父类的地方，也可以使用子类实例

泛化关系使用带空心箭头的实线表示，箭头指向父类。如下图：

关联关系

关联关系表示两个类之间存在某种语义上的联系，比如一个公司有多个部门，一个部门有多个员工。
关联关系是所有关系语义最弱的关联。UML类中中，用实线来表示。

在上图中1、1..n是用来表示关联的两个类之间的数量关系。具体参见类的多重性。

聚合关系

聚合关系是一种特殊的关联关系。聚合关系表示了类之间的整体与部分的关系。整体与部分之间并没有相同的生命周期，整体消亡后部分可依旧存在。在UML中用带有空心菱形的实线表示，空心菱形指向代表整体的类。比如：电脑是由CPU、主板等组成的。UML表示图如下：

组合关系

组合关系也是部分和整体的关系，相对聚合关系，组合关系中的部分和整体联系更为紧密。整体与部分之间有相同的生命周期，整体消亡后部分也随之消亡。比如公司和部门之间的关系，一旦公司解散，部门也随之解散。UML中用带有实心菱形的实线表示。UML图如下：

组合关系

实现关系

实现关系用来规定接口和实现接口的类或组件之间的关系。接口可以看作是操作的集合，这些操作用于规定类或组件的服务。在UML中，用一个带空心箭头的虚线来表示。比如我们抽象出飞行这个动作，而对于不同的类可以通过实现飞行接口来作个性化处理。UML图如下：

实现关系

类的多重性

多重性是用来说明两个类之间的数量关系，表示为一个整数范围n...m，整数n定义所链接的最少对象的数目，m为最多对象数目（但不确定最大数时，可以*号表示）。常见的多重性如下表

表示	含义
0...1	表示0或者1的关联数目
0...*	表示0或多个关联数目
1...1	表示1个关联数目
1...*	表示1或多个关联数目
*	表示有多个关联数目

UML类图学习(二)

在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)

1. 泛化（Generalization）

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

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

2. 实现（Realization）

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

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

3. 关联（Association)

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

【代码体现】：成员变量

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

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

下图为自身关联：

4. 聚合（Aggregation）

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

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

【代码体现】：成员变量

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

5. 组合(Composition)

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

组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

【代码体现】：成员变量

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

6. 依赖(Dependency)

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

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

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

各种关系的强弱顺序：

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

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

UML学习归纳整理

UML的分类

主要分为两类：结构型的UML和行为型的UML

仅作参考，不同应用环境可能略有不同

其中基本不使用和很少会使用的我们不必深究，主要看实际应用较多的其他几种。

静态视图

1、类元
类元是模型中的离散概念，拥有身份、状态、行为和关系。有几种类元包括类、接口和数据类型。其他几种类元是行为概念、环境事物、执行结构的具体化。这些类元中包括用例、参与者、构件、节点和子系统。图列出了几种类元和它们的功能。元模型术语类元中包括了所有这些概念。

2、类元之间关系
类元之间的关系有关联、泛化、各种形式的依赖关系，包括实现关系和使用关系。
关联：对象通常要和其他对象发生关联，关联可以具有多层形式。多重性问题（一对一、一对多）。在UML中关联用一条直线来表示。
泛化：一个类继承了其他类的属性和操作。在UML中泛化用“从之类画一条带空心三角形箭头的连线指向父类”来表示。
依赖：一个类使用了另一个类。在UML中依赖用“从依赖类到被依赖的带箭头的虚线”表示。
聚集是关联的一种，聚集对象由部分对象组成。也就是整体与部分关联。在UML中用“整体和部分之间用带空心菱形箭头的连线连接”来表示。
组合是一种特殊的聚集，在一个组合对象中，部分对象只能作为组合对象的一部分与组合对象同时存在。在UML中用“整体和部分之间用带实心菱形箭头的连线连接”来表示。
实现：类和接口之间的关系被称为实现。在UML中实现关系用一个带空心三角形箭头加虚线来表示，箭头指向接口。

关系的种类图举例：
1.关联

2.依赖

3.限定关联

聚集和组成

5.泛化

6.实现关系

结构型的UML

(1)类图

请看下面这个类图：

某模具系统类图

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

Person类图

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

关于类图的详细讲解，<a href="http://blog.csdn.net/wudalang_gd/article/details/53365240">请戳这里</a>

(2)构建图

构件图也叫组件图，两个名字均符合UML中文术语标准。
一辆汽车由轮子、发动机等物理部件组成，一个软件往往也是由很多“物理部件”(如：控件、重用构件等)组成的，构件图就是用来描述软件内部物理组成的一种图。下图是某权限构件设计图：

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

待开发的系统需要与第三方的系统、原有系统、某些老系统等交互，这时可用构件图描述交互要求。
客户对软件设计有某些特殊要求，这时可用构件图来描述要求。
构件图有时不会单独使用，还会和部署图一起结合使用。

关于构建图的详细讲解，请戳这里

(3)部署图

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

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

图中一个个立体的矩形是部署图的“节点”，一个节点表示一个物理的设备，节点之间的线条表示节点间的物理连接关系。
大部分客户都会具备一定的IT基础环境(如具备局域网、一些服务器、某些软件平台等)，软件系统需要基于当前的IT基础环境来规划，这时我们可以使用部署图来做这个规划。
分析系统的需求，不能忽略系统架构、部署、IT架构等方面的要求，我们要基于客户当前的IT基础环境，做一个最符合客户利益的规划。
要活用构件图、部署图来分析需求，需要具备一定的IT基础架构知识和软件设计知识，如果你还不具备相关知识，那么可以考虑抓紧补充相关知识。不过需求分析工作更多的还是分析业务，提炼功能性需求，这部分工作能做好是相当不容易的事情。对于技术方面的非功能性需求分析，可交由有技术背景的专业人士负责。

关于部署图的详细讲解，请戳这里

行为型的UML

(1)活动图

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

起床到出门上班的活动图

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

关于活动图的详细讲解，请戳这里

(2)状态图

状态机图又叫状态图，但状态图这个译名并没有译出Machine的意思。
状态机图从某个物品的状态是如何变化的角度来展示流程，下图某请假条审批流程：

请假处理流程

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

关于状态图的详细讲解，请戳这里

(3)顺序图

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

点菜的顺序图

该图有三个“小人”，每个“小人”下面的文字说明(如：顾客)表示其代表的角色。角色与角色之间有一些线条链接，表示角色之间是如何交互的。该图表示的意思是：顾客向服务员点菜后，服务员将点菜信息传递给厨师，然后厨师做菜，最后再由服务员送菜给你。
点菜过程涉及几个环节，每个环节均由不同的角色来负责，如果遇到类似的情况，你可以考虑使用顺序图来分析。用顺序图来分析的好处是能清晰表达整个过程所参与的角色，角色与角色之间的关系，各角色是如何被卷入这个过程当中的。

关于顺序图的详细讲解，请戳这里

(4)用例图

下图是用例图的示意图：

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

关于用例图的详细讲解，请戳这里