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

OO系统分析员之路--用例分析系列（6）--用例实现、用例场景和领域模型2010-03-01 csdn博客 coffeewoo上一篇说到我们经过初步的业务分析，得到了用户、业务用例以及业务场景模型。这三项工作成果形成了基本的需求框架，并圈定了业务范围。这时应当做一份基线。

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

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

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

业务用例实现视图：

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

应当在业务用例实现里添加活动图用以描述用例场景，下图为示例，用活动图绘制。如果有多个场景，则应当绘制多个场景图。

业务用例场景（借书过程）：