OO系统分析员之路--用例分析系列（6）--用例实现、用例场景和领域模型

作者: coffeewoo 先生

上一篇确定了业务用例，以及业务场景。该场景只描述了业务框架，接下来要对业务用例进行场景分析。用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型（领域模型），每个业务用例还应当写一份用例文档，也称为用例规约（UseCase Specification）。若有非功能性需求，例如性能要求，吞吐量要求等，还应当写一份补充用例规约。





上一篇说到我们经过初步的业务分析，得到了用户、业务用例以及业务场景模型。这三项工作成果形成了基本的需求框架，并圈定了业务范围。这时应当做一份基线。

当然，第一份基线所包括的内容是非常粗的，要达到完整的需求说明还有更多工作要做。这一篇就来说说详细的需求过程和产出物，以及这些成果对需求的贡献。在开始之前，还是提醒读者下载实例，本文下面只会从实例中挑选很少一部分来说明，对照实例读者将能更好的理解。

上一篇确定了业务用例，以及业务场景。该场景只描述了业务框架，接下来要对业务用例进行场景分析。用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型（领域模型），每个业务用例还应当写一份用例文档，也称为用例规约（UseCase Specification）。若有非功能性需求，例如性能要求，吞吐量要求等，还应当写一份补充用例规约。用例规约将在下一篇描述。


首先是业务用例实现视图。并非所有的业务用例都一定要最终在系统中实现，因此，这个视图的含义是表达由需求范围到系统范围的映射关系。这个视图没什么技巧，也可以省略，不过笔者建议不要省略。需求应当保持过程的连续和可追溯性，这是软件过程可控的重要保证。

业务用例实现视图：



针对每个业务用例实现，应当对用例的实现过程进行场景模拟。上一篇是业务场景，而用例实现既然已经谈到“实现”，则应当将计算机包括进来，从人-机交互的视角来模拟业务场景。这是概念模型的一种，表达用户的实际业务在计算机环境下是如何实现的，给用户一个初步印象，告诉他们将来他们将怎样来做业务。请注意，虽然计算机已经参与需求描述，但是要尽量避免使用计算机术语，因为这时的文档仍然属于需求文档，是要与用户交流的，太多的计算机术语会大大降低用户对需求的理解能力。霍金在写时间简史时曾经说过，在书中加入哪怕一个数学公式，都会让书的销量减半。业务用例场景是概念模型的一种，但不是概念模型的全部。概念模型本篇不打算讨论，简单说一下，概念模型主要包括业务架构和系统原型。
应当在业务用例实现里添加活动图用以描述用例场景，下图为示例，用活动图绘制。如果有多个场景，则应当绘制多个场景图。

业务用例场景(借书过程)：



用例场景有另一个重要意义，是帮助系统分析员发现和定义业务实体。业务实体一般来说就是调研时用户所提供的各类表单或报表，但在很多情况下，并非每一份表单就是一个业务实体，所有业务表单也不一定涵盖全了所有业务实体。很多系统分析员声称业务实体的发现过程是全凭经验的，到底有哪些业务实体，靠经验进行提取。笔者要说，经验固然重要，但经验有一个最大的缺陷---不能重复和验证。即，这些实体是怎么从业务中提取出来的？它们是怎样参与业务的？这些实体已经足够支持业务了吗？凭经验分析者无法通过文档将这个提取过程记录下来，而脑子里的东西是无法共享和传承的，越大的团队，越复杂的项目，尤其是横向结构的项目组结构下，这个缺陷越严重。很多人觉得用UML和RUP描述的需求总是一块块分离的，不知道是怎么出来的，觉得很乱，原因就在于此。实际上，RUP做需求，每一步都是可验证和回溯的。用例实现视图是一个例子，这里也是一个例子。
让我们看看上面的业务场景视图，每一个活动都有类似的命名：出示借阅证、查找需要的图书、放入借书栏.....看出什么来了吗？每个活动都是一个动作加上一个动作的受体。受体正是我们要寻找的业务实体，这些名词就是实体的来源。在需求阶段，系统分析员不要去考虑什么抽象，什么模式，别急，那是系统模型做的事情。抽象了，还弄一堆什么Factory模式，Builder模式之类的出来，用户能看懂吗？别忘了我们正在做的是需求文档，是做给用户看的。
观察上面的用例场景，分析出现的名词，我们得到一个个业务实体，再根据场景分析这些业务实体之间的关系。实际上就是大家都熟悉的ER模型，但是与数据库建模的视角还是有所差别的。数据库ER模型要受到数据关系范式的限制，而业务实体ER模型则不必理会这种限制。只要与现实物体符合就OK。好了，罗嗦了一大堆，我们终于得到了我们的成果。

借阅图书过程业务实体视图：


上图中画那么多虚线连接到业务用例实现是用来表示业务实体与业务用例实现之间的追溯关系的，这些线虽然麻烦，但是笔者强烈建议不要图省事。因为业务实体通过它们可以追溯到原始需求，再次重申，软件过程要可控，需求可追溯是需要时时谨记的。当然，如果嫌麻烦，您也可以用下面的这种形式，是不是简洁得多呢？



经过以上的过程，我们得到了什么呢？往下看之前笔者建议您回想一下，总结一下。

第一、我们通用用例实现视图，从业务用例中找出了那些我们将在系统中实现的用例，并且记录了要在系统中实现的用例是如何映射到原始需求的。这提供了需求可追溯的验证。

第二、针对每个用例实现，我们引入了计算机，将实际的业务从人-机交互的角度模拟了执行过程。不仅得到了一个业务怎样在计算机环境下执行的概念模型，同时也给用户描述了他们将怎么和计算机交互以达到他们的目标。笔者提醒大家，用例场景非常非常的重要，后续工作就得靠它们了！！绝对要认真对待，深入调研，不可漏掉一个场景，也不可模糊不清。

第三、通过对场景的分析，给了我们重要的线索去发现业务实体。而我们发现了业务实体之后，又通过用例场景来验证这些实体是否支持了用例的实现。

现在请读者思考一下，如果记不清了，可以翻翻之前的文章。到现在为止，我们的需求是不是一步一步推出来的？从粗到细，从模糊到清晰，从原始需求到计算机的引入，是不是每一步都是可以追溯的呢？每一步的分析结果是不是都有方法来验证正确性和完备性呢？如果您之前迷惑于需求的各个阶段无法关联，也说不清分析结果是否是正确的，那么建议您再从头看看笔者目前已经完成的文章，找出这些线索来，相信您会对UML和RUP的理解提高一个层次的。

这篇文章该结束了。可是等等，到目前为止，虽然我们已经得到了不少产品，或可交付物，或成果，或deliverable...不管叫什么吧，我们已经做了很多工作了。不过作为需求来说，好象还缺点什么吧？对了，我们还缺少业务规则和业务实体的详细属性，这两个需求必不可少的内容，将在下一篇中讨论。敬请期待。