《话用例建模：用例间的关系：include和extend》由会员分享，可在线阅读，更多相关《话用例建模：用例间的关系：include和extend（2页珍藏版）》请在金锄头文库上搜索。
1、话用例建模【5】：用例间的关系：include和extendPosted on 2009-06-16 23:30 Aaron 阅读（455）评论（2）编辑收藏关于Use Case之间的关系，绝大部分书籍一带而过，大概是因为很简单。但是却是在实际应用中争 论和疑惑蛮多的问题之一。通常来说，用例之间有两种关系：包含（include），扩展（extend）。这也是UML 2.2官方规范中 说明的两种关系。包含（include）关系为用例建模提供了从两个或更多的Use Case的描述中抽取通用部分的能力。所 以，在描述Use Case之前就开始抽取包含用例是不可取的；再有，如果没有两个以上的Use C
2、ase来包含 这个Use Case，那么这个抽取是毫无意义的。P.S:子功能块？ ？扩展（extend）关系提供了使用另外的可选流程来补卜充I或插入到一个已存在的Use Case中的能力。因此，这是一种能够扩展原Use Case却不用对原来的Use Case进行重新描述的方法。这两种关系在实际应用中究竟应如何区别有时会很难把握，建议可以根据如下特征来区分。包含关系：1. 对基用例来说，如果缺少了被包含用例则是不完整的。即，被包含用例是基用例不可缺少的一 部分。2. 被包含用例对基用例是可见的，即基用例知道被包含用例的存在。3. 被包含的用例通常应被两个以上的其他用例所包含，否则应该考虑一下是否
3、应该使用包含。例子：校内网（）中，“查找好友”可能为“发送消息”和“删除好友”所包含。发送消息查技好友._-indude扩展关系：异常流程扩展；1. 如果去掉扩展关系，基用例仍然完整。2. 扩展用例本身具有独立的功能，而非从其他用例抽取出来的。3. 基用例对扩展用例是可见的，而扩展用例对基用例不可见。也即，基用例不知道有扩展用例的存在。Kurt Bittner等在Use Case Modeling给出了可能需要使用扩展用例的几种情况： 描述一些对系统的基本功能来说是可选的特性。例如，可能是一些由系统提供甚至可从第三方购买的一些可选的系统特，性| 描描述一些可能使主流程变得很晦涩难懂的、十分复杂
4、的错误或异常处理过程。例如，有些分支流程巨长，尤其是比主流程还长|为一些特殊顾客定制的需求。由于范围管理和发布管理的需要。例如，有些系统特性或行为在后来的发布中才会包括，那么在后 来的项目中可以用扩展用例来对系统功能进行扩展。例子：收邮件时，忘记密码了，需要找回密码。“找回密码”对“收邮件”来说是个扩展用例。如果在有些情况下你仍然觉得很难决定应该使用还是，那么停止纠结，就用 吧（因为包含比扩展更容易让人懂，而扩展比包含更容易让人懵，:-）！ “错”就“错”了， 总比无谓的浪费时间好。另外，你可能偶尔还会看到关系，这见于较早版本的UML中，以前的和 被现在的 取代，可以将之理解为 关系。还有Ge
5、neralization，虽然在官方规范中未明确说明，但是偶尔会有人讨论Use Case之间的 Generalization关系。我对此不欲多说，因为在我几年的Use Case Modeling经历中，我真的没有 觉得我需要在Use Case间使用Generalization关系的场景。本着“简单”和“沟通”的原则，忘记 它吧！虽然前面说了这么多，可是最后我想说，Use Case之间不要随便搞“关系”。很多人喜欢把Use Case 图画得很玄乎，关系搞得很复杂！很不幸，方向错了。Kurt Bittner等的Use Case Modeling 中说：If there is one thing that sets teams down the wrong path, it is the misuse of the use-case relationships include,extend and generalization. Alistair 在编写有效用 例中也十分强调，Use Case真正有价值的是Use Case描述，所谓的用例间的关系往往价值 不大还会适得其反。
