时序图中是否必须要有同步消息的回复消息答案

【问题标题】：Is it a must to have a reply message for synchronous message in sequence diagrams时序图中是否必须要有同步消息的回复消息
【发布时间】：2021-12-15 10:54:34
【问题描述】：

我对序列图只有 3 个疑问。

是否必须对每条同步消息都有回复消息，我还想知道回复消息是一种方法还是只是一条消息？
在下图中，我可以使用从右到左的同步消息而不是回复方向（例如：'showAllCompaniesView' 和 'updateCompaniesView()'）吗？

【问题讨论】：

标签： uml diagram class-diagram sequence-diagram

【解决方案1】：

不需要回复。如果省略它，同步消息将隐含返回。在被调用对象执行某些操作并且只有在发生进一步操作时才返回给调用者的情况下，您将使用返回消息。这是一个粗略的草图，我省略了几乎所有不需要的东西：

所以在上图中，第一条消息没有显示返回，因为它是微不足道的。 Object2 只执行一些操作。
第二条消息在Object2 中触发了更复杂的内容（即发给Object3 的消息）。忽略返回仍然是微不足道的，因为 Object1 只能在消息的 Object2 执行结束后开始。
第三条消息有明确的返回。您可能会展示在执行期间您有一些复杂的消息结构（我只展示了一条消息，但您可以在这里想象一个森林，我猜）。如果您有分配或与某些返回结果相关的任何其他签名，您还将显示返回消息。从 p。 UML 2.5 的 575：

回复消息标签用于回复消息。它具有以下形式：

<reply-message-label> ::= [<assignment-target> ‘=’] <message-name> [‘(’ [<output-argument-list>] ‘)’] [‘:’ <value-specification>]

是的。反之亦然，您可以使用消息。如果你有一个调用，你最终会进入一个堆栈（你也可以看到对象生命线顶部的附加方块。从编程的角度来看，这将更加棘手，因为你必须以某种方式在你的程序中接受外部调用正在运行。通常您需要使用线程技术来实现它。

更多关于 1 的背景知识。我的陈述更多是出于经验而非规范。我再次开始阅读 UML 2.5（第 17.4.3 章）以查找详细信息 - 但找不到直接的陈述。以下是我找到的段落（按命名章节下方的顺序）：

如果 messageSort 是回复，则 Message 表示从对 Operation 的同步调用返回。 Message的参数分别对应Operation的out、inout和returnownedParameters，按照ownedParameters的顺序排列。

[...]

消息显示为从发送方 MessageEnd 到接收方 MessageEnd 的一条线。当从发送事件遍历到接收事件时，该行必须使得每个行片段都是水平的或向下的。发送和接收事件可能都在同一条生命线上。线或箭头的形式反映了消息的属性：

[...]

回复消息（messageSort 等于回复）的虚线带有空心或实心箭头。

[...]

出现在 request-message-label 中的 message-name 是 Message 的 name 属性。如果消息有签名，这将是签名引用的操作或信号的名称。否则名称不受约束。

到目前为止的规格。 reply 出现的次数更多，但只是为了描述它必须是什么样子。此外，通常与虚线和空心箭头一起使用的返回箭头未列在17.1 包含在序列图中的图形节点下的表格中，没有在B.6 UML Notations and UML DI Representations下的表格中列出。时间>。但它用于17.14 CombinedFragment等示例图表。

让我特别皱眉的是语句回复消息（messageSort 等于回复）有一条虚线，上面有一个打开或填充的箭头。 看起来你可以任意选择表单（填充与否）没有语义差异。

嗯，UML 规范是人工制定的，并非没有错误（我已经发送了一些错误报告）。不过，我也是人。也许其他人发现了一些我找不到的细节。

正如 AxelScheithauer 所评论的，开/关箭头可能与 a-/synch 符号兼容。不过，从异步消息返回似乎毫无意义。好吧，除非少数 OMG 的作者之一出现在这里告诉我们真相，否则我们将其留给猜测 xD

【讨论】：

谢谢你的详细说明，这很有帮助，你能看看我在第一张图片下面的第三个问题吗，我现在刚刚编辑了这个问题。
@YeshanSanthush 请不要这样开始。一个问题可以被编辑但不能扩展（或者我已经看到完全改变了）。请改为添加另一个！
不错的分析。青色生活中显而易见的事情有时很难在（过度？）正式规格中掌握。可能是因为相同的 UML 元素需要涵盖通过传统方法调用实现的事物以及使用数据报或其他通信机制与真实消息交换的组件。
@qwerty_so 回复消息有两种符号的原因仅仅是因为没有人可以回答这个问题，为什么它首先有一个开放的箭头。由于相应的同步消息有一个填充的头部，自然也有一个。但是，为了向后兼容，不可能删除旧的符号。似乎没有工具供应商注意到这一点。顺便说一下，表 17.2 “包含在序列图中的图形路径”中显示了一个开头示例。
@www.admiralalit.nl 我刚刚添加了一个示例来阐明我的意思。