关于采用业务用例视图来展示、归纳、整理业务用例的三点指导原则

今日，网友LeoXu给我发了封邮件，提到了业务建模如何组织业务用例的问题。这个问题还是第一次被问到，而且Leo同学显然走了一点小弯路。在回答他的同时，他的这个问题也非常好，把它分享出来。另一方面，Leo同学显然是喜欢思考的，他给我问题的同时也包含了他的许多思考，这点要赞之。为了表示对他热爱思考的鼓励和赞许，特地在最后又留了一个问题，请Leo同学来回答。同时也欢迎各位网友就该问题畅所欲言！

Leo同学的来信：

谭老师,你好.

                       我是<大象> 的读者,看了您的书收获良多.在使用本书知识进行业务建模时, 遇到了让我有些困惑的问题。描述如下：

                       以我目前分析的餐饮管理系统为例，该系统的一项业务是， 处理顾客对餐台的要求，包括转台和并台， 转台就是我们所说的更换餐桌， 并台可以理解为将多个餐桌的服务及费用和并到一个餐桌。 两种情况因为都发生在客户下单之后， 所以系统要及时更改服务信息，如上菜的地点等。 类似特征的业务还有很多。分析时我以“处理顾客要求” 的业务目标作为边界，因此获取了很多业务用例。建模时， 业务用例视图中有很多用例，整个视图显得很零乱。 因此我想到了对用例“分类”，如上述例子，将“处理并台要求” 和“处理转台要求”和并为“处理餐台要求”，用来表示“ 处理客户对餐台提出要求”。目前，我用extend关系来表示“ 处理餐台要求”与“处理并台要求”或“处理转台要求” 之间的关系。但总觉得不妥，因为“extend”表示的是“ 可选”关系，但实际上我想表达的是一旦客户对餐台提出要求， 不是并台要求就是转台要求，是“必选”其中之一。因此“