参与者（Actor）是模型中非常重要的元素，识别参与者是需求分析阶段的主要任务之一。
理论上，找出参与者并不太困难。与当前待开发系统（或者子系统，或者组件）存在交互的外部实体都可以视为参与者。这些外部实体是数据、信息或事件来源或者去向，它包括与该系统交互的人、外部系统、传感器或者数据库等。但在实际需求分析场景中，一次性识别出所有参与者可能是困难的，需求分析人员所面对的访谈人员通常只了解待开发系统的部分应用场景，因而需要从可获得的相关工作流程规章、业务专家的描述中去进一步挖掘、追问方能找出所有的参与者。
如前所述，如果你已经找出了所有与待开发系统存在交互的外部实体，那你就能够找到所有的参与者。但其中有一个细节需要注意，那就是要区分出哪些是真正的参与者，哪些只是“传递型参与者”。所谓传递型参与者，他们只是真正参与者与系统进行交互的中介或者工具。例如，键盘、鼠标、手写板等都是系统输入的交互实体，而显示器则是系统输出的交互实体，但这些实体本质上是为使用系统的“人”提供交互的媒介，在建模时可以将它们视为透明的，它们都不是参与者。
参与者在UML中通常用小人图像表示，在参与者不是人而是另外一系统或者数据库时，可能需要为参与者添加属性，此时可以使用构造型（版型）的形式表示参与者，它可以更方便地添加、展示属性甚至操作。两种图形分别如下：
参与者通常代表角色，因而参与者之间可以存在继承（泛化或派生）关系。例如一个系统的使用者包含游客、会员和管理员等不同角色。在这些角色中，游客是最基础的角色，可能仅拥有访问系统公开信息的权限；会员则继承游客的所有特性，并增加如购买商品、发表评论等更多权限；而管理员则不仅具备会员的所有功能，还拥有管理用户、监控系统等高级权限。游客、会员与管理员之间的关系可以通过下图表示。
在用例图中，参与者与他们参与的用例之间用关联线（即带箭头或不带箭头的实线）连接，如果一个参与者连接多个用例，意味着这个参与者可以触发运行或参与这些用例；如果一个用例连接多个参与者，意味着这多个参与者都可以触发运行或参与这个用例。多个参与者关联同一用例时，可能会只有一个主要参与者，他触发启动用例，而其他参与者可视为次要参与者，他们配合用例执行。
参与者与用例之间的关联还可以有修饰符。
例如可以为关联添加箭头，由参与者指向用例的箭头表示由该参与者启动用例，由用例指向参与者的箭头表示用例执行过程中会联系该参与者完成某个行为（用例一旦启动运行，数据和消息可以双向流动，与关联的方向无关）。
关联上还可以标示多重性，关联任意未标示多重性的端其多重性默认为0..1，其含义是对应参与者实例可能参与到当前实例，也可能不参与当前实例，这符合大多数情况下的实际场景。而在另外一些场景下，多重性则是明确的，例如在一局象棋比赛中，参与的棋手一定是两名。
由于通常用例图只在概念层级描述需求，它的受众包括不具备技术背景的人员，所以用例图中其实一般不标示关联可能具有的这些修饰符。
如前所述，参与者不应当是一个人而是一个与系统交互时所扮演的角色，因为一个人在不同场景下会扮演不同的角色，同一角色也可能由多个人担当。例如报销费用的审批由是费用审批人完成，费用审批人是一个角色而不是具体的人，普通员工作为申请人报销费用由财务总监作为费用审批人，当前财务总监是张三，所以普通员工报销费用由张三审批，而如果下个月财务总监变成李四，则普通员工报销费用则由李四审批。身为财务总监的李四作为报销费用的申请人时，他的费用审批人则可能是总经理。在这个例子中，李四扮演了报销费用申请人和费用审批人，而费用审批人在不同场景下则分别由张三、李四及总经理充当。
个人与角色的关系如下图所示：
通常参与者是人，但并非总是如此，与该系统交互的人、外部系统、传感器或者数据库等都可能是参与者。前述说明围绕人类参与者说明，在某些场景下，也会有非人类的参与者，例如在以下两个用例图中，读者在借阅图书时，外部图书馆系统（外部系统）和图书目录库（数据库）都是用例的参与者。
上例中，图书目录库（数据库）在“查找图书”用例中是次要参与者，它在该用例中没有目标，它不能启动“查找图书”用例，但它是数据的来源（类似地，在某些用例中它可能是数据的归宿）。此外，以上例来描画用例意味着图书目录库这个数据库不在当前项目或团队的控制下，它已经完成或者正由其他团队建设，如果该数据库在当前项目或团队的控制下，则可将该数据库视为当前系统的一部分，也就是说它是内部设计项，此时则不需要将数据库作为参与者。
识别参与者与识别用例通常是同时进行的，换一个视角看待这两者的关系，可以将用例看作是提供给参与者的服务，而这个服务由一个系统或系统组件提供。这里的系统或系统组件称为主题或者系统边界，明确主题或系统边界是正确识别参与者与用例的前提条件。例如要构建一个复杂的系统，将该系统作为边界时，与该系统发生交互的外部的人、系统、设备等都是参与者；而一个复杂系统通常由若干个子系统组成，当以子系统A为主题/系统时，与该子系统交互的人、其他子系统（例如子系统B）、设备等都是参与者；而当以子系统B作为主题/系统时，此时子系统A也成了参与者。也就是说对于同一元素，在不同模型中，可能是主题/系统，可能是参与者，甚至可能不被体现。
用例图中主题/系统可用一个方框表示，通常在其顶部或左上角标示出主题/系统名称，例如上图中的“图书馆流通系统”，在必要时甚至也可以为其添加构造型（版型）说明。
如前所述，主题本身表达的是一个系统的范围，故它也是系统边界的含义。多个系统可以提供相同的用例，所以一个用例可以出现在多个系统边界内，例如当前在移动开发项目中，通常需要同时提供IPhone和Android两个平台下的相同用例，如下图所示。
有些用例是由系统本身触发的，此时通常是通过定时器、传感器触发。这种情况下在建模时，一般直接将定时器或传感器建模为参与者，虽然此时它们都在主题/系统内。
查阅合集
