简单点说，在以业务目标为边界的业务模型中，业务场景图描绘的是贡献于这个业务目标的什么人及其做的什么事，这些人和事的交互过程和完成顺序就是完成整个业务目标的流程。而这些人往往是业务主角、而他们所做的事便是业务用例了。所以我认为，绘制业务用例图和业务场景图并没有谁先谁后的问题，这两个图是互相验证的。可以先绘制业务场景图，然后把其中的泳道和活动拿出来，得到的就是活生生的业务用例。但根据业务场景图得到的业务用例不一定是完整的，因为可能存在独立的、未参与交互、但仍贡献于整个业务目标的业务用例存在。所以，需要业务用例图与业务场景图进行互相验证。这样才能得到完整并且正确的业务用例。
到了绘制业务用例场景图的时候，边界必须要缩小了，缩小到每一个业务用例的大小，透过这个边界观看业务用例的内部，看到的是完成这个业务用例所需的步骤，也就是一个人是如何去做一件事的。把边界重新拉大看，这个人做的这件事是完成某个业务目标的一个步骤。正是这些不同的人做的不同的事才构成了整个宏大的业务目标。
举个例子，一个人要周游世界（业务目标），那么他需要周游亚洲（业务用例），周游欧洲（业务用例），周游拉丁美洲（业务用例）……
他需要把这些地方都周游过了才能完成周游世界这个伟大的业务目标，于是他可以列出各洲的周游计划表（业务场景图），比如先亚洲、再欧洲、再拉丁美洲……
周游计划表搞定了，那么仅仅凭这一张空泛的蓝图还是不行的，还需针对每一个步骤设计更详细的各国周游计划表（业务用例场景图）。比如对周游亚洲来说，他要先游中国、再游日本、越南、印度……
可以看到，一开始的边界是全世界，以这个边界绘制了各洲周游计划表（业务场景图）后，然后再将边界缩小到周游每一个洲上（业务用例），他开始绘制各国周游计划表（业务用例场景图），如果他还觉得不够详尽，还可以以一个国家为边界，绘制游览各风景区的计划表，得到粒度更小的用例。这样边界和抽象层次可以根据需要不断缩小降低，直至得到满意的结果。
故，从业务建模到系统建模这一整个过程就是一个边界不断缩小、抽象层次不断降低、用例粒度不断变小的过程。
以业务目标为边界时，得到的是业务场景图，其中的每一个活动往往都是业务用例；
缩小边界到业务用例，得到业务用例场景图，而粒度更小的系统用例就是从该图的活动里筛选出来的；
然后可以再缩小边界到每一个系统用例，可以绘制出系统用例场景图，这个时候对用例的建模工作就已经差不多了。而在这个过程当中，不同大小的边界、不同高低的抽象层次是不可交叉的，因为交叉会导致混乱、会将原来自顶向下井井有条的分析过程彻底打乱。可以想象，对于上面的例子来说，当设计各国的周游计划时，不可能出现这种情况：日本—>泰国—>长城—>印度—>欧洲
再举个例子，当描述一个人的外表时，应当以人的身体外部为边界，从而得到如此词汇：身材高挑、发型整齐、鼻梁挺拔……如果混淆了边界，在这些词汇后突然冒出来一句血压偏低，只会令人莫名奇妙。同样，体检单上也不会出现如下描述：血压正常、心率正常、发型凌乱……
所以在建模过程中最重要的就是把握边界。但建模过程中的边界有时并不像现实中那样显而易见，一不小心就会逾越边界，我就经常犯错，在以业务目标为视角的用例图中拉进了一大堆不同抽象层次的用例，不同边界的用例交杂在一起，混乱无比，时常把自己搞得也是头昏脑胀。所以这个时候就要多思考、多与同伴讨论、多向zzdsp请教。