Softwaretechnik / Software-Engineering Lecture 15: UML State Machines & Software Quality Assurance 2018-07-02 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universität Freiburg, Germany – 15 – 2018-07-02 – main –
Topic Area Architecture & Design: Content • Introduction and Vocabulary VL 11 • Software Modelling . . • model; views / viewpoints; 4+1 view . • Modelling structure • (simplified) class & object diagrams VL 12 . . • (simplified) object constraint logic (OCL) . VL 13 • Principles of Design • modularity, separation of concerns • information hiding and data encapsulation . . • abstract data types, object orientation . • Design Patterns VL 14 • Modelling behaviour . • communicating finite automata (CFA) . . • Uppaal query language VL 15 • CFA vs. Software – 15 – 2018-07-02 – Sblockcontent – . • Model-driven/-based Software Engineering . . • Unified Modelling Language (UML) • basic and hierarchical state-machines 2 /67
Content I (Architecture & Design) • CFA vs. Software • a CFA model is software • CFA at Work • drive to configuration, scenarios, invariants • tool demo (verifier). • Model-based/-driven Software Engineering • Unified Modelling Language • Brief History • Sub-Languages • UML Modes • UML State Machines • Hierarchical State Machines • Core State Machines • steps and run-to-completion steps – 15 – 2018-07-02 – Scontent – • Rhapsody 3 /67
– 15 – 2018-07-02 – main – CFA vs. Software 4 /67
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} . – 15 – 2018-07-02 – Scfasw – • Note : the structural model just consists of the set of variables and the locations of C . 5 /67
Example: Software Specification Alphabet : • M – dispense cash only, http://commons.wikimedia.org (CC-by-sa 4.0, Dirk Ingo Franke) • C – return card only, M • – dispense cash and return card. C • Customer : “I don’t care about the order of M and C ” � � � � ω � M � � S 1 = M.C � C.M C • Refined Specification : “be consistent: either always M.C or always C.M ” S 2 = ( M.C ) ω or ( C.M ) ω • Design Idea : “consider human errors: always do C.M ” S 1 = ( C.M ) ω – 15 – 2018-07-02 – Scfasw – • Implementation (goal): software S 2 behaves according to the design idea. 6 /67
Formal Methods in the Software Development Process Mmmh, Software! validate Customer 2 Requirements analyse � S 1 � = { ( M.C, � · � 1 ) , ( C.M, � · � 1 ) } 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 – 15 – 2018-07-02 – Scfasw – � S 2 � = { σ 2 → σ 2 → σ 2 1 2 − − − − 2 · · · , . . . } analyse 0 1 7 /67
CFA and Queries at Work – 15 – 2018-07-02 – main – 8 /67
Example: Vending Machine — Model Architecture water_selected WATER? water_enabled DWATER! idle soft_selected request_sent SOFT? DSOFT! soft_enabled C50, E1 CoinValidator User DTEA! TEA? DOK? tea_enabled WATER, SOFT, TEA tea_selected OK! water_enabled := false, OK soft_enabled := false, half_idle tea_enabled := false DOK ChoicePanel SYSTEM ENVIRONMENT DWATER DTEA DSOFT WaterDispenser SoftDispenser TeaDispenser Service FILLUP • Shared variables : • bool water_enabled, soft_enabled, tea_enabled; • int w = 3, s = 3, t = 3; – 15 – 2018-07-02 – Scfaatwork – • Note : Our model does not use scopes (“information hiding”) for channels. That is, ‘Service’ could send ‘WATER’ if the modeler wanted to. 9 /67
Design Sanity Check: Drive to Configuration • Question : Is is (at all) possible to have no water in the vending machine model? (Otherwise, the design is definitely broken.) • Approach : Check whether a configuration satisfying w = 0 is reachable, i.e. check N VM | = ∃ ♦ w = 0 . for the vending machine model N VM . – 15 – 2018-07-02 – Scfaatwork – 10 /67
Design Check: Scenarios • Question : Is the following existential LSC satisfied by the model? (Otherwise, the design is definitely broken.) LSC: buy tea AC: true AM: initial I: permissive User Coin Validator Choice Panel C 50 C 50 ¬ E1 ! C 50 TEA • Approach : Use the following newly created CFA ‘Scenario’ C50! C50! C50! TEA! end_of_scenario instead of User and check whether location end_of_scenario is reachable, i.e. check N ′ VM | = ∃ ♦ Scenario . end_of_scenario . – 15 – 2018-07-02 – Scfaatwork – for the modified vending machine model N ′ VM . 11 /67
Design Verification: Invariants • Question : Is it the case that the “tea” button is only enabled if there is e 1.50 in the machine? (Otherwise, the design is broken.) • Approach : Check whether the implication tea _ enabled = ⇒ CoinValidator . have_c150 holds in all reachable configurations, i.e. check N VM | = ∀ � tea _ enabled CoinValidator . have_c150 imply for the vending machine model N VM . 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) have_c100 have_c150 E1? – 15 – 2018-07-02 – Scfaatwork – tea_enabled := (t > 0) OK? OK? OK? OK? drink_ready 12 /67
Design Verification: Sanity Check • Question : Is the “tea” button ever enabled? (Otherwise, the considered invariant ⇒ CoinValidator . have_c150 tea _ enabled = holds vacuously.) • Approach : Check whether a configuration satisfying water _ enabled = 1 is reachable. Exactly like we did with w = 0 earlier. – 15 – 2018-07-02 – Scfaatwork – 13 /67
Design Verification: 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) have_c100 have_c150 E1? – 15 – 2018-07-02 – Scfaatwork – tea_enabled := (t > 0) OK? OK? OK? OK? drink_ready 14 /67
Recall: Universal LSC Example LSC: buy water AC: true AM: invariant I: strict User CoinValidator ChoicePanel Dispenser C 5 0 ¬ ( C50 ! ∨ E1 ! ∨ pSOFT ! p ∨ pTEA ! ∨ pFILLUP !) W A T E R water _ in _ stock d W A T E R ¬ ( dSoft ! ∨ dTEA !) K O – 15 – 2018-07-02 – Scfaatwork – 15 /67
Content I (Architecture & Design) • CFA vs. Software • a CFA model is software • CFA at Work • drive to configuration, scenarios, invariants • tool demo (verifier). • Model-based/-driven Software Engineering • Unified Modelling Language • Brief History • Sub-Languages • UML Modes • UML State Machines • Hierarchical State Machines • Core State Machines • steps and run-to-completion steps – 15 – 2018-07-02 – Scontent – • Rhapsody 16 /67
Model-based/-driven Software Engineering – 15 – 2018-07-02 – main – 17 /67
– 15 – 2018-07-02 – Smdse – 18 /67
Model-Driven Software Engineering • (Jacobson et al., 1992): “System development is model building.” • Model based software engineering (MBSE): some (formal) models are used. • Model driven software engineering (MDSE): all artefacts are (formal) models. Idea elicit � requirements Structure Declarative �� model Behaviour � refine � requirements/ refine Declarative �� constraints Behaviour ′ � = ? | � Structure ′ Constructive �� design Behaviour � = ? refine refine | � Structure ′′ Constructive �� system model Behaviour ′ � generate/ program – 15 – 2018-07-02 – Smdse – Implementation 19 /67
– 15 – 2018-07-02 – Smdse – 20 /67
Development Approaches task, problem outside-in user interface top-down bottom-up inside-out system software, hardware • top-down risk: needed functionality hard to realise on target platform. • bottom-up risk: lower-level units do not “fit together”. • inside-out risk: user interface needed by customer hard to realise with existing system, • outside-in risk: elegant system design not reflected nicely in (already fixed) UI. – 15 – 2018-07-02 – Smdse – 21 /67
Transform vs. Write-Down-and-Check – 15 – 2018-07-02 – Smdse – 22 /67
Recommend
More recommend
