谭老师，您好
我现在有一个疑问，在银行的自助终端系统进行业务建模时，客户端（即自助终端）连接银行中间业务平台系统。
终端用户可以利用自助终端进行如下操作，如终端用户业务用例图所示
自助终端的业务用例图如下图所示：
问题1) 我把所有终端用户的请求在自助终端用例图里都概括转化为一个“业务请求”，您觉得这么做合适吗？应该怎么做呢？
下面是订购机票的业务场景图，如下图所示
问题2) 在这里有“终端用户”、“自助终端”、“中间业务平台”、“航空公司”等四个泳道，是否有多余？或者有遗漏？
问题3) 你在博客中说泳道都是在定义涉众时所定义的Business Actor，我看您的例子里面，泳道都是人！我这里除了“终端用户”是人外，
其它都是系统，这样做合适否？是不是有点系统建模的意味了？
谭老师，在这里建模的时候，每遇到新的场景或新的问题，就感觉有些不知所措了，希望谭老师在百忙之中抽出时间为我指点一下。多谢！！
祝你元旦快乐，新年新气象！！
我的回复:
问题一：
这样做是可以的，相当于你从大量业务用例当中抽象出了一个大家都会使用到的业务请求用例。不过，这样做要基于以下的几点考虑：
1. 这个业务请求用例对于其它的业务用例来说，用例场景是一致的，也就是说它对其它业务用例来说是公用的；
2. 这个业务请求用例不依赖于某个业务用例的场景。换言之，它可以独立出来，它的启动、停止和执行过程不依赖于其它的业务用例；
3. 其它业务用例与它的关系是扩展或包含的关系，即其它用例扩展或包含它，而不是它来扩展或包含其它业务用例；
如果符合以上三点，那么把它抽象出来是合理的。不过，即使是合理的，我仍然建议不要在业务建模阶段做这样的抽象。原因是诸如充值、缴费这些业务用例对应于实际的业务，非常好理解，并且能够很清楚的向业务人员和技术人员解释。如果抽象出一个所谓业务请求用例，它就没有与现实业务有对应关系，并且你不能够把它的业务目标说清楚。业务请求？请求什么？返回什么？谁来请求？如何请求？，这些问题你必须把所有的其它相关业务用例都融合进来才能讲清楚。对吧，因为这是一个抽象用例，必须结合实际才能解释明白，在业务层面上太多抽象是不太合适的。你可以在概念建模阶段来抽象它，也可以在系统建模时来抽象它。概念建模阶段这个抽象用例可以给你提供公用的场景来分析公用的分析对象；系统建模阶段则可以给你提供公共的接口分析设计来源。
问题二：
以我的业务理解，这里不缺什么内容了。判断是否有多余或者遗漏不是从技术层面来的，而是业务层面，应该由业务专家来评判。
问题三：
business actor可以是人，也可以是物。我的例子里全是人是因为我的例子是一个单一的人机交互系统，业务是人与人借助系统交互完成的。你这个系统是由系统和系统交互来完成的，所以泳道是系统完全没有问题。你这里虽然有系统存在，但绝对不是系统建模，所谓系统建模，是要描述系统行为，而不是业务行为，对应的，泳道应当是具体的对象，并且消息应当是方法级别的。