关系
--->在UML中关系是非常重要的语义，它抽象出对象之间的联系，让对象构成特定的结构。
一,关联关系（association）
--->关联关系是用一条直线表示的。
--->描述不同类的对象之间的结构关系。它在一段时间内将多个类的实例链接在一起，这与依赖关系是不同的。依赖关系通常表示两个实例之间的临时关联关系。
--->单行关联关系，A知道B的存在，B不知道A的存在。比如UML建模中，参与者知道用例的存在，用例不知道参与者的存在。
二,依赖关系（dependency）
---->依赖关系是用一条带箭头的虚线表示的。它描述一个对象的修改会导致另一个对象的修改这样的关系。
--->与关联关系不同的是，依赖关系除了“知道”其他对象的存在，还会“使用”其他对象的属性或方法。从这个角度讲，以来关系是一种特殊的关联关系。
--->举例，A对象保存了B对象的ID，但A对象对B对象没有操作，这时A仅仅是“知道”B对象，应当用关联关系；如果A对象使用了B对象的属性或方法，则B的修改会导致A的修改，这时A依赖于B。
--->以来关系也有单向依赖和双向依赖之分。但是双向依赖关系是一种非常不好的结构，我们总是应当保持单向依赖，杜绝双向依赖的产生。
三,扩展关系（extends）
---->扩展关系是用一条带箭头的虚线加版型《extends》来表示
---->它特别用于在用例模型中说明向基本用例中的某个扩展点插入扩展用例。
---->一般来说，扩展用例是带有抽象性质的。它表示用例场景中某个“支流”，由特定的扩展点触发而被启动。所以严格来说扩展用例应当用在概念用例模型中，通过分析业务用例场景抽象出关键的可选核心业务而形成扩展用例。不过，在业务模型当中使用也是可以接受的，它可以更显示地表示出一个复杂业务用例的各个“分支”
---->与包含关系不同的是，扩展表示的是“可选”而不是“必需”，这意味着即使没有扩展用例，基本用例也是完整的。如果没有基本用例，扩展用例是不能单独存在的。如果有多个扩展用例，则同一时间用例实例也只会使用其中一个。
---->在建模过程中，我们使用扩展关系可能基于以下理由
（1）表明用例的某一部分是可选（或可能可选）的系统行为，这样就可以将模型中的可选行为和必选行为分开。
（2）表明只有在特定条件（有时是例外条件）下才执行分支流，如触发警报。
（3）表示可能有一组行为段，其中的一个或多个段可以在基本用例的扩展点处插入，所插入的行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互。
（4）表明多个基本用例中都有可能触发一个可选的分支流，从这个意义上说，扩展用例也代表了多个用例的可复用部分。
---->举例子：在打电话时，如果在通话过程中收到另一个呼叫，我们可以将当前通话保留而接听另一个通话。在这个场景中，保留通话用例就是打电话用例的一个扩展用例。我们可以看到，是否需要保留通话取决于打电话人的决定，而不是必需的，即使没有我们没有使用保留通话功能，也不影响打电话的完整性。但是如果没有之前的打电话用例，也就不可能单独启动所谓的保留通话用例了。
四,包含关系（include）
--->包含关系是用一个带箭头的虚线加版型《include》来标示的，它特别用于用例模型，说明在执行基本用例的用例实例过程中插入的行为段。
--->包含用例总是带有抽象性质的，基本用例可控制与包含用例的关系，并可依赖于执行包含用例所得到的结果，但基本用例和包含用例都不能访问对方的属性。从这种意义上讲，包含用例是被封装的，它代表可在各种不同基本用例中复用的行为。因此，与扩展用例一样，包含用例也应当用在概念用例模型中，通过分析业务用例场景而抽象出关键的必选的核心业务而形成包含用例。同样，在业务模型中使用也是可以接受的。它可以显式地表示出那些可复用的业务过程。
---->与扩展用例不同的是，包含用例表示的是“必需”而不是“可选”，这意味着如果没有包含用例，基本用例是不完整的，同时如果没有基本用例，包含用例是不能单独存在的。
---->在建模过程中使用包含用例可能基于以下理由：
（1）从基本用例中分解出这样的行为，它对于了解基本用例的主要目的并不是必需的，只有它的结果才是比较重要的。
（2）分解出两个或更多个用例共有的行为。
---->为了理解包含关系，让我们看一个例子。去银行办业务，不论是取钱，转帐，还是修改密码，我们都需要首先核对帐号和密码，因此可以将可对帐号作为上述业务用例的共有行为提取出来，形成一个包含用例，我们可以看到这个包含用例就带有可复用的意义，如果没有包含用例，取钱，转帐业务是不完整的。同时，核对帐号也不能脱离取钱，转帐等业务用例而单独存在。
五,实现关系（realize）
--->实现关系是用一个带空心箭头的虚线表示的。它特别用于在用例模型中链接用例和用例实现，说明基本用例的一个实现方式。
--->实现所代表的含义是，基本用例描述一个业务目标，但是该业务目标有多种可能的实现途径，每一种实现途径可以用用例实现（或称用例实例）来表示，而用例实现与基本用例之间就构成了实现关系。换言之，每个实现途径都实现了基本用例的业务目标。
六,精化关系（refine）
--->精化关系是用一条带箭头的虚线加版型《refine》来表示的。它特别用于用例模型，一个基本用例可以分解出许多更小的关键精化用例，这些更小的精化用例更细致地展示基本用例的核心业务。精化关系用来连接基本用例和精化用例，说明精化用例是由基本用例精化得来的。
--->精化关系也可以用于模型与模型之间，表示某个模型是通过精化另一个模型而得来的。比如说，我们认为设计类是通过精化分析类而得来的，我们可以用XX设计类《refine》XX分析类来表示他们之间的关系。
--->与泛化关系不同的是，精化关系表示由基本对象可以分解为更明确，精细的子对象，这些子对象并没有增加，减少，改变基本对象的行为和属性。仅仅是更加细致和明确化了。在泛化关系中，基本对象被泛化成为子对象后，子对象继承了基本对象的所有特征，并且子对象可以增加，改变基本对象的行为和属性。
--->另一方面精化关系仅仅用于建模阶段，在实现语言中是没有精化这一语义的。泛化则等同于实现语言中的继承语义。
---->我们讲到概念模型是用于获取业务模型中的关键概念的，从业务模型中分析出实现业务目标的那些核心行为和实体，从而描述出一个关键的业务结构以得到一个易于理解的业务框架。这些关键概念就是对业务用例的精化。他们表示为概念用例到业务用例的精化关系。
作为例子，图展示预存话费业务用例被精化成为四个核心的概念用例，这些概念用例合在一起就满足了实现业务目标的所有关键过程，我们可以根据这精化结果建立业务框架。
七,泛化关系（generalization）
---->泛化关系是用一条带空心箭头的直线表示。泛化关系可用于建模过程任意一个阶段，说明两个对象之间的继承关系。
---->泛化关系表示一个类对另一个类的继承。继承而得的类称为后代。被继承的类称为祖先。继承意味着祖先的定义（包括任何特征，如属性，关系或对其对象执行的操作）对于后代的对象也是有效的。
---->泛化关系是从后代类到其祖先类的关系。
---->特别需要说明的是，作者并不赞同在用例之间使用泛化关系，尽管UML认为它是合法的。原因是用来带有原子特征，每个用例都应当是独一无二的。用例描述了参与者完成一个目标的整个过程，如果采用泛化关系，很难描述子用例继承了基本用例什么。过程？还是业务实体？如果仅仅为了将用例之间的可复用部份或用例的可扩展部分描述出来，那么使用包含关系和扩展关系就足够了。
八,聚合关系（aggregation）
---->聚合关系是用一条带空心菱形箭头的直线表示
---->聚合关系用于类图，特别用于表示实体对象之间的关系，表达整体由部分构成的语义。例如一个部门由许多人员构成
---->与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，部分仍然存在。例如部门撤销以后，人员不会因此而消失，他们依然存在。
九,组合关系（composition）
---->组合关系是用一条带实心菱形箭头的直线表示。
---->需要特别说明的是，在Rose中没有采用实心菱形箭头这一标准的UML图形，而采用了带箭头的空心菱形。箭头指向组合的子对象，表示子对象属于母对象。
---->组合关系用于类图，特别用于表示实体对象关系，表达整体拥有部分的语义。例如母公司拥有许多子公司。
---->组合关系是一种强依赖的特殊聚合关系，如果整体不存在了，则部门也将消亡。例如：母公司解体了，子公司将不存在。
