用例图中同一参与者在不同用例兼具主次角色的规范可视化方法

首先明确UML 2.5正式规范对主/次参与者的定义：主参与者是主动发起用例、从用例执行中获取明确业务价值的角色；次参与者是被用例流程调用、为用例提供外部支撑，或被动接收用例输出的角色，本身不会主动触发该用例。

两种常见的非规范做法要避开 #

• 绝对不要把同一个Customer参与者在图上拆成两个、分别放在左右两侧。UML规范要求同一系统边界内，逻辑属性一致的同一个参与者只能出现一次，重复排布会让阅读者误以为是两个独立的角色，直接造成语义歧义，不管加什么注释解释都很难消除误解。
• 不要靠无规范依据的箭头自定义来硬区分角色。如果没有统一规则就随意给关联线加箭头，跨团队协作时很容易出现理解偏差，毕竟行业内默认大家对无方向关联线的认知是双向通信，没有共识的自定义表达完全起不到清晰传递语义的作用。

可直接落地的规范表达步骤 #

• 第一步：保持Customer参与者在图中的唯一实体位置，就按常规主参与者的排布放在系统边界左侧，不需要特意挪动位置。
• 第二步：通过关联线的单向箭头明确交互触发方向，这个表达是完全符合UML规范的：
  • 对Customer主动发起的用例（注册、服务搜索、预约时段选择），关联线保持无方向，或者画成从Customer指向对应用例的单向箭头，代表交互的触发源是Customer，他是主参与者
  • 对Customer作为被动接收方的两个通知类用例，把关联线的箭头画在从用例指向Customer的一端，代表交互的触发源是系统（服务提供方），Customer是被动接收输出的次参与者
• 第三步：可选的阅读体验优化，在不违反规范的前提下减少理解成本：
  • 给两个通知类用例加简短的注释，明确标注该用例中Customer的次参与者身份
  • 用例命名保持动宾结构，把两个次参与的用例直接命名为推送预约成功通知、推送预约时段调整通知，从命名上就明确主动执行方是系统，不需要额外翻注释理解

很多新人会被“主左次右”的固定布局思维绑住，觉得次参与者必须放到系统边界右侧——这是最早一批UML教材里为了教学方便总结的经验排布，从来不是强制规范。判断一个参与者是主还是次，核心从来不是他在图上的位置，而是交互的触发方向、从用例执行中拿到业务价值的主体是谁。你这个场景里Customer同时是多类用例的主/次参与者，如果硬要把对应次参与角色的Customer拆到右边，反而会破坏图的布局一致性，完全是舍本逐末。

内容的提问来源于stack exchange，提问作者Promeixcel