UML模型图

一. 静态模型

1. 用例图

2. 类图

(1). 关联关系（association）

表示对象之间的联系

描述类的结构之间的关系。具有方向、名字、角色和多重性等信息。一般的关联关系语义较弱。也有两种语义较强，分别是聚合与组合

表示类与类之间的连接，它使得一个类知道另外一个类的属性和方法。

关联可以使用单箭头表示单向关联，使用双箭头或者不适用箭头表示双向关联，不建议使用双向关联，关联有两个端点，每个端点可以有一个基数，表示这个关联的类可以有几个实例。

0..1 表示可以有0个或者1个实例

0..* 表示对实例的数目没有限制

1     表示只能有一个实例

1..* 表示至少有一个实例

关联关系体现的是两个类，或者类与接口之间的强依赖关系，这种关系很强烈，比依赖更强，不是偶然性的，也不是临时性的，而是一种长期性，相对平等的关系

表现在代码层面，为被关联的类B以类属性的形式出现在类A中，也可能是关联类A引用了被关联类B的全局变量。

在Java中，关联关系是使用实例变量来实现的

比如：学生与课程之间就是通过选课关系进行关联

(2). 聚合关系（aggregation）

特殊关联关系，指明一个聚集（整体）和组成部分之间的关系

表示两个类之间是“is part of”关系，即整体–部分关系。

是关联关系的特例，是强的关联关系，聚合是整个与个体的关系，即has-a关系，
此时整体和部分是可以分离的，他们具有各自的生命周期，部分可以属于多个对象，也可以被多个对象共享

比如计算机和CPU，公司与员工的关系

在代码层面聚合与关联是一致的，只能从语义上来区分。

(3). 组合关系（compostion）

语义更强的聚合，部分和整体具有相同的生命周期

组合关系应该是A类的属性中含有一个B的对象；构成has a关系

也是关联关系的一种特例，体现的是一种contain-a关系，比聚合更强，是一种强聚合关系。它同样体现整体与部分的关系，但此时整体与部分是不可分的，整体生命周期的结束也意味着部分生命周期的结束

体现在代码层面与关联时一致的，只能从语义来区分。

它表示部分对象被嵌入到整体对象中。

比如：引擎是飞机的一部分；大脑和人类

(4). 泛化关系(继承关系)（generalization）

在面向对象中一般称为继承关系，存在于父类与子类、父接口与子接口之间

关系时指一个类（子类、子接口）继承另外一个类（称为父类、父接口）的功能，并可以增加它自己新功能的能力，继承是类与类或者接口与接口最常见的关系，在Java中通过关键字extends来表示

(5). 实现关系（realization）

对应于类和接口之间的关系

是指一个class实现interface接口（一个或者多个），表示类具备了某种能力，实现是类与接口中最常见的关系，在Java中通过implements关键字来表示。

(6). 依赖关系（dependency）

表示类与类之间的连接，表示一个类依赖于另外一个类的定义，依赖关系时是单向的。简单理解就是类A使用到了类B，这种依赖具有偶然性、临时性，是非常弱的关系。但是类B的变化会影响到类A。

举个例子，如某人要过河，则人与船的关系就是依赖，人过河之后，与船的关系就解除了，
因此是一种弱的连接。在代码层面，为类B作为参数被类A在某个方法中使用。

在java中，依赖表现为：局部变量，方法中的参数和对静态方法的调用。

(7). 几种关系强弱比较

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

3. 对象图

对象图是系统在某一时刻的快照。

4. 部署图

部署图描述系统资源运行时的物理分布，系统资源成为结点

部署图用于静态建模，是表示运行时过程节点结构、构件实例及其对象结构的图。

如果含有依赖关系的构件实例放置在不同节点上，部署视图可以展示出执行过程中的瓶颈。

部署图的两种表现形式：实例层部署图和描述层部署图

部署图与构件图相同的构成元素：

构件、接口、构件实例、构件向外提供服务、构件要求外部提供的服务。

部署图与构件图的关系：

部署图表现构件实例；
构件图表现构件类型的定义。

部署图偏向于描述构件在节点中运行时的状态，描述了构件运行的环境；
构件图偏向于描述构件之间相互依赖支持的基本关系。

5. 组件图

组件图描述可重用的系统组件及组件间的依赖

构件图用于静态建模，是表示构件类型的组织以及各种构件之间依赖关系的图。

构件图通过对构件间依赖关系的描述来估计对系统构件的修改给系统可能带来的影响。

二. 动态模型

1. 用例图

用例图描述执行者在各个用例中的参与情况

用例图的功能：

捕获系统用户需求
描述系统边界
指明系统外部行为
指导系统开发者的功能开发
系统建模的起点，指导所有的类图和交互图的设计
产生测试用例，用户文档
估计项目大小和进度

2. 状态图

(1). 定义

状态机图是对单个类的对象的生命周期进行建模，描述了对象时间上的动态行为，每个对象被认为是事件驱动的孤立实体

事件表达对象间的调用、显式信号、值的改变或时间的推移

调用事件、变更事件、信号事件、时间事件

状态描述对象生命周期的一段时间，可以是等待其它事件时所处的时间，或是执行某一活动时所处的时间，状态分为简单状态和复合状态

状态图用于揭示Actor、类、子系统和组件的复杂特性。 为实时系统建模。

(2). 状态图的组成

状态

对象的状态是指在这个对象的生命期中的一个条件或状况，在此期间对象将
满足某些条件、执行某些活动，或等待某些事件。

转移

转移是由一种状态到另一种状态的迁移。这种转移由被建模实体内部或外部事件触发。
对一个类来说，转移通常是调用了一个可以引起状态发生重要变化的操作的结果。

3. 活动图

(1). 定义

活动图是用状态机对工作流进行建模的特殊形式，它和流程图很类似，不过它支持并发控制

活动图一般不描述所有的运算细节，它显示活动的流，但不显示执行活动的对象

活动图处于系统的外部和内部视图之间，所以它可以作为设计的起点，为了完成设计，每个活动必须扩展成一个和多个操作，每个操作被指派给特定的对象来实现

带有生命线的活动图和无生命线的活动图

4. 序列图

(1). 定义

• 对象行为是通过交互来实现的，交互是对象间为完成某一目的而进行的一系列消息交换

• 消息是对象间的单向通信，从发送者到接受者的携带信息的控制流消息可能带有值参

• 消息序列可用两种图表示：序列图（重点在消息的时间顺序）和协作图（重点在交换消息的对象间的关系）对协作图来说，时间顺序可以从顺序号获得

5. 协作图

(1). 定义

协作图包含分类角色和关联角色，当它实例化时，对象被绑定到分类角色，链被绑定到关联角色。
协作图对实现协作的对象和链进行建模，而忽略其他对象

协作图是一种交互图，强调的是发送和接收消息的对象之间的组织结构，使用协作图来说明系统的动态情况。

协作图主要描述协作对象间的交互和链接，显示对象、对象间的链接以及对象间如何发送消息。

协作图可以表示类操作的实现。

(2). 协作图与时序图转换

打开时序图，Ctrl+A选中图中的所有的元素，然后菜单上找到DESIGNE | Model Transformation (MDA) | Transform Selected Elements，在弹出的界面中右边的Transformations 中选Communication, 再点击 Do Transform 即可。

三. UML机制

1. 注释

注释用于解释设计的思路，便于理解
一个好的模型应该有详尽的注释

2. 规范说明

• 软件模型必须是完整的，以便于软件系统的建造。此模型必须具备足够的详细信息以供软件建造使用。

• 构成完整模型的详细信息就是模型的规范说明（简称规范）

• 规范说明的内容一般用属性名和属性值的形式来表达。UML中有许多预定义的属性

    如：文档(documentation)、持续性(persistence)和并发性(Concurrency)等
  

• 属性一般作为模型成分附加说明

    比如，用一些文字逐条列举类的功能，这种规范说明方式是非形式化的
  

3. 修饰

修饰描述UML模型成分最主要的特征

UML模型中类:

“-”表示私有的(Private)，
“+”表示公开的（Public），其他类可访问，
“#” 表示受保护的（Protected）

4. 扩充机制

UML扩充机制（extensibility mechanisms）：

版型（stereotype）、标记值（tagged value）和约束（constraint） 

5. 公共划分

四. UML建模

1. UML建模流程

UML是一种建模语言而不是方法，这是因为UML中没有过程的概念，而过程正是方法的一个重要组成部分UML本身独立于过程，这意味着用户在使用UML进行建模时，可以选用任何适合的过程

2. 建模步骤举例

基于UML的系统开发采取增量迭代开发模型

1. 需求

   最初需求规格说明应当由代表系统最终用户的人员提供，内容包括系统基本功能需求和对计算机系统的要求

2. 分析

   分析的任务是找出系统的所有需求并加以描述，同时建立模型，以定义系统中的关键领域类，应由系统用户和开发人员合作完成

   分析的第一步是定义用例，以描述所开发系统的外部功能需求用例分析包括阅读和分析需求说明，此时需要与系统的潜在用户进行讨论

3. 设计

   设计阶段的任务是通过综合考虑所有的技术限制，以扩展和细化分析阶段的模型

   设计阶段可以分为两个部分：

    1. 结构设计：是高层设计，其任务是定义包（子系统），
    包括包间的依赖性和主要通信机制我们希望得到尽可能简单和清晰的结构，
    各部分之间的依赖尽可能的少，并尽可能的减少双向的依赖关系 
    
    2. 详细设计：细化包的内容，使编程人员得到所有类的一个足够清晰的描述
   

4. 实现

   构造或实现阶段是对类进行编程的过程可以选择某种面向对象对象编程语言（如Java）作为实现系统的软件环境Java很容易实现从逻辑视图到代码部件的映射，因为类到Java代码文件之间是一一映射关系

    在实现阶段中，可以选取各种图的说明来辅助编程，比如：类图，状态图和动态图等
   

5. 测试和配置

   完成系统编码后，需要对系统进行测试，它通常包括：单元测试、集成测试、系统测试和验收测试

五. 建模工具

六. UML与软件工程对应关系

如果把软件开发比作学校建一座高楼，那么软件工程就是指导我们怎么盖，不至于在构建一座大楼的时候，最后不知不觉变成四不像。而UML图正是对大楼主体架构的设计。软件工程是软件开发设计的灵魂，是我们前进的思想性指导。它使我们的设计有法可依，有章可循。比如我们学校现在盖的大楼，必须要有蓝图来规划哪块哪块盖什么楼，什么类别的都是前期需要用例建模来具体协商的。

具体步骤：
1.前期的需求分析描述需要用例图，用例图的使用者是学校，了解这栋大楼的主体结构，功能是什么，教学楼还是宿舍。学校最关心的是楼质量问题和安全性，是否能够满足学生的基本使用。

2.进一步需要设计楼内部的具体结构，此时就需要类图，对象图，组件图和部署图来制定标准化的结构，详细的描述内部需求和具体设施的安排，为具体施工指明工作点。

3.接下来就需要安排具体的人员开工，活动图安排各个工种在自己的岗位工作；状态图安排施工设备的使用情况，表明设备的忙碌和空闲状态；而具体施工步骤需要工程安排每一块的开始，不能先上后下，从基地开始。

此外还需要各个施工队的协作，连接性是这个工程的最后标志，各个团队之间必须密切协作才能完成整体的。

1、需求分析

用例图用来建模客户的需求。角色以及系统功能建模是用例建模来画的。它们之间的关系建模被用于角色和用例。每个用例都代表了客户的需求。需求分析不仅适用于软件系统进行而且适用于建筑工程行业。

2、系统分析

此阶段是寻找问题 -就是找刺的，需要考虑系统可能遇到的问题是主要的工作。借助于逻辑视图和动态视图实现。系统的静态由类图来建模，系统的动态则是协作图、序列图、活动图和状态图建模。只是列出系列的问题和稍微一点解决思路，不作出详细的解决方案。只是大方向上的做出引导，提纲，具体细节需要下一阶段结合实际分析。

3、系统设计

将分析阶段列出的问题进行汇总，根据提纲作出具体、细节办法。进而把分析结果扩展为技术层次的解决依据，不在停留在文字方面，需要依靠用户接口提供技术基础结构。数据库在这个技术基础结构中，分析阶段的领域问题类被嵌入在其中。构造阶段的详细的规格说明是设计阶段的结果。

4、系统实现（构造）

把设计阶段的类转换成某种面向对象程序设计语言的代码。只能在构造阶段实现代码的转变，其他阶段不能！在对UML表述的分析和设计模型进行转换时，最好不要直接把模型转化成代码。在早期阶段，模型是理解系统并对系统进行结构化的手段。

5、系统测试

根据测试的先后顺序排序：单元测试、集成测试、系统测试和接受测试。不同的测试采用不同的UML图作为工作的基础。类图和类的规格说明是单元测试；组件图和协作图的是集成测试；系统测试实现用例图来确认系统的行为符合这些图中的定义。
在系统测试阶段，UML模型还可以作为测试阶段的依据。如单元测试使用类图和类规格说明；集成测试使用组件图和协作图；系统测试用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。