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

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

Leo同学的来信：

谭老师,你好.

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

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

我本人使用UML建模时间不长，因此对一些概念的理解不深，<wbr>希望您能给予指点。</wbr>

我的回复:

Leo你好：

这是个挺好的例子。先提个小意见，“处理并台要求”和“处理转台要求”业务用例的命名不太合适。这些业务用例是为顾客服务的，顾客是业务主角。所以如果加上业务主角，连起来念成“顾客处理转台要求”就不通了，“餐馆处理转台要求”才说得通。但显然餐馆并不是业务主角，只是业务工人而已。所以，业务用例命名为“要求转台”和“要求并台”比较合适。

书归正转，我们说业务用例必须要是明确的、完整的、独立的表达业务主角的业务目标，例如“要求并台”和“要求转台”就是完整的、明确的目标，但你后来合并出来的“处理餐台要求”就不是明确的（什么要求？）和独立的（包含很多目标），它不符合业务用例的规则，所以导致你后面的困惑。

你遇到的问题是用例视图比较零乱，其实这个并不是用例识别的问题，而是信息组织的问题。当你把多个边界的用例都放在一起，这些用例的信息之间没有相关性，就会显得零乱。所以第一，只把同一个边界内的业务用例放在一个视图里，或者，把每个边界定义成一个包，相关的用例和用例视图都放在一起；

如果同一个边界内也有很多业务用例，并且之间也出现信息相关度不高的情况呢？这种情况一般只会发生在同一个边界有多个业务主角的情况，多个业务主角各有各有抽象角度，即业务目标，这些抽象角度或业务目标彼此有可能是完全无关的，因此也会导致信息零乱。所以第二，在第一条的基础上，为每个业务主角建立一个业务用例视图，只把该业务主角的业务用例显示在该视图里；

如果同一个业务主角有许多的业务目标，这些业务目标明显的分属于不同的业务领域或可以明显的分类，那么第三，在第一条的基础上，为信息做分类，为每个分类建立一个用例视图，把与该分类相关的业务用例显示在上面。

根据上面的指导原则，你的问题就可以归结为：1. 以“处理顾客请求”为边界，所有与顾客请求有关的业务用例都放在这个边界包里；2.如果有的请求是顾客提出的，有的是由服务人员代顾客提出的，或者顾客也分好几类，那么可以为每类业务主角建立一个用例视图，如“顾客请求视图”，“服务人员代提请求视图”；3.如果顾客请求分为很多类，比如并台类的、转台类的，那么你可以为每个信息类别再建立用例视图，例如“转台类请求用例视图”和“并台类请求用例视图”。

请思考，用例视图是用例的展示工具，每个视图都表达了对同样一组业务用例的不同角度的表达。所以只要需要，你就可以建立相应的视图去展示用例。同一个用例完全有可能出现在多个视图上。例如“要求转台”业务用例就既会出现在“转台类请求视图”里，又会出现在“顾客请求视图”里。 相信这样做以后就能解决你的问题了。

留给Leo及各位网友的问题：

接下来再深入一点讨论。 正如Leo所说，不管是并台还是转台，甚至其它更多用例都会涉及更新上菜地点等信息。那我们怎么表达这一信息呢？可不可以建立一个命名为“更新上菜地点类业务视图”的用例视图，然后把所有会涉及到更新上菜地点的用例都展示在该视图里呢？ 为什么？