难点讲解业务用例系与统用例的区别以及include和extend的使用.docxVIP

业务用例与系统用例的区别所谓的“业务用例”和“系统用例”有什么区别呢？首先，业务用例和系统用例是相对而言的。其次，业务用例和系统用例的研究对象不同。以经典的银行为例。我去银行开户：我在柜台前拿张空白的开户申请单，填写好我的信息，然后把我的身份证和填写好的申请单递给柜员（此处省去排队数十分钟等巨不爽事…）。柜员接个单子，啪嗒啪嗒的把我的信息录入他们的系统。一番折腾后，我面前的密码输入器提示我设置帐号的密码两次。接着，他递出打印了信息的单子，让我签字确认。我签字后递给他，他使劲敲上几个印章，然后把我的存折、身份证以及手续单递给我，并且告诉我办好了。这是银行很简单很常见的服务，也可以说是银行的功能。其实银行还有很多其它“功能”，比如存钱、取钱、挂失等等。此时，我们其实是在把银行看作一个能提供很多“功能”的“系统”。同时，在这个过程中，柜员一直在操作银行的软件系统，过程可能是这样的：柜员首选选择开户功能；软件系统要求柜员将我的信息录入，并选择开户类型（我在申请单上写的是活期）；软件系统可能会检查我的身份证号是否合法；软件系统为我生成一个银行帐号；软件系统会问柜员我是否要密码（我在开户申请单上注明了需要），所以软件系统提示我设定密码；软件系统将我的存折打印出来。银行的软件系统给柜员提供了很多功能，除了开户当然也会有存钱、取钱、挂失等。但这些功能是银行的软件系统提供给银行职员的。这样我们综合上述两个过程来看，其实我们在研究两个层次的“功能”。第一层次是银行提供给银行的客户的功能；第二层次是软件系统提供给银行职员的功能。如下图所示： 当我们对银行的业务进行建模时，我们会把银行看作一个整体，去研究银行会提供给客户哪些服务。此时我们的研究对象是银行。?? 当我们对银行的软件系统进行建模时，我们把软件系统当作一个整体，去研究它需要提供哪些功能给银行的职员使用。此时我们的研究对象是银行的软件系统。 这样我们为了区分起见，把前者称作“业务用例模型”；相对的，把后者称作“系统用例模型”。业务用例和系统用例在用例技术的使用上没什么差别，如用例的关系、用例的描述等。在业务模型中还有一个概念，即“业务工人（Business Worker）”。业务工作表示实现业务的人、软件或硬件等角色。比如银行的“开户”业务用例中，银行柜员、软件系统、打印存折的打印机等都可看作是“业务工人”。用例间的关系：include和extend通常来说，用例之间有两种关系：包含（include），扩展（extend）。这也是UML 2.2官方规范中说明的两种关系。包含（include）关系为用例建模提供了从两个或更多的Use Case的描述中抽取通用部分的能力。所以，在描述Use Case之前就开始抽取包含用例是不可取的；再有，如果没有两个以上的Use Case来包含这个Use Case，那么这个抽取是毫无意义的。扩展（extend）关系提供了使用另外的可选流程来补充或插入到一个已存在的Use Case中的能力。因此，这是一种能够扩展原Use Case却不用对原来的Use Case进行重新描述的方法。?这两种关系在实际应用中究竟应如何区别有时会很难把握，建议可以根据如下特征来区分。包含关系：1.?对基用例来说，如果缺少了被包含用例则是不完整的。即，被包含用例是基用例不可缺少的一部分。2.?被包含用例对基用例是可见的，即基用例知道被包含用例的存在。3.?被包含的用例通常应被两个以上的其他用例所包含，否则应该考虑一下是否应该使用包含。例子：校内网（）中，“查找好友”可能为“发送消息”和“删除好友”所包含。??? 扩展关系：1.?如果去掉扩展关系，基用例仍然完整。2.?扩展用例本身具有独立的功能，而非从其他用例抽取出来的。3.?基用例对扩展用例是可见的，而扩展用例对基用例不可见。也即，基用例不知道有扩展用例的存在。Kurt Bittner等在《Use Case Modeling》给出了可能需要使用扩展用例的几种情况：描述一些对系统的基本功能来说是可选的特性。例如，可能是一些由系统提供甚至可从第三方购买的一些可选的系统特性。描述一些可能使主流程变得很晦涩难懂的、十分复杂的错误或异常处理过程。例如，有些分支流程巨长，尤其是比主流程还长。为一些特殊顾客定制的需求。由于范围管理和发布管理的需要。例如，有些系统特性或行为在后来的发布中才会包括，那么在后来的项目中可以用扩展用例来对系统功能进行扩展。例子：收邮件时，忘记密码了，需要找回密码。“找回密码”对“收邮件”来说是个扩展用例。??? ?如果在有些情况下你仍然觉得很难决定应该使用include还是extend，那么停止纠结，就用include吧（因为包含比扩展更容易让人懂，而扩展比包含更容易让人懵，:-)）！“错”就“错”了，总比无谓的浪费时间好