定义当系统用户与系统交互时,用户可以扮演的一组连贯角色。参与者实例可以由单个系统或外部系统扮演。 
其它关系:  部分的 用例模型
扩展:软件需求
角色: 需求指定者 
可选/发生: 早在先启阶段发现并与用例有关。
模板和报告:
     
示例:
     
UML 表示: 参与者
更多信息:  
活动的输入:   活动的输出:  

用途 到页首

不同的涉众为了不同用途而使用此工件:

  • 系统分析人员 - 定义系统边界。
  • 用户界面设计人员 - 获取人物的特征。
  • 用例作者 - 描述用例及其与参与者之间的交互。
  • 对象分析人员 - 实现用例及其与参与者之间的交互。

属性 到页首

属性名 简述 UML 表示
名称 参与者的名称。 模型元素上的属性“名称”。
简述 参与者的职责范围和参与者所需系统操作的简短描述。  “短文本”类型的标注值。 
特征 对于人物:参与者所处的实际环境,参与者所代表的用户的个数,参与者对领域的了解程度,参与者的计算机经验水平,参与者正在使用的其它应用程序和其它常用特征(如性别、年龄、文化背景等等)。  “格式化文本”类型的标注值。 
关系 诸如参与者泛化关系、参与者参与的通信关联之类的关系。  通过聚集“所有”,归封闭包拥有。 
所有针对参与者的图,如描述参与者与用例的通信关联的用例图。  通过聚集“所有”,归封闭包拥有。 

计时 到页首

参与者 检查系统时,在先启阶段早期发现了与用例相关的工件。在制作用户界面原型并实现之前,描述和明确参与者的特征是一种好的做法。

职责 到页首

需求指定者角色最终负责管理工件。虽然需求指定者角色和用户界面设计员角色都将更新关于每个参与者的详细信息,需求指定者 负责确保每个 参与者:

  • 定义一个固有的角色并且确实是独立于其它分类的分类。
  • 具有与该角色所参与的用例的正确通信关联。
  • 是正确的泛化关系的一部分。
  • 工件获取将作为用户界面需求的必要特征。
  • 本地用例图,描述工件是可读的且与其它属性一致。

定制 到页首

确定要使用的属性和使用方法。特别地,您要确定需要在多大程度上详细地描述“特征”属性。



Rational Unified Process   2003.06.15