Date post: | 06-May-2015 |
Category: |
Technology |
Upload: | ricardo-quintero |
View: | 7,009 times |
Download: | 3 times |
1
UML 2-OMG certification course(OCUP Fundamental-4)
Instructor:
M.C. Ricardo Quintero
2
Interaction Diagrams
The topics described in this section refer to the following metamodel areas:Package Interactions::BasicInteractions
Interactions Lifelines Messages
The topic area constitutes 20 percent of the test.
3
Interactions
Def.- An interaction describes a series of messages that a selected set of participants exchange within a situation limited in time.
4
Interactions
UML 2.0 defines four diagrams to represent interactions: Sequence diagrams: emphasize the sequence in which
messages are exchanged. (*) Communication diagrams: emphasize the relationship
between the participants. Timing diagrams: emphasize the state changes of the
participants relative to the time and the messages exchanged. Interaction overview diagrams: present the order of
interactions in an activity-like notation.
(*) The most important to the Fundamental certification level
5
Notation & Semantics
The most important aspect in sequence diagrams is the time of messages.
Each participant is represented by a rectangle and a vertical dashed line called lifeline.
Messages are represented by arrows between lifelines.
The time runs from top to bottom, showing the time of message flows.
6
Simple example of a sequence diagram
:Customer :ATM :Server
1: Insert Card
2: ok=checkCard(cardData)
3:
4:
sd Identify Authorized Person
log()
ok:Boolean
Lifelines
Only 1 interactionLocal attribute
7
The lifeline metamodel
NamedElement(from Kernel)
InteractionFragment
ConnectableElement(from InternalStructures)
OpaqueExpression(from Kernel)
OccurrenceSpecification StateInvariant
Lifeline*
*
+covered
*
+coveredBy
*
*
0..1
*
+represents0..1 0..1
0..1
+selector0..1 {subsets ownedElement}
0..1
*
1
*
+covered1{redefines covered}
*
1
*
+covered1 {redefines covered}
Interaction
*
1
+lifeline
*{subsets ownedMember}
+interaction 1
{subsets namespace}
8
Connectable elements
The name in the header of the lifeline is not underlined because lifelines represent connectable elements.
They describe instances located in the classifier to which the interaction belongs. So it’s not bad idea if you think of the lifelines as objects of the specified types (as in UML 1.x).
9
Multiobjects
The header of a lifeline shows (optionally) the element name, together with the pertaining classifier (name:type).
A lifeline always represent exactly one element (so the Multiobjects of 1.x are not permited).
Of course, a lifeline can represent an element from a multivalued property.
In order to select one specific element, you have to state a selector.
The header of lifeline can also show the keyword self, which represents an instance of the classifier to which the interaction belongs
10
Lifelines & set types
res[2]:BookingList:BookingList :Booking
A set type Using a selector to select one
element from a set type
Multiobjects 1.x not permited
11
Execution occurrence
When messages are exchanged between lifelines, then a behavior in the participating elements has to be executed.
This behavior is represented by oblong rectangles on the lifelines and represent the execution occurrence.
The beginning and the end of an execution occurrence are defined by event occurrences.
The sending and receiving of messages determine the beginning and the end of an execution occurrence.
12
The metamodel for event occurrences
NamedElement(from Kernel)
BehaviorExecutionSpecification
Behavior(from BasicBehaviors)
0..1+behavior 0..1
Event(from Communications)
OccurrenceSpecification
1
*
+event 1
*
InteractionFragment
GeneralOrdering
*1
+toAfter
*
+before
1
1*
+after
1
+toBefore
*
0..1
*
0..1
+generalOrdering
*
ActionExecutionSpecification
Action(from BasicActions)
*
1
*
+action 1
Interaction *
0..1 +action
*
{subsets ownedElement}0..1
{subsets owner}
ExecutionSpecification
ExecutionEvent
ExecutionOccurrenceSpecification
1*
+finish
1*
1 *
+start
1 *
11
+execution
11
1
*
+event
1{redefines event}
*
13
Notation forms for various message types
S T
asynchronous
call(syncronous)
reply
lost message
found message
Unew
14
Message sintax[attribute=] name [(arguments)][:return value]|’*’
Where: attribute: can a be a local variable or an instance fo a lifeline. Is
used only for synchronous messages with return values. name: the name of the called message or the name of the signal
sent. Signal sending is always asynchronous. arguments: list of parameters, separated by commas. Sintax:
[parameter=]value (for in parameters)Attribute=output parameter[:output value] (for out, inout or return)
‘-’ (used when the value is unknown and when it doesn’t play a role for
the interaction) Instead of the message you can specify an asterisk (*). It’s a kind of
joker for any message.
15
Message examples
message(4,-,2,”HelloWorld!”) X=calculate(17,bpos):42 message(arg=2003)
16
Destroying objects
The destruction of an object is a special event ocurrence (see the metamodel).
17
The metamodel for messages
0..1
0..1
MessageKind
completelostf oundunknown
<<enumeration>>
NamedElement(from Kernel)
MessageSort
sy nchCallasy nchCallasy nchSignal
<<enumeration>>
OccurrenceSpecification
Connector(from InternalStructures)
Interaction
ValueSpecification(from Kernel)
NamedElement(from Dependencies)
Message
/ messageKind : MessageKindmessageSort : MessageSort
0..1
*
+connector 0..1
*
*
1
+message* {subsets ownedMember}
+interaction1{subsets namespace}
*
0..1
+argument
* {ordered, subsets ownedElement}
0..1
0..1 +/signature0..1
MessageEnd
0..1 +sendEv ent
0..10..1
0..1
0..1 +receiv eEv ent
0..1
0..1 0..1
+message
0..1 0..1
MessageEvent(from Communications)
MessageOccurrenceSpecif ication
1
*
+ev ent1{redef ines ev ent}
*
18
Event ocurrence: sending and receiving messages Event ocurrences that arise immediately
upon sending and receiving messages are more important than a stop for the certification.
Sending is an event, as is Receiving. These events are used to define the
semantics of an interaction that can be described by two sets.
19
Event ocurrence: sending and receiving messages One set contains the valid sequences of
send and receive events. The other set contains invalid
sequences. All remaining sequences are irrelevant for
the interaction.
20
Example of sequences-valid sequencesInteraction Example
S T
p
r
p! p*
q!
r*r!
q
Secuencias válidas de interacción:
<p!,p*,q!,r!, r*, q*>
<p!, r!, p*, q!, r*, q*>
21
Rules to determine valid sequences
1. Before a receive event, there must always be the pertaining send event first.
2. The sequence along one lifeline is relevant. In contrast, the position of one event relative to an event on another lifeline is insignifcant.
Ex.- Thought event r! comes after q!, r! can nevertheless happen first.
22
General ordering
Is possible to use the GeneralOrdering relationship to influence the sequence of events.
GeneralOrdering is a relationship between two events, bringing these events into a time sequence.
The relationship is drawn as a dotted line between a centered filled triangle, showing the direction between the two events involved.
The triangle points to the later of the two events.
23
Adding a GeneralOrdering relationship to the example
Interaction Example
S T
p
r
p! p*
q!
r*r!
q
Provoca que la secuencia ahora sea inválida, porque el evento r!
tiene que ocurrir antes que p*
<p!,p*,q!,r!, r*, q*>
24
StateInvariant
The exchange of messages can causes the states of instances represented by lifelines to change.
This can be denoted by state invariants.
25
The metamodel for interactions
ExecutionSpecification OccurrenceSpecification
Behavior(from BasicBehaviors)
NamedElement(from Kernel)
Constraint(f rom Kernel)
StateInvariant
1+invariant
1{subsets ownedElement}
InteractionFragment
Interaction
*
0..1
+fragment
*
{orderedsubsets ownedMember}
+enclosingInteraction0..1
26
State Invariants on a lifelineS
State X
{self.list->size().notEmpty()}
{self.listA->size()>self.listB->size()}
27
Structure of interactions
The metamodel class Interaction owns the elements Message and Lifeline.
The abstract superclass of Interaction and other elements, such as EventOcurrence, is InteractionFragment.
The entire structure of an interaction is formed by means of the composite pattern.
28
Checklist: Interaction diagrams
1. What is an interaction?2. What does a lifeline represent?3. What does self mean in a lifeline?4. What is an execution ocurrence?5. What types of message are there?6. What is a stop?7. What events are triggered by an exchange of
messages?
29
Checklist: Interaction diagrams
8. How is the semantics of an interaction defined?
9. How many valid event sequences can an interaction have?
10. What rules determine valide event sequences?11. What does the GeneralOrdering relationship
express?12. What is a state invariant?13. How are state invariants denoted?
30
Diagramas de comunicación
Emphasizes the relationship of the participants rather than the time sequence of the exchange of messages as in sequence diagrams.
31
Example of a communication diagram
Interaction System start
:System
:Subsystem2
:SubSystem1
2:initialize()
1:initialize()
32
Timing diagram
Is another view on the interaction model. It emphasizes timing aspects; in particular, the state change of the lifelines at specific times.
The states are state invariants in the interaction model.
33
Example of a timing diagram
34
Interaction overview diagram
It looks like an activity diagram. However it is an interaction diagram that
uses the same notation. The nodes are interactions or
interaction uses. The diagram specifies the executing
order of interactions.
35
Example of an interaction overview diagram
36
Use cases
The topics discussed in this section refer to the following areas of the metamodel: Package: UseCases
Actors Include and extend relationships The classifiers of a use case Other use case concepts
This topic area constitutes 20 percent of the test.
37
Use cases & Actors
Def.- A use case specifies a set of actions that are executed by a system or subject and that lead to a result.
An actor is a role outside the system or subject of the pertaining use case that interacts with the system in the context of the use case.
38
Notation & Semantics
A use case diagram describes the relationships among a set of use cases and the actors participating in these use cases.
The diagram does not show sequence flow (though is possible define it textually or by activity diagrams)
39
Example of use case diagram
Branch employee
Call Center vehicle Book Vehicle
Charge for car use Tariffing System
40
The metamodel for use cases and actors
DirectedRelationship
(from Kernel)
RedefinableElement(from Kernel)
BehavioredClassifier(from BasicBehaviors)
Actor
NamedElement(from Kernel)
Constraint(from Kernel)
Include
ExtensionPoint
Extend
0..1
0..1
+condition 0..1
{subsets ownedElement}
0..1
1..*
*
+extensionLocation1..*
{ordered}
*
Classifier
UseCase
1
*
+includingCase 1
{subsets source}
+include
*{subsets ownedMember}
1
*
+addition1
{subsets target}
*
* 1
+extensionPoint
*
{subsets ownedMember}+useCase
11
*
+extendedCase1
{subsets target}
*
1
*
+extension1
{subsets source}
+extend*{subsets ownedMember}
*
0..1
+ownedUseCase
*{subsets ownedMember}
0..1*
*
+subject*
+useCase*
41
Some terms used in use cases
System: (is not a direct model element) refers to the context of a use case. It describes a classifier in which the actions specified by the use case are executed. Can be a class or a component that represents the entire application.Synonymous: use case context, subject,
modeling focus and context.
42
Some terms used in use cases
Stakeholder: (is not a model element) it is a general term used to describe a person who has an interest in the system and who is especially interested in the results.
43
Notation for actors
Call Center vehicle
Call Center vehicle
Call Center vehicle
<<actor>>
ActorExternal System
The block (in the right) is not a UML symbol, is a user-specific symbol.
44
Associations
A simple association is used to connect an actor and use cases.
The association expresses a communication path between the actor and the use case.
Directed associations are permitted. It is common for the navigation direction to point from the active to the passive part (from who initiated the communication).
45
Multiplicity
Multiplicity on the side of the use case specifies how often this use case may be executed concurrently by the actor (default=0..1).
Multiplicity on the side of the actor, specifies how many actors with the specified roles must or can participate in the use case (default=1).
46
Several notations for use cases
Use case
Use case
Use case
Extension points
Standard notation
Using the name
underneath the ellipse
As a behaviored classifier. This
representation is suitable, i.e., when a large
number of extension points
have to be defined
47
Representing the system underlying a use case
<<subsystem>>
Booking System
Call Center vehicleAgent
Book vechicle
Cancel booking
It is a component with the
stereotype <<subsystem>>
48
A use case belonging to a classifier
<<subsystem>>
Booking System
Book vechicle
Cancel booking
A use case can belong to a classifier, by a special Classifier model element enhanced by the property to own use cases
49
Checklist: Actors & Use cases
1. What is the subject of a use case?2. Can an actor be only a human user?3. Name the base class of an actor in the
metamodel?4. Which notations are ther for an actor?5. Name tha base class of a use case in the
metamodel?6. Which notations are there for a use case?7. Who can own a use case?
50
Use case relationships
Def.- An include relationship is used to integrate a use case into another use case, thus becoming a logical part of that use case.
An extend relationship is used to express that a use case will be extended by another use case in certain circunmstances, and at certain point, which is the extension point.
Use cases are special classifiers, they can be generalized and can be abstract.
51
The metamodel for use cases and actors (again...)
DirectedRelationship
(from Kernel)
RedefinableElement(from Kernel)
BehavioredClassifier(from BasicBehaviors)
Actor
NamedElement(from Kernel)
Constraint(from Kernel)
Include
ExtensionPoint
Extend
0..1
0..1
+condition 0..1
{subsets ownedElement}
0..1
1..*
*
+extensionLocation1..*
{ordered}
*
Classifier
UseCase
1
*
+includingCase 1
{subsets source}
+include
*{subsets ownedMember}
1
*
+addition1
{subsets target}
*
* 1
+extensionPoint
*
{subsets ownedMember}+useCase
11
*
+extendedCase1
{subsets target}
*
1
*
+extension1
{subsets source}
+extend*{subsets ownedMember}
*
0..1
+ownedUseCase
*{subsets ownedMember}
0..1*
*
+subject*
+useCase*
52
Include relationship
Parts of use cases that occur identically in several use cases can be swapped into a separate use case, and then include relationship can be used to integrate the desired part in another use case.
It is not necessary that an actor be connected to an included use case.
53
Include relationshipPay out cash
Identify authorized
person
<<include>>
Pay out cash
1.Include:Identify authorized person2.Determine pay-out amount3. Check pay-out possibility4. Pay out cash
Identify authorized person
1. Read customer card2. Check card lock3. Ask for PIN4. Check PIN
54
Extend relationshipA
extension points
P
B<<extend>>
Condition:{boolean expression}extension point: p
Use case A is extended by use case B at the extension point P under certain condition.
If no condition is specified, then the extension will allways occur.
It is not necessary that an actor be connected to the extended use case
55
Example of use case diagram with use case relationships
C
B
EActor 3
Actor 1 A
Actor 2D
Can you specify the kind of
relationships (include or extend)
of the dashed arrows?
56
Checklist: use case relationships
1. In what direction does the include relationship point?2. Does an included use case have to have an actor?3. In what direction does the extend relationship point?4. How many extension points can a use case define?5. Does an extend relationship have to specify a
condition?6. Does an extended use case have to have an actor?