网友 laibagefei 的邮件：
我是您的一个读者，《大象》一书和您的blog我都在看，现在有一个必须要请教你一下，因为我看了这么多UML建模的资料，只有您
讲得比较全面，而且自成体系哈。
1. 我在做业务建模的时候，在第三步“绘制业务场景图”时，说是要使用Business Actor中的actor和Business Use case中的case
组成活动图，但是我看您的Business Actor中的actor都是人，而没有计算机系统的概念，而我的系统在业务建模阶段如果没有计算机系统的
参与则不能形成完整的活动图，我是不是写错了？应该在业务建模阶段完全使用人作为涉众？
2. 我的系统是一个C/S架构的手机银行系统，中间几乎不需要“人”进行干预，该如何做业务建模？该怎样定义涉众？
3. Business Use Case和BBusiness use case realization的区别是什么？各自负责的域是什么？还有它们内部的活动图有什么区别？
无论如何，非常感谢！！
我的回复：
第1，2个问题：
我书中的例子大是针对行业服务软件的，因此在业务建模时主要是以人为主。的确在另一些领域，比如工控，嵌入式等软件是与机器打交道的，人并不参与。所以并不是说业务建模就一定要人的。业务建模建立的模型是一种计算无关模型。所谓计算无关，是指建立的是一种业务模式，对工控来说，可能就是一种控制模式，对嵌入式来说，可能就是一种信息交换模式。我对工控和嵌入式了解不多，说错了请谅解，只是想表达这个意思。业务建模的目的是描述一种特定的业务或模式，它与特定的平台和设备无关，而只是概念上的设备。比方说交换机，芯片，单片机，传感器等，我们并不指定具体的产品，甚至有可能市面上现在还没有这种设备。
这样说来，对工控和嵌入式来说，所谓的"人"，其实就是一些概念上的设备、机器、其他软件等等。它们同样对你将来开发的软件有各式各样的期待，与人没什么差别。
而到了概念建模，进行系统分析时，就会进入所谓平台无关建模阶段。针对业务建模同样的信息，我们会引入特定的计算环境，将设备定位成某一类设备。但这时具体的设备还不确定。
最后在系统建模，进入设计时，就会进入所谓平台相关建模阶段，这时我们在概念建模的结果中引入我把打算支持的芯片型号，单片机型号，设备型号等等，这样才能够支持编码实现。
第3个问题：
一般来说，Business Use Case 的场景是用活动图画的，目的是描述参与完成business use case的各方所执行的活动，也就是各方的职责。从这个场景中我们能获得角色，业务实体等。同样的这个业务用例，可能会有多种可能的实现途径，每一种实现途径就是一个realization， 通常，我们可以用已经获得的角色，业务实体等绘制时序图或交互图来表示如何实现这个业务用例。
网友 laibagefei 的用例场景设计
谭老师，您好：
非常感谢啊，看了您的回复，
这是通过手机订票的一个业务用例实现，如果您有时间，
我的回复：
活动图绘制没有什么问题，就业务方面我有点疑问。这里用计算机作为泳道给人一种手机直接和计算机交互的感觉，似乎计算机在这里不是很明确，因为手机毕竟不是坐在计算机前直接操作的，所以感觉有点怪。
我不太懂手机业务，不过感觉与手机直接交互的应该是某种电信网关，或者是某种平台。比方，如果是通过短信的，那么似乎应该是某个SMS平台而不是一台计算机；而支付行为，一般也不会和机票预定是同一个系统，似乎应当是某种支付网关，或支付平台，一般支付会是一个第三方平台，而不会是订票系统。
另外，手机终端和用户这里也比较迷惑。这里的用户是指手机的用户，还是指操作订票系统的用户？如果你的意思是订票人可以通过手机，也可以通过直接操作订票系统界面来订票，那么这应当是两个用例场景。在这里正好就这个例子多说两句，这正是一个业务用例有多个用例场景的例子，通过手机和直接操作订票系统对订票人来说显然是同一个业务目标，但也显然有着不同的操作内容和步骤，换言之，这个业务用例有着不同的实现途径，在建模时，你可以通过建立多个business use case realization 来表示多个实现途径。
如果这里的用户指的就是手机用户，那就是一个业务场景。但你应当把手机用户作为一个单独的泳道，由他向手机发出指令，手机再与订票系统进行交互。这样，在这个场景里，不但包含了手机与订票系统之间的交互行为，也包含了手机用户与手机的交互行为。也就是说，将来实现这个业务场景时，不但要实现手机与订票系统的接口，也要在手机上提供供手机用户操作手机的界面。似乎这样更加合理。
我对手机业务不是很懂，根据个人经验提点意见，供参考。