OCUP2I 07 Interactions

Module 7. Interactions⌘

References⌘

UML 2.5 specification:

TODO

• • Intervals
• Chapter 12: Packages
  • Packages
• Chapter 20: Information Flows

Sequence Diagram⌘

• Participants are represented by a rectangle and a dashed line (lifeline)
• Messages are represented by arrows between lifelines
• Time runs from top to bottom
• The entire diagram represents one interaction

Event Occurrences⌘

• send event is denoted by an exclamation mark (!p)
• receive event is denoted by question mark (?p)
• A valid sequence for the interaction: < !p, ?p, !q, ?q >
• It's not the only valid sequence!

Event Occurrences valid trace⌘

Event Occurrences Rule⌘

• Send event before receive event
• The order of events along one lifeline is relevant.
• The position of one event relative to an event on another lifeline is insignificant.

Fragments⌘

• Combined Fragment is an interaction fragment which defines a combination (expression) of interaction fragments.
  • Interaction Operator specifies the meaning of Combined Fragment
  • Interaction Operands are separated by a dashed horizontal line. The Interaction Operands together make up the framed Combined Fragment
  • Interaction Constraint is shown in square brackets covering the lifeline where the first event occurrence will occur, positioned above that event

 <interactionconstraint> ::= ‘[‘ (<Boolean-expression> | ‘else‘) ‘]’

Interaction Operator Kind⌘

Only one operand fragments		One or more operands fragments
opt - option	neg - negative	alt - alternatives
break	assert - assertion	par - parallel
loop- iteration	consider	strict - strict sequencing
critical	ignore	seq - weak sequencing

alt⌘

• The interaction Operator alt designates that the Combined Fragment represents a choice of behavior.
• At most one of the operands will be chosen.

opt⌘

• The interaction Operator opt designates that the Combined Fragment represents a choice of behavior where either the (sole) operand happens or nothing happens.

break⌘

• The interaction Operator break designates that the Combined Fragment represents a breaking scenario in the sense that the operand is a scenario that is performed instead of the remainder of the enclosing Interaction Fragment.
• A Combined Fragment with interaction Operator break should cover all Lifelines of the enclosing Interaction Fragment.

loop⌘

 <loop-operator>::==loop[‘(‘ <minint> [‘,’ <maxint> ] ‘)’]
 <minint> ::= non-negative natural
 <maxint> ::= non-negative natural greater than or equal to <minint> | ‘*’ as unlimited

• If only <minint> is present, this means that <minint> = <maxint> = <integer>.
• If only loop, then this means a loop with unlimited upper bound and with 0 as lower bound.

loop example⌘

par⌘

• The interaction Operator par designates that the Combined Fragment represents a parallel merge between the behaviors of the operands.
• The OccurrenceSpecifications of the different operands can be interleaved in any way as long as the ordering imposed by each operand as such is preserved.

strict⌘

• The interaction Operator strict designates that the Combined Fragment represents a strict sequencing between the behaviors of the operands.

seq⌘

• The interaction Operator seq designates that the Combined Fragment represents a weak sequencing between the behaviors of the operands.
• Weak sequencing reduces to a parallel merge when the operands are on disjunct sets of participants.
• Weak sequencing reduces to strict sequencing when the operands work on only one participant.

Interaction Use⌘

• Interaction Use is an interaction fragment which allows to use another interaction.
• It is shown as a Combined Fragment symbol where the operator is called ref.

Interaction Use referring the Interaction EstablishAccess with (input) argument “Illegal PIN.” Within the optional CombinedFragment there is another Interaction Use without arguments referring OpenDoor

Part Decomposition⌘

• A Part Decomposition is an Interaction Use that specifies fragmentation of a lifeline within one Interaction by an Interaction.
• The messages that go into (or go out from) the decomposed lifeline are interpreted as actual gates that are matched by corresponding formal gates on the decomposition.

State Invariant⌘

• A state invariant is an interaction fragment which represents a runtime constraint on the participants of the interaction.
• It may be used to specify different kinds of constraints, such as values of attributes or variables, internal or external states, etc.
• The Constraint is evaluated immediately prior to the execution of the next Occurrence Specification.
• If the Constraint is true, the trace is a valid trace; if the Constraint is false, the trace is an invalid trace.
• Notation:
  • as text in curly brackets on the lifeline
  • as state symbol represents the equivalent of a constraint that checks the state of the object represented by the Lifeline
  • as a Note associated with an OccurrenceSpecification

State Invariant example⌘

Unexpected trigger reception⌘

• The interpretation of the reception of an Event occurrence that does not match a valid trigger for the current State, state invariant, or pre-condition is not defined.
• It can be ignored, rejected, or deferred; an exception can be raised; or the application can stop on an error.

Communication Diagram⌘

• Communication Diagrams focus on the interaction between Lifelines where the architecture of the internal structure and how this corresponds with the message passing is central.
• The sequencing of Messages is given through a sequence numbering scheme.
• Communication Diagrams correspond to simple Sequence Diagrams.
• A Lifeline represents an individual participant in the interaction.

Message⌘

• A message is shown as a line from the sender to the receiver.
• The send and receive events may both be on the same lifeline.
• The form of the line or arrowhead reflects properties of the message:
  • Synchronous message (send message and suspend execution while waiting for response)
  • Asynchronous message (send message and proceed immediately without waiting)
  • Reply message (reply to synchronous message)

Sequence Expression⌘

• Sequence expression is used to specify an ordering of messages.

 <sequence-expression> ::= <sequence-term> [‘.’ <sequence-term>]* ‘:’ <message-name>
 <sequence-term> ::= <integer> [<name>] [<recurrence>]

• Examples:
  • 1a:m1
  • 1b.1:m3
  • 1b.1.1.1:m2

Sequence Expression rules⌘

• The integer represents the sequential order of the Message within the next higher level of procedural calling.
• Messages that differ in one integer term are sequentially related at that level of nesting. Example: Message 3.1.4 follows Message 3.1.3.
• The name represents a concurrent thread of control. Messages that differ in the final name are concurrent at that level of nesting. Example: Message 3.1a and Message 3.1b are concurrent.