View source for OCUP2I 07 Interactions

[[Category:Private]]
[[Category:OCUP2]]

==Module 7. Interactions⌘==
===References⌘===
UML 2.5 specification:

TODO

** Intervals
* '''Chapter 12: Packages'''
** Packages
* '''Chapter 20: Information Flows'''
===Sequence Diagram⌘===
[[File:SimpleSequenceDiagram.png]]
* 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⌘====
[[File:SequenceEventOcc.png]]
* 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⌘====
[[File:SequenceEventOcc2.png]]

====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⌘===
[[File:ClipCapIt-160614-113008.PNG]]
* '''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
<source lang=bnf> <interactionconstraint> ::= ‘[‘ (<Boolean-expression> | ‘else‘) ‘]’ </source>
====Interaction Operator Kind⌘====

<table border="1px" cellpadding="10" cellspacing="0">
		<tr bgcolor="#E3E3E3">
			<td colspan="2">'''Only one operand fragments'''</td>
			<td>'''One or more operands fragments'''</td>
		</tr>
		<tr>
			<td>'''opt''' - option</td>
			<td>'''neg''' - negative</td>
			<td>'''alt''' - alternatives</td>
		</tr>
		<tr>
			<td>'''break'''</td>
			<td>'''assert''' - assertion</td>
			<td>'''par''' - parallel</td>
		</tr>
		<tr>
			<td>'''loop'''- iteration</td>
			<td>'''consider'''</td>
			<td>'''strict''' - strict sequencing</td>
		</tr>
		<tr>
			<td>'''critical'''</td>
			<td>'''ignore'''</td>
			<td>'''seq''' - weak sequencing</td>
		</tr>
</table>

====alt⌘====
[[File:ClipCapIt-160915-095849.PNG]]
* The interaction Operator '''alt''' designates that the Combined Fragment represents a choice of behavior. 
* At most one of the operands will be chosen.

====opt⌘====
[[File:ClipCapIt-160915-100310.PNG]]
* The interaction Operator opt designates that the Combined Fragment represents a choice of behavior where either the (sole) operand happens or nothing happens.

====break⌘====
[[File:ClipCapIt-160915-100509.PNG]]
* 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⌘====
[[File:ClipCapIt-160915-101101.PNG]]
<source lang=bnf>
 <loop-operator>::==loop[‘(‘ <minint> [‘,’ <maxint> ] ‘)’]
 <minint> ::= non-negative natural
 <maxint> ::= non-negative natural greater than or equal to <minint> | ‘*’ as unlimited
</source>
* 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⌘=====
[[File:ClipCapIt-160915-101509.PNG]]

====par⌘====
[[File:ClipCapIt-160915-115956.PNG]]
* 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.
[[File:ClipCapIt-160614-105446.PNG]]

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⌘===
[[File:ClipCapIt-160614-152939.PNG]]
* 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.

===Gate⌘===

===State Invariant⌘===
[[File:StateInvariant.png]]
* 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⌘====
[[File:ClipCapIt-160613-161321.PNG]]
====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⌘===
[[File:CommunicationDiagram.png]]
* 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.
<!--
The Interaction described by a Communication Diagram in Figure 17.26 shows messages m1 and m3 being sent
concurrently from :r towards two instances of the part s. The sequence numbers show how the other messages are
sequenced. 1b.1 follows after 1b and 1b.1.1 thereafter etc. 2 follows after 1a and 1b.
-->
====Message⌘====
[[File:UMLCommunicationMessage.png]]
* 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:
** [[File:SynchronousMessage.png]] Synchronous message (send message and suspend execution while waiting for response)
** [[File:AsynchronousMessage.png]] Asynchronous message (send message and proceed immediately without waiting)
** [[File:ReplyMessage.png]] Reply message (reply to synchronous message)
====Sequence Expression⌘====
* '''Sequence expression''' is used to specify an ordering of messages.
<source lang=bnf>
 <sequence-expression> ::= <sequence-term> [‘.’ <sequence-term>]* ‘:’ <message-name>
 <sequence-term> ::= <integer> [<name>] [<recurrence>]
</source>
* 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.