UML之参与者

定义：参与者是在系统之外与系统交互的某人或某事物；

        第一参与者是在系统之外，在系统之内的不是参与者；参与者与系统有明显的系统边界；

寻找参与者可以提问的问题：

1. 谁负责提供、使用或删除信息？
2. 谁使用此功能？
3. 谁对某个特定功能感兴趣？
4. 在组织中的什么地方使用系统？
5. 谁负责支持和维护系统？
6. 系统有哪些外部资源？
7. 其他还有哪些系统将需要与该系统进行交互？
8. 谁对系统有着明确的目标和要求并且主动发出动作？
9. 系统是为谁服务的？

参与者一个重要的来源就是涉众。

参与者一定是直接并且主动地向系统发出动作并活的反馈的。

参与者的板型：

business actor 业务主角   主要针对的业务人员而非计算机用户；在查找业务主角时必须抛开计算机，没有计算机这些人员也是存在的；

在建立业务模型、查找业务用例都必须使用业务主角，而不是普通参与者；

在初始需求阶段都必须使用业务主角，牢记业务主角时客户实际业务里的业务参与者，没有计算机系统，没有抽象的计算机角色；业务主角必须在实际的业务里能够找到对应的岗位或人；如果对获得的业务主角不是很自行可以尝试回答一下问题：

1. 业务主角的名称是否是客户的业务术语？
2. 业务主角的职业是否在客户的岗位手册里有对应的定义？
3. 业务主角的业务用例是否都是客户的业务术语？
4. 客户是否对业务主角能够顺利理解？

 

业务工人

business worker 业务工人好像也是业务的参与者，但是业务工人只是被动的被参与进来了，就好像电影里的主角和配角一样，业务工人不会主动向系统发出动作的；

可以通过一下几个问题来判断：

1. 他是否主动向系统发出动作？
2. 他有完整的业务目标吗？
3. 系统是为他服务的吗？

如果这几个问题都是否定的那就是业务工人了;

 

参与者与涉众的关系

stakeholder 涉众也成为干系人；涉众是与建设的这个系统有利益关系的一切人和事，涉众的利益要求会影响到系统建设；

参与者是涉众的代表

 

检查点

如何保证找到的参与者是正确的，下面给出了检查点列表，回答这个检查点列表可以发现参与者是否正确：

1. 是否已经找到所有参与者？也就是说，是否您已经对系统环境中的所有角色都进行了说明或建模？虽然您应该检查这一点，但是要到你找到说明了所有用例或才能确定。
2. 每个参与者是否至少涉及到一个用例？删除未在用例说明中提及的所有参与者，或与用例无通信关联关系的所有参与者。
3. 您能否列出至少2名可以作为特殊参与者的人员吧？如果不能，请检查参与者所建模的角色是否为另一个角色的一部分。如果这样，您应该将参与者与另一参与者合并。
4. 是否有参与者担任与系统相关的相似角色？如果有，您将他合并到一个主角中。通信关联关系和用例说明表明参与者和系统是如何相互关联关系的。
5. 是否有2个参与者担任与用例相关的统一角色？如果有，您应该利用参与者泛化关系来为他们的共享行为建立模型。
6. 特定的参与者是否将以几种（完全不同）方式使用系统？或者，他使用用例是否处于几个（完全不同）目的？如果这样，您也许应该有多个参与者。
7. 参与者是否有这关名称忽而描述性名称？用户和客户是否能够理解这些名称？参与者的名称务必要与角色相符。否则，应对其进行修改。

 

参考：大象 Thinking in UML