*/ 出自： 编程中国 http://www.bc-cn.net
*/ 作者： guoyu
*/ 时间： 2007-10-17 编程论坛首发
*/ 声明： 尊重作者劳动，转载请保留本段文字
*/ --------------------------------------------------------------------------------------
[size=5]1.5.1用例不能清晰表达吗？
分析师R在阅读了需求分析师N的用例后，颇有一些想法，于是R去找N进行探讨。原因是这样的，请见用例模型，如图1.17所示。
[/size]
图1.17 系统用例1
这个用例模型是需求分析师N在完成了需求调研后所画的，N的说法是“库存管理员在查询分销商的信息后，将得到分销商一览界面，接着库存管理员可以选择一个分销商，对该分销商的详细信息进行修改”。在N的脑海中，这样的用例模型将会产生如下的界面原型，如图1.18、1.19所示。
图1.18 分销商一览
图1.19 分销商修改
图1.18所表示的是“分销商一览界面”，通过对每个分销商名字链接的单击，可以进入图1.19的“分销商修改界面”。N认为自己的用例没有画错，图1.17用例的字面上解释是“查询分销商信息用例包含了修改分销商信息用例”，所以图1.18和1.19完全可以通过图1.17的用例模型来画出。但是事实怎么样呢？R是怎么理解的呢？
1.5.2 另一张用例模型图
对于N的解释，R并没有去争辩什么，只是，R也画了一张用例模型图，并作出了解释。如图1.20所示。
图1.20 系统用例2
图1.20的用例模型与图1.17的用例模型最大的不同，在于“查询分销商业信息”和“修改分销商信息”之间的箭头被改成了反向，并且线上的注解从“include”变成了“extend”。R说图1.20的用例模型的含义是“修改分销商信息用例从查询分销商信息用例扩展而来”，同样可以表述图1.18和1.19。
这下N也觉得诧异了，R的说法不无道理，从字面上说，先通过得到分销商信息的一览界面，然后扩展出修改分销商信息的界面是很正确的。难道两个不同的画法可以表明同一个问题吗？或者extend和include是可以互相转换的吗？
1.5.3 更多的用例模型画法
在解释1.5.2节所提出的问题前，请读者不妨再看另两张用例模型的画法，请不要吃惊和迷惑，因为从字面上来看，这两张用例模型的画法同样可以达到图1.17的用例模型所要表述的内容。如图1.21、图1.22所示。
图1.21 系统用例3
图1.22 系统用例4
图1.21字面上的意思是，在修改分销商信息的用例中，将会包含查询分销商信息的用例，所以，同样是先查询分销商信息一览然后进行修改。
图1.22字面上的意思是，查询分销商信息的用例是从修改分销商信息扩展而来的，因为主业务是要做修改分销商信息。
这又如何呢？读者是不是觉得已经很混乱了呢？
1.5.4 理解extend和include
要想找到真正的答案，理解清楚extend和include是非常重要的，这是关键。
（1）extend是扩展的意思，它的含义是当B用例是从A用例扩展而来的，那么就应该用箭头从B指向A，并注明extend。所谓扩展，就是对于A用例来说，并不一定要存在的，即就算把B用例去除，A用例依然可以运转下去。
（2）include是包含的意思，它的含义是当B用例是被A用例包含的，那么就应该用箭头从A指向B，并注明include。所谓包含，就是对于A用例来说必须存在，即不能把B用例去除，否则A用例将无法运转。
注意：从主动和被动方面，可以轻松记得箭头的指向，包含（include）必然是己方主动的，那箭头应该对着对方，扩展（extend）必然是他方主动的，那箭头就应该指向己方。
1.5.5 再来看图
究竟哪一张用例模型图是正确表达了N的意思呢？根据extend和include的理论，看图说话是最清晰的。extend意味着即使把B用例去掉也不影响A用例，从extend来下手是最妥当的。把图1.20和图1.22中extend的用例去掉，看看是否满足了N的需求呢？如图1.23和1.24所示。
图1.23 系统用例图1.20改
把extend的用例去掉后，图1.20改成了图1.23，可以看到库存管理员一开始需要查询分销商信息，然后什么都不做。这很明显是符合了N先查询一览的思想。
图1.24 系统用例图1.22改
* 把extend用例去掉后，图1.22改成了图1.24，库存管理员一进来就需要修改分销商信息，而事实是，库存管理员需要先使得系统状态转变为分销商信息一览，然后选择一个分销商进行修改。所以图1.22是不满足N的想法的。
* 图1.17根据include的理论，对于图1.17来说，修改分销商信息是必须存在的，否则就不能称其为“查询分销商信息”，当查询分销商信息时，必须同时修改分销商信息。这不满足N的想法。
* 图1.21说明查询分销商信息是必须存在的，否则就不能称其为“修改分销商信息”，听起来没错，但是请仔细看一下图，参与者业务角色“库存管理员”第一步是去做的“修改分销商信息”，在这步里面去“查询分销商信息”，这也是不正确的（针对这张图的界面是另一种结果，将在下一节中展示）.
1.5.6 看图说话
在之前所给出的四张图中，只有图1.20是最符合N的想法的，其余三张用例模型虽然在这个例子中是不正确的，但是在其他需求的可能中却会是正确的。作为一名分析师，做用例和看用例都要学会“看图说话”，因为用例模型本身是用来交流的，做用例的人想把自己的想法表达给别人，而不会造成别人误解是关键。下面就将图1.17、图1.21、图1.22真正想表达的含义用界面原型和文字来阐述一下，以加深印象。
* 对于N所画的图1.17，其真正表达的含义是这样的：在查询分销商信息的同时，需要修改分销商信息。对于一个业务要求“每次查询分销商信息的时候，必须记录下查询者的身份，并修改所有被查询分销商的访问率”来说，图1.17就是正确的了。如图1.25所示的业务流程。
图1.25 业务流程
* 对于图1.21，其真正表达的含义是这样的：在修改分销商信息的同时，必须查询分销商信息，就是批量修改的概念。其界面原型如图1.26所示。分销商名称作为条件，通过模糊查询查询出一览页面，以此作为前提，修改分销商的信息。
图1.26 批量修改的界面原型
* 对于图1.22，其真正表达的含义是这样的：在修改分销商信息的时候，可以查询分销商信息，通过界面原型可以更好的理解其意义，如图1.27所示。
图1.27扩展的查询用例
用例如何画，分析师如何看是必须掌握的，这样对于一个团队项目的成功有很大的好处。
摘自：人民邮电出版社的《揭密J2EE项目开发的70个问题》.
