UML设计初步 - 基本概念一(actor, use case)

UML全程统一建模语言，是专门为面向对象建模的设计语言。

在我们讨论UML之前，我们先来看看面向对象和面向过程的区别。

假设我们要为一个公司制作一个业务系统，这个系统会有许多部门各个岗位的人参与，
那么，面向过程和面向对象分别是怎么设计的呢？

我们先来看看面向过程的调研思路：
首先弄清楚有多少业务流程，然后画出业务流程图，
然后顺藤摸瓜，找出没一个步骤参与的部门和岗位，
弄清楚参与者所做的事情和填写表单的情况，然后怎么
把表单传到下一个环节。

面向对象：
弄清楚有多少部门，多少岗位；
找到每一个岗位的业务代表，问类似问题：
你平时都做些什么？这件事是谁交办的？
做完了需要通知或传达谁吗？
做这件事情需要填写什么表格吗？

下面我们就来看一下UML的一些基本概念：
1）参与者(actor) 
    
  参与者是整个建模的中心，再好的设计不符合客户需求也等于零。
  参与者代表了现实世界中的“人”。

2）用例(use case)
 
  用例表示驱动的业务目标，也就是参与者想要做什么并且获得什么。
  用例代表了现实世界中的“事”。

3）业务工人(business worker)
  这里我们经常会与参与者搞混。
  事实上，业务工人是系统中的被动参与者。

如果要区分actor与business worker，我们通常可以问2个问题就能区分了：
1）系统是为谁服务的？
2）这个人会主动发出动作吗？

我们下面来看一个用例场景，如下：
小王带着钱去银行开户，向大厅经理询问了办理手续，填写好表单后，
交给柜台职员，柜台职员帮小王办理手续，小王拿到存折。

在上面这个场景中，谁是参与者，谁是业务工人呢？
很明显：
参与者：   小王
业务工人：大厅经理，柜台职员

理由：系统是为小王服务的，小王主动发出动作，大厅经理和柜台职员是被动的，他们不会
        主动发出请求。

有人常常会有这样的错误概念：认为参与者必须是人。
事实上，这种想法是错误的，参与者有时候也可以是物。

我们来看这样一个场景；
每天自动统计网页访问量，生成自动报表，将报表发送至相关人员信箱。

很明显，这个场景中没有人。
那么参与者是谁呢？
我们说，是“计时器”。
因为它在每天的固定时间启动这个需求。

关于用例，我们经常会有误导，那就是
把它和具体业务操作混淆起来。
我们可以用这样一句话来加以区分：

用例是有意义的，它代表了参与者的愿望，
不能完整达到参与者愿望的不能称为用例。

我们还是看上面这个小王去银行开户的场景。
在这个场景中，我们可以提炼出来的动作有：
银行开户，询问手续，填写表单，办理手续，拿到存折

在以上动作中，只有银行开户才是真正的用例，其它都是该用例的具体操作。
就拿填写表单来说，填写表单是小王的愿望吗？显示不是，小王去银行又不是为了
填写表单，他是为了开户，但是银行规定这么做，如果能够不填写表单就直接办理
开户，小王当然高兴了。

所以，我们说：
用例必须代表参与者完整的愿望。

以上场景的用例图如下：