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

业务用例与系统用例的区别所谓的“业务用例”和“系统用例”有什么区别呢？
首先，业务用例和系统用例是相对而言的。

其次，业务用例和系统用例的研究对象不同。

以经典的银行为例。

我去银行开户：我在柜台前拿张空白的开户申请单，填写好我的信息，然后把我的身份证和填写好的申请单递给柜员（此处省去排队数十分钟等巨不爽事…）。

柜员接个单子，啪嗒啪嗒的把我的信息录入他们的系统。

一番折腾后，我面前的密码输入器提示我设置帐号的密码两次。

接着，他递出打印了信息的单子，让我签字确认。

我签字后递给他，他使劲敲上几个印章，然后把我的存折、身份证以及手续单递给我，并且告诉我办好了。

这是银行很简单很常见的服务，也可以说是银行的功能。

其实银行还有很多其它“功能”，比如存钱、取钱、挂失等等。

此时，我们其实是在把银行看作一个能提供很多“功能”的“系统”。

同时，在这个过程中，柜员一直在操作银行的软件系统，过程可能是这样的：
柜员首选选择开户功能；软件系统要求柜员将我的信息录入，并选择开户类型（我在申请单上写的是活期）；软件系统可能会检查我的身份证号是否合法；软件系统为我生成一个银行帐号；软件系统会问柜员我是否要密码（我在开户申请单上注明了需
要），所以软件系统提示我设定密码；软件系统将我的存折打印出来。

银行的软件系统给柜员提供了很多功能，除了开户当然也会有存钱、取钱、挂失等。

但这些功能是银行的软件系统提供给银行职员的。

这样我们综合上述两个过程来看，其实我们在研究两个层次的“功能”。

第一层次是银行提供给银行的客户的功能；第二层次是软件系统提供给银行职员的功能。

如下图所示：
当我们对银行的业务进行建模时，我们会把银行看作一个整体，去研究银行会提供给客户哪些服务。

此时我们的研究对象是银行。

当我们对银行的软件系统进行建模时，我们把软件系统当作一个整体，去研究它需要提供哪些功能给银行的职员使用。

此时我们的研究对象是银行的软件系统。

这样我们为了区分起见，把前者称作“业务用例模型”；相对的，把后者称作“系统用例模型”。

业务用例和系统用例在用例技术的使用上没什么差别，如用例的关系、用例的描述等。

在业务模型中还有一个概念，即“业务工人（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>>吧（因为包含比扩展更容易让人懂，而扩展比包含更容易让人懵，:-)）！“错”就“错”了，总比无谓的浪费时间好。

另外，你可能偶尔还会看到<<uses>>关系，这见于较早版本的UML中，以前的<<uses>>和<<includes>>被现在的<<include>>取代，可以将之理解为
<<include>>关系。

还有Generalization，虽然在官方规范中未明确说明，但是偶尔会有人讨论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描述，所谓的用例间的关系往往价值不大还会适得其反。