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

灰太狼 2021-12-24 12:41 179阅读 0赞

UML全程统一建模语言，是专门为面向对象建模的设计语言。  
  
在我们讨论UML之前，我们先来看看面向对象和面向过程的区别。  
  
假设我们要为一个公司制作一个业务系统，这个系统会有许多部门各个岗位的人参与，  
那么，面向过程和面向对象分别是怎么设计的呢？  
  
我们先来看看面向过程的调研思路：  
首先弄清楚有多少业务流程，然后画出业务流程图，  
然后顺藤摸瓜，找出没一个步骤参与的部门和岗位，  
弄清楚参与者所做的事情和填写表单的情况，然后怎么  
把表单传到下一个环节。  
  
**面向对象：**  
弄清楚有多少部门，多少岗位；  
找到每一个岗位的业务代表，问类似问题：  
你平时都做些什么？这件事是谁交办的？  
做完了需要通知或传达谁吗？  
做这件事情需要填写什么表格吗？  
  
下面我们就来看一下UML的一些基本概念：  
**1）参与者(actor)**  
![actor.png][]  
参与者是整个建模的中心，再好的设计不符合客户需求也等于零。  
**参与者代表了现实世界中的“人”。**  
  
**2）用例(use case)**  
 ![use_case.png][]  
用例表示驱动的业务目标，也就是参与者想要做什么并且获得什么。  
**用例代表了现实世界中的“事”。**  
  
**3）业务工人(business worker)**  
 这里我们经常会与参与者搞混。  
事实上，业务工人是系统中的被动参与者。  
  
如果要区分actor与business worker，我们通常可以问2个问题就能区分了：  
**1）系统是为谁服务的？  
2）这个人会主动发出动作吗？**  
  
我们下面来看一个用例场景，如 下：  
小王带着钱去银行开户，向大厅经理询问了办理手续，填写好表单后，  
交给柜台职员，柜台职员帮小王办理手续，小王拿到存折。  
  
在上面这个场景中，谁是参与者，谁是业务工人呢？  
很明显：  
参与者： 小王  
业务工人：大厅经理，柜台职员  
  
理由：系统是为小王服务的，小王主动发出动作，大厅经理和柜台职员是被动的，他们不会  
主动发出请求。  
  
有人常常会有这样的错误概念：认为参与者必须是人。  
事实上，这种想法是错误的， **参与者有时候也可以是物**。  
  
我们来看这样一个场 景；  
每天自动统计网页访问量，生成自动报表，将报表发送至相关人员信箱。  
  
很明显，这个场景中没有人。  
那么参与者是谁呢？  
我们说，是“计时器”。  
因为它在每天的固定时间启动这个需求。  
  
关于用例，我们经常会有误导，那就是  
把它和具体业务操作混淆起来。  
我们可以用这样一句话来加以区分：  
  
用例是有意义的，它代表了参与者的愿望，  
不能完整达到参与者愿望的不能称为用例。  
  
我们还是看上面这个小王去银行开户的场景。  
在这个场景中，我们可以提炼出来的动作有：  
银行开户，询问手续，填写表单，办理手续，拿到存折  
  
在以上动作中，只有银行开户才是真正的用例，其它都是该用例的具体操作。  
就拿填写表单来说，填写表单是小王的愿望吗？显示不是，小王去银行又不是为了  
填写表单，他是为了开户，但是银行规定这么做，如果能够不填写表单就直接办理  
开户，小王当然高兴了。  
  
所以，我们说：  
**用例必须代表参与者完整的愿望。**  
  
以上场景的用例图如下：  
![openAccount.png][]

转载于:https://www.cnblogs.com/davidgu/archive/2009/08/15/1546443.html

[actor.png]: /images/20211223/6a502a8a5e114eb08cb2c78c19435015.png
[use_case.png]: /images/20211223/0218d400b0ec427082e999828f3d17d3.png
[openAccount.png]: /images/20211223/33f8166b19524d478a576ebe72a98da5.png