UML详解

1.what is the UML

UML 全称是 Unified Modeling Language（统一建模语言），它以图形的方式来描述软件的概念

2.它存在的目的

UML 的目标是通过一定结构的表达，来解决现实世界到软件世界的沟通问题。

3.什么是模，什么是建模

1）模简单讲，就是人、事、物和规则。

特定的事 = 特定的人的行为 + 特定的物 + 特定的规则

比如说：，一个特定的事件（比如购物）里，会有特定的人的行为（比如甲乙丙要上电商网站），会有特定的物（比如货），有特定的规则（比如注册会员），共同完成购物这件事。

2）建立模型的关键就是弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人、事、物之间的关系定义出来，一个模型也就基本成型了。

4.为什么要用UML（同目的）

统一建模语言(UML)就试图用标准化的语言来覆盖整个软件过程，让不同团队不同角色可以用相同的语言顺畅的沟通

5.UML的过程

第一个阶段是通过建模将现实世界转为业务模型。业务模型真实映射了参与者（业务活动的驱动者）在现实世界的行为

第二个阶段是对业务模型概念化，建立适合计算机理解和实现的模型，也就是概念模型，或者叫分析模型。分析模型向上映射了原始需求，向下为计算机实现规定了一种高层次的抽象，是一种过渡模型。

第三个阶段是对概念模型实例化，得到相对详细的设计模型。

在设计模型中，概念模型中的边界类可以被转化为操作界面或者系统接口；控制类可以被转化为计算程序或控制程序，例如工作流、算法体等；实体类可以转化为数据库表、XML 文档或者其他带有持久化特征的类。

同样的概念模型会因为选择不同而得到不同的设计模型。比如技术选型上使用不同的编程语言，不同的中间件就会得到不同的设计。

换句话说，设计模型是概念模型在特定环境和条件下的实例化，实例化后的对象行为执行了概念模型描述的那些信息。

6.核心元素

1）版型：也称「类型」或「构造型」。是对 UML 元素基础定义的扩展，在元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。

比如，我们前边提到的「边界类」、「实体类」、「控制类」都是类的版型。

2）参与者

参与者定位：事件的第一驱动者，也是系统的服务方。比如你在电商网站购物，你就是参与者。

3）用例

用例定位：系统执行的一系列操作，并生成参与者可以观察的值。比如你在电商网站交易，会生成在线订单，用户下单就是一个用例。

用例版型：

业务用例：用于需求阶段业务领域建模。与计算机系统建模无关，比如下单可以不依赖在线服务，而只是线下签署协议。业务建模的目标是让需求人员和客户能够达成共识。
业务用例实现：业务用例的一种实现方式，一个业务用例可以有多种实现方式。比如下单后的支付，可以用现金，也可以银行卡转账，还可以第三方支付。
系统用例：用于定义系统范围、获取功能性需求。也就是我们常挂在嘴边的用例。像业务用例中提到的线下签约的方式，就不会纳入到系统用例中，但如果是电子签约的话，就可以成为系统用例了。
系统用例实现：系统用例的一种实现方式，一个系统用例可以有多种实现方式。比如下单后的支付，可以接入微信支付接口，也可以接入支付宝支付接口。
你会发现，同是用例的版型，业务用例与系统用例的区别就在于业务用例是客户业务视角，系统用例是系统视角。

4）边界

边界定位：用于业务建模和系统建模阶段的分析，保证分析粒度在一定的范围内，不会扩散。

比如一个电商网站按领域职责作为边界，会有店铺域、商品域、会员域、交易域、支付域和营销域等。各域只负责域内的事情，就能够减少混乱紧耦合的局面。

5）业务实体

业务实体定位：它代表参与者执行业务用例时所处理或使用的事物，特别用于在业务建模阶段建立领域模型。业务实体是类（class）的一种版型。

业务实体的结构：包含属性和方法。属性用来保存业务实体特征，方法用来访问业务实体。比如一台电视，把它看成一个业务实体的话，它的属性有运行状态和音量，它的方法就是遥控器，我们可以开、关、调声音，但是我们不可以试图让它飞起来——因为它没有这样的方法。

6）包

包定位：容纳并为其他 UML 元素分类。比如 Java 后端经常会提供 jar 包给接入方使用。

7）分析类

分析类定位：用于代表系统中主要的职责簇，由此产生系统的设计类和子系统。

边界类：用于对系统外部环境和内部运作之间的交互进行建模。比如现实世界的窗户，计算机世界的网页。
控制类：用于对用例特有的控制行为进行建模。比如显示逻辑和业务逻辑通过控制层分离的 MVC 架构。
实体类：用于对需要存储的信息和相关行为进行建模。源于业务模型中的业务实体。

分析类的抽象层次较高，比设计和实现要稳定很多，因此方便维护，也更容易获得一个稳定架构来指导整个软件的开发。

8）设计类

设计类定位：是系统实施中一个或多个对象的抽象，由此映射到实现代码，依赖于实施语言。

设计类结构：

类型：对对象某一方面特征的归纳和抽象。映射到编码中的 class。
属性：对象特征。映射到编码中的 field。
方法：访问对象属性的唯一途径。映射到编码中的 method。

9）关系

关系定位：抽象出对象之间的联系，让对象构成某个特定的结构。

关系分为以下几种：

关联（association）
- 关系：是一种拥有的关系，即一个类知道另一个类的属性和方法；比如老师与学生可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
- 箭头和连线：带普通箭头的实心线，指向被拥有者。
- 适用场景：类图。
依赖（dependency）
- 关系：是一种使用的关系，即一个类的实现需要另一个类的协助，是一种弱关系，随运行场景变化。比如削苹果时，人依赖于刀，脱离了这个场景，依赖关系就不存在了。
- 箭头和连线：带箭头的虚线，指向被使用者。
- 适用场景：类图。
泛化（generalization）
- 关系：是一种继承的关系，比如猫是动物的一种。
- 箭头和连线：带三角的实线，箭头指向父类。
- 适用场景：类图。
实现（realization）
- 关系：是一种实现的关系，比如用例和用例实现的关系，接口与实现类的关系。
- 箭头和连线：带三角的虚线，箭头指向用例实现或接口类。
- 适用场景：用例图，类图。
聚合（aggregation）
- 关系：是整体与部分的关系，且部分可以离开整体而单独存在。生命周期各自独立。如车和轮胎是聚合关系，轮胎离开车仍然可以存在。
- 箭头和连线：带空心菱形的实线，菱形指向整体。
- 适用场景：类图。
组合（composition）
- 关系：是整体与部分的关系，但部分不能离开整体而单独存在。同生同灭。如公司和部门是组合关系，没有公司就不存在部门。
- 箭头和连线：带实心(黑色实心：要死一起死，良心是黑的)菱形的实线，菱形指向整体。
- 适用场景：类图。
扩展（extends）
- 关系：用于在用例模型中说明向基本用例中的某个扩展点插入扩展用例。
- 箭头和连线：带箭头的虚线加版型<<extends>>。
- 特点：用例可选。
包含（include）
- 关系：用于在用例模型中说明在执行基本用例的用例实例过程中插入的行为段。
- 箭头和连线：带箭头的虚线加版型<<include>>。
- 特点：用例必需。

关联关系和依赖关系的区别：

关联关系是静态天然的联系，依赖关系是动态临时的联系。

10）组件

组件定位：实现特定功能的逻辑代码模块。比如分布式应用架构下，将业务目标拆成多个功能，每个功能作为组件独立部署。这样这些组件也能被其他场景复用。

11）节点

节点定位：表示应用程序的部署单元。比如分布式应用的环境中，服务器或设备会有很多，就需要通过节点来体现物理部署的情况。

7.核心视图

前面我们介绍了 UML 的核心元素，这些元素分别应用于面对对象分析设计的各个阶段，正是它们之间的相互组合，才形成了 UML 里的各种视图，最终指导软件设计。

1）结构视图

结构视图也称为静态视图。静态视图就是表达静态事物的。它只描述事物的静态结构，而不描述其动态行为。这里简要介绍的静态视图包括用例图，对象图，类图，组件图，包图和部署图。

1）用例图包含参与者、用例和关系这三种核心元素，不同的视角可以得到不同的用例视图，它展现了系统的功能性需求。所谓不同的视角，可以对应面向对象分析设计的三阶段。建立业务模型阶段，产出业务用例视图。建立概念模型阶段，产出概念用例视图。建立设计模型阶段，产出系统用例视图。就借阅图书的用例而言，业务用例视图如下，它是完全从业务角度出发，和计算机系统无关。2）类图
类图用于展示系统中的类及其相互之间的关系。类图建模常用的方式是从概念层，到说明层，最后到实现层这么一个抽象层次逐步降低和细化的过程。概念层类图位于业务建模阶段，这个阶段采用业务实体这个核心元素来表示。
3） 对象图
对象图是类图的实例，标识和类图基本相同。由于对象存在生命周期，对象图只能在系统某一时间段存在，因此对象图可以被想象成正在运行的系统在某一时刻的快照。比如一个正在运行的列车，如果用对象图来描述，某个时间点你会发现以下静态图片：当前的运行状态（运行中或停车中）
当前的乘客数量。（如果捕捉在不同的时间，该值会变化）
4）包图
在实际的项目中，建模过程获得的元素可能是非常多的，如果将这些元素的关系都绘制出来，看上去就会特别乱，特别复杂，也难以识别。那为了更好的理解和管理这些建模元素，我们就需要有规律的对元素进行组织。包图就起到了这么一个作用，通过包这个容器，可以从大到小、从粗到细地将建模元素组织起来，便于我们的分析，交流和细化。
5）组件图
当有些包能够被多个场景重复使用，那这个包就可以认为有着特定的功能，能够完成特定的目标。这种情况下，包就可以定义为组件，组件是一种特殊的包，既起到了普通包组织和容纳的作用，又能完成特定的功能。
6）部署图
部署图描述了物理上系统运行时的结构，包括系统中硬件的分布以及软件部署到硬件上的具体方式。部署图用于设计建模阶段，采用节点和关系两种核心元素来绘制。常用于分布式应用环境和多设备应用环境。

2）行为视图

行为视图也称为动态视图。动态视图就是描述事物动态行为的。动态视图不能独立存在，它必须基于一个静态视图或者 UML 元素，说明在静态视图规定的事物结构下它们的动态行为。

这里简要介绍的动态视图包括状态图、活动图、时序图和协作图。

状态图

状态图也称状态机，它描述了一个对象的生命周期，你可以把它理解成一台运行中的机器，这台机器负责这个对象在固定几个状态间的流转。

这个对象可以是业务实体对象，也可以是分析类对象，还可以是设计类对象。也就是说，在面向对象分析设计的三个阶段（业务建模，概念建模，设计建模），都可以用状态图来表达。

下图是一个产品的生命周期状态图。绿色部分是状态图相关的元素，红色部分是元素的解释。

从图中，我们可以看到，状态图有以下关键元素：

初始状态：它是状态机的起始位置，不需要事件的触发。用实心圆圈表示。

状态：状态是对象执行某项活动或者等待某个事件时的条件。比如要想执行产品入库动作，产品得是未入库的状态，如果想销售某个产品，产品得是入库的状态。

转移：转移是两个状态之间的关系，它表示当发生指定事件并且满足指定条件时，第一个状态中的对象将执行某些操作并进入第二个状态。比如产品入库这个动作，就将产品的状态从未入库转移到了已入库。

事件：事件是一个特定的动作或行为，有时候也包括系统时钟之类的定时器。如果条件满足，事件的发生将触发一个转移。比如产品销售这个动作，出发产品从已入库状态转移至已销售状态。

条件：条件是一个布尔表达式，当事件发生时将检查这个表达式的值。条件求值结果可能决定转移的分支，或者拒绝转移。条件有可能引用当前状态。比如产品合不合格这个布尔判断，决定了产品是可被销售，还是不可被销售。

最终状态：最终状态表示状态机执行结束，或者对象生命周期结束。用带环的实心圆圈表示。

活动图

活动图描述了为了完成某一个目标需要做的活动以及这些活动的执行顺序。

UML 中有两个层面的活动图，一种是用例活动图，它用于描述用例场景，常用于业务建模阶段，另一种是对象活动图，用于描述对象交互，常用于设计建模阶段。

下图是一个登机手续办理的用例活动图。绿色部分是活动图相关的元素，红色部分是元素的解释。

从图中，我们可以看到，活动图有以下几个关键元素：

起始点：起始点标记业务流程的开始。一个活动图仅有一个。用实心圆圈表示。

活动：活动是业务流程中的一个执行单元。比如办理登机手续需要出示机票和身份证这样的动作。

判断：判断根据某个条件进行决策，执行不同的流程分支。比如身份核对决定了你能否继续办理登机手续。

基本流：基本流表示最主要、最频繁使用的、默认的业务流程分支。比如身份核对的正常分支。

支流：支流是进行判断后走进的业务流程分支。比如图中无行李分支。

异常流：异常流表示非正常的、不是业务目标期待的、容错性的、处理意外情况的业务流程分支。比如身份证核对错误。

同步：同步分为同步起始和同步汇合。

同步起始表示从它开始多个支流并行执行。比如托运行李的处理和登机牌的打印操作，可以并行。

同步汇合表示多个支流同时到达后再执行后续活动。

结束点：结束点表示业务流程的终止。一个或多个。

用例活动图常常是从业务的角度上，分析要完成某个目标，要执行哪些活动。如果在系统设计的角度上，要表达完成目标需要的活动，就需要用到对象活动图。

时序图

时序图用于描述按时间顺序排列的对象之间的交互模式。

前面类图那一节有提过类有三个层次的观点：概念层、说明层和实现层，分别对应于面向对象分析设计的业务建模阶段、概念建模阶段和设计建模阶段，相应的，也可以在这三个层次上分别对业务实体对象、分析类对象和设计类对象绘制业务模型时序图、概念模型时序图和设计模型时序图。