UML学习笔记

一、UML介绍

UML（统一建模语言）是当前软件开发中使用最为广泛的建模技术之一

UML中的视图包括用例视图（Use Case View）、逻辑视图（Logical View）、实现视图（Implementation View）、进程视图（Process View）、部署视图（Deployment View），这5个视图被称作”4+1”视图。

每一个视图只关心系统的一个侧面，5个试图结合在一起才能反映系统的软件体系结构的全部内容。

每个视图需要用一组图（diagram）来描述，图中包含的是代表系统模型元素的各种图形符号，不同的图体现出着系统的不同的方面。正如我们观察一个物体一样，从不同的角度看到的局部图像可能会出现重叠，不同的视图之间也可能出现重叠的状况，所以同一个图可以从属于不同的视图。

二、用例图

用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象。强调这个系统是什么而不是这个系统怎么工作。

用例图与情节紧紧相关的。情节scenario是指当某个人与系统进行互动时发生的情况。下面是一个医院门诊部的情节。

“一个病人打电话给门诊部预约一年一次的身体检查。接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录。”

用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和。角色actor是发动与这个工作有关的事件的人或者事情。角色简单的扮演着人或者对象的作用。下面的图是一个门诊部Make Appointment用例。角色是病人。角色与用例的联系是通讯联系communication association（或简称通讯communication）

角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线。

一个用例图是角色，用例，和它们之间的联系的集合。我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分。注意一个单独的用例可以有多个角色。

用例图在三个领域很有作用：

• 决定特征（需求）。当系统已经分析好并且设计成型时，新的用例产生新的需求 客户通讯。
• 使用用例图很容易表示开发者与客户之间的联系。
• 产生测试用例。一个用例的情节可能产生这些情节的一批测试用例。

三、类图

类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统。类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响。

下面是一个顾客从零售商处预定商品的模型的类图。中心的类是Order。连接它的是购买货物的Customer和Payment。Payment有三种形式：Cash，Check，或者Credit。订单包括OrderDetails（line item），每个这种类都连着Item。

UML类的符号是一个被划分成三块的方框：类名，属性，和操作。抽象类的名字，像Payment是斜体的。类之间的关系是连接线。

类图有三种关系。

• 关联association－表示两种类的实例间的关系。如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联。在图中，关联用两个类之间的连线表示。
• 聚合aggregation－当一个类属于一个容器是的一种特殊关系。聚合用一个带菱形的连线，菱形指向具有整体性质的类。在我们的图里，Order是OrderDetails的容器。
• 泛化generalization－一个指向以其他类作为超类的继承连线。泛化关系用一个三角形指向超类。Payment是Cash，Check和Credit的超类。

一个关联有两个尾端。每个尾端可以有一个角色名role name来说明关联的作用。比如，一个OrderDetail实例是一个Order实例的项目。

关联上的方向性navigability箭头表示该关联传递或查询的方向。OrderDetail类可以查询他的Item，但不可以反过来查询。箭头方向同样可以告诉你哪个类拥有这个关联的实现；也就是，OrderDetail拥有Item。没有方向性的箭头的关联是双向。

关联尾端的数字表示该关联另一边的一个实例可以对应的数字端的实例的格数，通过这种方式表达关联的多样性multiplicity。多样性的数字可以是一个 单独的数字或者是一个数字的范围。在例子中，每个Order只有一个Customer，但一个Customer可以有任意多个Order。

下面这个表给出了最普遍的多样性示例。

多样性 意义
0..1 0或1个实例. n..m符号表示有n到m个实例
0..* or * 没有实例格数的限制（包括没有）.
1 只有一个实例
1..* 最少一个实例
每个类图包括类，关联和多样性表示。方向性和角色是为了使图示得更清楚时可选的项目。

四、包和对象图

为了简单地表示出复杂的类图，可以把类组合成包packages。一个包是UML上有逻辑关系的元件的集合。一般用于展示高层次的观点。

下面这个图是是一个把类组合成包的一个商业模型。
dependencies关系。如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B。包是用一个在上方带有小标签的矩形表示的。包名写在标签上或者在矩形里面。点化线箭头表示依赖。

对象图Object diagrams用来表示类的实例。他们在解释复杂关系的细小问题时（特别是递归关系时）很有用。

这个类图示一个大学的Department可以包括其他很多的Departments。

下面的对象图表示上面类图的实例。（大学：统计学，数学。UML中实例名带有下划线。只要意思清楚，类或实例名可以在对象图中被省略。）

每个类图的矩形对应了一个单独的实例。实例名称中所强调的UML图表。类或实例的名称可能是省略对象图表只要图的意义仍然是明确的。

五、 组合结构图

描述系统中某一部分（组合部分）的内部结构，包括该部分与系统其它部分的交互点。

（借书内部结构）

六、组件图

描述在系统实现环境中的软件构件和它们之间的关系。

七、部署图

描述系统所需的硬件构件的物理部署。

八、活动图

活动图主要目的是陈述活动与活动之间流程控制的转移。一般用于描述企业的本质性工作流程（Essential Workflow）。

活动是没有复用性的，为了能够清晰易懂地描述整个流程，为了避免一张图里包含太多信息，可以对其进行拆分。活动图是描述用例场景最常用的图，因为它可以最方便地描述角色职责（每一个泳道对应一个角色）。

应用：
业务场景建模：以业务主角（客户代表）为泳道，以从业务主角处获取的业务用例为活动来编排活动图。有助于发现及检查业务用例
用例场景建模：以业务主角和业务工人为泳道，以工作单元作为活动来编排活动图以描述用例场景。有助于获取概念用例、角色、业务对象，建立领域模型。

领域模型：
对业务有着重要意义的业务对象。如果在同一个或多个用例场景的不同活动中某个名称重复出现，那么它很可能是一个关键的业务对象，这个业务对象在不同活动中的状态以及它与活动图中其他名词间的关系很可能就决定了业务的结构。绘制出这个结构就能获得领域模型。

（对象交互泳道图）

（带角色职责的活动图）

九、状态图

状态图显示一个状态机。用于对模型元素的动态行为进行建模，具体地说就是对系统行为中受事件驱动的方面进行建模。可以说明业务主角和业务实体可能的状态。状态图可以简化对类的设计的确认。

我们可以用状态机描述业务实体对象、分析类对象和设计类对象。通常只用于描述单个对象的行为，如果要描述对象间的交互，最好采用时序图或协作图。

关键元素：
初始状态（起始位置，不需要事件的触发）、状态（entry/do/event/exit四个特定事件）、复合状态、转移、事件、条件、最终状态。

（图书生命周期状态图）

十、时序图

时序图用于描述按时间顺序排列的对象之间的交互模式，它按照参与交互的对象所具有的“生命线”和它们相互发送的消息来显示这些对象。在时序图中包含对象和主角实例，以及说明它们如何交互的消息。

时序图对我们确定对象职责和接口有着显著的作用。

因为类有三个层次：概念层、说明层、实现层。分别对应三个建模阶段，相应的时序图也有3个层次。

• 业务模型时序图：采用业务实体来绘制，其目标是实现业务用例。一般是先通过活动图发现业务实体，然后再绘制业务实体时序图。
• 概念模型时序图：采用分析类来绘制，目标是实现业务用例。但因为分析类本身代表了系统原型，这个阶段的时序图已经带有了计算机理解。
• 设计模型时序图：使用设计类为对象绘制，目标是显示概念模型中的某个事件流，一般以一个完整交互为单位，消息细致到方法级别。一般用于描述典型的交互场景。

（网上购买商品业务模型时序图）

（购买商品概念模型时序图片断）

（登录和查询事件流设计模型时序图片断）

十一、协作图

时序图强调消息事件的发生顺序，更方便于阐述事件流的过程，适于获得对调用过程的理解，而难以表达表达对象之间的关系。而协作图可以直观地展现对象间的关系，更适于获得对对象结构的理解。二者是可以互相转换的。

（网上购买商品业务模型协作图）

（购买商品概念模型协作图片断）

（登录和查询事件流设计模型协作图片断）