Lecture 14: UML State Machines 2016-06-30 Prof. Dr. Andreas - PDF document

Softwaretechnik / Software-Engineering Lecture 14: UML State Machines 2016-06-30 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universität Freiburg, Germany – 14 – 2016-06-30 – main – Topic Area Architecture & Design: Content • Introduction and Vocabulary VL 11 • Principles of Design (i) modularity (ii) separation of concerns (iii) information hiding and data encapsulation . (iv) abstract data types, object orientation . . • Software Modelling (i) views and viewpoints, the 4+1 view (ii) model-driven/-based software engineering (iii) Unified Modelling Language (UML) VL 12 (iv) modelling structure . a) (simplified) class diagrams . . b) (simplified) object diagrams c) (simplified) object constraint logic (OCL) VL 13 (v) modelling behaviour . a) communicating finite automata . . b) Uppaal query language c) implementing CFA VL 14 . d) an outlook on UML State Machines . . – 14 – 2016-06-30 – Sblockcontent – • Design Patterns VL 15 . . • Testing : Introduction . 2 /38

Content • CFA at Work continued • design checks and verification • Uppaal architecture • case study • CFA vs. Software • a CFA model is software • implementing CFA • Recall MDSE • UML State Machines • Core State Machines • steps and run-to-completion steps • Hierarchical State Machines • Rhapsody • UML Modes – 14 – 2016-06-30 – Scontent – 3 /38 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 . – 14 – 2016-06-30 – Scfaatworkrest – 4 /38

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 ′ – 14 – 2016-06-30 – Scfaatworkrest – VM | = ∃ ♦ Scenario . end_of_scenario . for the modified vending machine model N ′ VM . 5 /38 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 ⇒ CoinValidator . have_c150 tea _ enabled = 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 – 14 – 2016-06-30 – Scfaatworkrest – E1? tea_enabled := (t > 0) OK? OK? OK? OK? drink_ready 6 /38

Design Verification: Sanity Check • Question : Is the “tea” button ever enabled? (Otherwise, the considered invariant tea _ enabled = ⇒ CoinValidator . have_c150 holds vacuously.) • Approach : Check whether a configuration satisfying water _ enabled = 1 is reachable. Exactly like we did with w = 0 earlier. – 14 – 2016-06-30 – Scfaatworkrest – 7 /38 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 – 14 – 2016-06-30 – Scfaatworkrest – E1? tea_enabled := (t > 0) OK? OK? OK? OK? drink_ready 8 /38

Recall: Universal LSC Example LSC: buy water AC: true AM: invariant I: strict User CoinValidator ChoicePanel Dispenser C 50 ¬ ( C50 ! ∨ E1 ! ∨ pSOFT ! pWATER ∨ pTEA ! ∨ pFILLUP !) water _ in _ stock dWATER ¬ ( dSoft ! ∨ dTEA !) OK – 14 – 2016-06-30 – Scfaatworkrest – 9 /38 Uppaal Architecture Java .xml .trc .q server C++ verifyta – 14 – 2016-06-30 – Suppaalarch – yes / no /don’t know 10 /38

Case Study: Wireless Fire Alarm System errorDetected channel gO � Sensor / gO � Repeater Switcher gBlockedChannel Jammer Media . . . (Arenis et al., 2014) TX Channels RX Channels �$�������!� ������������� !�"! Components ���� (�"�!'!"$ ��������� ��!)��� ������������$������*!� ������������������ ������������������� ������'��� . . . ��������+���� !�"! * ����",-�.���� ������������� !�"!�#�������$ �������+� ��!)��� �������������������&�� FrameTimer Master ��������+����% !�"! ��������������������� �������������% !�"!�#�������$ ����������� ��!%��� ������������������&�� channelLZ, ... ������'!"$ * ����",-�.���� ��������+����������� SlotTimer ��������+�� ��!%��� ��������+����� !�"! �������������� !�"!�#�������$ ChanRot �������������������� �������������������� Frame Timers Window !��"�'!"$ * ����",-�.���� ���!'��� �$�������!� (R1) The loss of the ability of the system to transmit a signal from a component to the central unit is detected in less than 300 seconds [...]. � i ∈ C � ( ⌈ FAIL = i ∧ ¬ DET i ⌉ = ⇒ ℓ ≤ 300 s ) – 14 – 2016-06-30 – Scfawfas – (R2) A single alarm event is displayed at the central unit within 10 seconds . � i ∈ C ⌈ ALARM { i } ⌉ = ⇒ � ( ⌈ ALARM i ∧ ¬ DISP i ⌉ = ⇒ ℓ ≤ 10 s ) , 11 /38 Content • CFA at Work continued • design checks and verification • Uppaal architecture • case study • CFA vs. Software • a CFA model is software • implementing CFA • Recall MDSE • UML State Machines • Core State Machines • steps and run-to-completion steps • Hierarchical State Machines • Rhapsody • UML Modes – 14 – 2016-06-30 – Scontent – 12 /38

CFA vs. Software – 14 – 2016-06-30 – main – 13 /38 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} . – 14 – 2016-06-30 – Scfasw – • Note : the structural model just consists of the set of variables and the locations of C . 14 /38

Model-Driven Software Engineering • (Jacobson et al., 1992): “System development is model building.” • Model driven software engineering (MDSE): everything is a model. • Model based software engineering (MBSE): some models are used. Idea elicit � requirements Structure Declarative �� model Behaviour � refine � requirements/ refine Declarative �� constraints Behaviour ′ � = ? � | Structure ′ design Constructive �� Behaviour � = ? refine refine | � Structure ′′ Constructive �� system model Behaviour ′ � generate/ program – 14 – 2016-06-30 – Smdse – Implementation 16 /38

Implementing CFA • Now that we have a CFA model C ( A 1 , . . . , A n ) ( thoroughly checked using Uppaal), we would like to have 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 – 2016-06-30 – Simpl – 17 /38 Example FILLUP? w := 3 Wi w > 0 FILLUP? DWATER? DOK! w := 3 w := w - 1 w == 0 DOK! dispense W0 – 14 – 2016-06-30 – Simpl – 18 /38