第30章用例关联-暨南大学..docVIP

第 30 章 用例关联 目标： 以文本和图形两种形式，使用包含（ include ） 和扩展（ extend ） 关联将用例联系在一起。 Include 包含关系 包含关系就是将几个用例中相同部分抽出来，形成一个单独的用例，那么就说那几个用例包含该用例。其实包含的意义在于减少冗余，增加复用，所以在编写用例时出现包含关系应该是一件水到渠成的事情。于是 Fowler 给出了何时使用包含关系的简单且实用的准则 [Fowler03] ： 当在两个或多个独立用例中存在重复，而你想避免这种冗余时，可以使用 包含 关系。 包含 关系的另一个用途是描述异步事件的处理。指的是在任何时候都可以在主场景中插入该动作。 Cockburn 建议： 使用包含关系来处理用例之间的关系是首要原则。 Extend 扩展关系 扩展关系 是当一个用例不便或不能任意在其上添加新功能时创建扩展或附加用例，并且在其中描述，在何处和何种条件下该用该用例扩展某基础用例的行为。相当于一部没用照相机的手机（基础用例），想要添加照相功能，就需要增加一个扩展插件（扩展用例），但是需要在原来手机中提供插入接口（扩展点）。具体例子见 360 页。 批驳和指正一些不正确的做法是 Larman 本书的一个特点，在这一部分他指出“某些用例准则建议使用扩展用例和扩展关系，将有条件行为或者可选行为加入基础用例。这一观点是不正确的。”好的做法是“将其直接写入（基础用例的） 扩展 部分”。增加扩展用例和扩展关系的最现实动机（或者可以说是最好的动机）就是：由于某种原因实在不能在基础用例上进行修改了。 泛化关系 绝大多数情况下不会使用，而且避免过多使用用例关系是好的实践，即便使用了用例关系，也只是在必要时使用简单的包含关系就可以了。用例顾问们共同观测结论是：大量用例关系会导致复杂结果，并且会花费大量徒劳的时间。 第 31 章 领域模型的精化 时间间隔 反映了某些业务对象仅在有限的一段时间内有效者一概念。 包 使用包可以将大的领域模型组织成较小的单元。 概念分类列表 分类 示例 有形对象 CreditCard ， Check 事务 CashPayment ， CreditPayment 其他外部的计算机或机电系统 CreditAuthorizationService 抽象概念 组织机构 CreditAuthorizationService 金融、工作、合同、法律事务等的记录 AccountsReceivable 从用例中识别名词短语 不能机械地从用例中提取概念，应该作出必要的判断和适当的抽象。 Generalization 泛化 泛化是 在多个概念中识别共性和定义超类（普遍概念）与子类（具体概念）关系的活动。 此活动对概念进行分类学意义上的分类，并将其在类层次结构中表示出来。遇到相似的概念，将其组织起来，形成泛化—特化类层次结构（简称类层次结构）。在这里我们讨论的是概念类而非软件类。 什么样的概念子类是正确的？ 正确的概念子类应遵守下面两条规则（ 规则意味着一定要遵守）： ????????? 100% 规则（定义的一致性） ????????? Is-a 规则（集合成员关系的一致性） 定义概念子类的动机 准则 在下述几种情形下创建概念类的子类： 1 ）子类有额外的有意义的属性 2 ）子类有额外的有意义的关联 3 ）子类概念的操作、处理、反应或使用的方式不同于超类或其他子类，而这些方式是我们所关注的。 4 ）子类概念表示了一个活动体（例如动物、机器人等），其行为与超类或者其他子类不同，而这些行为是我们所关注的。 有意义和我们所关注的成为了上述准则（也可以说是 Larman 的整体思想）所强调的一个重点，子类的创建一定要创造价值，否则就不要创造它了。而上述准则为我们指明了创造子类的动机，无外乎就是说子类有了新的有意义的属性、关联和方法，需要将其创建出来。 定义概念超类的动机 准则 在下述几种情形下可以创建与子类具有泛化关系的超类： 1） ? 2） ? 100% 和 Is-a 规则 3） ? 4） ? 对变化的状态建模 准则 不要将概念 X 的状态建模为 X 的子类。有两个办法可供选择： 1 ）定义状态类层次结构，并将其与类 X 关联 2 ）在领域模型中忽略概念的状态，而在状态图中加以反映。 关联类 准则 在领域模型中，如果类 C 可能同时有多个相同的属性 A ，则不要将属性 A 置于 C 之中。应该将属性 A 放在另一个类中，并且将其与类 C 关联。 增加关联类的准则 准则