As far as I understood, synchronous messages will be handled one after another.

Then we have the interaction operator for combined fragments called "strict" which states, that the operands inside the fragment should run one after another.

I can't see the difference to the normal behaviour with synchronous messages.

Why would I want (or need) to use the keyword "strict" instead of just using synchronous messages?

  • 2
    Synchronous is a relative concept; it describes a behavior relative to the main thread of an implementation (and as @Robert says, think "blocking" a thread). In messaging there are two implementations: a sender and a receiver, and either can be doing messaging operations synchronously or async independent of each other. Sync vs. async is not a property of a message itself (e.g. while it is on the wire).
    – Erik Eidt
    Commented Aug 17, 2019 at 17:10

3 Answers 3


"Synchronous" means the same thing as "blocking." It doesn't necessarily have anything to do with the order in which messages are handled.

See here, which says that the system "waits for a message response before it continues processing."

Accordingly, you need "strict" to distinguish between synchronous message handling where order matters and synchronous message handling where order doesn't matter.


The UML 2.5 specs tells on p. 617:

• strict | The InteractionOperatorKind strict designates that the CombinedFragment represents a strict sequencing between the behaviors of the operands. The semantics of strict sequencing defines a strict ordering of the operands on the first level within the CombinedFragment with interactionOperator strict. Therefore OccurrenceSpecifications within contained CombinedFragment will not directly be compared with other OccurrenceSpecifications of the enclosing CombinedFragment.

(That would leave me with quite some question marks hovering over my head.)

Earlier on p. 590 you find PartDecomposition

PartDecomposition is designated by a referencing clause in the head of the Lifeline as can be seen in the notation sub clause 17.3.4 (Lifeline) (see also Figure 17.21).

If the part decomposition is denoted inline under the decomposed lifeline and the decomposition clause is “strict,” this indicates that the constructs on all sub lifelines within the inline decomposition are ordered in strict sequence (see 17.6.4 (Strict interactionOperator).

Extra global CombinedFragments have their rectangular frame go outside the boundaries of the decomposition Interaction.

The reference to on p. 584: Strict interactionOperator

Notationally, this means that the vertical coordinate of the contained fragments is significant throughout the whole scope of the CombinedFragment and not only on one Lifeline. The vertical position of an OccurrenceSpecification is given by the vertical position of the corresponding point. The vertical position of other InteractionFragments is given by the topmost vertical position of its bounding rectangle.


If you have just two lifelines where one sends synchronous messages and the other is replying, there is indeed not much difference with or without strict.

However, the order of message in a sequence diagram is partial and applies to messages of the same owning lifeline . (the rules are somewhat more complex, but this is the main idea). So if you have more than two lifelines sending messages or if you mix synchronous and asynchronous messages, you can no longer assume that the graphical order will always be respected. For example:

enter image description here

This example allows 3a to come before or after 3b, because the partial order of each lifeline does not allow to establish a global order across lifelines. and one of the lifeline could go faster.

This is where the strict comes in. If in the above diagram you insert each message in its own argument (region separated with a dashed line), you would be ensured that C always sends 3a before A sends 3b.

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