用例图会不会

l  简介

 

 

n  用例图比较官方定义是这么说的：

 

 

用例图就是由主角、用例以及它们之间的关系构成的图。该图说明了用例模型中的关系。

 

n  可以从两个方面来理解用例图的重要性：

 

 

u 对客户来说用例图是他们业务领域的逻辑化表达；

 

 

u 对建设单位来说，用例图是系统蓝图和开发的依据。

 

 

也就是说只有画好了用例图才能更好的了解系统的功能性需求，才能比较准确的做出客户希望的系统。

 

 

l  遇到的问题

 

 

相信画过用例图的朋友一定有这么一个体会，要么满篇一个小人几个圆圈几根连线——空荡荡；要么N多小人M多圆圈满篇连线——蜘蛛网。这些都是我们所不希望的，这样的用例图可以说没有存在的意义。因为失败的用例图不能准确的表达这个系统具备什么功能，如下面得“用电业务”用例图（其中只画出边界和涉众，未画出各个用例，相信如果画出各个用例将是一片蜘蛛网）。可以说失败的用例图使阅读者看起来就头大，更别说搞懂整个系统的功能需求了！

 

 

l  解决方案

 

 

造成上述问题的原因是没有准确的找到系统边界，进而没有找到真正的主角（actor）！也就是说如果把一个用例的所有涉众都画出来，那么这个用例图肯定是一塌糊涂的。

 

 

我们画图的宗旨：先找系统的边界然后再确定对应的主角，最后才能画出清晰明了的用例图。

 

 

n  怎样确定比较合理的边界？

 

 

通过业务目标（还以上图为例，业务目标是办理业务和交费）可以得到相应比较合理的边界，例如上图的“用电客户服务边界”可以这么确定（如下图）

可以清楚的看到，有了一个准确的业务目标后就可以轻松的找到这个业务的边界。

 

 

具体的方法：只要是关于“办理业务和交费”的操作统统属于这个用例之内，而这个目标的受益者是“银行”和“用电客户”，其他的涉众只能算是配合完成业务目标。于是自然而然的涉众被我们划分成了内外两部分。其中外部的涉众（“用电客户”和“银行”）很可能成为业务主角，内部的涉众（其他涉众）很可能成为业务工人。

 

 

n  确定主角

 

 

在上面的一个步骤中我们知道了可能成为业务工人或业务主角的涉众。

 

 

这里为什么说是可能呢？

 

 

主角一定是对系统有着希望并且直接对系统进行操作的人。

 

 

注意：在系统边界之外的人固然可能对系统有希望，但他们不一定直接对系统进行操纵。

 

 

这也就是说需要一个代理者来行使操作这个系统的动作，而这个代理者正是我们千辛万苦要寻找的业务主角！（如下图）

就像上图那样，业务主角找到了用例自然而然就清晰鸟~

 

 

l  确定最终用例图

 

 

以上仅仅是画用例图前期准备工作，真正我们最终要的用例图才刚刚开始。

 

 

首先说明我们平时口中说的用例实际上是指系统用例，是从系统的视角来看待整个需求的。而上面我们分析了大半天的那些个用例只能叫做业务用例，是从客户业务视角来分析需求和功能的。如果您还不是很清楚的话，以上图中的“申请永久用电”这个业务用例为例可以推导出对应的系统用例（如下图）

也就是说系统用例是将业务用例“具体”、“细化”，即加上要完成这项业务需要的那些其他操作，把这些小项聚集到一起就是我们最重要的也是我们苦苦追求的系统用例！

 

 

到此为止用例图就告一段落，当然用例图只是UML建模的开始，后面系统细化、编码、其他图的绘制等软件开发的每一项都需要用例进行驱动。那些都是后话，咱以后再说……

文中用到的例子及图片引用自《大象》，感谢原书作者提供这么好的案例