《Thinking in UML》读书笔记 3 : 参与者（Actor）

板型

  在学习参与者之前，先来看一下UML里面的一个概念--板型（类型，构造型）

  定义：   板型是对UML元素基础定义的一个扩展，在同一个元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。

  举例说明 ： 用例的板型有“”“业务用例”“业务用例实现”，类的板型有“接口”“边界类”“控制类”“实体类”等。

  板型也可以自定义，就是说可以在自己的系统中定义自己的板型。

 

参与者（Actor）

  UML官方定义：actor是在系统之外与系统交互的某人或某事物。

 

   参与者只能位于系统边界之外，边界之类的所有人和食物都不是参与者

   参与者位于系统之外

   思考下面两个问题有助于找到参与者

   1.谁对系统有着明确的目标和要求并且主动发出动作

   2.系统是为谁服务的

   参与者可以是非人

   参与者也可能是非人类，例如一个每天自动统计网站访问量报表的系统，这个参与者就是一个时间触发器

   参与者肯定是一个需求的启动者，如果找不到启动者，说明这不是一个功能性需求。

   发现参与者

   参与者的一个重要来源是涉众（也成为干系人，是与要建设的这个系统有利益关系的一切人和事，涉众不一定是参与者，但因为利于关系会对系统有影响）

   参与者的另一个来源是客户的岗位设置

   要注意的是，参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就不是参与者。

   可以向客户经理问下列的问题有助于找到参与者：

   1.谁负责提供，使用或删除信息？

   2.谁将使用此功能？

   3.谁对某个特定功能感兴趣？

   4.在组织中的什么地方使用系统？

   5.谁负责支持和维护系统？

   6.系统有哪些外部资源？

   7.其他还有那些系统将需要与该系统进行交互？

  业务主角（Business Actor）

   业务主角是参与者的一个板型，业务主角是脱离计算机系统的参与者，就是说在确定义务主角的时候要完全跑开计算机系统的概念，不能事先假设系统，这样会造成客户对系统的误解。

   业务主角必须在实际的业务里找到对应的岗位或人员。

   业务工人（Business Worker）

   业务工人就像电影里的配角，他不直接主导电影的剧情，但辅助剧情的发展，是电影不可或缺的一部分，在系统中，业务工人在系统边界内，他的工作辅助完成用例。例如定票系统中的人工作机，他的最终目的不是订票，而是服务客户，他属于系统之内，所以他是业务工人，而不是参与者。

   参与者与涉众的关系

   参与者是涉众的代表，涉众是系统的获利者，他可能不是参与者，但由于利益的因素影响着系统。

   参与者与用户的关系

   用户是指系统的使用者，通俗点说就是系统的操作员。并非所有的参与者都是用户。利于一个科室的主人负责行政审批，但他可能吧工作交给他的秘书去做，但他是参与者而不是用户，他的秘书是这个系统的用户，一个用户可以代理多个参与者。

   参与者与角色的关系

   角色是参与者的职责，是一个抽象的概念，从众多单于着的职责中抽象出相同的恶意部分，将其命名形成一个角色。利于一个正处长和局长都可以审批文件，这时就可以抽象出审批者这个角色，他为系统带来很好的灵活性。一个用户可以代理多个参与者，因此一个用户可以拥有多个职责，也就是可以被指定多个角色。

 

   总结

   参与者是涉众的代表，它代表涉众对系统的利益要求，并向系统提出建设要求；参与者通过代理给其他用户或将自身实例化成用户来使用系统；采纳与这的职责可以用角色来归纳，哦你各户被指定扮演哪个或那个角色因此来获得参与者的职责。

   

  

转载于:https://www.cnblogs.com/ccmaycry/archive/2009/07/08/1518820.html