UML中的关系比较与解析

   在画UML中的9种图之前，我想有必要先要把UML图中的关系搞清楚，以下的内容是我在看视频和看书之后总结出来的，希望能够对大家有所帮助，同时我更希望得到大家的意见来纠正我理解得不对的地方。

   扩展关系及扩展用例：

• 没有扩展用例，基本用例也是完整的；没有基本用例，扩展用例是不能单独存在的。
• 如果有多个扩展用例，同一时间只会使用其中的一个。
• 表明用例的某一部分是可选的系统行为。

举例：目前我还想不出来可以用机房收费系统来说明此关系和此用例的例子。不过，为了便于大家理解，还是把书中的例子介绍给大家。用户用手机打电话是个基本用例，但是在通话过程中，有另外一个电话打来，这时保留当前通话，就可作为一个可选的扩展用例，因为用户可以继续当前通话，也可以暂时保留当前通话，而去接听刚打来的电话，我们看到扩展用例并不影响用户打电话的完整性。它可有可无。

  包含关系及包含用例：

• 没有包含用例，基本用例是不完整的；没有基本用例，包含用例是不能单独存在的。

举例：比如在机房收费系统的用例图中有个基本用例是：Log in the system（登录进入系统），但是在执行该用例时，必需先Check name and password(核对用户名和密码)。所以核对用户名和密码可认为是包含用例。没有它基本用例是不完整的，但是它又不能成为一个单独存在的基本用例。

• 包含用例常常代表在各种不同用例中可复用的行为。

举例：比如在机房收费系统中，在On computer（上机），Charge Cash（充值），Return Card（退卡）这几个基本用例执行时，都必须验证欲上机的卡号是否已经注册过，所以验证卡号是否已注册，就是个包含用例，它可以在不同的基本用例中复用。

• 从基本用例中分解出的行为，它对于了解基本用例的目的不是必需的，只有它的结果比较重要。

举例：就比如上面说到的“验证卡号是否已经注册”可以说根本不是用户的需求，目的，用户只想用系统来上机，充值，退卡，但是我们只有验证了卡号，知道该卡号是否已经注册，才会正确地去执行符合我们需求的用例。

• 分解出的两个或更多个用例共有的行为

举例：这也就是我们前面说的“复用”，验证卡号是否已注册在三个基本用例中都有用到。

  实现关系：

举例：比如我们想实现强制学生下机这个用例，我们可以通过选中学生分别下机来实现，也可以通过让所有学生同时下机来实现。选择哪种方式来实现，就得看在实际使用过程中用户的具体需求了。

以下的表格中列出了UML中的关系比较：

UML中的关系比较与解析

原文：http://blog.csdn.net/u010924834/article/details/19248543