Uml 系统顺序图-系统能否请求参与者输入？

在uml-系统序列图中，系统能否请求参与者的输入（见附图）

在我的示例中，场景是：系统提示用户确认输入，用户输入

想知道这是否是它的正确表示吗？我像往常一样，以另一种方式提问，参与者向系统提供输入，系统根据输入返回输出…

初步评论 在交互图中显示参与者的做法已被广泛接受，并且相当普遍

然而，原则上，UML交互图（如序列图）应显示生命线之间的交互：

• 作为系统外部的参与者，它不是系统中任何封闭分类器的一部分
• 因此，只有当您的模型范围大于IT系统时，这才是有效的UML，即，您对使用IT系统的组织进行建模
• 此外，对于人类参与者来说，消息语义没有明确定义，这正是问题背后的问题

始终如一

如果您选择继续使用建模方法，并将参与者视为任何其他分类器，则您的参与者实例应该与任何其他对象一样。

的流显示哪个对象是消息的发送者，哪个对象响应。您应该始终保持这种逻辑，就像您在图表中所做的那样。顺便说一句，这将是你的模型上罕见的一个地方，在那里你可以显示系统是在这个特定交互的起源，而不是用户。（提示：别忘了生命线上的：它会增加可读性）

如果你想通过相反方向的箭头/信息来实现参与者的自由意志，那么你只会进一步增加模糊性：这会给人一种印象，即参与者是信息的主动者，而参与者可以发送完全不同的信息。我不确定你的系统是不是专门为响应用户的任意消息而设计的

另一种选择？ 一个不那么模棱两可的替代方案是显示系统核心元素和表示UI的元素之间的交互：UI元素充当用户的代理，但由于它与其他任何对象一样是一个对象，因此消息流的解释是明确的

这是分解背后的想法之一，C是一个特定于用例的控制器（因此它将此交互与需求联系起来），B是向特定类型的参与者公开的UI边界（不输入UI细节）。

确认是模糊的

作为对用户输入的响应，此部分将在SD中丢失。不完整不会错。在这种情况下，您只需描述从确认开始的部分

作为某些系统活动的一部分（例如，您有一个检测过热并要求用户继续关机的控制过程），该部分不会显示用例的开始，可能类似于“观察XY”

在任何情况下，将

系统

用作右边的生命线似乎都是毫无意义的。人们可能会对系统的哪个对象要求确认感兴趣

---

问题总是：图表的编辑想要告诉其他人什么。

简短回答：是

当然，这种交互的上下文不能是系统，因为参与者在系统之外。但是，不允许对上下文建模，而允许交互成为其自己的上下文。或者您可以引入一个上下文类，它包含参与者和系统。但这些只是形式上的考虑

更重要的是，这样做是否有用。我想说，这是可能的。描述参与者将如何与系统交互是分析用例的结果之一。许多人会使用文本来描述这一点，但在复杂的情况下，可以使用UML行为图，如活动图或序列图

不过，我会重新考虑在这里使用同步消息。与人类参与者的交流本质上是异步的。您永远不知道消息是否到达，参与者是否理解它，参与者是否用适当的回复消息进行响应

---

PS：回复消息应该显示它回复的消息的名称，而不是一些任意文本。如果需要，可以在冒号后显示返回值（confirmationput（）：Answer）

对我来说，第二种方法是正确的，系统显示一个对话框，用户要求系统执行confirm（）/cancel（）/。。。