Search code examples
umlsequence-diagram

Goto in Sequence Diagram?


How can I show goto statements in Sequence Diagrams.

For example in the diagram below, once "sleep till hold period" is expired I want to take control back to the "is_item_inventory_onhold_state(item_id)" statement. How can I show this is a diagram?

enter image description here

I am using https://sequencediagram.org/ to create these diagrams.

Code written to generate the diagram above:

title Item Executor

loop  for each item in a list 
Client->ItemExecutor: execute(item)

ItemExecutor -> ItemStateService:is_item_inventory_onhold_state(item_id)

alt True - Item state is on hold
ItemStateService -->ItemExecutor: True
ItemExecutor ->ItemExecutor: sleep till hold period 

goto  ItemExecutor -> ItemStateService:is_item_inventory_onhold_state(item_id)

else False - Item is not in Held State
ItemStateService -->ItemExecutor:False
ItemExecutor ->ItemExecutor: do_something()

end

ItemExecutor ->Client : Acknowledge
end 

Solution

  • Goto is not supported in sequence diagrams (for good reasons). Use a combination of a loop and a break operator instead. See this diagram: enter image description here sequencediagram.org/Item Executor

    sequencediagram.org/Item Executor (with Execution Specifications)

    Some remarks on this diagram

    • the break-fragment leaves the immediately enclosing fragment. Therefore it must be contained directly in the loop-fragment. If it is within an alt-fragment, only this fragment is left.
    • Both alt and opt fragments don't use a guard. The fragment that happens is choosen by the occurrence of the reply message with a certain return-value. If you want to use a guard, you have to assign the return-value to a local variable. This would then happen above the alt-fragment (see diagram below).
    • return values are shown with a preceeding colon. The message name would preceed this, but when it is obvious it can be omitted (as it is here).
    • execution specifications (sometimes referred to as "activations") are only shown, where they help the readability. Contrary to popular belief they are not mandatory.
    • UML doesn't know for each loops. Therefore I added iterator operations. The term "for each item in a list" is not a guard condition. If you want to avoid spelling out the iterator, you can use a - semantic free - comment attached to the loop. Misusing the boolean guard for this makes no sense. If you want a formal definition, you have to add you own stereotype «for each loop»
    • I assume ItemExecutor and ItemStateService are class-names. They need a preceeding colon to distinguish them from role-names. Of course if the role- and class-names are identical, your diagram can be correct.
    • The "Acknowledge" message is just the reply message for the execute message. As such it would carry the same name (which is omitted here).
    • In the version with Execution Specifications, the drawing tool didn't allow the end of the execution specifications to coincide with the send events of the reply-messages, which would have been correct.

    Example with guards for the alt and break fragments (excerpt): with guards sequencediagram.org/Item Executor (with Execution Specifications and guards)