Formal Methods in Software Engineering

Transcription

1 Formal Methods in Software Engineering Modeling Prof. Dr. Joel Greenyer October 21, 2014

2 Organizational Issues Tutorial dates: I will offer two tutorial dates Tuesdays 15:00-16:00 in A310 (before the lecture, same room) Wednesdays 9:00-10:00 in G325 best compromise in student/room availability I hope everyone can make it to one of the tutorials! First tutorial is tomorrow at 9:00 in room G325 2

3 Organizational Issues What we will do in the tutorials: students (you) present results of assignments and mini-projects we discuss assignments you can ask questions about mini-projects and work on them Submit presentations if you want to present your results, please prepare a few slides MS Powerpoint, Libreoffice Im or PDF and them to me prior to the tutorial greenyer@inf.uni-hannover.de, subject prefix [FMSE] example: Subject [FMSE] presentation of project results Hi, I would like to present the results of our project in the tutorial on Wednesday... 3

4 Organizational Issues Google community: now 43 members anyone did not join? 4

5 in the last lecture... A typical Software/Systems Development Process... informal specification: informal unambiguous? requirements consistent? informal or integration/ semi-formal specification system tests use andnot what stakeholder maintenance =? wanted. Violates critical requirements, dire consequences design All requirements considered? Design correct? public void run(){...; } implementation unit tests Testing? Based on informal specification. 5

6 Model Checking in the last lecture... modify model (usually the error is here) Model false + counter example (how the specification can be violated) Model Checking true or modify specification (may also be wrong) Specification 6

7 in the last lecture... Model Checking in the development process GQ6 informal specification formalize transform assert(...); formal specification specification for MC tool check []!a b; []<> a; Model Checker (MC) chan ts2c =... transform Model for MC tool modify design or specification detail design or generate code create design design write/ generate code public void run(){...; } code 7

8 Today: Modeling the behavior of systems Which modeling languages do you know for modeling the behavior of software or software-controlled systems? 8

9 Different kinds of systems/behavior transformational, interactive, reactive Transformational systems transform input values to output values Inputs are given at the start of the computation Output are returned when computation terminates gcd 7 computing greatest common divisor, solving traveling salesman problem,... 9

10 Different kinds of systems/behavior transformational, interactive, reactive Interactive systems The system interacts with its environment (may include human users) The system asks for new input during computation Usually, computation terminates at some point but may also, conceptually, run forever Q z.b. online shop, flight booking application, etc. 10

11 Different kinds of systems/behavior transformational, interactive, reactive Reactive systems The system interacts with its environment (may include human users) The system must react to input, external events (instead of asking for it) Often, the computation has no definitive end system may, conceptually, run forever Q control software for planes, cars, robots, satellites, trains, power plants, ATMs, telecommunication systems, etc. 11

12 Discrete, Continuous, Hybrid Behavior Models Discrete behavior Behavior interpreted as sequence of events and states states remain unchanged between events Continuous behavior The state of the system changes continuously over time Hybrid behavior continuous and discrete aspects are relevant in Cyber-Physical Systems 12

13 Timed Behavior For some systems, considering the passage of time is important Events must/must not occur in certain time bounds Time scales can be different flight booking: check in 24h before start airbag must open within milliseconds & return book after + four weeks Bib time-critical: train moves, barriers require some time to close 13

14 Stochastic Behavior In some systems, some events are known to occur with certain probabilities Examples It starts raining Communication channel breaks down Data package is lost Behavior of users Probability of virus infection probability that a computer will be infected by a computer virus 14

15 Data-intensiveness The behavior of some system can be modeled with simple events coffee machine: Insert Coin, Choose Coffee, Pour Coffee, In other systems, more complex concepts must be modeled with more complex data structures flight data in flight booking application Events are data intensive e.g. Tony Shark, Passport-Nr. XY, books Flug AF5342 on Dec. 28th from New York to Paris... buche(...) Q 15

16 Labeled Transition Systems (LTSs) One very basic modeling language for modeling reactive systems is Labeled Transition Systems (LTSs) LTSs are a simple form of automata consisting essentially of states and transitions transitions are labeled by actions suited for modeling concurrent systems systems with several modules/processes that are executed concurrently and communicate with each other 16

17 Labeled Transition Systems (LTSs) A (Labeled) Transition System is a tuple TS= (S, Σ, T, I) S is a set of states I S is the set of initial states Σ is an alphabet, an element in Σ is called a symbol (a symbol is also called an input, event, or action) T S Σ S is a transition relation an element of T is a transition A TS is called finite if S and Σ are finite off low hold high S = {off, low, high} I = {off} Σ = {, hold} T = {(off,, low), (low, hold, high), (low,, off) (high,, off)} model of a flashlight 17

18 Path in a Labeled Transition System A path of a labeled transition system is a sequence of transitions (s i, a i,s' i ) that follow each other, i.e., i: s' i = s i+1 (off,, low), (low, hold, high), (high,, off),... off low hold high 18

19 Word / language accepted by an LTS Similar to finite automata, we can define that a word / language is accepted by an LTS An LTS TS= (S, Σ, T, I) accepts word w = e 0, e 1, e 2, over the alphabet Σ if there exists a sequence of states s 0, s 1, in S with s 0 I (s i, e i, s i+1 ) T for all i = 1,.. The set of all words accepted by an LTS TS is called the language accepted by TS, written L(TS) L(A) Σ ω words have infinite length if there are no deadlocks L(A) Σ* Σ ω words can be finite if there are deadlocks 19

20 Parallelism and Communication Often systems consist of multiple communicating components that run concurrently parallel software threads system is physically distributed, e.g. cars, trains, phones, We want to define a composition operator such that we can talk about TS = TS 1 TS n Different kinds of concepts for modeling parallelism and communication exist what kind of parallelism: parallel execution, interleaving handshaking communication via shared variables messages and channels (synchronous and asynchronous) 20

21 Parallel Execution Processes execute independently Transitions may take place simultaneously TrafficLight A red Parallel execution of TrafficLight A and TrafficLight B turnred green turngreen red A, red B --, turngreen (other transition labels skipped for brevity) TrafficLight B red green A, red B red A, green B turnred turngreen green A, green B green 21

22 Interleaving No simultaneous firing of transitions (partly independent) Like parallel threads scheduled on one processor Interleaving of TrafficLight A and TrafficLight B, TrafficLight A red we write TrafficLight A TrafficLight B turnred green turngreen red A, red B --, turngreen (other transition labels skipped for brevity) TrafficLight B red green A, red B red A, green B turnred turngreen green A, green B green 22

23 Parallel Composition via Handshaking Processes synchronize on certain common events transitions with these events are executed simultaneously only if both processes are ready execute a common event the other transitions are interleaved Light hold off low high Light {, hold} Switch Switch rel release pr hold off, rel release low, pr hold release high, pr release off, pr low, rel high, rel 23

24 Handshaking Let TS 1 = (S 1, Σ 1, T 1, I 1 ) and TS 2 = (S 2, Σ 2, T 2, I 2 ) be two transition systems and H Σ 1 Σ 2 then TS 1 H TS 2 is defined as follows TS 1 H TS 2 = (S 1 S 2, Σ 1 Σ 2, T, I 1 I 2 ) where T is defined by the following rules if a H and (s 1, a, s' 1 ) T 1 and (s 2, a, s' 2 ) T then (<s 1, s 2 >, a, <s' 1, s' 2 >) T if a if a 2 Σ 1 \ H and (s 1, a, s' 1 ) T 1 then (<s 1, s 2 >, a, <s' 1, s 2 >) T Σ 2 \ H and (s 2, a, s' 2 ) T 2 then (<s 1, s 2 >, a, <s 1, s' 2 >) T If H = Σ 1 Σ 2 we just write TS 1 TS 2 instead of TS 1 H TS 2 If H = {} then TS 1 H TS 2 is equivalent to TS 1 TS 2 Handshaking is also called synchronous message passing 24

25 Reachable States Note: Only some states in S 1 S 2 may be reachable Light off low hold high Switch Light Switch rel release pr off, rel low, pr high, pr hold release release release off, pr low, rel hold high, rel 25

26 Variables, Conditions, and Assignments When modeling real-life systems, it is often convenient to consider variables consider guarded transitions and side-effects of transitions on variables (assignments) Consider the following extended LTS. (We introduce these concepts in a by-example fashion.) (we can also represent sequential programs this way) var: int[0..3] b; // brightness variable declaration guard condition off on hold [b<3] / b++ hold [b=3] / b=0 assignment 26

27 Unfolding An LTS with variables, guard conditions, and assignments can be transformed into a regular LTS via unfolding var: int[0..3] b; // brightness off on hold [b<3] / b++ hold [b=3] / b=0 unfolded LTS without variables, guards and assignments: ( off b=2 is just the name of a state---not a variable!---to illustrate the correspondence) off off b=0 off b=1 off b=2 off b=3 on b=0 on b=1 on b=2 on b=3 hold hold hold hold 27

28 Communication via Shared Variables Example: Printer Manager PM A end /p++ idle wait req var: int p = 1 begin [p>0] / p-- end A wait A, idle B, p=1 req A idle A, idle B, p=1 PM B PM B req B idle A, wait B, p=1 end B print begin A req B req A begin B PM B end /p++ idle req wait begin [p>0] / p-- print A, idle B, p=0 req B end B begin A print A, wait B, p=0 wait A, wait B, p=1 end A wait A, print B, p=0 begin B idle A, print B, p=0 req A print 28

29 The LTSA Tool with Animator (for Simulation) 29

30 Labelled Transition System Analyser (LTSA) Modeling and verification tool for concurrent systems Modeling with Finite State Processes (FSP) they can be transformed into Labeled Transition Systems (LTS) Supports some rich language features composition via handshaking shared variables multiple instances of processes (process labeling) Supports deadlock detection and automated verification 30

31 Finite State Processes (FSP) The graphical notation for LTSs becomes unmanageable for big processes / transition systems Alternative: Textual, algebraic notation process SWITCH = RELEASED, RELEASED = (->PRESSED), PRESSED = (release->released). process definition action prefix start state 31

32 Finite State Processes (FSP) The following process definitions are equivalent: SWITCH = RELEASED, RELEASED = (->PRESSED), PRESSED = (release->released). SWITCH = RELEASED, RELEASED = (->(release->released)). SWITCH = (->(release->switch)). again the corresponding LTS: 32

33 Choice LIGHT_LOW engages either in the actions hold or. Then behaves as LIGHT_HIGH or LIGHT_OFF, respectively LIGHT_LOW = (hold->light_high ->LIGHT_OFF) Full Light example: LIGHT = LIGHT_OFF, LIGHT_OFF = (->LIGHT_LOW), LIGHT_LOW = (hold->light_high ->LIGHT_OFF), LIGHT_HIGH = (->LIGHT_OFF). 33

34 Variables and Conditions const N = 3 range Brightness = 0..N LIGHT = OFF[0], OFF[b:Brightness] = (->ON[b]), ON[b:Brightness] = (->OFF[b] when (b<n) hold->on[b+1] when (b==n) hold->on[0]). 34

35 Parallel Composition Composite process definitions are preceeded by Shared actions must be executed at the same time by all processes that share the action Example: LIGHTSWITCH = (LIGHT SWITCH). 35

36 The LTSA Tool with Animator (for Simulation) 36

37 Summary Different kinds of systems have different characteristics Different aspects of interest require different modeling concepts LTSs are a simple modeling language for modeling concurrent reactive systems concurrent processes can communicate via handshaking or shared variables network of concurrent LTSs can be composed: mapped to another LTS that models the equivalent behavior Outlook: certain properties of LTS can be proven automatically via model-checking 37

38 Assignment: First Mini-Project First small Mini-Project, due November 4 (two weeks time) to be solved in groups of three or four Implement Labeled Transition Systems: 1. Create a class diagram for LTSs model concepts such as states, transitions, alphabet, etc. 2. Implement the class diagram in Java (or another language) 3. Implement a parallel composition operator ( ) that takes two (or more) LTSs as input and produces an LTS that is the parallel composition of the input LTSs 4. find some way to visualize the output (Graphviz or Eclipse Zest) 5. Input can be specified programmatically, optionally you can build a parser for some input file format, e.g. some XML Test it with some examples and compare results with LTSA tool 38