Lecture 17: Live Sequence Charts I 2016-01-21 Prof. Dr. Andreas - PowerPoint PPT Presentation

Software Design, Modelling and Analysis in UML Lecture 17: Live Sequence Charts I 2016-01-21 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal – 17 – 2016-01-21 – main – Albert-Ludwigs-Universit¨ at Freiburg, Germany

Contents & Goals Last Lecture: • Hierarchical state machines: the rest • Deferred events • Passive reactive objects This Lecture: • Educational Objectives: Capabilities for following tasks/questions. • What are constructive and reflective descriptions of behaviour? • What are UML Interactions? • What is the abstract syntax of this LSC? • How is the semantics of LSCs constructed? • What is a cut, fired-set, etc.? – 17 – 2016-01-21 – Sprelim – • Content: • Rhapsody code generation • Interactions: Live Sequence Charts • LSC syntax • Towards semantics 2 /45

A Closer Look to Rhapsody Code Generation – 17 – 2016-01-21 – main – 3 /45

– 17 – 2016-01-21 – main – 4 /45

– 17 – 2016-01-21 – main – You are here. 5 /45

Course Map N UML W E CD , SM ϕ ∈ OCL CD , SD S ✔ ✔ ✘ ✔ Model S = ( T , C , V, atr ) , SM expr S , SD ✘ ✔ ✔ ✔ M = (Σ D S , A S , → SM ) B = ( Q SD , q 0 , A S , → SD , F SD ) ✘ ✔ ✔ ( cons 0 , Snd 0 ) π = ( σ 0 , ε 0 ) − − − − − − − − → ( σ 1 , ε 1 ) · · · w π = (( σ i , cons i , Snd i )) i ∈ N Instances u 0 ✘ ✔ Mathematics G = ( N, E, f ) – 17 – 2016-01-21 – main – ✔ OD UML 6 /45

Reflective Descriptions of Behaviour – 17 – 2016-01-21 – main – 7 /45

Requirements Recall : • The semantics of the UML model M = ( C D , S M , OD ) is the transition system ( S, − → , S 0 ) constructed according to discard/dispatch/continue/etc.-rules. • The computations of M , denoted by � M � , are the computations of ( S, − → , S 0 ) . A requirement ϑ is a property of computations; something which is either satisfied or not satisfied by a computation ( cons 0 , Snd 0 ) ( cons 1 , Snd 1 ) π = ( σ 0 , ε 0 ) − − − − − − − − → ( σ 1 , ε 1 ) − − − − − − − − → · · · ∈ � M � , u 1 u 2 denoted by π | = ϑ and π �| = ϑ , resp. We write M | = ϑ if and only if ∀ π ∈ � M � • π | = ϑ . – 17 – 2016-01-21 – Sreflective – Simplest case : OCL constraint viewed as invariant . But how to formalise “if a user enters 50 cent and then (later) presses the water button (while there is water in stock), then (even later) the vending machine will dispense water”? 8 /45

Constructive vs. Reflective Descriptions 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. – 17 – 2016-01-21 – Sreflective – Note : No sharp boundaries! (Would be too easy.) 9 /45

Interactions as Reflective Description • 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 • communication diagram (formerly known as collaboration diagram), • timing diagram , or • sequence diagram . Lifeline State or condition DurationConstraint Lifeline sd UserAccepted sd M sd UserAcc_User 1a:m1 Message :User :ACSystem {d..3*d} with DurationObservation :r s[k]:B Sequence number DurationConstraint Code d= duration :User Idle WaitAccess WaitCard Idle Messages 1b:m3 2:m2 {d..3*d} 1b.1:m3 1b.1.1:m3, TimeConstraint CardOut {0..13} 1b.1.1.1:m2 t= now OK Figure 14.30 - Compact Lifeline with States (OMG, 2007, 522) {t..t+3} Unlock s[u]:B TimeObservation Lifelines State or condition Duration Constraints – 17 – 2016-01-21 – Sinteract – (OMG, 2007, 515) Figure 14.26 - Sequence Diagram with time and timing concepts (OMG, 2007, 513) Figure 14.27 - Communication diagram sd UserAccepted {d..3*d} WaitAccess :User Time Constraint WaitCard {t..t+3} CardOut {0..13} Idle OK Message Code :ACSystem NoCard Duration Observation Unlock HasCard t=now d Time Observation 0 1 2 t (OMG, 2007, 522) Figure 14.31 - Timing Diagram with more than one Lifeline and with Messages 10 /45

Interactions as Reflective Description • 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 • communication diagram (formerly known as collaboration diagram), • timing diagram , or • sequence diagram . sd OverviewDiagram lifelines :User, :ACSystem InteractionUse ref EstablishAccess("Illegal PIN") Lifeline State or condition DurationConstraint Duration Constraint {0..25} Lifeline sd UserAccepted sd M sd sd UserAcc_User 1a:m1 Message (inline) Interaction :User :ACSystem {d..3*d} with :User :ACSystem DurationObservation :r s[k]:B Sequence CardOut number DurationConstraint Code d= duration :User Idle WaitAccess WaitCard Idle Messages 1b:m3 2:m2 {d..3*d} 1b.1:m3 1b.1.1:m3, TimeConstraint CardOut {0..13} 1b.1.1.1:m2 decision t= now OK Figure 14.30 - Compact Lifeline with States (OMG, 2007, 522) {t..t+3} Unlock s[u]:B interaction constraint [pin ok] TimeObservation Lifelines State or condition Duration Constraints – 17 – 2016-01-21 – Sinteract – sd (OMG, 2007, 515) Figure 14.26 - Sequence Diagram with time and timing concepts (OMG, 2007, 513) Figure 14.27 - Communication diagram sd UserAccepted :User :ACSystem {d..3*d} Msg("Please Enter") WaitAccess :User Time Constraint WaitCard {t..t+3} CardOut {0..13} Idle ref OpenDoor OK Message Code {1..14} :ACSystem NoCard Duration Observation Unlock HasCard (OMG, 2007, 518) Figure 14.28 - Interaction Overview Diagram representing a High Level Interaction diagram t=now d Time Observation 0 1 2 t (OMG, 2007, 522) Figure 14.31 - Timing Diagram with more than one Lifeline and with Messages 10 /45

Why Sequence Diagrams? Most Prominent : Sequence Diagrams — with long history : • Message Sequence Charts , standardized by the ITU in different versions, often 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? User CoinValidator ChoicePanel Dispenser C 50 • unclear progress requirement: must all messages be observed? p W A T E R – 17 – 2016-01-21 – Sinteract – • conditions merely comments water in stock • no means to express d W A T E R forbidden scenarios K O 11 /45

Thus: Live Sequence Charts • SDs of UML 2.x address some issues, yet the standard exhibits unclarities and even contradictions Harel and Maoz (2007); St¨ orrle (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. LSC: buy water AC: true AM: invariant I: strict User CoinValidator ChoicePanel Dispenser C 50 ¬ ( C50 ! ∨ E1 ! ∨ pSOFT ! – 17 – 2016-01-21 – Sinteract – pWATER ∨ pTEA ! ∨ pFILLUP ! water in stock dWATER ¬ ( dSoft ! ∨ dTEA !) OK 12 /45

Live Sequence Charts — Syntax – 17 – 2016-01-21 – main – 13 /45

LSC Body: Abstract Syntax : C 1 : C 2 : C 3 Let Θ = { hot , cold } . An LSC body is a tuple A v = 0 ( I, ( L , � ) , ∼ , S , Msg , Cond , LocInv ) B C x > 3 • I is a finite set of instance lines , D E • ( L , � ) is a finite, non-empty, partially ordered set of locations ; each l ∈ L is associated with a temperature θ ( l ) ∈ Θ and an instance line i l ∈ I , • ∼⊆ L × L is an equivalence relation on locations, the simultaneity relation, – 17 – 2016-01-21 – Slscasyn – 14 /45