Uml Omg Fundamental Certification 5

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?