类 图

软件包

• 如果建模者决定在大长方形中显示软件包的成员，则所有的那些成员需要被放置在长方形里面。另外，所有软件包的名字需要放在软件包的较小长方形之内。
• 
  
  
• 如果建模者决定在大的长方形之外显示软件包成员，则所有将会在图上显示的成员都需要被置于长方形之外。为了显示属于软件包的分类器属于，从每个分类器画一条线到里面有加号的圆周，这些圆周粘附在软件包之上。

泛化 (generalization)是两类别之间的关系，不同于上述的关联、聚合或组合关系，它是一种分类关系。或者说，针对某一概念或事 物，其个体可区分为一般类(父类别)与特殊类(子类别)时，两者之间便可以放置泛化关系。举例来说，我们会说无线鼠标和有线鼠标(它们都是特殊类别/子 类别)都是一种鼠标(一般类别/父类别)。

泛化关系

 

接口关系

依赖关系 又与上列几种关系不同，先说明为何许多UML书上会说它是短暂关系，其实这是相对于结合(聚合、组合)关系，前面有我们有提到，结合关系是一种静态结构关系，是需要被保存下来的。相较之下，依赖关系并不需要被储存起来，所以才会说它是短暂关系。

 

依赖关系

最常见的依赖关系(dependency)是一种使用关系，譬如顾客类别里头有一个计算年度交易总额操作好了，在这个操作中必须连到一群当年度 的交易对象，并且呼叫交易对象取得交易金额进行累加，才能计算出年度交易总额。在这个例子中，顾客类别与交易类别就有短暂的依赖关系。

关联关系 (association)是一种静态结构上的关系，换言之，它偏向于数据关系。所以，两类别之间放置关联关系，同时意味着这个关系必须被保存起来，这也是为何UML类别图中最常出现的是关联关系。比方说，顾客跟订单之间的关系，就会使用关联关系，因为我们希望系统可以保存两者之间的关系。

关联关系

 

关联关系的两端通常是平等的，如果要表达整体-部分(whole-part)意涵时，就可以改用聚合关系 (aggregate,空心菱形)，或是组合关系 (composite,实心菱形)。特别注意的是：

 

聚合 关系

组合关系

1. 聚合与组合都是一种结合关系，只是额外具有整体-部分的意涵。

 

2. 聚合关系中，整件(whole object)不会拥有部件(part object)的生命周期，所以整件删除时，部件不会被删除。再者，多个整件可以共享同一个部件。

 

3. 组合关系中，整件拥有部件的生命周期，所以整件删除时，部件一定会跟着删除。而且，多个整件不可以同时间共享同一个部件。

 

至于，实务上倒底要采用聚合关系还是组合关系，不决定于真实，而是决定于企业规则。比方说，订单与细项之间的关系，通常采用组合关系，一旦订单 被删掉时，底下的细项也会同时被删除。但是，这是比较常见的企业规则，试想，或许有些领域的交易是可以拆单的，订单被取消时，原先的细项可以被并入别的订 单中，若是如此，就适合使用聚合关系了。