UML对基本结构建模---关系
1.术语和概念
当建造抽象时，会发现类很少单独存在，相反，大多数类以几种方式相互协作。因此，当对系统建模时，不仅要识别形成系统词汇的事物，而且还必须对这些事物如何相互联系建模。关系是事物之间的联系。在面向对象的建模时，最重要的3种关系是依赖、泛化和关联。在图形上，把关系画成一条线，并用不同的线区别关系的种类。
（1）依赖
依赖是一种使用关系，说明一个事物使用另一个事物的信息和服务，但反之未必。在大多数情况下，在类与类之间用依赖指明一个类使用另一个类的操作，或者使用其他类所定义的变量和参量，，如果被使用的类发生变化，那么另一个类的操作也会受到影响，因为这个被使用的类此时可能表现出不同的接口或行为。
（2）泛化
泛化是一般事物（称为超类或父类）和该事物的较为特殊的种类（称为子类）之间的关系。有时也称泛化为“is-a-kind-of”关系。一个类可以有0个、1个或多个父类。在大多数情况下，用类或接口之间的泛化来表明继承关系。
（3）关联
关联是一个结构关系，它指明一个事物的对象与另一个事物的对象间的联系。给定一个连接两个类的关联，可以从一个类的对象联系到另一个类的对象。这里有4种应用于关联的修饰。
1’.名称
关联可以有一个名称，用以描述该关系的性质。为了消除名称的歧义，可提供一个指出读名称方向的三角形，给名称一个方向，如下图所示。虽然关联可以有名称，但在显式地给出关联的端点名的情况下通常不需要给出关联名称。
2’.角色
当一个类参与了一个关联时，它就在这个关系中扮演了一个特定的角色。角色是关联中靠近它的一端的类对另一端的类呈现的面孔。可以显式地命名一个类在关联中所扮演的角色。把关联端点扮演的角色称为端点名。
3’.多重性
关联表示了对象间的结构关系。在很多建模问题中，说明一个关联的实例中有多少个相互连接的对象时很重要的。这个“多少”被称为关联角色的多重性，它表示一个整数的范围，指明一组相关对象的可能个数。
4’.聚合
两个类之间的简单关联表示了两个同等地位的类之间的结构关系，这一位着这两个类在概念上是同级别的，一个类并不比另一个类更重要。有时要对“整体/部分”关系建模，其中一个类描述了一个较大的事物（“整体”），它由较小的事物（“部分”）组成。这种关系成为聚合，它描述了“has-a”关系，意思是整体对象拥有部分对象。
2.常用建模技术
（1）对简单依赖建模
创建一个依赖，从含有操作的类指向被该操作用来作为参数的类。
（2）对单继承建模
对继承关系建模，要做如下工作。
- 给定一组类，寻找两个或两个以上的类中的共同职责、属性和操作。
- 把这些共同的职责、属性和操作提升到较为一般的类中。如果需要，创建一个新类，用以指派这写元素（但小心不要引入过多的层次）。
- 画出每个特殊类到它的较为一般的父类的泛化关系，用以表示较特殊的类继承较一般的类。
（3）对结构关系建模
对结构关系建模，要做如下工作。
- 对于每一对类，如果需要从一个类的对象到另一个类的对象导航，就要在这两个类之间说明一个关联。这是关联的数据驱动观点。
- 对于每一对类，如果一个类的对象要与另一个类的对象相互交互，而后者不作为前者的过程局部变量或者操作参数，就要在这两个类间说明一个关联。这是关联的行为驱动观点。
- 对于这样的每一个关联，要说明其多重性或角色名。
- 如果关联中的一个类与另一端的类相比，前者在结构或者组织上是一个整体，后者看其阿里像它的部分，则在靠近整体的一端用一个菱形对该关联进行修饰，从而把它标记为聚合。
3.提示和技巧
在用UML对关系建模时，要遵循如下策略。
- 仅当被建模的关系不是结构关系是，才使用依赖。
- 仅当关系是“is-a-kind-of”关系时，才使用泛化。往往可以用聚合代替多继承。
- 小心不要引入循环的泛化关系。
- 一般要保持泛化关系的平衡；继承的层次不要太深（大约多于5层就应该想一想），也不要太宽。
- 关联主要用于对象间有结构关系的地方。不要用关联来表示暂时关系，例如过程的参数或局部变量。
- 除非绝对必要，否则要避免连线交叉。
- 仅显示对理解特定的成组事物必不可少的关系。避免使用多余的关系（特别是多余的关联）。