一 聚合关系

聚合关系描述了一个较大的事务（整体），是由较小事务（部分）组成的。

公司和部门、部门和员工之间是聚合关系。聚合关系用一个空心菱形表示，菱形要画在“较大的事务”一侧。

1 常见存在聚合关系的类

聚合关系表达的是大事务和小事务、整体和部分之间的关系，常见的就是组织和订单。

比如，企业是一个组织，从总公司到分公司再到营业点是一层层的聚合关系，都表达了大事务和小事务、整体和部分之间的关系。再如，订单和订单项之间是聚合关系，订单是较大事务，订单项是较小事务。

2 聚合的判定案例

很多类间都没有“聚合关系”。比如，订单类图中的订单和支付信息、订单和发票项之间，都不是聚合关系。因为 UML 中的聚合关系表明的是大事务和小事务，整体和部分之间的关系。而订单和支付信息、订单和发票项之间，不存在大事务和小事务之间的关系。

二 组成形式的聚合

组成关系是聚合关系的一种形式，表达了整体对部分有很强的所有权和生存控制，组成一旦创建，部分就和整体共存亡。

下图是部门和员工之间的组成关系，强调的是一个员工只属于一个部门。

下图是班级和老师之间的聚合关系，一个老师可以属于多个班级

1 组成关系的判定标准

组成关系是一种聚合关系，是一种特殊形式的聚合关系。和聚合关系不同的是，组成关系强调了“一心一意”，“同生共死”。

a 一心一意

在一个大型公司里，一个员工必须从属于一个部门，即使是 CEO，也要从属于总裁办，并且不能在其他部门兼职。这个时候员工对部门就是一心一意的。

b 同生共死

部门会被裁掉，当部门被裁掉时，员工要么辞职，要么转岗，部门和员工是同生共死的关系。

一个部门只属于一个公司，如果所有部门都不存在了，公司也就不存在了，同样的，如果公司不存在了，部门也就不存在了，两者之间也是同生共死的关系。

一个学生总是要毕业的，毕业后班级就不存在了，班级和学生之间就是组成关系。

订单和订单项之间也是组成关系，两者也体现了“一心一意”和“同生共死”的关系。

2 聚合关系和组成关系的记忆

可以这样理解，如果员工不是铁了心要和一个部门在一起，他还要兼职，那么两者之间就是聚合关系。没有铁了心，就不是一心一意，就用空心的菱形表示。聚合的意思是，聚则合不聚则散。如果员工铁了心要和一个部门在一起，则两者之间就是组成关系。铁了心就是一心一意，就用实心的菱形表示。

三 聚合关系和组成关系的区别

1 聚合关系包含组成关系

在本质上，组成关系仍然是聚合关系，只是强调了“一心一意”和“同生共死”。

因此在实战中，我们都用聚合关系也可以。比如，在公司，部门和员工的案例中，无论员工是否会“从一而终”，都可以用聚合关系表达。

2 两者的区别和应用

• 组成关系：强调的是“一心一意”和“同生共死”。
• 聚合关系：强调的是“临时伙伴”和“各营生死”。

这个区别对产品交互的影响如下。

组成关系：有的公司希望员工只属于一个部门，那么员工和部门之间的关系可以用组成关系表达。如果部门撤销，该员工的工作也就没了。在原型设计中，产品经理就要在撤销部门时，提示要转移所有员工。在转移完毕后员工的访问权限也要变化。

聚合关系：有的公司的员工内部可以兼职，那么员工和其兼职部门之间可以用聚合关系表达。兼职的部门撤销，员工的本来工作还在。

四 对聚合关系和组成关系的第二种解释

认为聚合关系强调了一个事务将另一个事务聚到了一起。此时，前一个事务更像是牵头方、发起方。

比如，用户创建了订单，则用户就是牵头方，其牵头创建了订单，用户和订单之间的聚合关系如下图。

五 小结

聚合关系描述了一个较大的事务（整体）是由较小的事务（部分）组成的。同样是聚合关系，还是有所不同，组成关系强调了“同生共死”和“一心一意”，而普通的聚合关系是“临时伙伴”和“各管生死”。常见的是，一个组织的部门和员工之间是组成关系，一个学校的班级和老师之间是聚合关系。

我们抽象出聚合关系和组成关系，有利于理清部门和员工的关系、老师和班级的关系等，从而有利于指导原型图设计和数据库的搭建。

1、什么是类图

　　类图(Class diagram)主要用于描述系统的结构化设计。类图也是最常用的UML图，用类图可以显示出类、接口以及它们之间的静态结构和关系。

2、类图的元素

　　在类图中一共包含了以下几种模型元素，分别是：类（Class）、接口（Interface）、依赖（Dependency）关系、泛化（Generalization）关系、关联（Association）关系、聚合关系（Aggregation）、组合关系（Composition）和实现（Realization）关系。

2.1 类（Class)

　　在面向对象（OO) 编程中，类是对现实世界中一组具有相同特征的物体的抽象。

2.2 接口（Interface）

　　接口是一种特殊的类，具有类的结构但不可被实例化，只可以被实现（继承）。在UML中，接口使用一个带有名称的小圆圈来进行表示。

2.3 依赖（Dependency）关系

　　依赖关系是指两个或多个类之间的依存关系，如植物类依赖于土壤类。 依赖关系还可以再细分为5种类型，分别是绑定（Binding）依赖、实现（Realization）依赖、使用（Usage）依赖、抽象（Abstraction）依赖和授权（Permission）依赖。

　　依赖关系用虚线箭头来表示，箭头指向为依赖的方向。

2.4 泛化（Generalization）关系

　　简单的讲就是类之间的继承关系。在UML中，泛化关系用空心三角形+实线来表示，箭头指向为父类。

2.5 聚合（Association）关系

　　聚合关系是类之间的一种较弱的耦合关系，如一个字符串数组和一个字符串就是一种聚合关系。在UML中类图中，聚合关系用空心的菱形+实线箭头来表示，箭头指向为被聚合的类。

2.6 组合（Aggregation）关系

　　组合关系是类之间一种整体与部分之间的关系，如一只青蛙有四条腿，青蛙类与青蛙腿类之间的关系就是组合关系。在UML类图中，组合关系用实心的菱形+实线箭头来表示，箭头指向为被组合的类。

2.7 关联（Composition）关系

　　关联关系是类之间一种相互影响的关系，影响的方向就是关联的方向。在UML类图中，组合关系用实线箭头来表示。

2.8 实现（Realization）关系

　　一般来讲实现关系是针对类与接口之间的关系而言的。在UML类图中，实现关系用空心三角形+虚线来表示。

3、简单的类图示例

UML定义

UML（Unified Modeling Language，统一建模语言），是一种面向对象的建模语言。它的主要作用是通过提供模型图帮助用户对软件系统进行面向对象的描述和建模，它可以描述这个软件开发过程从需求分析直到实现和测试的全过程。

UML图结构

用例图定义

• 从系统的使用者的角度所理解的系统的总体功能。强调这个系统是什么而不是这个系统怎么工作。
• 建立于系统需求阶段，是需求分析人员和用户对系统需求达成的共识。

用例图中的事物

1. 用例
   系统外部可见的一个系统功能单元。
   

2. 参与者
   表示用例的使用者在与这些用例交互时所扮演的角色
   可以是：人、硬件设备或一个系统
   
   
   

用例图中的关系

关联关系

• 参与者与用例之间的关系
• 表示该用例是该参与者发起的，表示参与者可以行使系统中的这个功能
  
  
  

包含关系

特点

• 用例之间的关系
• 基用例必须和包含用例一起使用才够完整，包含用例也必然被执行。包含关系在用例图中使用带箭头的虚线表示(在线上标注<>)，箭头从基用例指向包含用例。

使用场景

• 如果两个以上用例有大量一致的功能，则可以将这个功能分解到另外一个用例中。其它用例可以和这两个用例建立包含关系。
  

扩展关系

特点

• 用例之间的关系
• 扩展用例是对基用例的扩展，即使没有扩展用例的参与，也可以完成一个完整的功能。扩展在用例图中使用带箭头的虚线表示(在线上标注<>)，箭头从扩展用例指向基用例。
  

使用场景

UML用例图中扩展用例为基用例添加新的行为，相当于为基础用例提供一个附加功能。

泛化关系

特点

• 子用例指向父用例，父用例一般是抽象用例（用例之间的关系）
  

• 是一种继承关系，泛化关系在用例图中用实线+空心三角形表示，空心三角形指向父参与者，子参与者可以继承父参与者所有的行为。
  

使用场景

子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系

包含关系和扩展关系的联系和区别

联系：

• 都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

区别：

• 扩展关系中基本用例的基本流执行时，扩展用例不一定执行，即扩展用例只有在基本用例满足某种条件的时候才会执行。
• 包含关系中基本用例的基本流执行时，包含用例一定会执行。