Software Design, Modelling and Analysis in UML

Software Design, Modelling and Analysis in UML Lecture 09: Constructive Behaviour, State Machines Overview – 09 – 2011-12-14 – main – 2011-12-14 Pr...
Author: Astrid Neumann
0 downloads 1 Views 363KB Size
Software Design, Modelling and Analysis in UML Lecture 09: Constructive Behaviour, State Machines Overview

– 09 – 2011-12-14 – main –

2011-12-14

Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universit¨at Freiburg, Germany

Contents & Goals Last Lecture: • Completed discussion of modelling structure.

This Lecture: • Educational Objectives: Capabilities for following tasks/questions. • Discuss the style of this class diagram. • What’s the difference between reflective and constructive descriptions of behaviour? • What’s the purpose of a behavioural model? • What does this State Machine mean? What happens if I inject this event?

– 09 – 2011-12-14 – Sprelim –

• Can you please model the following behaviour. • Content: • Purposes of Behavioural Models • Constructive vs. Reflective • UML Core State Machines (first half) 2/75

– 09 – 2011-12-14 – main –

Modelling Behaviour

3/75

Stocktaking... Have: Means to model the structure of the system. • Class diagrams graphically, concisely describe sets of system states. • OCL expressions logically state constraints/invariants on system states.

Want: Means to model behaviour of the system. • Means to describe how system states evolve over time,

that is, to describe sets of sequences σ0 , σ1 , · · · ∈ Σω

– 09 – 2011-12-14 – Sbehav –

of system states.

4/75

Course Map N

UML CD, SM

Model



ϕ ∈ OCL

!

S

= (T , C , V, atr ), SM



!

S

S , SD

expr



B = (QSD , q0 , AS , →SD , FSD )

!

✔ Instances

CD, SD

E



(ΣD S , AS , →SM ) = M

– 09 – 2011-12-14 – Sbehav –

W

(cons 0 ,Snd 0 )

(cons 1 ,Snd 1 )

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



G = (N, E, f )



OD

Mathematics

UML 5/75

Constructive UML UML provides two visual formalisms for constructive description of behaviours: • Activity Diagrams • State-Machine Diagrams

We (exemplary) focus on State-Machines because • somehow “practice proven” (in different flavours), • prevalent in embedded systems community, • indicated useful by [Dobing and Parsons, 2006] survey, and • Activity Diagram’s intuition changed (between UML 1.x and 2.x) from transition-system-like to petri-net-like...

– 09 – 2011-12-14 – Sbehav –

• Example state machine:

s1

E[n 6= ∅]/x := x + 1; n ! F

F/x := 0

s3

s2

/n := ∅ 8/75

– 09 – 2011-12-14 – main –

UML State Machines: Overview

9/75

UML State Machines s1

E[n 6= ∅]/x := x + 1; n ! F

F/x := 0

s3

s2

/n := ∅

Brief History: • Rooted in Moore/Mealy machines, Transition Systems • [Harel, 1987]: Statecharts as a concise notation, introduces in particular hierarchical states.

– 09 – 2011-12-14 – Sstmover –

• Manifest in tool Statemate [Harel et al., 1990] (simulation, code-generation); nowadays also in Matlab/Simulink, etc. • From UML 1.x on: State Machines (not the official name, but understood: UML-Statecharts) • Late 1990’s: tool Rhapsody with code-generation for state machines.

Note: there is a common core, but each dialect interprets some constructs subtly different [Crane and Dingel, 2007]. (Would be too easy otherwise. . . ) 10/75

Roadmap: Chronologically (i) What do we (have to) cover? UML State Machine Diagrams Syntax. (ii) Def.: Signature with signals.

N

UML

(iii) Def.: Core state machine.

Semantics: The Basic Causality Model

Model

(iv) Map UML State Machine Diagrams ✔ to core state machines.

– 09 – 2011-12-14 – Sstmover –

(viii) Def.: Transformer.

CD, SD

S



= (T , C , V, atr ), SM



!

S , SD

expr



(ΣD S , AS , →SM ) = M

B = (QSD , q0 , AS , →SD , FSD )

!

✔ Instances

(vii) Def.: Event.

ϕ ∈ OCL

!

S

(v) Def.: Ether (aka. event pool) (vi) Def.: System configuration.

CD, SM

W

(cons 0 ,Snd 0 )

(cons 1 ,Snd 1 )

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



Mathematics

G = (N, E, f )



(ix) Def.: Transition system, computation.

OD

UML

(x) Transition relation induced by core state machine. (xi) Def.: step, run-to-completion step. (xii) Later: Hierarchical state machines.

11/75

UML State Machines s1

E[n 6= ∅]/x := x + 1; n ! F

F/x := 0

s3

s2

/n := ∅

Brief History: • Rooted in Moore/Mealy machines, Transition Systems • [Harel, 1987]: Statecharts as a concise notation, introduces in particular hierarchical states.

– 09 – 2011-12-14 – Sstmover –

• Manifest in tool Statemate [Harel et al., 1990] (simulation, code-generation); nowadays also in Matlab/Simulink, etc. • From UML 1.x on: State Machines (not the official name, but understood: UML-Statecharts) • Late 1990’s: tool Rhapsody with code-generation for state machines.

Note: there is a common core, but each dialect interprets some constructs subtly different [Crane and Dingel, 2007]. (Would be too easy otherwise. . . ) 12/75

Roadmap: Chronologically (i) What do we (have to) cover? UML State Machine Diagrams Syntax. (ii) Def.: Signature with signals.

N

UML

(iii) Def.: Core state machine.

Semantics: The Basic Causality Model

Model

(iv) Map UML State Machine Diagrams ✔ to core state machines.

– 09 – 2011-12-14 – Sstmover –

(viii) Def.: Transformer.



S

!

S , SD

expr



(ΣD S , AS , →SM ) = M

B = (QSD , q0 , AS , →SD , FSD )

!



(ix) Def.: Transition system, computation.

CD, SD



= (T , C , V, atr ), SM

Instances

(vii) Def.: Event.

ϕ ∈ OCL

!

S

(v) Def.: Ether (aka. event pool) (vi) Def.: System configuration.

CD, SM

W

(cons 0 ,Snd 0 )

(cons 1 ,Snd 1 )

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



G = (N, E, f )



OD

Mathematics

UML

(x) Transition relation induced by core state machine. (xi) Def.: step, run-to-completion step. (xii) Later: Hierarchical state machines.

13/75

– 09 – 2011-12-14 – main –

UML State Machines: Syntax

14/75

UML State-Machines: What do we have to cover? [St¨ orrle, 2005]

PA Client

[ true ] / [ausstehendeAufrufe = ausstehendeAufrufe @pre + 1 ] anmelden()/

abgemeldet

angemeldet abmelden()/

Wenn der Endzustand eines Zustandsautomaten erreicht wird, wird die Region beendet, in der der Endzustand liegt.

[ ausstehendeAufrufe>1 ] empfangeErgebnisse(nr, parameter) / [ausstehendeAufrufe = ausstehendeAufrufe @pre - 1]

Protokollzustandsautomaten beschreiben das Verhalten von Softwaresystemen, Nutzfällen oder technischen Geräten. Ein komplexer Zustand mit einer Region.

Der Anfangszustand markiert den voreingestellten Startpunkt von „Boarding“ bzw. „Bordkarte einlesen“.

ZA Boarding

when(Drehkreuzsensor=”drehen”) / Drehkreuz blockieren

Bordkarte einlesen Validität überprüfen [ valide ] after(10s) /timeout

Passagier überprüfen

Bordkarte akzeptieren

entry/Suchanfrage starten do/Anzeigelämpchen blinkt

entry/Karte auswerfen do/Drehkreuz freigeben

Ergebnis der Suchanfrage liegt vor

ut eo tim

Bordkarte zurückweisen

aussetzen H

Der Gedächtniszustand sorgt dafür, dass nach dem Wiederaufnehmen der gleiche Zustand wie vor dem Aussetzen eingenommen wird.

[ Passagier nicht angemeldet ]

warten

wieder aufnehmen

Der Austrittspunkt erlaubt es, von einem definierten inneren Zustand aus den Oberzustand zu verlassen.

ZA Boardingautomat (HW)

ZA Kartenleser Auch Zeit- und Änderungsereignisse können Zustandsübergänge auslösen:

after(10s) / Drehkreuz blockieren [ Passagier angemeldet ]

Passagier identifizieren

Das Zeitereignis after(10s) löst einen Abbruch von „Bordkarte einlesen“ aus.

– 09 – 2011-12-14 – Sstmsyn –

Ein Eintrittspunkt definiert, dass ein komplexer Zustand an einer anderen Stelle betreten wird, als durch den Anfangszustand definiert ist.

Reguläre Beendigung löst ein completion-Ereignis aus.

Passagier-ID auslesen

drehkreuz leer

- after definiert das Verstreichen eines Intervalls; - when definiert einen Zustandswechsel.

when(k=1)/ “Karte liegt an”

Zustände und zeitlicher Bezugsrahmen werden über den umgebenden Classifier definiert, hier die Werte der Ports, siehe das Montagediagramm „Abfertigung“ links oben.

“Karte laden” / setze(f,1)

an/

gesperrt

when(k=0)/

“Drehkreuz freigeben” / setze(s,0)

“Karte zurückweisen” / setze(f,-1)

bereit

“Drehkreuz blockieren” / setze(s,1)

freigegeben “Karte auswerfen” / setze(f,1)

when(d>0) / “Kreuz dreht sich” aus/

belegt

Kartenleser

“Karte auslesen” / inhalt = i

when(k=0) / setze(f,0)

Die Zustandsübergänge von Protokoll-Zustandsautomaten verfügen über eine Vorbedingung, einen Auslöser und eine Nachbedingung (alle optional) – jedoch nicht über einen Effekt.

Ein Zustand löst von sich aus bestimmte Ereignisse aus: - entry beim Betreten; - do während des Aufenthaltes; - completion beim Erreichen des Endzustandes einer Unter-Zustandsmaschine - exit beim Verlassen. Diese und andere Ereignisse können als Auslöser für Aktivitäten herangezogen werden. Ein Zustand kann eine oder mehrere Regionen enthalten, die wiederum Zustandsautomaten enthalten können. Wenn ein Zustand mehrere Regionen enthält, werden diese in verschiedenen Abteilen angezeigt, die durch gestrichelte Linien voneinander getrennt sind. Regionen können benannt werden. Alle Regionen werden parallel zueinander abgearbeitet. Wenn ein Regionsendzustand erreicht wird, wird der gesamte komplexe Zustand beendet, also auch alle parallelen Regionen. Ein verfeinerter Zustand verweist auf einen Zustandsautomaten (angedeutet von dem Symbol unten links), der

15/75

UML State-Machines: What do we have to cover? [St¨ orrle, 2005]

PA Client

[ true ] / [ausstehendeAufrufe = ausstehendeAufrufe @pre + 1 ] anmelden()/

abgemeldet

angemeldet abmelden()/

Wenn der Endzustand eines Zustandsautomaten erreicht wird, wird die Region beendet, in der der Endzustand liegt.

[ ausstehendeAufrufe>1 ] empfangeErgebnisse(nr, parameter) / [ausstehendeAufrufe = ausstehendeAufrufe @pre - 1]

Protokollzustandsautomaten beschreiben das Verhalten von Softwaresystemen, Nutzfällen oder technischen Geräten. Ein komplexer Zustand mit einer Region.

Reguläre Beendigung löst ein completion-Ereignis aus.

Ein Eintrittspunkt definiert, dass ein komplexer Zustand an einer anderen Stelle betreten wird, als durch den Anfangszustand definiert ist.

ZA Boarding

when(Drehkreuzsensor=”drehen”) / Drehkreuz blockieren

Bordkarte einlesen Proven approach: Validität überprüfen [ valide ]

Passagier überprüfen

Bordkarte akzeptieren

entry/Suchanfrage starten do/Anzeigelämpchen blinkt

entry/Karte auswerfen do/Drehkreuz freigeben

Start out simple, consider the essence, namely

Der Anfangszustand markiert den voreingestellten Startpunkt von „Boarding“ bzw. „Bordkarte einlesen“.

after(10s) /timeout

Passagier-ID auslesen

• basic/leaf states Passagier identifizieren

• transitions,

Das Zeitereignis after(10s) löst einen Abbruch von „Bordkarte einlesen“ aus.

ut eo tim

Ergebnis der Suchanfrage liegt vor

after(10s) / Drehkreuz blockieren [ Passagier angemeldet ]

aussetzen H

wieder aufnehmen

[ Passagier nicht angemeldet ]

warten

Bordkarte zurückweisen

then extend to cover the complicated rest.

– 09 – 2011-12-14 – Sstmsyn –

Der Gedächtniszustand sorgt dafür, dass nach dem Wiederaufnehmen der gleiche Zustand wie vor dem Aussetzen eingenommen wird.

Der Austrittspunkt erlaubt es, von einem definierten inneren Zustand aus den Oberzustand zu verlassen.

ZA Boardingautomat (HW)

ZA Kartenleser Auch Zeit- und Änderungsereignisse können Zustandsübergänge auslösen:

drehkreuz leer

- after definiert das Verstreichen eines Intervalls; - when definiert einen Zustandswechsel.

when(k=1)/ “Karte liegt an”

Zustände und zeitlicher Bezugsrahmen werden über den umgebenden Classifier definiert, hier die Werte der Ports, siehe das Montagediagramm „Abfertigung“ links oben.

“Karte laden” / setze(f,1)

an/ when(k=0)/

gesperrt “Drehkreuz freigeben” / setze(s,0)

“Karte zurückweisen” / setze(f,-1)

bereit

“Drehkreuz blockieren” / setze(s,1)

freigegeben “Karte auswerfen” / setze(f,1)

when(d>0) / “Kreuz dreht sich” aus/

belegt when(k=0) / setze(f,0)

“Karte auslesen” / inhalt = i

Die Zustandsübergänge von Protokoll-Zustandsautomaten verfügen über eine Vorbedingung, einen Auslöser und eine Nachbedingung (alle optional) – jedoch nicht über einen Effekt.

Kartenleser

Ein Zustand löst von sich aus bestimmte Ereignisse aus: - entry beim Betreten; - do während des Aufenthaltes; - completion beim Erreichen des Endzustandes einer Unter-Zustandsmaschine - exit beim Verlassen. Diese und andere Ereignisse können als Auslöser für Aktivitäten herangezogen werden. Ein Zustand kann eine oder mehrere Regionen enthalten, die wiederum Zustandsautomaten enthalten können. Wenn ein Zustand mehrere Regionen enthält, werden diese in verschiedenen Abteilen angezeigt, die durch gestrichelte Linien voneinander getrennt sind. Regionen können benannt werden. Alle Regionen werden parallel zueinander abgearbeitet. Wenn ein Regionsendzustand erreicht wird, wird der gesamte komplexe Zustand beendet, also auch alle parallelen Regionen. Ein verfeinerter Zustand verweist auf einen Zustandsautomaten (angedeutet von dem Symbol unten links), der

15/75

Signature With Signals Definition. A tuple

S

= (T , C , V, atr , E ),

E

a set of signals,

is called signature (with signals) if and only if (T , C ∪ E , V, atr ) is a signature (as before).

– 09 – 2011-12-14 – Sstmsyn –

Note: Thus conceptually, a signal is a class and can have attributes of plain type and associations.

16/75

Core State Machine Definition. A core state machine over signature S = (T , C , V, atr , E ) is a tuple M = (S, s0 , →) where • S is a non-empty, finite set of (basic) states, • s0 ∈ S is an initial state, • and

→ ⊆ S × (E ∪ { }) × Expr S × Act S ×S | {z } | {z } | {z }

– 09 – 2011-12-14 – Sstmsyn –

trigger

guard

action

is a labelled transition relation. We assume a set Expr S of boolean expressions over S (for instance OCL, may be something else) and a set Act S of actions. 17/75

From UML to Core State Machines: By Example UML state machine diagram SM: annot

s1

annot ::=



hevent i[ ‘.’ heventi]∗

s2

[ ‘[’ hguard i ‘]’ ]

[ ‘/’ hactioni]



with • event ∈ E ,

• guard ∈ Expr S

(default: true, assumed to be in Expr S )

– 09 – 2011-12-14 – Sstmsyn –

• action ∈ Act S

(default: skip, assumed to be in Act S )

maps to  M (SM) = {s1 , s2 }, s1 , (s1 , event, guard , action, s2 ) {z } | {z } |{z} | S

s0



18/75

Annotations and Defaults in the Standard Reconsider the syntax of transition annotations:  annot ::= heventi[ ‘.’ heventi]∗ [ ‘[’ hguard i ‘]’ ]

[ ‘/’ hactioni]



and let’s play a bit with the defaults: / E/ / act E / act

[true] [true] E [true] [true] E [true]

/ / / / /

skip skip skip act act

– 09 – 2011-12-14 – Sstmsyn –

In the standard, the syntax is even more elaborate: • E(v) — when consuming E in object u, attribute v of u is assigned the corresponding attribute of E. • E(v : τ ) — similar, but v is a local variable, scope is the transition 19/75

State-Machines belong to Classes • In the following, we assume that a UML models consists of a set C D of class diagrams and a set SM of state chart diagrams (each comprising one state machines SM). • Furthermore, we assume each that each state machine SM ∈ SM is associated with a class CSM ∈ C (S ). • For simplicity, we even assume a bijection, i.e. we assume that each class C ∈ C (S ) has a state machine SMC and that its class CSMC is C. If not explicitly given, then this one: SM0 := ({s0 }, s0 , (s0 , , true, skip, s0 )).

– 09 – 2011-12-14 – Sstmsyn –

We’ll see later that, semantically, this choice does no harm. • Intuition 1: SMC describes the behaviour of the instances of class C. Intuition 2: Each instance of class C executes SMC .

Note: we don’t consider multiple state machines per class. Because later (when we have AND-states) we’ll see that this case can be viewed as a single state machine with as many AND-states. 20/75

– 09 – 2011-12-14 – main –

References

74/75

References [Crane and Dingel, 2007] Crane, M. L. and Dingel, J. (2007). UML vs. classical vs. rhapsody statecharts: not all models are created equal. Software and Systems Modeling, 6(4):415–435. [Dobing and Parsons, 2006] Dobing, B. and Parsons, J. (2006). How UML is used. Communications of the ACM, 49(5):109–114. [Harel, 1987] Harel, D. (1987). Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3):231–274. [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.

– 09 – 2011-12-14 – main –

[Harel and Gery, 1997] Harel, D. and Gery, E. (1997). Executable object modeling with statecharts. IEEE Computer, 30(7):31–42. [Harel et al., 1990] Harel, D., Lachover, H., et al. (1990). Statemate: A working environment for the development of complex reactive systems. IEEE Transactions on Software Engineering, 16(4):403–414. [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. 75/75