UML类图几种关系的总结（转）

标签：

原文：http://gjhappyyy.iteye.com/blog/1422515

在UML类图中，常见的有以下几种关系: 泛化（Generalization）,  实现（Realization）, 关联（Association), 聚合（Aggregation）, 组合(Composition), 依赖(Dependency)

1.       泛化（Generalization）

【泛化关系】：是一种继承关系, 表示一般与特殊的关系, 它指定了子类如何特化父类的所有特征和行为. 例如：老虎是动物的一种, 即有老虎的特性也有动物的共性.

【箭头指向】：带三角箭头的实线，箭头指向父类

2. 实现（Realization）

【实现关系】：是一种类与接口的关系, 表示类是接口所有特征和行为的实现.

【箭头指向】：带三角箭头的虚线，箭头指向接口

3. 关联（Association)

【关联关系】：是一种拥有的关系, 它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子

关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。

【代码体现】：成员变量

【箭头及指向】：带普通箭头的实心线，指向被拥有者

上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。

上图为自身关联：

4. 聚合（Aggregation）

【聚合关系】：是整体与部分的关系, 且部分可以离开整体而单独存在. 如车和轮胎是整体和部分的关系, 轮胎离开车仍然可以存在.

聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

【代码体现】：成员变量

【箭头及指向】：带空心菱形的实心线，菱形指向整体

5. 组合(Composition)

【组合关系】：是整体与部分的关系, 但部分不能离开整体而单独存在. 如公司和部门是整体和部分的关系, 没有公司就不存在部门.

       组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期

【代码体现】：成员变量

【箭头及指向】：带实心菱形的实线，菱形指向整体

6. 依赖(Dependency)

【依赖关系】：是一种使用的关系,  即一个类的实现需要另一个类的协助, 所以要尽量不使用双向的互相依赖.

【代码表现】：局部变量、方法的参数或者对静态方法的调用

【箭头及指向】：带箭头的虚线，指向被使用者

各种关系的强弱顺序：

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

下面这张UML图，比较形象地展示了各种类图关系：

序列图主要用于展示对象之间交互的顺序。

序列图将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。

消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。

序列图中涉及的元素：

1.   生命线：

生命线名称可带下划线。当使用下划线时，意味着序列图中的生命线代表一个类的特定实体。

2.       同步消息

发送人在它继续之前，将等待同步消息响应

3.       异步消息

在发送方继续之前，无需等待响应的消息

4.       注释

5.       约束

约束的符号很简单；格式是: [Boolean Test]

6.       组合片段

组合片段 用来解决交互执行的条件及方式。 它允许在序列图中直接表示逻辑组件，用于通过指定条件或子进程的应用区域，为任何生命线的任何部分定义特殊条件和子进程。

常用的组合片段有：

a.       抉择（Alt）

抉择用来指明在两个或更多的消息序列之间的互斥的选择，相当于经典的if..else..。

抉择在任何场合下只发生一个序列。 可以在每个片段中设置一个临界来指示该片段可以运行的条件。 else 的临界指示其他任何临界都不为 True 时应运行的片段。 如果所有临界都为 False 并且没有 else，则不执行任何片段。

b.       选项（Opt）

包含一个可能发生或不发生的序列

c.       循环（Loop）

片段重复一定次数。 可以在临界中指示片段重复的条件。

d.       并行（Par）

下表列出了常用的组合片段：

有关如何解释序列的片段

默认情况下，序列图表明可能发生的一系列消息。 在运行的系统中，可能会出现您未选择显示在关系图上的其他消息。

以下片段类型可用于更改此释义：

用例图主要用来描述 用户、需求、系统功能单元 之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。

【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。

用例图所包含的元素如下：

1.       参与者(Actor)

表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。

2.       用例(Use Case)

 用例就是外部可见的系统功能，对系统提供的服务进行描述。 用椭圆表示

3.       子系统(Subsystem)

用来展示系统的一部分功能，这部分功能联系紧密。

4.       关系

用例图中涉及的关系有：关联、泛化、包含、扩展；

如下表所示：

a.       关联(Association)

表示参与者与用例之间的通信，任何一方都可发送或接受消息。

【箭头指向】：指向消息接收方

b.      泛化(Inheritance)

就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。

【箭头指向】：指向父用例

c.       包含(Include)

包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤；

【箭头指向】：指向分解出来的功能用例

d.      扩展(Extend)

    扩展关系是指 用例功能的延伸，相当于为基础用例提供一个附加功能。

   【箭头指向】：指向基础用例

e.       依赖(Dependency)

以上4中关系，是UML定义的标准关系。 但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示

表示源用例依赖于目标用例；

【箭头指向】：指向被依赖项

5.       项目(Artifact)

用例图虽然是用来帮助人们形象地理解功能需求，但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强，VS2010中引入了“项目”这样一个元素，以便让开发人员能够在用例图中链接一个普通文档。

用依赖关系把某个用例依赖到项目上

然后把项目-》属性 的Hyperlink 设置到你的文档上

这样当你在用例图上 双击项目时，就会打开相关联的文档。

6.       注释(Comment)

包含(include)、扩展(extend)、泛化(Inheritance) 的区别：

条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；

直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。

对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。

对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；

一个用例图示例：

牢骚：

感觉用例图还不成熟，并不能很好地表达系统的需求， 没有UML背景的用户几乎不知道画的些什么。

其次，包含关系、扩展关系 的箭头符号竟然是同样的箭头，仅靠上方写个文字来加以区别，翻译成其他语言的话，几乎就不知道代表什么意思。  扩展关系的箭头朝向也很难理解，为何要指向基用例，而不指向扩展用例

VS2010添加的“项目”元素，是个很好的创新，能够在用例图中关联word,excel这些文档。但为什么不把这些功能直接集成到用例里面，双击用例就弹出一份文档岂不更容易理解，非要画蛇添足地加一个元件，仅仅为了提供个链接功能。

用例描述表：

用列图并不能清楚地表达功能需求，开发中大家通常用描述表来补充某些不易表达的用例，下图的表给大家提供一个参考：

UML类图几种关系的总结（转）

标签：

原文地址：http://www.cnblogs.com/lipeng0824/p/4340728.html