Lecture 20: Live Sequence Charts 2015-02-03 Prof. Dr. Andreas - - PowerPoint PPT Presentation

– 20 – 2015-02-03 – main –

Software Design, Modelling and Analysis in UML

Lecture 20: Live Sequence Charts

2015-02-03

• Prof. Dr. Andreas Podelski, Dr. Bernd Westphal

Albert-Ludwigs-Universit¨ at Freiburg, Germany

Contents & Goals

– 20 – 2015-02-03 – Sprelim –

2/51

Last Lecture:

• Hierarchical State Machines completed.
• Behavioural feature (aka. methods).

This Lecture:

• Educational Objectives: Capabilities for following tasks/questions.
• What does this LSC mean?
• Are this UML model’s state machines consistent with the interactions?
• Please provide a UML model which is consistent with this LSC.
• What is: activation, hot/cold condition, pre-chart, etc.?
• Content:
• Reflective description of behaviour.
• LSC concrete and abstract syntax.
• LSC semantics.

You are here.

– 20 – 2015-02-03 – main –

3/51

Course Map

– 20 – 2015-02-03 – main –

4/51

UML

Model Instances

N S W E

CD, SM S = (T, C, V, atr ), SM M = (ΣD

S , AS , →SM )

ϕ ∈ OCL expr CD, SD S , SD B = (QSD, q0, AS , →SD, FSD) π = (σ0, ε0)

(cons0,Snd0)

− − − − − − − − →

u0

(σ1, ε1)· · · wπ = ((σi, consi, Sndi))i∈N G = (N, E, f)

Mathematics

OD

UML

✔ ✔ ✔ ✔ ✔ ✘ ✘ ✘ ✘ ✔ ✔ ✔ ✔ ✔

Motivation: Reflective, Dynamic Descriptions of Behaviour

– 20 – 2015-02-03 – main –

5/51

Recall: Constructive vs. Reflective Descriptions

– 20 – 2015-02-03 – Sbehav –

6/51

[Harel, 1997] proposes to distinguish constructive and reflective descriptions:

• “A language is constructive if it contributes to the dynamic semantics of

the model. That is, its constructs contain information needed in executing the model or in translating it into executable code.” A constructive description tells how things are computed (which can then be desired or undesired).

• “Other languages are reflective or assertive, and can be used by the

system modeler to capture parts of the thinking that go into building the model – behavior included –, to derive and present views of the model, statically or during execution, or to set constraints on behavior in preparation for verification.” A reflective description tells what shall or shall not be computed. Note: No sharp boundaries!

Recall: What is a Requirement?

– 20 – 2015-02-03 – Sreflective –

7/51

Recall:

• The semantics of the UML model M = (C D, SM , OD) is the transition

system (S, − →, S0) constructed according to discard/dispatch/commence-rules.

• The computations of M, denoted by M, are the computations of (S, −

→, S0).

Now: A reflective description tells what shall or shall not be computed. More formally: a requirement ϑ is a property of computations; something which is either satisfied or not satisfied by a computation π = (σ0, ε0)

(cons0,Snd0)

− − − − − − − − → (σ1, ε1)

(cons1,Snd1)

− − − − − − − − → · · · ∈ M, denoted by π | = ϑ and π | = ϑ, resp. Simplest case: OCL constraint.

Live Sequence Charts — Concrete Syntax

– 20 – 2015-02-03 – main –

8/51

Example

– 20 – 2015-02-03 – Slscsyn –

9/51

LSC: L AC: actcond AM: invariant I: strict

Environment : LightsCtrl Operational [1, 3] : CrossingCtrl t(10) t : BarrierCtrl [1, 5] secreq lights on barrier down lights ok b a r r i e r

• k

¬MvUp done

• signal, env
• secreq

CrossingCtrl

lights ok()

• signal
• barrier down

barrier ok done LightsCtrl

Operational : Bool lights on()

BarrierCtrl

MvUp : Bool

1 1 1 1

Example: What Is Required?

– 20 – 2015-02-03 – Slscsyn –

10/51

LSC: L AC: actcond AM: invariant I: strict

Environment : LightsCtrl Operational [1, 3] : CrossingCtrl t(10) t : BarrierCtrl [1, 5] secreq lights on barrier down lights ok b a r r i e r

• k

¬MvUp done CrossingCtrl LightsCtrl BarrierCtrl

1 1 1 1

• Whenever the CrossingCtrl has consumed a ‘secreq’ event
• then it shall finally send ‘lights on’ and ‘barrier down’ to LightsCtrl and BarrierCtrl,
• if LightsCtrl is not ‘operational’ when receiving that event,

the rest of this scenario doesn’t apply; maybe there’s another LSC for that case.

• if LightsCtrl is ‘operational’ when receiving that event,

it shall reply with ‘lights ok’ within 1–3 time units,

• the BarrierCtrl shall reply with ‘barrier ok’ within 1–5 time units, during this time

(dispatch time not included) it shall not be in state ‘MvUp’,

• ‘lights ok’ and ‘barrier ok’ may occur in any order.
• After having consumed both, CrossingCtrl may reply with ‘done’ to the environment.

Building Blocks

– 20 – 2015-02-03 – Slscsyn –

11/51

LSC: L AC: actcond AM: invariant I: strict

Environment : LightsCtrl Operational [1, 3] : CrossingCtrl t(10) t : BarrierCtrl [1, 5] secreq lights on barrier down lights ok b a r r i e r

• k

¬MvUp done CrossingCtrl LightsCtrl BarrierCtrl

1 1 1 1

• Instance Lines:

Environment : C

Building Blocks

– 20 – 2015-02-03 – Slscsyn –

12/51

LSC: L AC: actcond AM: invariant I: strict

Environment : LightsCtrl Operational [1, 3] : CrossingCtrl t(10) t : BarrierCtrl [1, 5] secreq lights on barrier down lights ok b a r r i e r

• k

¬MvUp done CrossingCtrl LightsCtrl BarrierCtrl

1 1 1 1

• Messages: (asynchronous or synchronous/instantaneous)

a b

Building Blocks

– 20 – 2015-02-03 – Slscsyn –

13/51

LSC: L AC: actcond AM: invariant I: strict

Environment : LightsCtrl Operational [1, 3] : CrossingCtrl t(10) t : BarrierCtrl [1, 5] secreq lights on barrier down lights ok b a r r i e r

• k

¬MvUp done CrossingCtrl LightsCtrl BarrierCtrl

1 1 1 1

• Conditions and Local Invariants: (expr1, expr2, expr3 ∈ Expr S )

expr1 expr2 expr3

Intuitive Semantics: A Partial Order on Simclasses

– 20 – 2015-02-03 – Slscsyn –

14/51

(i) Strictly After:

a b a

(ii) Simultaneously: (simultaneous region)

a expr 1 b c

(iii) Explicitly Unordered: (co-region)

a b

Partial Order Requirements

– 20 – 2015-02-03 – Slscsyn –

15/51

LSC: L AC: actcond AM: invariant I: strict

Environment : LightsCtrl Operational [1, 3] : CrossingCtrl t(10) t : BarrierCtrl [1, 5] secreq lights on barrier down lights ok b a r r i e r

• k

¬MvUp done CrossingCtrl LightsCtrl BarrierCtrl

1 1 1 1

• Whenever the CrossingCtrl has consumed a ‘secreq’ event
• then it shall finally send ‘lights on’ and ‘barrier down’ to LightsCtrl and BarrierCtrl,
• if LightsCtrl is not ‘operational’ when receiving that event,

the rest of this scenario doesn’t apply; maybe there’s another LSC for that case.

• if LightsCtrl is ‘operational’ when receiving that event,

it shall reply with ‘lights ok’ within 1–3 time units,

• the BarrierCtrl shall reply with ‘barrier ok’ within 1–5 time units, during this time

(dispatch time not included) it shall not be in state ‘MvUp’,

• ‘lights ok’ and ‘barrier ok’ may occur in any order.
• After having consumed both, CrossingCtrl may reply with ‘done’ to the environment.

LSC Specialty: Modes

– 20 – 2015-02-03 – Slscsyn –

16/51

With LSCs,

• whole charts,
• locations, and
• elements

have a mode — one of hot or cold (graphically indicated by outline).

chart location message condition/ local inv. hot:

a b b p

cold:

a b b p

always vs. at least once must vs. may progress mustn’t vs. may get lost necessary vs. legal exit

Example: Modes

– 20 – 2015-02-03 – Slscsyn –

17/51

LSC: L AC: actcond AM: invariant I: strict

Environment : LightsCtrl Operational [1, 3] : CrossingCtrl t(10) t : BarrierCtrl [1, 5] secreq lights on barrier down lights ok b a r r i e r

• k

¬MvUp done CrossingCtrl LightsCtrl BarrierCtrl

1 1 1 1

• Whenever the CrossingCtrl has consumed a ‘secreq’ event
• then it shall finally send ‘lights on’ and ‘barrier down’ to LightsCtrl and BarrierCtrl,
• if LightsCtrl is not ‘operational’ when receiving that event,

the rest of this scenario doesn’t apply; maybe there’s another LSC for that case.

• if LightsCtrl is ‘operational’ when receiving that event,

it shall reply with ‘lights ok’ within 1–3 time units,

• the BarrierCtrl shall reply with ‘barrier ok’ within 1–5 time units, during this time

(dispatch time not included) it shall not be in state ‘MvUp’,

• ‘lights ok’ and ‘barrier ok’ may occur in any order.
• After having consumed both, CrossingCtrl may reply with ‘done’ to the environment.

LSC Specialty: Activation

– 20 – 2015-02-03 – Slscsyn –

18/51

One major defect of MSCs and SDs: they don’t say when the scenario has to/may be observed. LSCs: Activation condition (AC ∈ ExprS ), activation mode (AM ∈ {init, inv}), and pre-chart.

: C : D a b

LSC: L AC: expr AM: invariant I: strict

: C : D a b

LSC Specialty: Activation

– 20 – 2015-02-03 – Slscsyn –

18/51

One major defect of MSCs and SDs: they don’t say when the scenario has to/may be observed. LSCs: Activation condition (AC ∈ ExprS ), activation mode (AM ∈ {init, inv}), and pre-chart.

: C : D a b

LSC: L AC: expr AM: invariant I: strict

: C : D a b

Intuition: (universal case)

• given a computation π, whenever expr holds in a configuration (σi, εi) of ξ
• which is initial, i.e. k = 0, or

(AM = initial)

• whose k is not further restricted,

(AM = invariant) and if the pre-chart is observed from k to k + n, then the main-chart has to follow from k + n + 1.

Example: What Is Required?

– 20 – 2015-02-03 – Slscsyn –

19/51

LSC: L AC: actcond AM: invariant I: strict

Environment : LightsCtrl Operational [1, 3] : CrossingCtrl t(10) t : BarrierCtrl [1, 5] secreq lights on barrier down lights ok b a r r i e r

• k

¬MvUp done CrossingCtrl LightsCtrl BarrierCtrl

1 1 1 1

• Whenever the CrossingCtrl has consumed a ‘secreq’ event
• then it shall finally send ‘lights on’ and ‘barrier down’ to LightsCtrl and BarrierCtrl,
• if LightsCtrl is not ‘operational’ when receiving that event,

the rest of this scenario doesn’t apply; maybe there’s another LSC for that case.

• if LightsCtrl is ‘operational’ when receiving that event,

it shall reply with ‘lights ok’ within 1–3 time units,

• the BarrierCtrl shall reply with ‘barrier ok’ within 1–5 time units, during this time

(dispatch time not included) it shall not be in state ‘MvUp’,

• ‘lights ok’ and ‘barrier ok’ may occur in any order.
• After having consumed both, CrossingCtrl may reply with ‘done’ to the environment.

Live Sequence Charts — Semantics in a Nutshell

– 20 – 2015-02-03 – main –

20/51

Restricted Syntax

– 20 – 2015-02-03 – main –

21/51

x : y : z :

E F G

Restricted Abstract Syntax

– 20 – 2015-02-03 – main –

22/51

x : y : z :

E F G

(I, (L , ), ∼, S , Msg)

Cuts

– 20 – 2015-02-03 – main –

23/51

x : y : z :

E F G

l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1

• ∼

Firedsets

– 20 – 2015-02-03 – main –

24/51

x : y : z :

E F G

l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1

• ∼

Towards Automata

– 20 – 2015-02-03 – main –

25/51

x : y : z :

E F G

l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1

• ∼

Alphabet — Progress Transitions

– 20 – 2015-02-03 – main –

26/51

x : y : z :

E F G

l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1

• ∼

q1 q2 q3 q4 q5 q6 q7

E!

x,y

E?

x,y

F !

y,x

F ?

y,z ∧ ¬G?! y,x

G?!

y,x ∧ ¬F ? y,z

G?!

y,x

F ?

y,z

F ?

y,z ∧ G?! y,x

Loops

– 20 – 2015-02-03 – main –

27/51

x : y : z :

E F G

l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1

• ∼

q1 q2 q3 q4 q5 q6 q7

E!

x,y

E?

x,y

F !

y,x

F ?

y,z ∧ ¬G?! y,x

G?!

y,x ∧ ¬F ? y,z

G?!

y,x

F ?

y,z

F ?

y,z ∧ G?! y,x

¬E!

x,y

¬E?

x,y

¬F !

y,x

¬(F ?

y,z ∨ G?! y,x)

¬G?!

y,x

¬F ?

y,z

true

Language

– 20 – 2015-02-03 – main –

28/51

x : y : z :

E F G

l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1

• ∼

q1 q2 q3 q4 q5 q6 q7

E!

x,y

E?

x,y

F !

y,x

F ?

y,z ∧ ¬G?! y,x

G?!

y,x ∧ ¬F ? y,z

G?!

y,x

F ?

y,z

F ?

y,z ∧ G?! y,x

¬E!

x,y

¬E?

x,y

¬F !

y,x

¬(F ?

y,z ∨ G?! y,x)

¬G?!

y,x

¬F ?

y,z

true

You are here.

– 20 – 2015-02-03 – main –

29/51

Course Map

– 20 – 2015-02-03 – main –

30/51

UML

Model Instances

N S W E

CD, SM S = (T, C, V, atr ), SM M = (ΣD

S , AS , →SM )

ϕ ∈ OCL expr CD, SD S , SD B = (QSD, q0, AS , →SD, FSD) π = (σ0, ε0)

(cons0,Snd0)

− − − − − − − − →

u0

(σ1, ε1)· · · wπ = ((σi, consi, Sndi))i∈N G = (N, E, f)

Mathematics

OD

UML

✔ ✔ ✔ ✔ ✔ ✘ ✔ ✔ ✘ ✔ ✔ ✔ ✔ ✔

Language of a Model

– 20 – 2015-02-03 – main –

31/51

Words over Signature

– 20 – 2015-02-03 – Smodellang –

32/51

• Definition. Let S = (T, C, V, atr , E ) be a signature and D a

structure of S . A word over S and D is an infinite sequence (σi, consi, Sndi)i∈N0 ∈

• ΣD

S × 2D(C )×Evs(E ,D)×D(C ) × 2D(C )×Evs(E ,D)×D(C )ω

.

The Language of a Model

– 20 – 2015-02-03 – Smodellang –

33/51

Recall: A UML model M = (C D, SM , OD) and a structure D denotes a set M of (initial and consecutive) computations of the form (σ0, ε0) a0 − → (σ1, ε1) a1 − → (σ2, ε2) a2 − → . . . where ai = (consi, Sndi, ui) ∈ 2D(C )×Evs(E ,D)×D(C ) × 2D(C )×Evs(E ,D)×D(C )

• =: ˜

A

×D(C ). For the connection between models and interactions, we disregard the configuration of the ether and who made the step, and define as follows:

• Definition. Let M = (C D, SM , OD) be a UML model and D a
• structure. Then

L(M) := {(σi, consi, Sndi)i∈N0 ∈ (ΣD

S × ˜

A)ω | ∃ (εi, ui)i∈N0 : (σ0, ε0)

(cons0,Snd0)

− − − − − − − − →

u0

(σ1, ε1) · · · ∈ M} is the language of M.

Example: The Language of a Model

– 20 – 2015-02-03 – Smodellang –

34/51

L(M) := {(σi, consi, Snd i)i∈N0 ∈ (ΣD

S × ˜

A)ω | ∃ (εi, ui)i∈N0 : (σ0, ε0)

(cons0,Snd0)

− − − − − − − − →

u0

(σ1, ε1) · · · ∈ M}

Signal and Attribute Expressions

– 20 – 2015-02-03 – Smodellang –

35/51

• Let S = (T, C, V, atr , E ) be a signature and X a set of logical variables,
• The signal and attribute expressions Expr S (E , X) are defined by the

grammar: ψ ::= true | expr | E!

x,y | E? x,y | ¬ψ | ψ1 ∨ ψ2,

where expr : Bool ∈ Expr S , E ∈ E , x, y ∈ X.

Satisfaction of Signal and Attribute Expressions

– 20 – 2015-02-03 – Smodellang –

36/51

• Let (σ, cons, Snd) ∈ ΣD

S × ˜

A be a triple consisting of system state, consume set, and send set.

• Let β : X → D(C ) be a valuation of the logical variables.

Then

• (σ, cons, Snd) |

=β true

• (σ, cons, Snd) |

=β ¬ψ if and only if not (σ, cons, Snd) | =β ψ

• (σ, cons, Snd) |

=β ψ1 ∨ ψ2 if and only if (σ, cons, Snd) | =β ψ1 or (σ, cons, Snd) | =β ψ2

• (σ, cons, Snd) |

=β expr if and only if Iexpr(σ, β) = 1

• (σ, cons, Snd) |

=β E!

x,y if and only if ∃

d • (β(x), (E, d), β(y)) ∈ Snd

• (σ, cons, Snd) |

=β E?

x,y if and only if ∃

d • (β(x), (E, d), β(y)) ∈ cons Observation: semantics of models keeps track of sender and receiver at sending and consumption time. We disregard the event identity. Alternative: keep track of event identities.

TBA over Signature

– 20 – 2015-02-03 – Smodellang –

37/51

• Definition. A TBA

B = (ExprB(X), X, Q, qini, →, QF) where ExprB(X) is the set of signal and attribute expressions ExprS (E , X) over signature S is called TBA over S .

• Any word over S and D is then a word for B.

(By the satisfaction relation defined on the previous slide; D(X) = D(C ).)

• Thus a TBA over S accepts words of models with signature S .

(By the previous definition of TBA.)

TBA over Signature Example

– 20 – 2015-02-03 – Smodellang –

38/51 (σ, cons, Snd) | =β expr iff Iexpr(σ, β) = 1; (σ, cons, Snd) | =β E!

x,y iff (β(x), (E,

d), β(y)) ∈ Snd

q1 q2 q3 q4 q5 q6 q7

E!

x,y

E?

x,y

F !

y,x

F ?

y,z ∧ ¬G?! y,x

G?!

y,x ∧ ¬F ? y,z

G?!

y,x

F ?

y,z

F ?

y,z ∧ G?! y,x

¬E!

x,y

¬E?

x,y

¬F !

y,x

¬(F ?

y,z ∨ G?! y,x)

¬G?!

y,x

¬F ?

y,z

true

Activation, Chart Mode

– 20 – 2015-02-03 – main –

39/51

Activation Condition

– 20 – 2015-02-03 – main –

40/51

x : y : z :

E F G

Universal vs. Existential Charts

– 20 – 2015-02-03 – main –

41/51

x : y : z :

E F G

Prechart

– 20 – 2015-02-03 – main –

42/51

x : y : z :

E F G

Conditions

– 20 – 2015-02-03 – main –

43/51

Conditions

– 20 – 2015-02-03 – main –

44/51

q1 q2 q3 q4 q5 q6 q7

E!

x,y

E?

x,y

F !

y,x

F ?

y,z ∧ ¬G?! y,x

G?!

y,x ∧ ¬F ? y,z

G?!

y,x

F ?

y,z

F ?

y,z ∧ G?! y,x

¬E!

x,y

¬E?

x,y

¬F !

y,x

¬(F ?

y,z ∨ G?! y,x)

¬G?!

y,x

¬F ?

y,z

true

Back to UML: Interactions

– 20 – 2015-02-03 – main –

45/51

Model Consistency wrt. Interaction

– 20 – 2015-02-03 – Sinteract –

46/51

• We assume that the set of interactions I is partitioned into two (possibly

empty) sets of universal and existential interactions, i.e. I = I∀ ˙ ∪ I∃.

• Definition. A model

M = (C D, SM , OD, I ) is called consistent (more precise: the constructive description of behaviour is consistent with the reflective one) if and only if ∀ I ∈ I∀ : L(M) ⊆ L(I) and ∀ I ∈ I∃ : L(M) ∩ L(I) = ∅.

Interactions as Reflective Description

– 20 – 2015-02-03 – Sinteract –

47/51

• In UML, reflective (temporal) descriptions are subsumed by interactions.
• A UML model M = (C D, SM , OD, I ) has a set of interactions I .
• An interaction I ∈ I can be (OMG claim: equivalently) diagrammed as
• sequence diagram,

timing diagram, or

• communication diagram (formerly known as collaboration diagram).

Figure 14.26 - Sequence Diagram with time and timing concepts sd UserAccepted

:User :ACSystem Code d=duration CardOut {0..13} OK Unlock {d..3*d} t=now {t..t+3}

DurationConstraint TimeObservation TimeConstraint DurationObservation

[OMG, 2007b, 513]

Figure 14.27 - Communication diagram sd M :r s[k]:B s[u]:B 1a:m1 2:m2 1b:m3 1b.1:m3 1b.1.1:m3, 1b.1.1.1:m2

Lifeline Message with Sequence number Messages

[OMG, 2007b, 515]

Figure 14.30 - Compact Lifeline with States sd UserAcc_User

Idle WaitCard WaitAccess Idle {d..3*d} :User

State or condition Lifeline DurationConstraint

[OMG, 2007b, 522]

Figure 14.31 - Timing Diagram with more than one Lifeline and with Messages sd UserAccepted

Idle WaitCard WaitAccess {t..t+3} {d..3*d} :User 1 2 t HasCard NoCard :ACSystem Code CardOut {0..13} OK Unlock d t=now

State or condition Lifelines Duration Observation Duration Constraints Time Observation Time Constraint Message

[OMG, 2007b, 522]

Figure 14.28 - Interaction Overview Diagram representing a High Level Interaction diagram

sd OverviewDiagram lifelines :User, :ACSystem ref EstablishAccess("Illegal PIN") sd :User :ACSystem CardOut sd :User :ACSystem Msg("Please Enter") ref OpenDoor

[pin ok]

InteractionUse (inline) Interaction decision interaction constraint Duration Constraint

[OMG, 2007b, 518]

Interactions as Reflective Description

– 20 – 2015-02-03 – Sinteract –

47/51

• In UML, reflective (temporal) descriptions are subsumed by interactions.
• A UML model M = (C D, SM , OD, I ) has a set of interactions I .
• An interaction I ∈ I can be (OMG claim: equivalently) diagrammed as
• sequence diagram,

timing diagram, or

• communication diagram (formerly known as collaboration diagram).

Figure 14.26 - Sequence Diagram with time and timing concepts sd UserAccepted

:User :ACSystem Code d=duration CardOut {0..13} OK Unlock {d..3*d} t=now {t..t+3}

DurationConstraint TimeObservation TimeConstraint DurationObservation

[OMG, 2007b, 513]

Figure 14.27 - Communication diagram sd M :r s[k]:B s[u]:B 1a:m1 2:m2 1b:m3 1b.1:m3 1b.1.1:m3, 1b.1.1.1:m2

Lifeline Message with Sequence number Messages

[OMG, 2007b, 515]

Figure 14.30 - Compact Lifeline with States sd UserAcc_User

Idle WaitCard WaitAccess Idle {d..3*d} :User

State or condition Lifeline DurationConstraint

[OMG, 2007b, 522]

Figure 14.31 - Timing Diagram with more than one Lifeline and with Messages sd UserAccepted

Idle WaitCard WaitAccess {t..t+3} {d..3*d} :User 1 2 t HasCard NoCard :ACSystem Code CardOut {0..13} OK Unlock d t=now

State or condition Lifelines Duration Observation Duration Constraints Time Observation Time Constraint Message

[OMG, 2007b, 522]

Figure 14.28 - Interaction Overview Diagram representing a High Level Interaction diagram

sd OverviewDiagram lifelines :User, :ACSystem ref EstablishAccess("Illegal PIN") sd :User :ACSystem CardOut sd :User :ACSystem Msg("Please Enter") ref OpenDoor

[pin ok]

InteractionUse (inline) Interaction decision interaction constraint Duration Constraint

[OMG, 2007b, 518]

Figure 9.11 - The internal structure of the Observer collaboration shown inside the collaboration icon (a connection is shown between the Subject and the Observer role). Observer Observer : SlidingBarIcon Subject : CallQueue

[OMG, 2007b, 170]

Figure 9.12 - In the Observer collaboration two roles, a Subject and an Observer, collaborate to produce the desired

• behavior. Any instance playing the Subject role must possess the properties specified by CallQueue, and similarly for

the Observer role. Observer SlidingBarIcon Observer CallQueue Subject queue: List of Call source: Object waitAlarm: Alarm reading: Real color: Color range: Interval Observer.reading = length (Subject.queue) capacity: Integer Observer.range = (0 .. Subject.capacity)

[OMG, 2007b, 170]

Why Sequence Diagrams?

– 20 – 2015-02-03 – Sinteract –

48/51

Most Prominent: Sequence Diagrams — with long history:

• Message Sequence Charts, standardized by the ITU in different versions,
• ften accused to lack a formal semantics.
• Sequence Diagrams of UML 1.x

Most severe drawbacks of these formalisms:

• unclear interpretation:

example scenario or invariant?

• unclear activation:

what triggers the requirement?

• unclear progress requirement:

must all messages be observed?

• conditions merely comments
• no means to express

forbidden scenarios

LSC: L AC: actcond AM: invariant I: strict

Environment : LightsCtrl Operational [1, 3] : CrossingCtrl t(10) t : BarrierCtrl [1, 5] secreq lights on barrier down lights ok barrier ok ¬MvUp done

Thus: Live Sequence Charts

– 20 – 2015-02-03 – Sinteract –

49/51

• SDs of UML 2.x address some issues, yet the standard exhibits unclarities

and even contradictions [Harel and Maoz, 2007, St¨

• rrle, 2003]
• For the lecture, we consider Live Sequence Charts (LSCs)

[Damm and Harel, 2001, Klose, 2003, Harel and Marelly, 2003], who have a common fragment with UML 2.x SDs [Harel and Maoz, 2007]

• Modelling guideline: stick to that fragment.

References

– 20 – 2015-02-03 – main –

50/51

– 20 – 2015-02-03 – main –

51/51

[Damm and Harel, 2001] Damm, W. and Harel, D. (2001). LSCs: Breathing life into Message Sequence Charts. Formal Methods in System Design, 19(1):45–80. [Harel, 1997] Harel, D. (1997). Some thoughts on statecharts, 13 years later. In Grumberg, O., editor, CAV, volume 1254 of LNCS, pages 226–231. Springer-Verlag. [Harel and Maoz, 2007] Harel, D. and Maoz, S. (2007). Assert and negate revisited: Modal semantics for UML sequence diagrams. Software and System Modeling (SoSyM). To appear. (Early version in SCESM’06, 2006, pp. 13-20). [Harel and Marelly, 2003] Harel, D. and Marelly, R. (2003). Come, Let’s Play: Scenario-Based Programming Using LSCs and the Play-Engine. Springer-Verlag. [Klose, 2003] Klose, J. (2003). LSCs: A Graphical Formalism for the Specification of Communication Behavior. PhD thesis, Carl von Ossietzky Universit¨ at Oldenburg. [OMG, 2007a] OMG (2007a). Unified modeling language: Infrastructure, version 2.1.2. Technical Report formal/07-11-04. [OMG, 2007b] OMG (2007b). Unified modeling language: Superstructure, version 2.1.2. Technical Report formal/07-11-02. [St¨

• rrle, 2003] St¨
• rrle, H. (2003). Assert, negate and refinement in UML-2
• interactions. In J¨

urjens, J., Rumpe, B., France, R., and Fernandez, E. B., editors, CSDUML 2003, number TUM-I0323. Technische Universit¨ at M¨ unchen.