Event-B Course. 1. Introduction

Transcription

1 Event-B Course 1. Introduction Jean-Raymond Abrial October-November 2010

2 Purpose of the Course 1 - To show that software (and systems) can be correct by construction - Insights about modeling and formal reasoning using Event-B - To show that this can be made practical with the Rodin Platform

3 Purpose of the Course (cont d) 2 - To illustrate this approach with some examples: - small sequential programs - controlling cars on a bridge - a mechanical press controller - a file transfer protocol - a routing algorithm - more sequential programs -...

4 What you Will Learn 3 - By the end of the course you should be "comfortable" with: - Modeling (versus programming) - Abstraction and refinement - Some mathematical techniques used for reasoning - The practice of proving as a means to construct programs - The usage of the Rodin Platform

5 Three Preambles 4 - A bit of history - The Vasa disaster - The Ariane 5 disaster

6 Preamble 1: A bit of History 5 - Tycho Brahe ( ) - Kepler ( ) - Newton ( ) - Einstein ( )

7 Preamble 1: A bit of History 6 - Tycho Brahe ( ) - Kepler ( ) - Newton ( ) - Einstein ( ) years of scientific efforts for mastering gravity

8 Measuring: Tycho Brahe ( ) 7

9 Observing: Kepler ( ) 8

10 Explaining: Newton ( ) 9

11 Explaining More: Einstein ( ) 10

12 How About Us : 42 years of Software "Engineering" - 42 years vs. 400 years: we are still very young! - Spending most of the time writing programs - Would have been better (maybe) spending time designing programs - How about generalizing the notion of program - Comparing these 42 years with other scientific achievements

13 Preamble 2: The Vasa Disaster 12

14 The Story 13 - August 10, 1628: The Swedish warship Vasa SANK. - This was her maiden voyage. - She sailed about 1,300 meters only in Stockholm harbor lives were lost in the disaster.

15 Problems with the Vasa Construction Changing requirements (by King Gustav II Adolf). 2. Lack of specifications (by Ship Builder Henrik Hybertsson). 3. Lack of explicit design (by Subcontractor Johan Isbrandsson) (No scientific calculation of the ship stability) 4. Test outcome was not followed (by Admiral Fleming)

16 References 15 - Enter keywords "Vasa disaster" in Google - The Vasa: A Disaster Story with Software Analogies. By Linda Rising. The Software Practitioner, January-February Why the Vasa Sank: 10 Problems and Some Antidotes for Software Projects. By Richard E. Fairley and Mary Jane Willshire. IEEE Software, March-April dfairley/the vasa.pdf

17 Preamble 3: The Ariane 5 Disaster 16

18 The Story 17 - June 4, 1996: The launch vehicle Ariane 5 EXPLODED. - This was its maiden voyage. - It flew about 37 Sec only in Kourou s sky. - No injury in the disaster.

19 The Story (cont d) 18 - Normal behavior of the launcher for 36 Sec after lift-off - Failure of both Inertial Reference Systems almost simultaneously - Strong pivoting of the nozzles of the boosters and Vulcain engine - Self-destruction at an altitude of 4000 m (1000 m from the pad)

20 More Details 19 - Both inertial computers failed because of overflow on one variable - This caused a software exception and stops these computers - These computers sent post-mortem info through the bus - Normally the main computer receives velocity info through the bus - The main computer was confused and pivoted the nozzles

21 More Details (cont d) 20 - The faulty program was working correctly on Ariane 4 - The faulty program was not tested for A5 (since it worked for A4) - But the velocity of Ariane 5 is far greater than that of Ariane 4 - The faulty program happened to be useless for Ariane 5 - It was kept for commonality reasons

22 References 21 - Enter keywords "flight 501" in Google - Ariane 5 flight 501 Inquiry Board Report: - INRIA report challenging the Inquiry Board Report: ftp://ftp.inria.fr/inria/publication/publi-pdf/rr/rr-3079.pdf

23 Topics of this Introductory Lecture About formal methods in general 1.2 About requirements 1.3 About modeling 1.4 A light introduction to Event-B (with small examples)

24 1.1. About formal methods in general

25 Formal Methods: a Great Confusion 23 - What are they used for? - When are they to be used? - Is UML a formal method? - Are they needed when doing OO programming? - What is their definition?

26 Purpose of Formal Methods 24 - Helping people in doing the following transformation: software requirements Formal Method running code - It does not seem to be different from ordinary programming

27 Purpose of Formal Methods 25 - Helping people in doing the following transformation: software requirements Formal Method running code - It does not seem to be different from ordinary programming - It can be generalized to: system requirements Formal Method running system

28 Preliminary Definitions and Categories 26 - A formal method is a systematic approach used to determine whether a program has certain wishful properties - Different kinds of formal methods (according to this definition) - Type checking - Static analysis - Model checking - Theorem proving

29 Type Checking 27 - Controlling low level properties of variables in a program - A type defines: - a set of values to be assigned to a variable - the operations that can be performed on a variable - the way a variable will be stored in the memory - Type checking controls that: - value assignments to a variable is correct - the variable is used in authorized operations only - It is done automatically within the compiler

30 Static Analysis: Abstract Interpretation 28 - It is an automatic technique used for checking that a program will not have certain run-time errors - Typical run-time errors detected: - Division by zero - Array bound overflow - Arithmetic overflow (floating point) - The analysis is performed by abstracting the program variables and "executing" the resulting abstraction rather than the program itself - The abstract interpretation may lead to false alarm

31 Model Checking 29 - The properties to be checked are not properties of programs - They are properties of models of program - Usually, these models denote finite state machines (state and transitions) - The properties to be checked are often temporal properties (reachability) - Model checkers work automatically

32 Theorem Proving: Model Construction 30 - This is the approach I am going to develop in this course - It concentrates on the construction of models by successive refinements - The properties to be proved are parts of the models: invariants and refinement - At the end of the process, the most refined model is automatically translated into a program

33 Costs 31 cost Type Checking Static Analysis Model Checking Theorem Proving P R O G R A M S M O D E L S

34 Comparisons 32 Nature Checked Properties type checking programs internal model checking models external static ananlysis programs external theorem proving models internal

35 Why Using Formal Methods with Proofs? 33 - When there is nothing better available. - When the risk is too high (e.g. in embedded systems). - When people have already suffered enough. - When people question their development process. - Decision of using formal methods is always strategic.

36 Claimed Difficulties in Using Formal Methods with Proofs 34 - You have to be a mathematician. - Formalism is hard to master. - Not visual enough (no boxes, arrows, etc.). - People will not be able to do formal proofs.

37 Genuine Difficulties (my own view) 35 - You have to think a lot before final coding. - Incorporation in development process. - Model building is an elaborate activity. - Reasoning by means of proof is necessary. - Poor quality of requirement documents.

38 How about other Engineering Disciplines? 36

39 How about other Engineering Disciplines? 37

40 How about other Engineering Disciplines? 38

41 Other Disciplines 39 - Some mature disciplines: - Avionics, - Civil Engineering, - Mechanical Constructions, - Train systems, - Ship building, -...

42 Other Disciplines 40 - Some mature disciplines: - Avionics, - Civil Engineering, - Mechanical Constructions, - Train systems, - Ship building, Does there exist methods similar to formal methods?

43 Other Disciplines 41 - Some mature disciplines: - Avionics, - Civil Engineering, - Mechanical Constructions, - Train systems, - Ship building, Does there exist methods similar to formal methods? - Yes

44 Other Disciplines 42 - Some mature disciplines: - Avionics, - Civil Engineering, - Mechanical Constructions, - Train systems, - Ship building, Does there exist methods similar to formal methods? - Yes, Blueprints

45 Blueprints 43

46 Architect Blueprint 44

47 What is a Blue Print? 45 - A certain representation of the system we want to build - It is not a mock-up (although mock-ups can be very useful too) - The basis is lacking (you cannot drive the blue print of a car) - Allows to reason about the future system during its design - Is it important? (according to professionals) YES

48 Reasoning about the Intended System? 46 - Defining and calculating its behavior (what it does) - Incorporating constraints (what it must not do) - Defining architecture - Based on some underlying theories - strength of materials, - fluid mechanics, - gravitation, - etc.

49 Techniques of Blue Printing 47 - Using pre-defined conventions (often computerized these days) - Conventions should help facilitate reasoning - Adding details on more accurate versions - Postponing choices by having some open options - Decomposing one blue print into several - Reusing old blue prints (with slight changes)

50 1.2 About requirements

51 What About BEFORE the Blue Print 48 - Define main objectives of future system - Define requirements - Study feasibility

52 The Requirement Document 49 - Place of requirement document - System life cycle - Difficulties and weak point - Role of requirement document - Characterizing the requirement document - Some structuring rules

53 The Classical Development Cycle Feasibility Study 4. Coding 2. Requirement Analysis 5. Test 3. Technical Specification 6. Documentation 4. Design 7. Maintenance

54 Difficulties 51 - Ensuring relative consistency between the phases - Formal Methods could help (in the later phases) - But still a problem in the earlier phases - Weakest part: the requirement document

55 About the Requirement Document 52 - Importance of this document (due to its position in the life cycle) - Obtaining a good requirement document is not easy: - missing points - too specific (over-specified) - Requirement document are usually difficult to exploit - There might exist some guidelines allowing us to better exploit it

56 About the Requirement Document (cont d) 53 - Hence very often necessary to rewrite it - It will cost a significant amount of time and money (but well spent) - The famous specification change syndrome might disappear

57 Some Structuring Rules 54 - Two separate texts in the same document: - explanatory text: the why - reference text: the what - Embedding the reference text within the explanation text - The reference text eventually becomes the official document - Must be signed by concerned parties

58 An Analogy: a Mathematical Text Book The Cantor-Bernstein Theorem. If a b and b a then a and b are equinumerous. This theorem was first conjectured by Cantor in 1895 and proved by Bernstein in Proof: Since b a, then a has a subset c such that b c In red: the reference text - In blue: the explanatory text

59 The Reference Text 56 - Contains the properties of the future system - Contains the assumptions about its environment - Made of short labeled fragments (traceability) - Should be easy to read (different font) and easy to extract (boxed) - About the abstraction levels (don t care too much) - The problem of over-specification (don t care too much)

60 An Example of Requirement Document (1) 57 - The system we are going to build is a piece of software connected to some equipment. - There are two kinds of requirements: - those concerned with the equipment, labeled EQP, - those concerned with the function of the system, labeled FUN. - The function of this system is to control cars on a narrow bridge. - This bridge is supposed to link the mainland to a small island.

61 An Example of Requirement Document (2) 58 The system is controlling cars on a bridge between the mainland and an island FUN-1 - This can be illustrated as follows Island Bridge Mainland

62 An Example of Requirements Document (3) 59 - The controller is equipped with two traffic lights with two colors. The system has two traffic lights with two colors: green and red EQP-1

63 An Example of Requirements Document (4) 60 - One of the traffic lights is situated on the mainland and the other one on the island. Both are close to the bridge. - This can be illustrated as follows: Island Bridge Mainland

64 An Example of Requirements Document (5) 61 The traffic lights control the entrance to the bridge at both ends of it EQP-2 - Drivers are supposed to obey the traffic light by not passing when a traffic light is red. Cars are not supposed to pass on a red traffic light, only on a green one EQP-3

65 An Example of Requirements Document (6) 62 - There are also some car sensors situated at both ends of the bridge. - These sensors are supposed to detect the presence of cars intending to enter or leave the bridge. - There are four such sensors. Two of them are situated on the bridge and the other two are situated on the mainland and on the island. The system is equipped with four car sensors each with two states: on or off EQP-4

66 An Example of Requirements Document (7) 63 The sensors are used to detect the presence of cars entering or leaving the bridge EQP-5 - The pieces of equipment can be illustrated as follows: Island Bridge Mainland

67 An Example of Requirements Document (8) 64 - This system has two main constraints: - the number of cars on the bridge and the island is limited - the bridge is one way. The number of cars on the bridge and the island is limited FUN-2 The bridge is one way or the other, not both at the same time FUN-3

68 The Reference Document (1) 65 The system is controlling cars on a bridge between the mainland and an island FUN-1 The number of cars on the bridge and the island is limited FUN-2 The bridge is one way or the other, not both at the same time FUN-3

69 The Reference Document (2) 66 The system has two traffic lights with two colors: green and red EQP-1 The traffic lights control the entrance to the bridge at both ends of it EQP-2 Cars are not supposed to pass on a red traffic light, only on a green one EQP-3

70 The Reference Document (3) 67 The system is equipped with four car sensors each with two states: on or off EQP-4 The sensors are used to detect the presence of cars entering or leaving the bridge EQP-5

71 Taxonomy of Properties (incomplete) 68 - Functional - Safety - Equipment - Degraded modes - Availability - Delays

72 Style of Reference Text (incomplete) 69 - Short natural language statements - Tables ( data description) - Transition diagrams - Mathematical formulae - Physical units table -...

73 1.3 About modeling

74 Back to the Questions about Formal Methods 70 - What are they used for? - When are they to be used? - Is UML a formal method? - Are they needed when doing OO programming? - What is their definition?

75 Definitions of Formal Methods Used in this Course 71 - Formal methods are techniques for building and studying blue prints ADAPTED TO OUR DISCIPLINE - Our discipline is: design of hardware and software SYSTEMS - Such blue prints are now called models - Reminder: - Models allow to reason about a FUTURE system - The basis is lacking (hence you cannot execute a model)

76 Conventions for Model Writing and Reasoning 72 - Reminder (cont d): - Using pre-defined conventions - Conventions should help facilitate reasoning (more to come) - Consequence: Using ordinary discrete mathematical conventions: - Classical Logic (Predicate Calculus) - Basic Set Theory (sets, relations and functions)

77 Systems we are Interested to Develop 73 - a classical piece of software - an electronic circuit - a file transfer protocol - an airline booking system - a PC operating system - a nuclear plant controller - a Smart-Card electronic purse - a launch vehicle flight controller - a driverless train controller - a mechanical press controller - etc.

78 Characterizing such Systems (general) 74 - They are made of many parts - They interact with a possibly hostile environment - They involve several executing agents - They require a high degree of correctness - There construction spreads over several years - Their specifications are subjected to many changes

79 Characterizing such Systems (more technical) 75 - These systems operate in a discrete fashion - Their dynamical behavior can be abstracted by: - A succession of steady states - Intermixed with sudden jumps - The possible number of state changes are enormous - Usually such systems never halt - They are called DISCRETE TRANSITION SYSTEMS

80 Reasoning about Discrete Transition Systems 76 - Test reasoning (a vast majority): VERIFICATION - Blue Print reasoning (a very few): CORRECT CONSTRUCTION

81 Test Reasoning: VERIFICATION 77 - Based on laboratory execution - Obvious incompleteness - The oracle is usually missing - Properties to be checked are chosen a posteriori - Re-adapting and re-shaping after testing - Reveals an immature technology

82 Blue Print Reasoning: CORRECT CONSTRUCTION 78 - Based on a formal model: the blue print - Gradually describing the system with the needed precision - Relevant Properties are chosen a priori - Serious thinking made on the model, not on the final system - Reasoning is validated by proofs - Reveals a mature technology

83 Blue Print Reasoning: Outcome of Proving 79 - The proof succeeds - The proof fails but refutes the statement to prove - the model is erroneous: it has to be modified - The proof fails but is probably provable - the model is badly structured: it has to be reorganized - The proof fails and is probably not provable nor refutable - the model is too poor: it has to be enriched

84 Price of Interactive Proofs in Industrial Projects 80

85 Price of Interactive Proofs in Industrial Projects 81 - n: number of lines of generated code

86 Price of Interactive Proofs in Industrial Projects 82 - n: number of lines of generated code - f: proof factor. Typical values are 2 or 3. n/f is the number of proofs generated

87 Price of Interactive Proofs in Industrial Projects 83 - n: number of lines of generated code - f: proof factor. Typical values are 2 or 3. n/f is the number of proofs generated - x: percentage of interactive proofs. Typical values are 2, 5, 10. n.x/100.f is the number of interactive proofs generated

88 Price of Interactive Proofs in Industrial Projects 84 - n: number of lines of generated code - f: proof factor. Typical values are 2 or 3. n/f is the number of proofs generated - x: percentage of interactive proofs. Typical values are 2, 5, 10. n.x/100.f is the number of interactive proofs generated - p: number of interactive proofs per man-day. Typical value is 20. n.x/100.f.p is the number of man-day for the interactive proofs

89 Price of Interactive Proofs in Industrial Projects 85 - n: number of lines of generated code - f: proof factor. Typical values are 2 or 3. n/f is the number of proofs generated - x: percentage of interactive proofs. Typical values are 2, 5, 10. n.x/100.f is the number of interactive proofs generated - p: number of interactive proofs per man-day. Typical value is 20. n.x/100.f.p is the number of man-day for the interactive proofs - m: number of man-months to perform the interactive proofs. n.x/100.f.p.20 is the number of man-month for proving

90 Price of Interactive Proofs in Industrial Projects (cont d) 86 - m = n.x/100.f.p.20 is the number of man-months needed for proving n 100, , , 000 f x 2.5% 5% 10% p m This shows the importance to prove as many automatic proofs as we can

91 1.4 A Light Introduction to Event-B (with Small Examples)

92 Topics Introduction First Example Second Example

93 Introduction

94 Model Developments with Event-B 88 - Event-B is not a programming language (even very abstract) - Event-B is a notation used for developing mathematical models - Mathematical models of discrete transition systems -

95 Model Developments with Event-B (cont d) 89 - Such models, once finished, can be used to eventually construct: - sequential programs, - distributed programs, - concurrent programs, - electronic circuits, - large systems involving a possibly fragile environment, The underlined statement is an important case. - In this lecture, we shall construct small sequential programs.

96 Main Influences 90 Action Systems developed by the Finnish school (Turku): R.J.R. Back and R. Kurki-Suonio Decentralization of Process Nets with Centralized Control. 2nd ACM SIGACT-SIGOPS Symposium Principles of Distributed Computing (1983) M.J. Butler Stepwise Refinement of Communicating Systems. Science of Computer Programming (1996)

97 The State of a Model 91 - A discrete model is first made of a state - The state is represented by some constants and variables - Constants are linked by some axioms - Variables are linked by some invariants - Axioms and invariants are written using set-theoretic expressions

98 The Events of a Model (Transitions) 92 - A discrete model is also made of a number of events - An event is made of a guard and an action - The guard denotes the enabling condition of the event - The action denotes the way the state is modified by the event - Guards and actions are written using set-theoretic expressions

99 A Model Schematic View 93 Variables invariants Events guards actions Constants axioms Dynamic Parts (Machines) Static Parts (Contexts)

100 Operational Interpretation 94 - An event execution is supposed to take no time - Thus, no two events can occur simultaneously - When all events have false guards, the discrete system stops - When some events have true guards, one of them is chosen non-deterministically and its action modifies the state - The previous phase is repeated (if possible)

101 Operational Interpretation 95 Initialize; while (some events have true guards) { Choose one such event; Modify the state accordingly; }

102 Comments on the Operational Interpretation 96 - Stopping is not necessary: a discrete system may run for ever - This interpretation is just given here for informal understanding - The meaning of such a discrete system will be given by the proofs which can be performed on it.

103 Being more Precise: Machines and Contexts 97 - A model is made of several components - A component is either a machine or a context: Machine variables invariants theorems events Context carrier sets constants axioms theorems

104 Machines and Contexts (cont d) 98 - Contexts contain the static structure of a discrete system (constants and axioms) - Machines contain the dynamic structure of a discrete system (variables, invariants, and events) - Machines see contexts - Contexts can be extended - Machines can be refined

105 Relationship Between Machines and Contexts 99 Machine sees Context refines Machine sees Context extends refines extends

106 A First Simple Example

107 Requirements for a First Simple Example 100 We are given a non-empty finite array of natural numbers FUN-1 We like to find the maximum of the range of this array FUN-2

108 Requirements for a First Small Example 101 We are given a non-empty finite array of natural numbers FUN-1 We like to find the maximum of the range of this array FUN-2 We want to find that 10 is the greatest element of this array

109 Development Strategy First, we show an initial model specifying the problem - Later, we refine our model to produce an algorithm. - In the initial model, we have: - a context where the constant array is defined - a machine where the maximum is "computed"

110 Initial Model: the Context as presented in the slides Constant n denotes the size of the non-empty array, - Constant f denotes the array, - Constant M denotes a natural number. constants: n f M 0 < n f 1.. n 0.. M ran(f) - Mind the inference typing

111 Initial Model: the Context as presented in the slides Constant n denotes the size of the non-empty array, - Constant f denotes the array, - Constant M denotes a natural number. constants: n f M axm0 1: axm0 2: thm0 1: 0 < n f 1.. n 0.. M ran(f) - Mind the inference typing

112 The Context as presented in the tool 105 Context sets constants axioms theorems context maxi ctx 0 constants n f M axioms axm1 : 0 < n axm2 : f 1..n 0.. M Notice that we have no set end thm1 : ran(f)

113 Math Refresher: Total Function and Range We are given two sets S and T S T

114 Math Refresher: Total Function and Range Here is a total function f from S to T : f S T S f T

115 Math Refresher: Total Function and Range Here is the range of f S f T

116 D E M O (showing a context)

117 Context Structure 109 context < context identifier > sets < set identifier >... constants < constant identifier >... axioms < label >: < predicate >... end

118 Explaining Context Sections "sets" lists various sets, which define pairwise disjoint types - "constants" lists the different constants introduced in the context - "axioms" defines the properties of the constants

119 Initial Model: the Machine as presented in the slides Variable m denotes the result. variable: m inv0 1: m N - Next are the two events: INIT begin m := 0 end maximum begin m := max(ran(f)) end - Event maximum presents the final intended result (in one shot)

120 Machine Example as presented in the tool 112 Machine variables invariants theorems events machine maxi 0 sees ctx 0 variables i invariants inv1 : i 1.. n events... end

121 Machine (and Context) Example as presented in the tool 113 machine maxi 0 sees maxi ctx 0 variables m invariants context maxi ctx 0 sets D constants n f v axioms inv1 : events... end m N axm1 : 0 < n axm2 : f 1..n 0.. M thm1 : ran(f) end

122 D E M O (showing a machine)

123 Machine Structure 114 machine < machine identifier > sees < context identifier >... variables < variable identifier >... invariants < label >: < predicate >... events... variant < variant > end

124 Explaining Machine Sections "variables" lists the state variables of the machine - "invariants" states the properties of the variables - "events" defines the dynamics of the transition system (next slides) - "variant" is explained later

125 Event An event defines a transition of our discrete system - An event is made of a Guard G and an Action A - G defines the enabling conditions of the transition - A defines a parallel assignment of the variables

126 Kind of Events 117 begin A end No guard when G then A end Simple guard any x where G(x) then A(x) end Quantified guard

127 Kind of Events 118 begin A end No guard when G then A end Simple guard any x where G(x) then A(x) end Quantified guard Our event (so far) have no guards INIT begin m := 0 end maximum begin m := max(ran(f)) end

128 Summary 119 constants: n f M axm0 1: axm0 2: 0 < n f 1.. n 0.. M thm0 1: ran(f) variable: m inv0 1: m N INIT begin m := 0 end maximum begin m := max(ran(f)) end

129 Our Task is not Completed We have to perform some proofs: - thm0 1 holds - Invariant inv0 1 is established by event "INIT" - Invariant inv0 1 is maintained by event "maximum" - Expression "max(ran(f))" is well-defined

130 Summary of what is to be Proved Stated theorems - Invariant maintenance - Well-definedness

131 D E M O (showing proof obligations)

132 The Rodin Platform Kernel Tools 122 Model Static Checker Proof Obligation Generator Prover Proofs

133 Automatic and Interactive Modes for the Prover 123 Proof Obligation Prover Proof Proof Obligation Prover Proof Human Intervention

134 Refinement: the New Variables We introduce two new variables in our model - Variables p and q denote two indices in the domain of f. variables: m p q inv1 1: inv1 2: p 1.. n q 1.. n

135 Initial, Intermediate, and Final Situations p q The maximum is always "between" p and q p q p q

136 Refinement: the Main Invariant Interval p.. q is never empty (inv1 3) - The maximum is always in the image of p.. q under f (inv1 4) inv1 1: p 1.. n variables: m p q inv1 2: inv1 3: q 1.. n p q inv1 4: max(ran(f)) f[p.. q] - inv1 4 is the main invariant

137 Math Refresher: Image B is the image of A under f: B = f[a] S f T B A

138 Refinement: Initial and Final Events 128 INIT begin m := 0 p := 1 q := n end maximum when p = q then m := f(p) end

139 Refinement: two New Events 129 INIT begin m := 0 p := 1 q := n end maximum when p = q then m := f(p) end increment when p < q f(p) f(q) then p := p + 1 end decrement when p < q f(q) < f(p) then q := q 1 end

140 Trace <9 (decrement) 3<9 (decrement) <9 (decrement) 9<10 (increment) 3<10 (increment)

141 Abstract and Concrete Traces 131 INIT maxi INIT dec dec dec inc inc maxi

142 Old Events must Refine their Abstractions 132 INIT maxi INIT dec dec dec inc inc maxi

143 How about New Events? 133 INIT????? maxi INIT dec dec dec inc inc maxi

144 New Events refine "skip" 134 INIT skip skip skip skip skip maxi INIT dec dec dec inc inc maxi

145 To be Proved Invariant maintenance - Event refinement - guard strengthening - concrete action simulates the abstract one - Well-definedness

146 Pathologies which Must be Avoided on the Concrete Trace Early deadlock INIT dec dec dec maxi

147 Pathologies which Must be Avoided on the Concrete Trace Early deadlock INIT dec dec dec maxi - Divergence INIT dec dec dec maxi

148 To be Proved (more) Invariant maintenance - Event refinement - guard strengthening - concrete action simulates the abstract one - Well-definedness - Trace refinement - Disjunction of guards must hold (no early deadlock) - New events must be convergent (must decrease a variant)

149 Towards the Final Construction 139 INIT begin m := 0 p := 1 q := n end maximum when p = q then m := f(p) end increment when p q f(p) f(q) then p := p + 1 end decrement when p q f(q) < f(p) then q := q 1 end

150 Statements for a Pidgin Programming Language 140 while condition do statement end if condition then statement else statement end statement ; statement variable list := expression list

151 IF Merging Rule 141 when P Q then S end when P Q then T end when P then if Q then S else T end end M IF - The two events must have been introduced at the same step

152 Applying Rule M IF 142 decrement when p q f(q) < f(p) then q := q 1 end increment when p q f(p) f(q) then p := p + 1 end decrement increment when p q then if f(q) < f(p) then q := q 1 else p := p + 1 end end

153 WHILE Merging Rule (special case) 143 when Q then S end when Q then T end while Q do S end; T M WHILE - The first event must have been introduced at one refinement step below the second one.

154 Applying Rule M WHILE (special case) 144 decrement increment when p q then if f(q) < f(p) then q := q 1 else p := p + 1 end end maximum when p = q then m := f(p) end decrement increment maximum while p q do if f(q) < f(p) then q := q 1 else p := p + 1 end end; m := f(p)

155 WHILE Merging Rule (general case) 145 when P Q then S end when P Q then T end when P then while Q do S end; T end M WHILE - P must be invariant under S - The first event must have been introduced at one refinement step below the second one.

156 Final Rule M INIT Once we have obtained an event without guard - We add to it the event init by sequential composition - We then obtain the final program

157 The Program: Putting the Events Together 147 m, p, q := 0, 1, n; INIT while p < q do if f(q) < f(p) then q := q 1 decrement else p := p + 1 end end; m := f(p) increment maximum INIT begin m := 0 p := 1 q := n end decrement when p < q f(q) < f(p) then q := q 1 end increment when p < q f(p) f(q) then p := p + 1 end maximum when p = q then m := f(p) end

158 A Second Simple Example

159 Requirements for a Second Simple Example 148 We are given a non-empty finite array FUN-1 We know that a value v is in this array FUN-2 We like to find an index with v FUN-3

160 Requirements for a Second Simple Example 149 We are given a non-empty finite array FUN-1 We know that a value v is in this array FUN-2 We like to find an index with v FUN-3 v? v?

161 Development Strategy First, we show an initial model specifying the problem - Later, we refine our model to produce an algorithm. - In the initial model, we have: - a context where the constant array is defined - a machine where the search is done (non-deterministically)

162 Context 151 sets: D axm1: n N axm2: f 1.. n D constants: n f v axm3: v ran(f) thm1: n > 0 - This context is generic: the set D is not specified (just supposed to be non-empty)

163 Pictorial Representation of the Context f? v n

164 Machine 153 variables: i inv1: i 1.. n INIT begin i := 1 end Notice the quantified guard in event "search" search any k where k 1.. n f(k) = v then i := k end

165 Pictorial Representation of the State after Event "search" f i v n

166 Abstract Trace: Where is v? v n v

167 Abstract Trace: v is in 4, v is in v 4 v n v 8 v n The abstract trace is non-deterministic

168 Abstract Trace is Non-deterministic 157 search INIT search

169 Refinement: New Variable j and New Event progress 158 variables: i j inv1 1: j 0.. n inv1 2: v / f[1.. j] thm1 1: v f[j + 1..n] INIT when i := 1 j := 0 end progress when f(j + 1) v then j := j + 1 end search when f(j + 1) = v then i := j + 1 end

170 Pictorial Representation of the State 159 f 1 v not found j j+1 v is somewhere n

171 Abstract Trace: Where is v? v n v

172 Abstract Trace: v is in 4, v is in v 4 v n v 8 v n The abstract trace is non-deterministic

173 Concrete Trace: v is not in v n v

174 Concrete Trace: v is not in v v n v n v

175 Concrete Trace: v is not in v 1 2 v v n v n v n v

176 Concrete Trace: v is in v 1 2 v v v n v n v n v n v The concrete trace is deterministic

177 Concrete Trace is Deterministic 166 search INIT skip skip skip search INIT progress progress progress search

178 Constructing the Final Program 167 i, j := 1, 0 ; INIT while f(j + 1) v do j := j + 1 progress end ; i := j + 1 search INIT begin i := 1 j := 0 end progress when f(j + 1) v then j := j + 1 end search when f(j + 1) = v then i := j + 1 end

179 Conclusion (1) : Some Guidelines for Development Write the requirement document - Propose a refinement strategy - Develop the model by successive refinements and proofs - Perform some animation (if useful)

180 Conclusion (2): Importance of Refinement Refinement allows us to build models gradually - We build an ordered sequence of more precise models - Each model is a refinement of the one preceding it - A useful analogy: looking through a microscope - Spatial (more variables) as well as temporal (more events) extensions