OO系统分析员之路--用例分析系列（5）--用户、业务用例和业务场景

作者: coffeewoo 先生

用户、业务用例以及业务场景。这三项工作成果已经形成了基本的需求框架，并圈定了业务范围。就笔者的工作习惯而言，在得到这三个成果后，就会暂停调研，而通过评审会，研讨会等形式充分论证这些成果的正确性和完备性。求得业务专家，用户代表，开发方，项目经理等各方的一致认可，将其作为第一份基线。




很久没有动笔了，这期间承蒙许多朋友的喜欢和鼓励，再不写点东西就对不住这些朋友了。

写点什么呢？按照原先的设想，应该开始动手写如何从业务用例转化到概念用例和系统用例，不过老实说这一步需要的是经验居多，而很难找出一个普适的步骤来。先暂时放一放吧，以后一定会写到的。上一篇讲到用例分析的一般步骤和方法，也给出了一个实例，不过没有做更进一步的说明，所以这一篇，笔者决定先罗嗦罗嗦之前的内容，说说业务建模中各种图的用法，以及它们对需求的贡献。

在说明实例之前，再重复一下的需求，并提醒读者下载实例，本文下面只会从实例中挑选很少一部分来说明，对照实例读者将能更好的理解。好了，让我们先回头看看需求吧，图书馆主任是这么说的：

我们原本是一个传统的图书馆，传统的借书方式要求读者亲自来到图书馆，这显得非常不方便，而且随着藏书的增加和读者群的增长，尤其而且大量的读者到图书馆，使得图书馆的场地不足，工作人员也不够了。所以想到借助网络，让读者通过网络借/还书，这样可以省掉大量的场地维护和工作人员成本支出，同时计算机可以方便的检索目录，让读者可以足不出户借到需要的书。为了把书送到借阅人手里，我们已经联系了A特快专递公司和B城市物流公司，初步达成协议，由他们往返借阅人和图书馆之间把图书送出和收回。读者在网上出示和验证借书卡，找到他们需要的书，提交申请，图书管理员确认后，就会通知物流公司来取书，当读者拿到书之后，物流公司需要把读者的签单拿回来以证明读者已经拿到了书。当然这个过程中，读者是需要付费的。还书也是基本同样的过程。

还记得上一篇是怎么说的吗？第一步骤是从涉众中找出用户。并定义这些用户之间的关系。 这里的用户是指将与要建设的系统发生关系的那些涉众。通过下图表示。这张图里要绘出所有用户，以及它们之间的关系。需要说明的是，这里的用户指的是业务用户，并非将来系统中的“角色”，虽然将来它们可能就是。这张图的意义在于，清楚的表明将来的系统是为谁在服务，他们都是干什么的，有什么特点，有什么关系。对用例方法来说，这是最基本的出发点。用例，是以人为本的。



第二步，找出每个用户要做的事，即业务用例。业务用例来自于系统分析员对上一步中所有用户的访谈，总结和归纳（笔者正在考虑写一写系统分析员调研技巧方面的文章，会对访谈技巧，归纳方法有所描述）。笔者建议从每个用户的角度以及从每项业务的角度来绘制业务用例图，就象下面这样：

用户视角：


从用户视角查看每个用户在系统中将参与什么业务。这个视图的意义在于，调研对象一眼就能看出来，这个模型是否已经涵盖了他所有需要做的事。

业务视角：


从业务的视角查看每项业务是由哪些用例和哪些角色参与完成的。这个视图的意义在于，需求研讨会上业务专家可以一眼看出这个模型是否已经能够完整的表达业务。

第三步，针对每项业务视图，应该绘制业务场景图，用活动图详细描述这些用户、用例是如何交互来完成这项业务的。就象下面这样:

借阅图书业务过程:

业务场景图可能不止一个。同样一项业务，会有很多种不同的业务实现方式，例如借阅图书业务，就有可能第一次借书，又还书又借书，VIP客户借书，借书时借证已经到期....等等许多种场景。对于这些场景来说，每一个都不能漏掉或省略，至少必须在文档中体现出来，除非已经很明确这个业务场景不包括在系统范围之内。这些业务场景图的意义在于，它已经绘制出了一份系统蓝图，将来的系统建设很大程度将依据这些场景图进行。


经过上面的三个步骤，我们得到了用户、业务用例以及业务场景。这三项工作成果已经形成了基本的需求框架，并圈定了业务范围。就笔者的工作习惯而言，在得到这三个成果后，就会暂停调研，而通过评审会，研讨会等形式充分论证这些成果的正确性和完备性。求得业务专家，用户代表，开发方，项目经理等各方的一致认可，将其作为第一份基线。笔者很少在这个基线形成之前深入细化需求，因为需求过程，或说用例过程是一个自顶向向下的过程，RUP中的每一个迭代实际上仍然是一个瀑布模型，大家都知道，如果上一步没有形成基线就进行下一步，对瀑布模型来说是无法控制的。

好了，这一篇就到此为止，下一篇继续讨论用例场景，用例文档等建模过程。