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.


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.

  • @Darrell, I guess you mean that the Producer inserts a new event before the Consumer finished processing the previous one. In that case, the "listen" call at the end of the event processing would immediately return the new event that is present in the queue. – Bart van Ingen Schenau Nov 4 '20 at 15:57
  • yeah - i.e this bit "and the other to the consumer to indicate completion of the listen call" - implies that the consumer doesn't continue to listening for new messages once it dequeues a message – Darrell Nov 4 '20 at 15:57
  • 1
    The consumer is indeed not listening for new events while it is processing an event. This prevents concurrency problems with processing multiple events at the same time. – Bart van Ingen Schenau Nov 4 '20 at 18:11
  • Ok thanks for clarifying, was useful to understand what you were going for. For my case I'll make some adjustments, as an application listens() to the queue only once (on startup), and it can process (dequeue) upto X messages concurrently. The application would only need to call listen() again if it was disconnected, but messages are dequeued as they arrive as long as the app is listening and a concurrent slot is free. The dequeue operations is what repeats in my model, not the listen(). I understand this is a different model. I've gone with a "Loop" construct around the dequeue operation. – Darrell Nov 5 '20 at 15:40

Implementing Bart's answer in the wonderful PlantUML could look like this, (ab)using an entity to distinguish the queue from the participating threads:

enter image description here

The corresponding source code:

participant Producer
entity Queue

Consumer->Queue : dequeue
activate Consumer
Producer->Queue : enqueue
activate Producer
deactivate Consumer
deactivate Producer

If you mean how to draw sequence diagram for something similar to this scenario..

enter image description here

..then I would also model the central "tuple space" or the central multi-agent coordination structure as dumb unconscious, but living actor which would metabolize some scent molecules whenever it "eats" something through the membrane. Agents in the neighborhood then might "smell" it and metabolize further..

wearing your shoes

..(1) yes I would create a lifeline representing the queue

..(2) and I would also draw the "queue changed" signal broadcasted by the queue upon receiving new token same as @bart-van-ingen-schenau

..(3) and yes I would represent the "listening" process as loop box on its own lifeline as you suggest

..and I would also consider drawing the scenario (use case) from different perspectives with different focus using different diagrams, mainly I would think about drawing an overview diagram using the language "BPMN 2.0 - Business Process Model and Notation" (cheat sheet is available here: http://www.bpmb.de/images/BPMN2_0_Poster_EN.pdf)

  • 1
    ... I a not completely sure that is an UML sequence diagram. – NullOrEmpty Aug 12 '14 at 14:25
  • 1
    @NullOrEmpty you are completely right. My picture is UML activity diagram trying to describe the very same scenario that you want to draw in the form of sequence diagram. If this is the scenario you want to draw then I'm giving my (1,2,3)cents for your sequence diagram :) plus one more cent pointing that perhaps BPMN diagram might be also useful. Drawing the sequence diagram is up to you. I just tried to give you answer to your question with some explanation what is behind my answer – xmojmr Aug 12 '14 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.