OO系统分析员之路--用例分析系列（6）--用例实现、用例场景和领域模型
作者: coffeewoo(http://coffeewoo.itpub.net)发表于: 2006.08.22 23:45
分类: 系统分析、设计，UML及OO ,
出处: http://coffeewoo.itpub.net/post/9169/197412
---------------------------------------------------------------
上一篇确定了业务用例，以及业务场景。该场景只描述了业务框架，接下来要对业务用例进行场景分析。用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型（领域模型），每个业务用例还应当写一份用例文档，也称为用例规约（UseCase Specification）。若有非功能性需求，例如性能要求，吞吐量要求等，还应当写一份补充用例规约。
上一篇说到我们经过初步的业务分析，得到了用户、业务用例以及业务场景模型。这三项工作成果形成了基本的需求框架，并圈定了业务范围。这时应当做一份基线。
当然，第一份基线所包括的内容是非常粗的，要达到完整的需求说明还有更多工作要做。这一篇就来说说详细的需求过程和产出物，以及这些成果对需求的贡献。在开始之前，还是提醒读者下载实例，本文下面只会从实例中挑选很少一部分来说明，对照实例读者将能更好的理解。
上一篇确定了业务用例，以及业务场景。该场景只描述了业务框架，接下来要对业务用例进行场景分析。用例场景分析要用到三种视图，业务用例实现视图、业务用例场景、业务实体模型（领域模型），每个业务用例还应当写一份用例文档，也称为用例规约（UseCase Specification）。若有非功能性需求，例如性能要求，吞吐量要求等，还应当写一份补充用例规约。用例规约将在下一篇描述。
业务用例实现视图： 
应当在业务用例实现里添加活动图用以描述用例场景，下图为示例，用活动图绘制。如果有多个场景，则应当绘制多个场景图。
业务用例场景(借书过程)： 
让我们看看上面的业务场景视图，每一个活动都有类似的命名：出示借阅证、查找需要的图书、放入借书栏.....看出什么来了吗？每个活动都是一个动作加上一个动作的受体。受体正是我们要寻找的业务实体，这些名词就是实体的来源。在需求阶段，系统分析员不要去考虑什么抽象，什么模式，别急，那是系统模型做的事情。抽象了，还弄一堆什么Factory模式，Builder模式之类的出来，用户能看懂吗？别忘了我们正在做的是需求文档，是做给用户看的。
观察上面的用例场景，分析出现的名词，我们得到一个个业务实体，再根据场景分析这些业务实体之间的关系。实际上就是大家都熟悉的ER模型，但是与数据库建模的视角还是有所差别的。数据库ER模型要受到数据关系范式的限制，而业务实体ER模型则不必理会这种限制。只要与现实物体符合就OK。好了，罗嗦了一大堆，我们终于得到了我们的成果。
借阅图书过程业务实体视图： 
上图中画那么多虚线连接到业务用例实现是用来表示业务实体与业务用例实现之间的追溯关系的，这些线虽然麻烦，但是笔者强烈建议不要图省事。因为业务实体通过它们可以追溯到原始需求，再次重申，软件过程要可控，需求可追溯是需要时时谨记的。当然，如果嫌麻烦，您也可以用下面的这种形式，是不是简洁得多呢？ 
经过以上的过程，我们得到了什么呢？往下看之前笔者建议您回想一下，总结一下。
第一、我们通用用例实现视图，从业务用例中找出了那些我们将在系统中实现的用例，并且记录了要在系统中实现的用例是如何映射到原始需求的。这提供了需求可追溯的验证。
第二、针对每个用例实现，我们引入了计算机，将实际的业务从人-机交互的角度模拟了执行过程。不仅得到了一个业务怎样在计算机环境下执行的概念模型，同时也给用户描述了他们将怎么和计算机交互以达到他们的目标。笔者提醒大家，用例场景非常非常的重要，后续工作就得靠它们了！！绝对要认真对待，深入调研，不可漏掉一个场景，也不可模糊不清。
第三、通过对场景的分析，给了我们重要的线索去发现业务实体。而我们发现了业务实体之后，又通过用例场景来验证这些实体是否支持了用例的实现。
现在请读者思考一下，如果记不清了，可以翻翻之前的文章。到现在为止，我们的需求是不是一步一步推出来的？从粗到细，从模糊到清晰，从原始需求到计算机的引入，是不是每一步都是可以追溯的呢？每一步的分析结果是不是都有方法来验证正确性和完备性呢？如果您之前迷惑于需求的各个阶段无法关联，也说不清分析结果是否是正确的，那么建议您再从头看看笔者目前已经完成的文章，找出这些线索来，相信您会对UML和RUP的理解提高一个层次的。
这篇文章该结束了。可是等等，到目前为止，虽然我们已经得到了不少产品，或可交付物，或成果，或deliverable...不管叫什么吧，我们已经做了很多工作了。不过作为需求来说，好象还缺点什么吧？对了，我们还缺少业务规则和业务实体的详细属性，这两个需求必不可少的内容，将在下一篇中讨论。敬请期待。
*********************************************************
作者coffeewoo 欢迎您访问文章原始出处 : http://coffeewoo.itpub.net ，阅读中有任何问题可以在BLOG上留言或发邮件到 coffeewoo@263.net，我将尽力为您解答。具有代表性的问题我会以 Q &A的形式收录到对应的文章之后。希望本系列文章对您有帮助。欢迎转载，敬请注明，谢谢 ^_^
re: OO系统分析员之路--用例分析系列（6）--用例实现、用例场景和领域模型 
感谢楼主！！
俺写它的目的就是对大家有些帮助，目的达到了，最高兴的是俺呀。谢谢喜欢，下一篇会尽快出来的
大家的肯定是我继续写下去的动力，老实说写得挺累的，写一篇半天就没了...多宣传宣传就是对我最大的鼓励了，谢谢
你给的链接我看了，基本观点是一样的。不过是我所不喜欢的表述方式，晦涩难懂。
不知道当初是怎么想的了，现在回想，怎么都应当用decision才对……
