如何在 UML 序列图中表示监听器
在序列图中，如何表示事件触发的侦听器？ 它不仅仅是常规方法调用，因此这样显示似乎不正确。
我尝试制作包含 JMS 侦听器的系统的序列图。我可以通过系统对 JMS 队列的 send() 调用来启动生命线（将调用 send() 的系统显示为业务参与者），或者我可以在 onMessage() 调用处启动生命线。 （将 JMS 队列显示为业务参与者） 或者我应该忽略图中的整个 JMS 队列？
就其价值而言：我正在使用 Astah Community 来创建图表。
In sequence diagrams, how would you represent an event triggered listener?
It is not just a regular method call, so displaying like that would not seem correct.
I try to make a sequence diagram of a system including a JMS listener. I could start the lifeline with the send() call of the system to the JMS queue (displaying the system calling send() as a business actor), or I could start the lifeline at the onMessage() call. (displaying JMS Queue as a business actor)
Or should I just ignore the whole JMS Queue in the diagram?
For what it's worth: I'm using Astah Community to create the diagrams.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您使用“事件”或显式“方法调用”，通常并不重要。
您的受众是什么？您如何为 JMS 侦听器建模？我假设 JMS 侦听器只是另一个参与者，如果您的受众处于“需求”级别，我将简单地使用一个事件（序列图中的消息通常可以是各种“类型”，例如事件、消息或方法称呼）。
It is usually not important if you either use an "event" or an explicit "method call".
What is your audience and how do you model the JMS listern? I would assume the JMS Listener is just another actor, and if your audience is on the "requirements" level I would simply use an event (a message in a sequence diagram usually can be of various "types" like event, message, or method call).
找到的消息是已知接收事件发生但不存在（已知）发送事件发生的消息。我们将此解释为因为消息的来源超出了描述的范围。例如，这可能是噪音或我们不想详细描述的其他活动。语义就是跟踪 (receiveEvent)
丢失的消息是已知发送事件发生但不存在接收事件发生的消息。我们将此解释为因为消息从未到达目的地。语义就是简单的跟踪（sendEvent）。
A found message is a message where the receiving event occurrence is known, but there is no (known) sending event occurrence. We interpret this to be because the origin of the message is outside the scope of the description. This may for example be noise or other activity that we do not want to describe in detail. The semantics is simply the trace (receiveEvent)
A lost message is a message where the sending event occurrence is known, but there is no receiving event occurrence. We interpret this to be because the message never reached its destination. The semantics is simply the trace (sendEvent).