UML Sequence Diagram for Queue Processor

couplingmessage-queuesequence-diagramuml

Which is the appropriate way of representing a queue processor in a UML sequence diagram?

I want to represent in the same diagram two systems that are loosely coupled through a queue. The first system, performs some actions and insert an action in a queue, the other system is always listening and when the event appears in the queue, it dequeues the event and processes it, generating new actions. They are both in the same diagram because it is to represent an integration use case that shows how both work together.

Should I create a life line representing the queue?

Should I represent the "listening" process as a loop box containing: a self-message with the label "listen", self-message for processing message and messages representing the sending of the outcome.

Best Answer

As the queue is an important component in the sequence you are presenting, it should most definitely be present with a lifeline.

As the consumer explicitly listens for events from the queue, I would start the diagram with the listen call from the consumer to the queue.
After that, the producer can insert its event into the queue (possibly with an indication that a considerable amount of time can elapse between the listen call and the insertion of the event). At this point, I would use two return arrows. One back to the producer to indicate completion of the insert call, and the other to the consumer to indicate completion of the listen call.
This is under the assumption that the producer and consumer execute asynchronously.

It would look like this:

+---+       +---+       +---+
| P |       | Q |       | C |
+---+       +---+       +---+
  |           |   listen  |
  |           | <|------- |
  |           |           |
  |  insert   |           |
  | -------|> ++          |
  | < - - - - ++  event   |
  |           ++ - - - - >++
  |           |           ++
  |           |           ++
  |           |   listen  ++
  |           | <|------- ++
  |           |           |

To indicate that the consumer is always listening, I have ended the diagram again with a listen call that hasn't returned.

Related Topic