问题描述
在UML用例图中，考虑两个角色A和B，以及一个用例“组织事件”。
我们希望对以下事实进行建模：A可以使用建模的系统启用“组织事件”，但是B需要获得组织的批准。然而，事实证明，也许B会在一周后批准B的批准。而不是异步的。
在这种情况下：
- B是否应该是UC的次要角色？但是，那么奇怪的是，UC的“激活时间”可能要花费B批准的时间，例如。几个星期？
- 还是应该有另一个以B为主要角色的UC，称为“批准组织”？但是然后，该图并不能清楚地表明B确实参与了A所做的“组织活动”？
解决方法
您使用角色Approve event的单独UC B对其进行建模。 UC Organize event只是将一些事件放在时间表中。但是只有获得批准，才能进行类似Cater event之类的UC。为此，您将附加一个读取{ UC Approve event for this event must have been performed }之类的约束。
Organize event和Approve event之间的«include»关系意味着后一个UC仅在完成第一个UC后才能完成。这与所需的异步性矛盾。
如果是组织的认可部门，那么您是第一种情况。次要参与者参加了该UC，但不是“异步”参加，以（a）同步或不同步的说法是没有意义的。为了使UC更加清晰，文本定义必须描述两个参与者的角色，以及组织可能需要很长时间的事实
但是拥有2个UC来分开创建和（非）认可似乎更加明确。在这种情况下，没有UC“组织活动”，“组织活动”是主题。当然，执行“创建事件”是“批准事件”的前提
我认为您可以使用3个用例，第一个是“创建事件”，第二个是“批准事件”，第三个是“组织事件”。第三个与第一个具有关系，第二个与第一个具有关系，该关系上的刻板印象是“ include”（请参见示例：https://www.uml-diagrams.org/use-case-include.html）。您的第一个参与者与第一个用例相关联，第二个参与者与第二个用例相关联。
您的应用程序中有2个参与者。 “创建事件”用例与“批准事件”没有关系，因此它们彼此“异步”，但是“组织事件”与前两个有关系，因此最终“组织事件”应完成第一个和第二个。
“创建事件”的场景：
- “ A”将有关事件的信息推送到应用程序中。
“批准事件”的场景：
- “ B”未从应用程序中获得批准的事件；
- “ B”发送他要批准的事件的ID。
“组织事件”是应用程序的责任。例如，该应用程序可以在“批准”之后向参与者发送电子邮件。