简单点说，在以业务目标为边界的业务模型中，业务场景图描绘的是贡献于这个业务目标的什么人及其做的什么事，这些人和事的交互过程和完成顺序就是完成整个业务目标的流程。而这些人往往是业务主角、而他们所做的事便是业务用例了。所以我认为，绘制业务用例图和业务场景图并没有谁先谁后的问题，这两个图是互相验证的。可以先绘制业务场景图，然后把其中的泳道和活动拿出来，得到的就是活生生的业务用例。但根据业务场景图得到的业务用例不一定是完整的，因为可能存在独立的、未参与交互、但仍贡献于整个业务目标的业务用例存在。所以，需要业务用例图与业务场景图进行互相验证。这样才能得到完整并且正确的业务用例。
到了绘制业务用例场景图的时候，边界必须要缩小了，缩小到每一个业务用例的大小，透过这个边界观看业务用例的内部，看到的是完成这个业务用例所需的步骤，也就是一个人是如何去做一件事的。把边界重新拉大看，这个人做的这件事是完成某个业务目标的一个步骤。正是这些不同的人做的不同的事才构成了整个宏大的业务目标。举个例子，一个人要周游世界（业务目标），那么他需要周游亚洲（业务用例）、周游欧洲（业务用例）、周游拉丁美洲（业务用例）……
他需要把这些地方都周游过了才能完成周游世界这个伟大的业务目标，于是他可以列出各洲的周游计划表（业务场景图），比如先亚洲、再欧洲、再拉丁美洲……
周游计划表搞定了，那么仅仅凭这一张空泛的蓝图还是不行的，还需针对每一个步骤设计更详细的各国周游计划表（业务用例场景图）。比如对周游亚洲来说，他要先游中国、再游日本、越南、印度……
可以看到，一开始的边界是全世界，以这个边界绘制了各洲周游计划表（业务场景图）后，然后再将边界缩小到周游每一个洲上（业务用例），他开始绘制各国周游计划表（业务用例场景图），如果他还觉得不够详尽，还可以以一个国家为边界，绘制游览各风景区的计划表，得到粒度更小的用例。这样边界和抽象层次可以根据需要不断缩小降低，直至得到满意的结果。
故，从业务建模到系统建模这一整个过程就是一个边界不断缩小、抽象层次不断降低、用例粒度不断变小的过程。以业务目标为边界时，得到的是业务场景图，其中的每一个活动往往都是业务用例；缩小边界到业务用例，得到业务用例场景图，而粒度更小的系统用例就是从该图的活动里筛选出来的；然后可以再缩小边界到每一个系统用例，可以绘制出系统用例场景图，这个时候对用例的建模工作就已经差不多了。而在这个过程当中，不同大小的边界、不同高低的抽象层次是不可交叉的，因为交叉会导致混乱、会将原来自顶向下井井有条的分析过程彻底打乱。可以想象，对于上面的例子来说，当设计各国的周游计划时，不可能出现这种情况：日本--->泰国--->长城--->印度--->欧洲
再举个例子，当描述一个人的外表时，应当以人的身体外部为边界，从而得到如此词汇：身材高挑、发型整齐、鼻梁挺拔……如果混淆了边界，在这些词汇后突然冒出来一句血压偏低，只会令人莫名奇妙。同样，体检单上也不会出现如下描述：血压正常、心率正常、发型凌乱……
所以在建模过程中最重要的就是把握边界。但建模过程中的边界有时并不像现实中那样显而易见，一不小心就会逾越边界，我就经常犯错，在以业务目标为视角的用例图中拉进了一大堆不同抽象层次的用例，不同边界的用例交杂在一起，混乱无比，时常把自己搞得也是头昏脑胀。所以这个时候就要多思考、多与同伴讨论、多向香蕉白猫请教。^_^
-------------------------------另附 讨论过程：------------------------------------------
Arthur：
老师您好，我以前看您博文的时候介绍到了业务场景图，但在您的《大象》一书中却没对书中的实例绘制业务场景图，只绘制了业务用例场景图。为什么您将业务场景图省却了呢？在博文中您有这样一段话介绍了业务场景图： 第三步，利用业务场景图帮助分析业务流程，在ROSE中，这个阶段最好使用活动图Activity diagram。在这个阶段，业务场景图非常重要，在绘制过程中，系统分析员必须采用第一步中定义的用户名字作为泳道名，使用第二步中定义的业务用例名作为活动名来绘制。必须这么做的原因是，如果你无法把利用已经定义出来的 business actor 和 business use case完备的描绘业务流程，那么一定是前面的定义出问题了，你需要回头审视是否 business actor 和 business use case定义不完善或错误。如果不是所有的business actor 和 business use case 都被用到，要么应该检查业务流程调研时漏了什么，要么应该检查是否定义了一些无用的business actor 和 business use case 。同时，绘制业务场景图也非常有助于选择合适的用例粒度并保持所有的用例都是同一粒度。 从这段话中我可以感受到业务场景的重要性，但您并未在书上有一个详尽的说法，所以我想了解一下业务场景图的意义与作用，以及和业务用例场景图的区别。因为用例场景图里的泳道也是用业务主角和业务工人定义的，业务场景做的似乎用例场景都做了，所以我有点难以区分两者的区别。 请疯狂的跳跳糖指点！ coffeewoo: 书中是因为例子太大，我只能挑其中的一部分用例来讲后续的部分章节。而如果要画出业务场景图，我需要加入更多的用例，这部分内容对书来说太多了。 业务用例场景图是描述的业务用例内部的场景，而业务场景图描绘的是业务用例之间的场景。例如生产管理当中，制定生产计划，执行生产计划，统计计划执行结果是三个可能的业务用例。业务用例场景图是针对每一个业务用例描述的，比方制定计划的过程。而业务场景图是描述业务用例之间场景的，活动图画出来的结果是先制定生产计划，然后执行生产计划，最后统计计划执行结果。 Arthur： 嗯，谢谢老师的指点，有些明白了。那么我是不是可以这样理解，整个建模过程就是一个边界从大到小的过程，业务场景图以一个业务目标为边界，其中的活动是由内部的业务用例所组成，而将边界缩小到每一个业务用例时，得出的是业务用例场景图，其中的活动可能是系统用例。这时边界更小了，同时用例粒度也更小，就可以得出系统用例场景图。 还有问一下老师，RUP的官方文档在哪里可以看或者下载，我一直找不到。谢谢老师了。^_^ coffeewoo: 恭喜！理解非常正确。这就是所谓的分析自顶向下过程，边界逐步缩小，视角逐步改变，粒度逐渐变小，分析目标也跟随变化，从现实世界到对象世界就是这样一步步来的。反过来，当对象设计出来以后，又要循着这条路倒着走回去，以验证你设计出的对象是否真能一路倒着实现到现实世界。这就是所谓自底向上的验证和反馈过程。所谓的系统分析设计，其实就是这样一个循环，每个迭代周期有至少一个这样的循环。
有兴趣的话，你可以针对这个问题，就自己的理解写一篇小文章，把你的心得给网友分享一下。发表在你自己的博客上我来连接，或者也可以发给我，我转载到我的博客上，可以给更多的人看到。相信有这样疑惑的不止你一个，呵呵。