UML笔记—九种图（一）

1.面向过程和面向对象

面向过程

面向过程方法认为我们的世界是一个一个相互关联的小系统组成的，
然而如果系统比较简单，需求复杂度较低的情况下还是非常管用的，
但是在系统需求复杂度高的情况下就会很难把这个过程模拟出来。
这也是面向过程的困难所在。

面向对象

面向对象(Object Oriented,OO)方法将世界看做一个一个
相互独立的对象，相互之间并无因果关系。面向对象的精髓在
于抽象，同时也是困难所在，面向对象的成功在于成功的抽象，
而面向对象失败在于失败的抽象。

实现抽象过程我们需要以下几点：

• 一种把现实世界映射到对象世界的方法
• 一种从对象世界描述现实世界的方法
• 一种验证对象世界行为是否正确反映了现实世界的方法

2.UML

UML采用了“可视化”的图形方式来定义语言。
UML(United Modeling Language),统一建模语言,是一种基于面向对象的可视化建模语言.
UML 采用了一组形象化的图形(如类图)符号作为建模语言, 使用这些符号可以形象地描述系统的各个方面
UML 通过建立图形之间的各种关系(如类与类之间的关系)来描述模型.

为什么UML很重要？

为了回答这个问题，我们看看建筑行业。设计师设计出房子。施工人员使用这个设计来建造房子。建筑越复杂，设计师和施工人员之间的交流就越重要。蓝图就成为了这个行业中的设计师和施工人员的必修课。

写软件就好像建造建筑物一样。系统越复杂，参与编写与配置软件的人员之间的交流也就越重要。在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”。现在它已经成为了软件行业的一部分了。UML提供了分析师，设计师和程序员之间在软件设计时的通用语言。

UML被应用到面向对象的问题的解决上。想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的。一个模型model就是根本问题的抽象。域domain就是问题所处的真实世界。

模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的。记住把一个对象想象成“活着的”。对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）。对象的属性的值决定了它的状态state。

类Classes是对象的“蓝图”。一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）。对象是类的实例instances。

UML核心元素：

• 版型
• 参与者(actor)：系统之外与系统交互的某人或某事物
• 用例：定义一组用例实例，每一个实例都是系统所执行的一系列操作。
• 边界：边界决定视界；决定抽象层次；
• 业务实体：代表业务角色执行业务用例时所处理或使用的事物。
• 包：包是容器，如同文件夹一样。
• 分析类：用于获取系统主要的职责簇。
• 设计类：系统实施中一个或多个对象的抽象。
• 关系：抽象出对象之间联系。
• 组件：系统中实际存在的可以更换部分，实现特定功能。
• 节点：带有至少一个处理器，内存以及可能还带有其他设备的处理元素

面向对象的问题的处理的关键是建模问题。建模可以
把在复杂世界的许多重要的细节给抽象出来。许多建
模工具封装了UML（也就是Unified Modeling Language™）

2 questions??

一、什么是模型？模型是对现实世界的形状或状态的抽象模拟和简化。
二、为什么要建模？最简单的理由：为了能够更好地理解正在开发的系统。通过建模，可以达到四个目的：

• 1、有助于按照需求对系统进行可视化的分析
• 2、能够系统的结构或行为
• 3、给出了知道构造系统的模板
• 4、对做出的决策进行文档化

3.UML核心视图

3.1.UML中的视图大体可以分为两大类：

• 静态模型图：描述系统的静态结构。 包括：用例图，类图， 包图
• 动态模型图：描述系统行为的各个方面。 包括：时序图，协作图，状态图，活动图。

3.2.UML中的关系

UML 中的关系主要包括 9 种:

• 关联关系(association)：用一条直线表示；
• 依赖关系(dependency)：用带箭头的虚线表示；
• 扩展关系（extends）：用带箭头的虚线加版型extends表示；
• 包含关系（include）：用带箭头的虚线加版型include表示；
• 泛化关系(generalization)：用带空心箭头的直线表示；
• 实现关系(realization)：用带空心箭头的虚线表示；
• 精化关系(refine): 用带箭头的虚线加版型refine表示；
• 聚合关系(aggregation):用带空心菱形箭头的直线表示；
• 组合关系（composition）:用带实心菱形箭头的直线表示；

UML九种图：参考这篇文章

1、用例图（use case diagrams）

【概念】描述用户需求，从用户的角度描述系统的功能
【描述方式】椭圆表示某个用例；人形符号表示角色
【目的】帮组开发团队以一种可视化的方式理解系统的功能需求
【用例图】

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

角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线。
用例图在三个领域很有作用。

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

一般有以下用例视图：

1.1.业务用例视图

• 1.1.1.业务主角视图
  【概念】:从业务主角视图来展示业务主角在业务中使用哪些业务用例来达成业务目标。
  【作用】:有利于向业务主角确认其业务目标是否齐全，来检测是否有遗漏的业务用例。

• 1.1.2.业务模块视图：从业务模块视角来展示业务领域的业务目标。
• 1.1.3.其他视图

1.2 业务用例实现视图

1.3 概念用例视图

2.类图

【概念】显示系统的静态结构，表示不同的实体是如何相关联的
【描述方式】三个矩形
【目的】表示一个逻辑类或实现类，逻辑类通常是用户的业务所涉及的事物；实现类是程序员处理的实体

【类图】：

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

类图有三种关系。

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

3.包和对象图

【概念】类图的一个实例，描述系统在具体时间点上所包含的对象以及各个对象的关系
【对象图】

为了简单地表示出复杂的类图，可以把类组合成包packages。一个包是UML上有逻辑关系的元件的集合。下面这个图是是一个把类组合成包的一个商业模型。

dependencies关系。如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B。

包是用一个在上方带有小标签的矩形表示的。包名写在标签上或者在矩形里面。点化线箭头表示依赖

4.序列图（顺序图/时序图）

【概念】描述对象之间的交互顺序，着重体现对象间消息传递的时间顺序
【描述方式】横跨图的顶部，每个框表示每个类的实例或对象；类实例名称和类名称使用冒号分开
【目的】显示流程中不同对象之间的调用关系，还可以显示不同对象的不同调用。
【序列图】

5.协作图（Collaboration diagrams）

【概念】描述对象之间的合作关系，侧重对象之间的消息传递
协作图也是互动的图表。他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色。在序列图中，对象的角色放在上面而消息则是连接线。

对象角色矩形上标有类或对象名（或者都有）。类名前面有个冒号（：）。

协作图的每个消息都有一个序列号。顶层消息的数字是1。同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等。

6.状态图（Statechart diagrams）

【概念】描述对象的所有状态以及事件发生而引起的状态之间的转移
【描述方式】

• 1.起始点：实心圆
• 2.状态之间的转换：使用开箭头的线段
• 3.状态：圆角矩形
• 4.判断点：空心圆
• 5.一个或多个终止点：内部包含实心圆的圆

【目的】表示某个类所处的不同状态以及该类在这些状态中的转换过程

对象拥有行为和状态。对象的状态是由对象当前的行动和条件决定的。状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移。
我们的模型例图建立了一个银行的在线登录系统。登录过程包括输入合法的密码和个人账号，再提交给系统验证信息。

登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及 Rejecting。每个状态都有一套完整的转移transitions来决定状态的顺序。

状态是用圆角矩形来表示的。转移则是使用带箭头的连线表示。触发转移的事件或者条件写在箭头的旁边。我们的图上有两个自转移。一个是在Getting SSN，另一个则在上Getting PIN。

初始状态（黑色圆圈）是开始动作的虚拟开始。结束状态也是动作的虚拟结束。

事件或条件触发动作时用（/动作）表示。当进入Validating状态时，对象并不等外部事件触发转移。取而代之，它产生一个动作。动作的结果决定了下一步的状态。

7.活动图（Activity diagrams）

活动图activity diagram是一个很特别的流程图。活动图和状态图之间是有关系的。状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程。活动图告诉了我们活动之间的依赖关系。

【概念】描述满足用例要求所要进行的活动以及活动时间的约束关系
【描述方式】

• 1.起始点：实心圆
• 2.活动：圆角矩形
• 3.终止点：内部包含实心圆的圆
• 4.泳道：实际执行活动的对象

【目的】表示两个或多个对象之间在处理某个活动时的过程控制流程
【活动图】

“通过ATM来取钱。”

这个活动有三个类Customer, ATM和 Bank。整个过程从黑色圆圈开始到黑白的同心圆结束。活动用圆角矩形表示

活动图可以被分解成许多对象泳道swimlanes ，可以决定哪些对象负责那些活动。每个活动都有一个单独的转移transition连接这其他的活动。

转移可能分支branch成两个以上的互斥的转移。保护表达式（在[]中）表示转移是从一个分支中引出的。分支以及分支结束时的合并merge在图中用菱形表示。

转移也可以分解fork成两个以上的并行活动。分解以及分解结束时的线程结合join在图中用粗黑线表示

8.构件图/组件图（Component diagrams）

【概念】描述代码构件的物理结构以及各构件之间的依赖关系
【描述方式】构件
【目的】提供系统的物理视图，根据系统的代码构件显示系统代码的整个物理结构
【构件图】

9.部署图（Deployment diagrams）

【概念】系统中硬件的物理体系结构
【描述方式】

• 1.三维立方体表示部件
• 2.节点名称位于立方体上部

【目的】显示系统的硬件和软件的物理结构
【部署图】

链接参考：

• JUDE工具使用
• UML实战经典教程
• 浅谈UML概念模型和视图