Uml 描述共享用例的事件流和序列图

在这种情况下，我有多个参与者共享同一个用例

我不知道应该从哪个角度来编写事件流并描述这个特定用例的序列图，因为它有多个参与者

您：我有多个参与者共享同一个用例。
... 我应该从哪个角度来写事件流程

用例是面向目标的。它们不应该是功能分解，也不应该是一系列动作。不是我，而是Ivar Jacobson，用例的发明者，在：

用例是使用系统为特定用户实现特定目标的所有方法。
（第4页）

因此，用例旨在提供全局。您的用例图应该识别这些独立的目标。当然，在每个用例背后，都有一些描述参与者和用例之间交互的叙述：

用例叙述的目的是讲述系统及其参与者如何协同工作以实现特定目标的故事。（…）
用例叙述可以在不同的细节层次上进行开发，从简单的大纲、确定基本流程和最重要的变体，到全面、高度详细的规范
（第47页）

描述这个流程的一种方式是在注释中如何解释：描述场景，告诉谁按哪个顺序做什么。此演示文稿的一个变体是表格形式：一列用于参与者操作，一列用于参与者操作

现在，如果您正处于设计的开始阶段，尤其是如果您有几个参与者，这种UC描述会迫使您决定如何设计交互。更具创造性的变体是描述：不描述事件流，而是创建一个表，更详细地描述参与者的意图（即意图）（在一列或n列中）到系统的相应职责（在单独的列中）的映射

---

然后，您可以开始考虑可能的序列，但也可以考虑可以提供更好的用户体验或更优化的信息流的替代序列。灵活性如此之高，以至于您甚至可以设计语音驱动或NLP驱动的接口，在这些接口中，顺序不是预先确定的，但对于每个用例的执行可能是不同的

您应该从用例的角度编写场景，我如何才能正确地完成它？我总是从演员的角度来写。传统上，你把场景写成演员和系统之间的对话：1）演员做xxx 2）系统做yyy 3）演员做zzz等等。。。没有明确指定哪一个（主要）参与者。添加或删除（主要）参与者不应改变用例。完美。非常感谢。