4

In a sequence diagram, when should a message originate from an occurrence specification and when should it originate from an execution specification?

Likewise, when should the message's target be each of the two?

Clarification of terms

I understand that the terms occurrence specification and execution specification might not be familiar to most, as such I point them out on a sequence diagram.

In the following depiction, there are two messages (marked in red):

  • m12 which leads from and to occurrence specifications, and
  • m2 which leads from an occurrence specification to an execution specification (the cyan-coloured block).

picture from eclipse.org (source)

Most tools capable of drawing UML sequence diagrams place an execution specification on both sides by default -- why is that? -- as is the case with Visual Paradigm enter image description here

and MagicDraw

enter image description here

Pétur Ingi Egilsson
  • 4,368
  • 5
  • 44
  • 72

3 Answers3

2

A nice summary of the terms is found at uml-diagrams.org.

The UML spec says on pp. 578

An ExecutionOccurrenceSpecification represents, on a lifeline, the start event or the end event of an ExecutionSpecification.

and

An ExecutionOccurrenceSpecification is represented by the start or finish endpoint of the vertical box for an ExecutionSpecification on a lifeline. See Figure 17.2.

So they just mark the point in time when something happens. Actually there are a number of examples in the spec where timing constraints are also applied in conjunction with ExecutionOccurrenceSpecification.

On p. 567:

ExecutionSpecifications are represented as thin rectangles (gray or white) on the lifeline (see 17.3.4 (Lifeline)).

We may also represent an ExecutionSpecification by a wider labeled rectangle, where the label usually identifies the action that was executed. An example of this can be seen in Figure 17.16.

Simply speaking: there is something happening in a black box.

Now for an OccurrenceSpecification there is a recursive definition in the specs on p. 566:

The semantics of an OccurrenceSpecification is just the trace of that single OccurrenceSpecification.

The understanding and deeper meaning of the OccurrenceSpecification is dependent upon the associated Message and the information that it conveys.

(Wow!) But then on p. 567:

OccurrenceSpecifications are merely syntactic points at the ends of Messages or at the beginning/end of an ExecutionSpecification.

Actually an OccurrenceSpecification is just a more general form of the ExecutionOccurrenceSpecification.

While fig. 17.2 uses ExecutionSpecification the following figures 17.3 etc. do no use them. So you are free to use them at your will.

Community
  • 1
  • 1
qwerty_so
  • 35,448
  • 8
  • 62
  • 86
1

The point where the message starts/ends is always an occurrence.

The execution specification shows the instance that is active. For the initiating instance it is not defined if there should be an execution occurrence or not. Thus various case tool developers took various approaches. If you can decide, you can depict if the instance remain active (e.g waiting for an answer) but that's modeler's choice.

Ister
  • 5,958
  • 17
  • 26
0

Your question was, why some tools show execution specifications on both sides. The reason is simply, that their support for Interaction Diagrams is sorely lacking. Neither the sender nor the receiver of a message is required to execute anything, thus no execution specification is necessary.

While it might often be the case, that the sender executes some behavior, in the course of which some message gets sent, and that the receiver of a message executes a behavior in reaction to receiving a message, this is not always the case. The sender might send spontaneously and the receiver might ignore the message. Even if something gets executed, the modeler might choose not to mention it. An Interaction diagram shows some interesting occurences, but it is by no means required to show all possible occurrences.

A message might start or end at an ExecutionOccurrenceSpecification, but it could also just be a MessageOccurrenceSpecification. An ExecutionSpecification could also be independent of a Message. Maybe the modeler wants to express, that an Object is executing something, whithout beeing disturbed by any messages. It is even possible to define the behavior that is being executed. However I have not found a tool that supports this mandatory feature of UML.

So the answer is, that the tools should allow any combination of Messages and ExecutionSpecifications, since it is entirely up to the modeler, which Occurrences she wants to show.

Axel Scheithauer
  • 2,758
  • 5
  • 13