第一个阶段以计算为中心，分析设计围绕程序的运行效率，算法优劣，存贮优化来进行。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文档中找到这些文档的模板。
预告：下一篇笔者将讲述如何根据业务模型建立系统概念模型。这里先说一点，系统概念模型建立最主要依据的是第三步、第四步、第五步建立的业务/用例场景和业务实体模型。这也突显了场景和实体模型的重要程度。
*********************************************************
作者coffeewoo 欢迎您访问文章原始出处 : http://coffeewoo.itpub.net ，阅读中有任何问题可以在BLOG上留言或发邮件到 coffeewoo@263.net，我将尽力为您解答。具有代表性的问题我会以 Q &A的形式收录到对应的文章之后。希望本系列文章对您有帮助。欢迎转载，敬请注明，谢谢 ^_^
谢谢coffeewoo [回复]谢谢coffeewoo作者！我怕网络有时不通，我都把上述文章下载到本机了。若coffeewoo作者能多结合一些自己在实际工作中碰到的实例来说明那就更理想了。希望能继续写下去。
实例用法 [回复]供下载的实例是用Rose生成的html文件，先解压，打开example.html就可以了。解压后有个"使用说明.txt"文件，里面写了用法。
要求你的机器上安装有java虚拟机，到网上搜索，挺多的。如果你用的是MYIE等浏览器，请改用标准IE浏览器看。如果还是打不开，请检查浏览器设置里是否禁止了小java程序。
re: OO系统分析员之路--用例分析系列（4）--业务建模一般步骤和方法 [回复]你的文章我读过几遍了,有几个问题请教一下:
你所讲的建模步骤说得很好,但在建模步骤上如何体现出RUP(UP) 的迭代啊?(当然你说过,发生迭代的话上述步骤应当从头到尾再执行一次)
那么请问一下这些迭代在需求规格说明书中如何体现出来?(或者是需求规格说明书中只记载最终的迭代分析结果)
或者是迭代过程有其它的文档来进行详细说明吗?
re: OO系统分析员之路--用例分析系列（4）--业务建模一般步骤和方法 [回复]路过，看过，收益过！！ 不顶不行！！！
不仅仅对楼主的知识佩服，更对楼主的精神和人品赞扬。
楼主给我们做了榜样，向楼主学习！！
附带：现在很多人都恃才自傲，不可否认他们的知识令人折服，但他们的人品却大打折扣。
re: OO系统分析员之路--用例分析系列（4）--业务建模一般步骤和方法 [回复]附件中的文件不能打开提示加载java程序失败，我已经装了java虚拟机
re: OO系统分析员之路--用例分析系列（4）--业务建模一般步骤和方法 [回复]请教一下，业务分析人员进行业务分析的过程，是否遍布于业务建模的4-7步骤的每个步骤，还是在建立好完整的业务模型之后，对业务模型图统一的应用OO思维，进行归纳和总结等等业务分析方法呢？
re: OO系统分析员之路--用例分析系列（4）--业务建模一般步骤和方法 [回复]请教一下,在还书过程业务实体视图中，还书申请单，借阅订单是什么关系，而且在业务实现场景中并没有体现出来。
re: OO系统分析员之路--用例分析系列（4）--业务建模一般步骤和方法 [回复]请教一下,在还书过程业务实体视图中，还书申请单，借阅订单是什么关系，而且在业务实现场景中并没有体现出来。
re: OO系统分析员之路--用例分析系列（4）--业务建模一般步骤和方法 [回复]博主写的此文的第二步、第三步、第四步描述的似乎有些自相矛盾，在第三步中，您说利用业务场景图帮助分析业务流程，最好使用Activity diagram来描述，使用第二步中定义的业务用例名作为活动名来绘制，与第四步所描述的矛盾。第四步中说用例场景图只针对一个业务用例绘制该用例的执行过程，而且必须使用第一步中定义的业务用户作为泳道名，以第二步中定义的业务用例名作为活动名来绘制。此处令人不解，既然是针对一个业务用例进行用例场景图的绘制，为什么会牵扯到其它的业务用例上，一个业务用例应该是一个独立的业务目标，跟其它的业务用例没有太多的联系，而且仔细观察了您的图书馆的建模实例，发现borrow process用例场景图中的活动也并未采用Business Use Case 中的业务用例，此处十分不解，敬请博主帮忙解答，多谢多谢!