UML总结4---UML九种图关系说明

转自：http://blog.csdn.NET/chenyujing1234/article/details/8173519

UML中包括九种图：用例图、类图、对象图、状态图、时序图、协作图、活动图、组件图、配置图。

１）用例图（Use Case Diagram）

它是UML中最简单也是最复杂的一种图。说它简单是因为它采用了面向对象的思想，又是基于用户视角的，绘制非常容易，简单的图形表示让人一看就懂。说它复杂是因为用例图往往不容易控制，要么过于复杂，要么过于简单。

用例图表示了角色和用例以及它们之间的关系。

※用例图是从用户角度描述系统功能，是用户所能观察到的系统功能的模型图，用例是系统中的一个功能单元。

²用例图多用于静态建模阶段(主要是业务建模和需求建模)。

用例图中的事物及解释

用例图中的关系及解释

例子

实例1  参与者之间的泛化关系

参与者：经理，安全主管，保安

用例：管理人事，批准预算，批准安全证书，监视周边

在参与者之间不存在泛化关系的情况下，各个参与者参与用例的情况分别是：经理参与用例管理人事和批准预算；安全主管参与用例批准安全证书；保安参与用例监视周边。由于安全主管与经理，安全主管与保安之间泛化关系的存在，意味着安全主管可以担任经理和保安的角色，就能够参与经理和保安参与的用例。这样，安全主管就可以参与全部4个用例。但经理或者保安却不能担任安全主管的角色，也就不能参与用例批准安全证书。

实例2  用例之间扩展和包含关系

用例的上下文是：短途旅行但汽车的油不足以应付全部路程。那么为汽车加油的动作在旅行的每个场景(事件流)中都会出现，不加油就不会完成旅行。吃饭则可以由司机决定是否进行，不吃饭不会影响旅行的完成。

实例3.  航空售票的用例图

²参与者(actor)：clerk，监督员，信用卡服务商，信息亭

²用例(use case)： Buy tickets， Buy Subscription， Make charges， Survey sales

²参与者Clerk参与(或称发起)Buy tickets和Buy Subscription 两个用例(关联关系)。这两个用例的事件流都包含Make

charges用例(包含关系)。

²系统由：Buy tickets， Buy Subscription， Make charges， Survey sales组成。

²该系统主要包含：Buy tickets， Buy Subscription， Make charges， Survey sales这几个功能。

²该系统主要面向的用户(参与者)：clerk，监督员，信用卡服务商，信息亭。

２）类图（Class Diagram）

是最常用的一种图，类图可以帮助我们更直观的了解一个系统的体系结构。通过关系和类表示的类图，可以图形化的方式描述一个系统的设计部分。

※类图描述系统中类的静态结构。不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等，也包括类的内部结构(类的属性和操作)

※类图是以类为中心来组织的，类图中的其他元素或属于某个类或与类相关联 

※从上到下分为三部分，分别是类名、属性和操作。类名是必须有的

※类如果有属性，则每一个属性都必须有一个名字，另外还可以有其它的描述信息，如可见性、数据类型、缺省值等

※类如果有操作，则每一个操作也都有一个名字，其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等。（按标准来做，我们常常没按标准）

 

以下是我画的类图，表现得很不规范：如属性名放到了面，其实应该放前面的。

 

 

 

 

3.2.3 抽象类

※不能被实例化的类，一般至少包含一个抽象操作

3.2.4 模版类

※一种参数化的类，在编译时把模版参数绑定到不同的数据类型，从而产生不同的类

3.3 类图中的关系及解释

3.3.1 关联关系

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

聚合关系 

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

组合关系 

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

3.3.2 泛化关系

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

3.3.3实现关系

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

3.3.4 依赖关系

※描述了一个类的变化对依赖于它的类产生影响的情况。有多种表现形式，

例如绑定(bind)、友元(friend)等

3.4 类图与代码的映射

3.4.1 类的映射

3.4.2 关联关系的映射

3.4.3 泛化关系的映射

3.4.4 实现关系的映射

3.4.5 依赖关系的映射

3.5 类图例子

3.5.1 图形编辑器

※图形编辑器一般都具有一些基本图形，如直线、矩形等，用户可以直接使用基本图形画图，也可以把基本图形组合在一起创建复杂图形

※如果区别对待基本图形和组合图形，会使代码变得复杂，而且多数情况下用户认为二者是一样的

※组合模式可以用相同的方式处理两种图形

3.5.2  演出售票系统

=================================================================================================================

=====================================================================================================================

转载自： http://www.cnblogs.com/olvo/archive/2012/05/03/2481014.html

UML类图关系（泛化 、继承、实现、依赖、关联、聚合、组合）

继承、实现、依赖、关联、聚合、组合的联系与区别

分别介绍这几种关系：

继承

指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java中此类关系通过关键字extends明确标识，在设计时一般没有争议性；

实现

指的是一个class类实现interface接口（可以是多个）的功能；实现是类与接口之间最常见的关系；在Java中此类关系通过关键字implements明确标识，在设计时一般没有争议性；

依赖

可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用；

关联

他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量；

聚合

聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与CPU、公司与员工的关系等；表现在代码层面，和关联关系是一致的，只能从语义级别来区分；

组合

组合也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束；比如你和你的大脑；表现在代码层面，和关联关系是一致的，只能从语义级别来区分；

对于继承、实现这两种关系没多少疑问，他们体现的是一种类与类、或者类与接口间的纵向关系；其他的四者关系则体现的是类与类、或者类与接口间的引用、横向关系，是比较难区分的，有很多事物间的关系要想准备定位是很难的，前面也提到，这几种关系都是语义级别的，所以从代码层面并不能完全区分各种关系；

但总的来说，后几种关系所表现的强弱程度依次为：组合>聚合>关联>依赖；

聚合跟组合其实都属于关联 只不过它们是两种特殊的关联 因为本是同根生 所以它们之间难免会有相似之处 下面让我们一起来看一下它们之间有何不同

聚合与组合的概念相信不用我在此赘述大家就已经了解了 下面直接上例子

程老师的《大话》里举大那个大雁的例子很贴切 在此我就借用一下 大雁喜欢热闹害怕孤独 所以它们一直过着群居的生活 这样就有了雁群 每一只大雁都有自己的雁群 每个雁群都有好多大雁 大雁与雁群的这种关系就可以称之为聚合 另外每只大雁都有两只翅膀 大雁与雁翅的关系就叫做组合 有此可见 聚合的关系明显没有组合紧密 大雁不会因为它们的群主将雁群解散而无法生存 而雁翅就无法脱离大雁而单独生存——组合关系的类具有相同的生命周期

聚合关系图：

组合关系图：

从从代码上看这两种关系的区别在于：

构造函数不同

雁群类：

1. public class GooseGroup
2. {
3. public Goose goose;
4. public GooseGroup(Goose goose)
5. {
6. this.goose = goose;
7. }
8. }
9. public class GooseGroup
10. {
11. public Goose goose;
12. public GooseGroup(Goose goose)
13. {
14. this.goose = goose;
15. }
16. }
17. 大雁类：
18. public class Goose
19. {
20. public Wings wings;
21. public Goose()
22. {
23. wings=new Wings();
24. }
25. }
26. public class Goose
27. {
28. public Wings wings;
29. public Goose()
30. {
31. wings=new Wings();
32. }
33. }

３）对象图

对象图是类图的实例，几乎使用与类图完全相同的标识。它们的不同点在于对象图显示类的多个对象实例，而不是实例的类。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。

４）状态图

描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。

５）时序图

又称顺序图，描述了对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。

顺序图由一组对象构成，每个对象分别带有一条竖线，称作对象的生命线，它代表时间轴，时间沿竖线向下延伸。顺序图描述了这些对象随着时间的推移相互之间交换消息的过程。消息用从一务垂直的对象生命线指向另一个对象的生命线的水平箭头表示。图中还可以根据需要增加有关时间的说明和其他注释。

６）协作图

协作图用于显示组件及其交互关系的空间组织结构，它并不侧重于交互的顺序。协作图显示了交互中各个对象之间的组织交互关系以及对象彼此之间的链接。与序列图不同，协作图显示的是对象之间的关系。

另一方面，协作图没有将时间作为一个单独的维度，因此序列号就决定了消息及并发线程的顺序。协作图是一个介于符号图和序列图之间的交叉产物，它用带有编号的箭头来描述特定的方案，以显示在整个方案过程中消息的移动情况。

协作图用途：

通过描绘对象之间消息的移动情况来反映具体的方案。

显示对象及其交互关系的空间组织结构，而非交互的顺序。

※协作图描述对象间的协作关系，协作图跟顺序图相似，显示对象间的动态合作关系。除显示信息交换外，协作图还显示对象以及它们之间的关系.

※协作图的一个用途是表示一个类操作的实现

７）活动图（Activity Diagram）

UML活动图记录了单个操作或方法的逻辑，单个用户案例，或者单个业务流程的逻辑。描述系统中各种活动的执行顺序，通常用于描述一个操作中所要进行的各项活动的执行流程。同时，它也常被用来描述一个用例的处理流程，或者某种交互流程。

活动图由一些活动组成，图中同时包括了对这些活动的说明。当一个活动执行完毕之后，控制将沿着控制转移箭头转向下一个活动。活动图中还可以方便地描述控制转移的条件以及并行执行等要求。

８）组件图（Component Diagram）

组件图是用来反映代码的物理结构。从组件图中，可以了解各软件组件（如源代码文件或动态链接库）之间的编译器和运行时依赖关系。使用组件图可以将系统划分为内聚组件并显示代码自身的结构。

组件图的主要目的是显示系统组件间的结构关系。

９）配置图

配置图描述系统中硬件和软件的物理配置情况和系统体系结构。

在配置图中，用结点表示实际的物理设备，如计算机和各种外部设备等，并根据它们之间的连接关系，将相应的结点连接起来，并说明其连接方式。在结点里面，说明分配给该结点上运行的可执行构件或对象，从而说明哪些软件单元被分配在哪些结点上运行