Softwaretechnik / Software-Engineering Lecture 14: UML State Machines & Software Quality Assurance 2017-07-10 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universität Freiburg, Germany – 14 – 2017-07-10 – main –
Topic Area Architecture & Design: Content • Introduction and Vocabulary VL 10 • Software Modelling I . (i) views and viewpoints, the 4+1 view . . (ii) model-driven/-based software engineering (iii) Modelling structure VL 11 a) (simplified) class diagrams . . . b) (simplified) object diagrams c) (simplified) object constraint logic (OCL) VL 12 d) Unified Modelling Language (UML) • Principles of Design . (i) modularity, separation of concerns . . (ii) information hiding and data encapsulation (iii) abstract data types, object orientation (iv) Design Patterns • Software Modelling II VL 13 (i) Modelling behaviour . . a) communicating finite automata . – 14 – 2017-07-10 – Sblockcontent – b) Uppaal query language c) basic state-machines VL 14 . d) an outlook on hierarchical state-machines . . • Testing : Introduction 2 /61
Content I (Architecture & Design) • CFA vs. Software • a CFA model is software • implementing CFA • formal methods in the real world: case study • UML State Machines • Core State Machines • steps and run-to-completion steps • Hierarchical State Machines • Rhapsody • Unified Modelling Language • Brief History • Sub-Languages • UML Modes – 14 – 2017-07-10 – Scontent – 3 /61
Recall: CFA, Queries, Model-Checking Example Satisfaction of Uppaal Queries by Con � gurations water_selected WATER? water_enabled DWATER! Exists finally : ChoicePanel : idle soft_selected request_sent • h ~ � path � of N starting in h ~ SOFT? DSOFT! � 0 , � 0 i | = � � term iff � 0 , � 0 i (simplified) � i � N 0 • � i | soft_enabled = term DTEA! User : TEA? “some configuration satisfying term is reachable” DOK? WATER! C50! l tea_enabled tea_selected SOFT! OK! E1! Example : h ~ � 0 , � 0 i | = � � � TEA! water_enabled := false, soft_enabled := false, half_idle h ~ tea_enabled := false � 0 , � 0 i ¬ � � 1 � 2 ¬ � ¬ � � 2 , 1 � 2 , 2 � 1 , 1 h ~ � , � i ¬ � ¬ � � . . . . � 2 , 2 , 1 � 2 , 2 , 2 . . – 13 – 2017-07-06 – Suppaal – ¬ � ¬ � . . – 13 – 2017-07-06 – Scfa – . . . . 27 /55 37 /55 Design Veri � cation: Another Invariant • Question : Is it the case that, if there is money in the machine and water in stock, that the “water” button is enabled? • Approach : Check N VM | = � � ( CoinValidator . have_c50 or CoinValidator . have_c100 or CoinValidator . have_c150 ) imply water _ enabled . have_e1 E1? C50? soft_enabled := (s > 0) water_enabled := (w > 0), tea_enabled := (t > 0) idle have_c50 C50? C50? C50? water_enabled := (w>0) soft_enabled := (s > 0) tea_enabled := (t > 0) – 14 – 2017-07-10 – Srecall – have_c100 have_c150 – 13 – 2017-07-06 – Scfaatwork – E1? tea_enabled := (t > 0) OK? OK? OK? OK? drink_ready 49 /55 4 /61
– 14 – 2017-07-10 – main – CFA vs. Software 5 /61
A CFA Model Is Software Definition. Software is a finite description S of a (possibly infinite) set � S � of (finite or infinite) computation paths of the form α 1 α 2 σ 0 − → σ 1 − → σ 2 · · · where • σ i ∈ Σ , i ∈ N 0 , is called state (or configuration ), and • α i ∈ A , i ∈ N 0 , is called action (or event ). The (possibly partial) function � · � : S �→ � S � is called interpreta- tion of S . • Let C ( A 1 , . . . , A n ) be a network of CFA. • Σ = Conf • A = Act λ 1 λ 2 λ 3 • � C � = { π = � � → � � → � � ℓ 0 , ν 0 � − − ℓ 1 , ν 1 � − − ℓ 2 , ν 2 � − − → · · · | π is a computation path of C} . • Note : the structural model just consists of the set of variables and the locations of C . – 14 – 2017-07-10 – Scfasw – 6 /61
Formal Methods in the Software Development Process Mmmh, Software! validate Customer 2 Requirements � S 1 � = { ( M.C, � · � 1 ) , ( C.M, � · � 1 ) } analyse Development Process/ Project verify Management Design � S 2 � = { ( M.T M .C, � · � 1 ) , ( C.T C .M, � · � 1 ) } analyse α 1 α 1 � S 1 � = { σ 1 → σ 1 → σ 1 1 2 − − − − 2 · · · , . . . } 0 1 verify Implementation α 2 α 2 � S 2 � = { σ 2 → σ 2 → σ 2 – 14 – 2017-07-10 – Scfasw – 1 2 − − − − 2 · · · , . . . } analyse 0 1 7 /61
Content I (Architecture & Design) • CFA vs. Software • a CFA model is software • implementing CFA • formal methods in the real world: case study • UML State Machines • Core State Machines • steps and run-to-completion steps • Hierarchical State Machines • Rhapsody • Unified Modelling Language • Brief History • Sub-Languages • UML Modes – 14 – 2017-07-10 – Scontent – 8 /61
– 14 – 2017-07-10 – main – Implementing CFA 9 /61
Implementing CFA • Now that we have a CFA model C ( A 1 , . . . , A n ) ( thoroughly checked using Uppaal), we would like to have executable software — an implementation of the model. • This task can be split into two sub-tasks: (i) implement each CFA A i in the model by module S A i , (ii) implement the communication in the network by module S C . (This has, by now, been provided implicitly by the Uppaal simulator and verifier .) S C calls A 1 A 2 ... A n – 14 – 2017-07-10 – Simpl – • Fully distributed implementation (without S C ): different story, possible for sub-class of CFA. 10 /61
Communication / Synchronisation • Let N = C ( A 1 , . . . , A n ) with pairwise disjoint variables . • Assume B = B input ˙ ∪ B internal , where B input are dedicated input channels , i.e. there is no edge with action a ! and a ∈ B input . • Then software S N consists of S A 1 , . . . , S A n and the following S C . Set � Act � R 1 := R 1 , ini , ..., R n := R n, ini ; / / initially enabled actions void main () { do � true : ( α, snd , rcv ) := select ( R 1 , . . . , R n ); / / choose synchronisation / / ( rcv = 0 if α = τ, / / blocks on deadlock ) for ( k = 1 to n ) if � snd = k : R k := take _ action k ( α ) / / sender � rcv = k : R k := take _ action k (¯ α ) / / receiver fi / / snapshot od } – 14 – 2017-07-10 – Simpl – 11 /61
Example FILLUP? w := 3 Wi int w := 3; w > 0 FILLUP? DWATER? typedef { Wi , dispense , W0 } st _ T ; DOK! w := 3 w := w - 1 st _ T st := Wi ; w == 0 Set � Act � take _ action ( Act α ) { DOK! Set � Act � R := ∅ ; dispense W0 if � st = Wi : if w := w − 1; � α = DWATER ? : st := dispense ; if ( w = 0) R := R ∪ { DOK ! } ; if ( w > 0) R := R ∪ { DOK ! } ; � α = FILLUP ? : w := 3; st := Wi ; R := R ∪ { FILLUP ? , DWATER ? } ; fi ; � st = dispense : if � α = DOK ! ∧ w = 0 : st := W0 ; R := R ∪ { FILLUP ? } ; � α = DOK ! ∧ w > 0 : st := Wi ; R := R ∪ { FILLUP ? } ; fi ; � st = W0 : if � α = FILLUP ? : w := 3; st := Wi ; R := R ∪ { FILLUP ? , DWATER ? } ; fi ; – 14 – 2017-07-10 – Simpl – fi ; return R ; } 12 /61
Translation Scheme. . . ... for A = ( { ℓ 1 , . . . , ℓ m } , B, { v 1 , . . . , v k } , E, ℓ ini ) with r 1 , 1 , ℓ ′ r 1 ,n 1 , ℓ ′ E = { ( ℓ 1 , α 1 , 1 , ϕ 1 , 1 , � 1 , 1 ) , . . . , ( ℓ 1 , α 1 ,n 1 , ϕ 1 ,n 1 , � 1 ,n 1 ) , . . . r m, 1 , ℓ ′ r m,nm , ℓ ′ ( ℓ m , α m, 1 , ϕ m, 1 , � m, 1 ) , . . . , ( ℓ m , α m,nm , ϕ m,nm , � m,nm ) } : T 1 v 1 := v 1 , ini ; ... T k v k := v k, ini ; typedef { ℓ 1 , . . . , ℓ m } st _ T ; st _ T st := ℓ ini ; Set � Act � take _ action ( Act α ) { Set � Act � R := ∅ ; if . . . � st = ℓ i : if . . . � α = α i,j ∧ ϕ i,j : � r i,j ; st := ℓ ′ i,j ; if ( ℓ ′ i,j = ℓ 1 ∧ ϕ 1 , 1 ) R := R ∪ { α 1 , 1 } ; . . . if ( ℓ ′ i,j = ℓ m ∧ ϕ m,n m ) R := R ∪ { α m,n m } ; . . . fi ; . – 14 – 2017-07-10 – Simpl – . . fi ; return R ; } 13 /61
Deterministic CFA Definition. A network of CFA C with (joint) alphabet B is called deterministic if and only if each reachable configuration has at most one successor configuration, i.e. if ∀ c ∈ Conf ( C ) reachable ∀ λ ∈ B !? ∪ { τ } ∀ c 1 , c 2 ∈ Conf ( C ) • λ λ c − → c 1 ∧ c − → c 2 = ⇒ c 1 = c 2 . Proposition. Whether C is deterministic is decidable . Proposition. If C is deterministic, then the translation of C is a deterministic program . – 14 – 2017-07-10 – Simpl – 14 /61
Model vs. Implementation α 1 α 2 • Define � S N � to be the set of computation paths σ 0 − − → σ 1 − − → σ 2 · · · such that σ i has the values at ‘ snapshot ’ at the i -th iteration and α i is the i -th action. • Then � S N � bisimulates the behaviour � C � of model C ( A 1 , . . . , A n ) . FILLUP? w := 3 Wi idle have_c50 water_selected C50? WATER? w > 0 FILLUP? DWATER? DOK! w := 3 C50! WATER! w := w - 1 DOK? DWATER! w == 0 DOK! FILLUP! half_idle dispense W0 – 14 – 2017-07-10 – Simpl – 15 /61
Recommend
More recommend
