OO系统分析员之路--用例分析系列（4）--业务建模一般步骤和方法

阅读更多

转自：http://blog.csdn.net/coffeewoo/archive/2008/12/16/3526067.aspx

本篇开始之前先扯点闲话，商业应用系统开发经历了三个阶段：

第一个阶段以计算为中心，分析设计围绕程序的运行效率，算法优劣，存贮优化来进行。90年代的大学课程讲的都是这些。

第二阶段以数据为中心，分析设计围绕数据流进行，以数据流程来模拟业务流程。这也就是所谓的面向过程的分析模式。

第三阶段以人为中心，分析设计围绕人的业务需求，使用要求，感受要求进行。这也就是现在的面象对象分析模式。 
使 用OO方法建立商业模型必须先定义涉众。商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限 制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。 无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么 人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。这时候可以说，系统分析员已经完全 了解了用户需求，可以进入系统建模阶段了。

书归正传，上篇笔者归纳了一些典型的涉众类型及他们的普遍期望。接下来，就是要将他们这些期望定义出来。这个过程，就是业务用例获取的过程。笔者可以跟大家分享的经验是通过以下步骤进行，这些步骤并非唯一正确，对于经验不多的系统分析员来说，这些步骤很有指导意义。

笔者做了一个建模实例，有需要有读者请到笔者的BLOG资源中心下载 ，实例以上一篇所述网上图书馆需求为蓝本建立了业务用例模型，之后的概念模型、系统模型则抽取了其中的借阅过程作为例子。不记得了可以后头找找。

建模第一步 ，从涉众中找出用户 。并定义这些用户之间的关系。在ROSE中，应该使用business actor 类型。参考上一篇的需求描述，下载实例

第二步 ， 找出每个用户要做的事，即业务用例 ，在ROSE中应使用Business use case类型。请参考《用例的类型与粒度》一文以帮助确定用例的粒度。笔者强烈建议为每一个business actor绘制一个业务用例图 ，这能很好的体现以人为中心的分析模式，并且不容易漏掉business actor需要做的事。至于以参与者为中心的视图容易漏掉某个业务用例的参与者的担心，可以在第四步中得到消除。下载实例

第三步 ， 利用业务场景图帮助分析业务流程 ，在ROSE中，这个阶段最好使用活动图Activity diagram 。在这个阶段，业务场景图非常重要，在绘制过程中，系统分析员必须采用第一步中定义的用户名字作为泳道名，使用第二步中定义的业务用例名作 为活动名来绘制 。必须这么做的原因是，如果你无法把利用已经定义出来的 business actor 和 business use case完备的描绘业务流程，那么一定是前面的定义出问题了，你需要回头审视是否 business actor 和 business use case定义不完善或错误。如果不是所有的business actor 和 business use case 都被用到，要么应该检查业务流程调研时漏了什么，要么应该检查是否定义了一些无用的business actor 和 business use case 。同时，绘制业务场景图也非常有助于选择合适的用例粒度并保持所有的用例都是同一粒度。下载实例

第四步 ， 绘制用例场景图。 与业务场景图不同的是，用例场景图只针对一个用例绘制该用例的执行过程 。笔者仍然强烈推荐使用activity diagram 。在用例场景图的绘制中，必须使用第一步中定义的业务用户作为泳道。 必须这么做的原因是，它能帮助你发现在定义业务用例图时的错误，比如是 否漏掉了某个业务用例的潜在使用者。不是每个业务用例都需要绘制场景图 ，只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍然需要在业务用例规约 文档中写明。下载实例

第五步 ，从第三步或第四步中绘制的活动图中找到每一步活动将使用到的或产生的结果 。这是找到物的过程。找到后，应当建立这些物之间的关系。在ROSE中，这称为业务实体模型 。应该使用business entity 类 型。下载实例

第六步 ，在上述过程中，随时 补充词汇表Glossary 。将此过程中的所有业务词汇，专业词汇等一切在建模过程中使用到的需要解释的名词。这份文档将成为模型建立人与读者就模型达成一致理解的重要保证。

第七步 ， 根据上一篇中提到的业主，老板等涉众的期望审视建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内 。那些不打算纳入建设范围内的业务用例有两 种情况，一种是该业务用例是被调用一方，那么应该把它改为 boundary 类型，意味着将来它是一个外部接口。另一种是该业务用例主动调用系统内业务用例，那么应该将它改为business actor类型。与普通business actor不同的是，由业务用例转换而成的business actor不是人，而通常是一个外部系统进程，因此应该在被调用的系统内业务用例与它之间增加一个boundary元素，意味着我们的系统将为这样一个外 部进程提供一个接口。严格来说，那些需要纳入建设范围的business use case 应当对应的生成一个 business use case realization， 以后的设计工作将归纳到这些实现用例中。但笔者觉得这一步并非很关键的，实际中本人也经常省略这一步，而将协作图，象活动图，类交互图等直接在 business usecase下说明。不过本实例中笔者还是按照正规方法来建模的。下载实例

需要说明的是，上述的步骤并非一次性完成的 ，在每一个步骤中都可能导致对以前步骤的调整。即使建模已经完成，当遇到变化或发现新问题时，上述步骤应当从头到尾再执行一次。这也是RUP倡导的迭代开发模式 。

经 过以上的步骤，我们已经建立了一个完整的业务模型。但这决不是建模工作的全部，以上过程只说明了建立一个完整业务模型的过程，不能说这样就建立了一个很好 的业务模型。因为上述的过程中并没有提及业务分析过程。分析过程全凭系统分析员的经验，对OO的理解和对行业业务的把握能力，对原始业务模型进行归纳，整 理，抽象，重构，以建立一个更高效，合理，扩展性更强的模型。这个过程无法以步骤说明。或许以后笔者会专门针对模型分析写点东西。另外除了模型，还至少需 要写业务架构文档、用例规约和补充用例规约 三种文档。因为模型虽然可以较好的体现业务架构，但很不好表达业务规则和非业务需求，这些需要在文档中说明。例 如用例的前置条件和后置条件就是一种业务规则。读者可以在RUP文档中找到这些文档的模板。

预告：下一篇笔者将讲述如何根据业务模型建立系统概念模型。这里先说一点，系统概念模型建立最主要依据的是第三步、第四步、第五步建立的业务/用例场景和业务实体模型。这也突显了场景和实体模型的重要程度。