Lecture 14: Architecture and Design Patterns L 6: 18.5., Mo - PowerPoint PPT Presentation

Contents of the Block “Design” Contents & Goals (i) Introduction and Vocabulary L 1: 20.4., Mo Introduction Last Lecture: T 1: 23.4., Do (ii) Principles of Design L 2: 27.4., Mo Development • Networks of CFA, Tool Demo (recording will be reconstructed), Implementable CFA L 3: 30.4., Do a) modularity Process, Metrics Softwaretechnik / Software-Engineering L 4: 4.5., Mo b) separation of concerns T 2: 7.5., Do This Lecture: c) information hiding and data encapsulation L 5: 11.5., Mo d) abstract data types, object orientation - 14.5., Do • Educational Objectives: Capabilities for following tasks/questions. Lecture 14: Architecture and Design Patterns L 6: 18.5., Mo Requirements (iii) Software Modelling L 7: 21.5., Do • What is the relation between greedy and standard semantics? Engineering - 25.5., Mo • What is an Uppaal Query for, e.g., “location ℓ is reachable”? a) views and viewpoints, the 4+1 view - 28.5., Do T 3: 1.6., Mo b) model-driven/based software engineering • What’s the difference between CFA and UML State-Machines? - 4.6., Do c) Unified Modelling Language (UML) • Can each network of UML State-Machines be encoded in CFA? L 8: 8.6., Mo 2015-07-02 d) modelling structure L 9: 11.6., Do • Explain an example of an architecture (design) pattern. L 10: 15.6., Mo 1. (simplified) class diagrams T 4: 18.6., Do • What is “software entropy”? 2. (simplified) object diagrams L 11: 22.6., Mo 3. (simplified) object constraint logic (OCL) Architecture & – 14 – 2015-07-02 – Scontents – L 12: 25.6., Do Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Design, Software – 14 – 2015-07-02 – Sprelim – • Content: e) modelling behaviour L 13: 29.6., Mo – 14 – 2015-07-02 – main – Modelling L 14: 2.7., Do 1. communicating finite automata • Implementable CFA Cont’d T 5: 6.7., Mo 2. Uppaal query language Albert-Ludwigs-Universit¨ at Freiburg, Germany L 15: 9.7., Do • Uppaal Query Language Quality Assurance 3. basic state-machines L 16: 13.7., Mo 4. an outlook on hierarchical state-machines Invited Talks L 17: 16.7., Do • UML State-Machines T 6: 20.7., Mo (iv) Design Patterns • Architecture and Design Patterns (with examples) Wrap-Up L 18: 23.7., Do 2 /51 3 /51 Recall: Implementable CFA Recall: Greedy CFA Semantics • Let each automaton in the network C ( A 1 , . . . , A n ) be marked as • Greedy semantics: either environment or controller . • each input synchronisation transition (plus: system start) of automaton A is followed We call C implementable if and only if, for each controller A in C , by a maximal sequence of internal transitions or output transitions of A . (i) A is deterministic, • Maximal : cannot be extended by an internal transition. (ii) A reads/writes only its local variables, There may still be interleaving of the internal transitions, but (by forbidding shared may also read variables written by environment automata, Implementing CFA Cont’d variables for controllers) cannot be observed outside of an automaton. but only in modification vectors of edges with input synchronisation, (iii) A is locally deadlock-free , i.e. enabled edges with output-actions are not blocked forever. Example : • The communicating finite automaton A = ( L, B, V, E, ℓ ini ) A 1 : E? F! G? E : is called deterministic if and only if v := v_env n := n + 1 v_env < 10 • for each location ℓ , A 2 , 2 : A 2 , 1 : v_env := v_env + 1 E! G! F! • either all edges with ℓ as source location have pairwise different input actions , F? G! v_env > -10 v_env := v_env - 1 • or there is no edge with an input action starting at ℓ , and all edges starting at ℓ have pairwise (logically) disjoint guards. – 14 – 2015-07-02 – Simplcont – – 14 – 2015-07-02 – Simplcont – – 14 – 2015-07-02 – main – • A 1 is implementable in C ( A 1 , A 2 , 1 , E ) (environment: only E ) • Note : implementable (i) and (ii) can be checked syntactically. • deterministic: ✔ , Property (iii) is a property of the whole network. • only local variables, environment variables with input: ✔ , Can be checked with Uppaal: • locally deadlock-free: ✔ . → ( A .ℓ ′ ) ( A .ℓ ∧ ϕ ) − • A 1 is not implementable in C ( A 1 , A 2 , 2 , E ) . for each edge ( ℓ, α, ϕ,� r, ℓ ′ ) of A . 4 /51 5 /51 6 /51

water_selected Recall: Implementing CFA WATER? Model vs. Implementation water_enabled DWATER! idle soft_selected request_sent SOFT? DSOFT! • Now an implementable model C ( A 1 , . . . , A n ) has two semantics : soft_enabled • � C � std — standard semantics. DTEA! TEA? DOK? tea_enabled • � C � grd — greedy semantics. tea_selected OK! water_enabled := false, • Are they related in any way? They are: � C � std ⊇ � C � grd . ( ∗ ) Uppaal Query Language soft_enabled := false, half_idle tea_enabled := false Exercise : prove ( ∗ ) . (Larsen et al., 1997; Behrmann et al., 2004) { idle, wsel, ssel, tsel, reqs, half } ; st : • What effect does this insight have on Uppaal verification results? take event( E : { TAU, WATER, SOFT, TEA, ... } ) { bool stable = 1; • If there is an error in � C � std , will it be in a correct implementation (of � C � grd )? switch (st) { case idle : Not necessarily. switch (E) { case WATER : • If there is no error in � C � std , will a correct implementation (of � C � grd ) be error-free? if (water enabled) { st := wsel; stable := 0; } Yes, definitely. ;; – 14 – 2015-07-02 – Simplcont – – 14 – 2015-07-02 – Simplcont – case SOFT : Uppaal verification ... shows no error reports error – 14 – 2015-07-02 – main – } false negative true positive case wsel: switch (E) { impl. has error yes case TAU : send DWATER(); st := reqs; true negative false positive ;; } } no 7 /51 8 /51 9 /51 The Uppaal Query Language Satisfaction of Uppaal Queries by Configurations Satisfaction of Uppaal Queries by Configurations • The satisfaction relation Exists finally : Consider N = C ( A 1 , . . . , A n ) over data variables V . � � ℓ, ν � | = F • � � ∃ path ξ of C starting in � � ℓ 0 , ν 0 � | = ∃ ♦ term iff ℓ 0 , ν 0 � • basic formula : ∃ i ∈ N 0 • ξ i | atom ::= A i .ℓ | ϕ | deadlock = term between configurations � � ℓ, ν � = � ( ℓ 1 , . . . , ℓ n ) , ν � where ℓ ∈ L i is a location and ϕ an expression over V . “some configuration satisfying term is reachable” of a network C ( A 1 , . . . , A n ) and formulae F of the Uppaal logic • configuration formulae : is defined inductively as follows: term ::= atom | not term | term 1 and term 2 Example : ∃ ♦ ϕ • existential path formulae : (“ exists finally ”, “ exists globally ”) • � � � � ℓ, ν � | = deadlock iff ℓ 0 ,i is a dedlock configuration ℓ 0 , ν 0 � ¬ ϕ e - formula ::= ∃ ♦ term | ∃ � term • � � ℓ, ν � | = A i .ℓ iff ℓ 0 ,i = ℓ λ 1 λ 2 • universal path formulae : (“ always finally ”, “ always globally ”, “ leads to ”) • � � ¬ ϕ ¬ ϕ ℓ, ν � | = ϕ iff ν | = ϕ a - formula ::= ∀ ♦ term | ∀ � term | term 1 --> term 2 – 14 – 2015-07-02 – Suppaal – – 14 – 2015-07-02 – Suppaal – – 14 – 2015-07-02 – Suppaal – λ 2 , 1 λ 2 , 2 λ 1 , 1 � � • � � iff � � ℓ, ν � • formulae (or queries ): ℓ, ν � | = not term ℓ, ν � �| = term ¬ ϕ ¬ ϕ ϕ . . . . λ 2 , 2 , 1 λ 2 , 2 , 2 • � � iff � � . . F ::= e - formula | a - formula ℓ, ν � | = term 1 and term 2 ℓ, ν � | = term i , i = 1 , 2 ¬ ϕ ¬ ϕ . . . . . . 10 /51 11 /51 12 /51