我们先来看看一个小例子，没有引入边界的概念对获取用例有什么影响，比如我去食堂就餐，要先领取餐具，然后点菜，打菜的阿姨帮忙盛菜，接着我刷卡付款，去盛饭和汤，之后是找座位，最后才开始就餐。那么领取餐具，点菜，刷卡付款之类的算是一个用例吗 ？说算也算，说不算也不算。因为这要根据边界来确定的，我们都知道用例是以主角发起的以完成主角的完整目标为标准的。这里的主角就是我本人，要确定我的目标就必须先确定边界，比如以整个食堂为边界，那么我去食堂的目的就是就餐，就餐才是我的完整目标，而其他诸如领取餐具，点菜，刷卡付款之类的都不是我去食堂的目的，这些只是我完成就餐的步骤而已，但如果把边界粒度降低到食堂的内部，那么这个时候领取餐具，刷卡付款之类的也是一个用例了，虽然都是用例，但是和就餐这个用例的粒度是不同的，因为他们边界所在的抽象层次不同。所以要描述用例就必须先划分出边界来，主角站在边界外对这个边界提出目标，一个目标就是一个用例，否则在描述系统的时候就会出现如我去食堂的目的是刷卡付款这样的笑话来，当然了，除非我去食堂的目的真的只是为了付款。

回到本文的案例中来，开始进行获取业务用例的分析，刚才说了，要获取用例必须先确定好边界，那么怎么确定边界呢 ？ 这个时候我们前面划分业务目标的作用就体现出来了，我们可以以每个业务目标为一个边界，因为所有业务目标汇集起来就表示达到了系统建设目标，而针对每个业务目标定义的边界，明确了哪些涉众与这一业务目标有关，他们作为业务主角站在这一边界外提出他们的期望，这些期望作为用例都是为实现这一业务目标服务的，获取业务用例的方向就明确了（不符合这一业务目标的期望则不被采纳）。

如上图，边界和业务主角都已经有了，接着就是找出用例了，我以员工账务服务边界为例，根据涉众分析报告和客户访谈（这个在实际项目中需要好好历练的，我觉得要有技巧引导客户，还要有较强的总结概括能力吧）得出的。假定我从与客户访谈的结果中得出员工对这个系统的期望和目标有通过计算机申请报销业务，申请借款业务，这两个期望都是与员工账务服务这个特定的业务目标有关的，所以可以作为业务用例被纳入到员工账务服务边界之中。如果假设员工也可以参与管理账务信息，那么得出的员工对系统的期望就不止这两个，但是分析的时候要注意与员工账务服务这一业务目标相关的期望只有申请报销业务和申请借款业务两个，其他的期望是与管理账务信息这个业务目标有关，应当被划分到管理账务信息边界中去。

出处：CSDN
责任编辑：bluehearts

上一页 面向对象分析过程案例实战 [1] 下一页 面向对象分析过程案例实战 [3]

◎进入论坛网络编程版块参加讨论