UML中关系整理

标签：

在UML中，关系是非常重要的语义，它抽象出对象之间的联系，让对象构成某个特定的结构。

1.关联关系(association)

关联关系是用一条直线表示的，如

它描述不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。关联关系是一种静态关系，通常与运行状态无关，而是由“常识”，“规则”，“法律”、等因素决定的，所以关联关系是一种”强关联“的关系。

• 一对一关联
• 一对多关联
• 多对多关联

2.依赖关系(dependency)

依赖关系是用一条带箭头的虚线表示，如

它描述一个对象在运行期间会使用到另一个对象的关系。与关联关系不同的是，依赖关系是一种临时性的关系，他通常在运行期产生，并且随着运行场景的不同，依赖关系也可能发生变化。
 
  例如人和船这两个对象，如果运行场景是开动轮船，那么轮船依赖于人(水手)；如果场景变为渡海，那么变成人依赖于船了。可见，依赖关系是一种“弱”关系，它不是天然存在的，并且会随着运行场景的变化而变化。如果人和刀这两个对象，平时它们没有关系的，但是在削苹果这个场景里，人依赖于刀；脱离了这个场景，或者当场景结束后，依赖关系也就不存在了。
  一般而言，依赖关系在最终的代码里体现为类构造方法，类方法等的传入参数。
  与关联关系相比，依赖关系除了临时“知道”对方外，还会“使用”对付的属性或方法。从这个角度讲，被依赖的对象改变会导致依赖对象的修改。举例来说，A对象保存了B对象的实例，但A对象对B对象没有操作，这时A仅仅是“知道”B对象，应当用关联关系，并且B修改了方法以后，A并不会变化；但如果A对象在某个场景中使用了B对象的属性或方法，则B的修改会导致A的修改，这时A依赖于B。
  同样的，依赖也有单向依赖和双向依赖之分。但是依赖关系却不像关联关系那样有带箭头和不带箭头的区分，统统都是带箭头的。这是因为在面向对象里，双向依赖是一种非常不好的结构，我们总是应当保持单向依赖，杜绝双向依赖关系的产生。

3.扩展关系(extends)

扩展关系是用一条带箭头的虚线加版型<<extends>>来表示的，如

• 表明用例的某一部分是可选(或可能可选)的系统行为。这样就可以将模型中的可选行为和必选行为分开。
• 表明只在特定条件(有时是列外条件)下才执行分支支流，如触发警报。
• 表明可能有一组行为段，其中的一个或多个段可以在基本用例的扩展点处插入。所插入的行为段(以及插入的顺序)将取决于在执行基本用例时与主角进行的交互。

4.包含关系(include)

包含关系是用一条带箭头的虚线加版型<<include>>来表示的，如：

• 从基本用例中分解出这样的行为：它对于了解基本用例的主要目的并不是必需的，只有它的结果才比较重要。
• 分解出两个或更多用例共有的行为。

5.实现关系(realize)

实现关系是用一条带空心箭头的虚线表示的，如
 
它特别用于在用例模型中连接用例和用例实现，说明基本用例的一个实现方式。
  实现所代表的含义是，基本用例描述了一个业务目标，但是该业务目标有多种可能的实现途径，每一种实现途径可以用用例实现(或称用例实例)来表示，而用例实现与基本用例之间就构成了实现关系。换而言之，每个实现途径都实现了基本用例的业务目标。

6.精化关系(refine)

 精化关系是用一条带箭头的虚线加版型<<refine>>来表示的，如
 
它特别用于用例模型，一个基本用例可以分解出许多更小的关键精化用例，这些更小的精化用例更细致地展示了基本用例的核心业务。精化关系用来连接基本用例和精化用例，说明精化用例是由基本用例精化得来的。
  精化关系也可以用于模型与模型之间，表示某个模型是通过精化另一个模型而得来的。比如说，我们认为设计类是通过分析类而得来的，我们可以使用XX设计类<<refine>>XX分析类来表示它们之间的关系。
  与泛化关系不同的是，精化关系表示由基本对象可以分解为更明确、精细的子对象，这些子对象并没有增加、减少、改变基本对象的行为和属性，仅仅是更加细致和明确化了。在泛化关系中，基本对象被泛化为子对象后，子对象继承了基本对象的所有特征，并且子对象可以增加、改变基本对象的行为和属性。
另一方面，精化关系仅仅用于建模阶段，在实现语言中是没有精化这一语意的。泛化则等同于实现语言中的继承语意。

7.泛化关系(generalization)

泛化关系是用一条带空心箭头的直线表示的，如
 
泛化关系可用于建模过程中的任意一个阶段，说明两个对象之间的继承关系。读者对面向对象中的继承应该不会陌生，泛化关系表示一个类对另一个类的继承。继承而得的类称为后代。被继承的类称为祖先。继承意味着祖先的定义(包括任何特征，如属性、关系或对其对象执行的操作)对于后代的对象也是有效的。泛化关系是从后代类到其祖先类的关系。
  特别需要说明的是，作者并不赞同在用例之间使用泛化关系，尽管UML认为它是合法的。原因是用例带有原子特性，每个用例都应当是独一无二的。用例描述了参与者完成一个目标的整个过程，如果采用泛化关系，很难描述子用例继承了基本用例的什么。过程还是业务实体？如果仅仅为了将用例之间的可复用部分或用例的可扩展部分描述出来，那么使用包含关系和扩展关系就足够了。

8.聚合关系(aggregation)

聚合关系是用一条带空心棱形箭头的直线表示的，如
 (A聚合到B上，或者说B由A组成)。
  聚合关系用于类图，特别用于表示实体对象之间的关系，表达整体由部分构成的语意。例如一个部门由许多人员构成。
  与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，部分仍然存在。例如部门撤销后，人员不会因此而消失，他们依然存在。

9.组合关系(composition)

组合关系是用一条带实心棱形箭头的直线表示的，如
 (A组合成B，或者说B由A构成)。
  组合关系用于类图，特别用于表示实体对象关系，表达整体拥有部分的语意。例如母公司拥有许多子公司。
  组合关系是一种强依赖的特殊聚合关系，如果整体不存在了，则部分也将消亡。例如母公司解体了，子公司也将不存在。

UML中关系整理

标签：

原文地址：http://blog.csdn.net/jiaotuwoaini/article/details/51691648