在uml - 系统时序图中，系统是否可以请求参与者的输入(见附图)
在我的例子中，场景是:系统提示用户输入确认信息，用户输入输入内容。
想知道这是否是它的正确表示？我一如既往地问，我用相反的方式来做，在这种方式中， Actor 向系统提供输入，系统根据输入返回输出...
最佳答案
初步评论
在交互图中显示参与者的做法已被广泛接受并且很普遍。
然而，原则上，UML 交互图(例如序列图)应该显示生命线之间的交互 within an enclosing classifier :
- Actor 在您的系统外部，它不是您系统中任何封闭分类器的一部分。
- 因此，只有当您的模型范围大于 IT 系统时，这才是有效的 UML，即您为使用您的 IT 系统的组织建模。
- 此外，消息语义没有为人类参与者明确定义，这正是您问题背后的问题
保持一致
如果您选择继续您的建模方法并将 Actor 视为任何其他分类器，那么您的 Actor 实例应该像任何其他对象一样表现。
流量messages显示哪个对象是消息的发送者以及哪个对象响应。您应该始终如一地保持此逻辑，就像您在图表中所做的那样。顺便说一下，这将是您模型中罕见的地方之一，您可以在其中显示系统是此特定交互的起源而不是用户。 (提示:不要忘记生命线上的 execution specification:它会增加可读性)
如果你通过相反方向的箭头/消息来具体化 Actor 的自由意志，你只会进一步增加歧义:这会给人一种印象，即 Actor 是消息的主动者，而且 Actor 可以发送完全不同的信息。而且我不确定您的系统是否设计用于响应来自用户的任意消息。
另一种选择？
一个不那么模糊的替代方案可能是显示系统核心元素和表示 UI 的元素之间的交互:UI 元素充当用户的代理，但由于它和其他任何对象一样，消息流的解释是明确的。
这是 ECB 背后的想法之一。分解，C 是特定于用例的 Controller (因此它将此交互与需求相关联)，B 是暴露给特定类型参与者的 UI 边界(无需进入 UI 细节)。
关于uml - 系统序列图 - 系统可以请求 Actor 输入吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/63084215/