Formal Engineering Technologies for Dependable Software Development

Transcription

1 Formal Engineering Technologies for Dependable Software Development Shaoying Liu Department of Computer Science Faculty of Computer and Information Sciences Hosei University, Tokyo, Japan HP:

2 Goals of the course Learning the most rigorous and effective software development methods. Understanding the mathematical meaning of fundamental concepts in software engineering. Improving your real ability for developing large scale software systems with high reliability.

3 Contents of the course Formal Methods Theoretical Practical formal specification Practical Specificationbased inspection Specification -based testing

4 Reference books (1) C.A.R. Hoare and C.B. Jones, ``Essays in Computing Science, Prentice Hall, (2) Shaoying Liu, Formal Engineering for Industrial Software Development, Springer-Verlag, (3) Latest publications on specification-based inspection and testing.

5 The way of learning Attend lectures Work on class exercises or discussions Complete a small project

6 1. Introduction Problems in software development Formal methods for the problems Challenges to formal methods Formal engineering methods for the challenges SOFL: a specific formal engineering method

7 1.1 Problems in software development A challenge to practitioners: Cost Software reliability Time

8 The major tasks in software development: Understanding Creation Confirmation Reliability!!!

9 What is a reliable system? Sausage machine input output Requirement: given a piglet as input, the machine will produce sausages automatically.

10 Example of unreliable system: Sausage machine beef input output Requirement: given a piglet, the machine will produce sausages automatically.

11 An abstract process model Specification Program S Transformation P What to do Verification How to do it How to write S so that it can effectively help the developer understand the user s requirements completely and accurately? How to ensure that S is not ambiguous so that it can be correctly understood by all the developers involved? How can S be effectively used for the construction of program P, and for the verification (e.g., proof, inspection, and testing) of P? How can software tools effectively support the analysis of S, transformation from S to P, and verification of P against S?

12 An example of informal specification: A software system for an Automated Teller Machine (ATM) is required to provide services on various accounts. The services include operations on current account, operations on savings account, transferring money between accounts, managing foreign currency account, and change password. The operations on a current or savings account include deposit, withdraw, show balance, and print out transaction records.

13 A better way to write the same specification: A software system for an automated teller machine (ATM) is required to provide services on various accounts. The services include 1 operations on current account 2 operations on savings account 3 transferring money between accounts 4 managing foreign currency account, 5 change password. The operations on a current or savings account include 1 deposit 2 withdraw 3 show balance 4 print out transaction records.

14 The major problems with informal specifications: Informal specifications are usually ambiguous, which is likely to cause misinterpretations. Informal specifications are difficult to be used for implementation and for inspection and testing of programs because of the big gap between the functional descriptions in the specifications and the program structures. Informal specifications are difficult to be analyzed for their consistency and validity. Information specifications are difficult to be supported by software tools in their analysis, transformation, and management (e.g., search, change, reuse).

15 2006 年 4 月 9 日の朝日新聞

16 A possible solution to these problems: Formal Methods!!!

17 1.2 Formal methods (FM) Formal methods mean verified design. Formal methods = Formal Specification (VDM, Z, B-Method) + Refinement (Back, Morgan) + Formal Verification (Floyd-Hoare, Dijkstra) Set theory, logics, algebra, etc.

18 1.2.1 The most commonly used formal notations (1) VDM-SL (Vienna Development Method Specification Language), IBM Research Laboratory in Vienna References: (1) Systematic Software Development Using VDM, by Cliff B. Jones, 2nd edition, Prentice Hall,1990. (2) Modelling Systems, by John Fitzgerald and Peter Gorm Larsen, Cambridge University Press,1998.

19 The major feature of VDM-SL is the technique for operation specification. What is an operation?

20 Addition x Divide result register state variable or external variable

21 Operation specification: Example: OperationName(input)output ext State variables pre pre-condition post post-condition Divide(x: int) result: real ext wr register: real pre x <> 0 post register = register~ / x and result = register

22 The difference and similarity between a VDM operation specification and program An example of a calculator: register Divide Multiply Subtract Add

23 The difference and similarity between a VDM operation specification and program register 5 register Divide Multiply Subtract Add

24 The difference and similarity between a VDM operation specification and program register 1 register / Divide Multiply Subtract Add

25 The difference and similarity between a VDM operation specification and program Let s consider the following program: import ; class Calculator { int register := 0; int Add(int x) { register := register + x; return register; } double Divide(int x) { register := register / x; return register; } } main(string arg[]) { int input; double divisionresult; Calculator mycal := new Calculator(); read(input); //reading from GUI divisionresult := mycal.divide(input); System.out.println( Division result: + divisionresult); } //end of the main method

26 The difference and similarity between a VDM operation specification and program The specification defines the relation between input and output, while the program defines the process of computing the output from the input. import ; class Calculator { int register := 0; double Divide(int x) pre x!= 0 { register := register / x; return register; } post register = register~ / x and result = register } main(string arg[]) { int input; double divisionresult; Calculator mycal := new Calculator(); read(input); //reading from GUI divisionresult := mycal.divide(input); System.out.println( Division result: + divisionresult); } //end of the main method

27 The difference and similarity between a VDM operation specification and program Omit the program and only use the specification to define the function of the program. import ; class Calculator { int register := 0; double Divide(int x) pre x!= 0 post register~ / x = register and register = result } main(string arg[]) { int input; double divisionresult; Calculator mycal := new Calculator(); read(input); //reading from GUI if (input!= 0) { divisionresult := mycal.divide(input); System.out.println( Division result: + divisionresult);} else System.out.println( The denominator is zero. ); } //the end of the main method.

28 The difference and similarity between a VDM operation specification and program Specification in VDM-SL: main(string arg[]) { module Calculator Divide(x: int) result: real ext wr register: real pre x <> 0 post register = register~ / x and result = register int input; double divisionresult; Calculator mycal := new Calculator(); read(input); //reading from GUI if (input!= 0) { divisionresult := mycal.divide(input); System.out.println( Division result: + divisionresult);} else System.out.println( The denominator is zero. ); } //the end of the main method.

29 (2) Z, PRG (Programming Research Group), Oxford University, UK A Z specification is composed of a set of schemas and possibly their sequential compositions. A schema can be used to define global variables, state variables, and operations. References: (1) The Z Notation, by J.M. Spivey, Prentice Hall, (2) Using Z: Specification, Refinement, and Proof, by Jim Woodcock and Jim Davies, Prentice Hall, 1996.

30 (3) B-Method, Jean-Raymond Abrial, France Reference: (1) The B-Book: Assigning Programs to Meanings, by J-R Abrial, Cambridge University Press,1996, A B specification is composed of a set of related abstract machines. Each abstract machine is a module that contains a set of operation definitions. Each operation is defined using pre- and postconditions.

31 Class dicsussion (1) Tell the difference between the assignment x := y + z (or x = y + z in Java) in a program and the equality x = y + z (2) What is the relation between them?

32 1.2.2 Refinement Refinement Abstract specification (Transformation) Concrete specification How is the correctness of the concrete program is ensured by refinement?

33 A novel view (1) A specification can be decomposed into sub-specifications, and each subspecification can be further decomposed or implemented as a program (executable). (2)Specifications, sub-specifications, and programs are all programs, but they may not be directly executable. Executable programs are called code.

34 client programmer program as contract program programmer client program client program programmer client program computer

35 A program has two roles: (1) it describes what one person (client) wants. (2) it describes what another person (programmer or computer) must do. A single person can be both client and programmer. For example, a system analyst is a programmer with respect to his firm s clients, but a client with respect to his own programming team.

36 Let prog1 and prog2 be two programs. If prog2 is better than prog1, for the client, we write prog1 prog2 We say that prog2 refines prog1, or prog1 is refined to prog2, or prog2 is a refinement of prog1. program as contract client prog1 prog2 programmer

37 Software development by refinement refinement refinement refinement... Spec Prog1 Prog2 Code

38 The specification is the principal feature of abstract programs. The form of a specification: w: [pre, post] w frame: a list of variables whose values may change pre precondition: a predicate expression describing the initial states post postcondition: a predicate expression describing the final states.

39 Law 1 strengthen postcondition If post post, then w: [pre, post] w: [pre, post ] where we read as implies and call post post proviso (required condition). It must hold whenever the law is used. For example, y: [0 < x 9, y² = x] y: [0 < x 9, y² = x y > 0] because y² = x y > 0 y² = x

40 Law 2 weaken precondition If pre pre, then w: [pre, post] w: [pre, post] The proviso pre pre must hold whenever the law is used. For example, y: [0 < x 9, y² = x] y: [0 < x, y² = x] because 0 < x 9 0 < x

41 Class discussion Do you think whether the following refinement is reasonable in the context of the human society? LawRequirement: [P.Age >= 18, Can_Watch(P, Classified_Film)] CinemaAdminstrator: [P.Age >= 15, Can_Watch(P, Classified_Film]

42 1.2.3 Formal Verification Specification S Construction Program P What to do Verification How to do it How to ensure that P is correct with respect to S? What does the correctness of P mean?

43 Methods for program verification Formal verification based on Hoare Logic Theoretical Model checking Practical C.A.R. Hoare (Microsoft) Edmund Clarke (CMU) Specificationbased inspection Specification -based testing

44 Partial and total correctness (1) Partial correctness Consider the Hoare triple: {P} S {R} It shows the partial correctness of program S with respect to P and R. This means that If the precondition P is true before initiation of a program S, then the postcondition R will be true on its completion, we say that S is correct with respect to P and R. Note that the termination of S is assumed.

45 (2) Total correctness Program S is totally correct with respect to predicates P and R iff S is partially correct and S terminates; that is, Total correctness of S = {P} S {R} + Termination of S

46 Hoare logic is designed for the proof of partial correctness of a program. It is established on the basis of first order logic, but includes additional axioms for reasoning about programs. The key of proving the termination of program S requires finding a loop variant, a mathematical function indicating that each repetition of a loop statement (e.g., while-loop) changes the loop-variable towards making the loop condition evaluate to false.

47 Program execution One of the most important properties of a program is whether or not it carries out its intended function. This property is known as functional property of program.

48 Two ways to express the functional property of a program: (1) List every initial state before the execution of the program and the corresponding final state after the execution terminates. Examples: {(x, 5), (y, 1)} initial state 1 int tem = 0; tem := x; Swap program x := y; y := tem; {(x, 1), (y, 5)} final state 1

49 {(x, 9), (y, 3)} initial state 2 int tem = 0; tem := x; Swap program x := y; y := tem; {(x, 3), (y, 9)} final state 2 {(x, 20), (y, 10)} initial state 3 int tem = 0; tem := x; Swap program x := y; y := tem; {(x, 10), (y, 20)} final state 3 many others

50 (2) Use pre- and post-assertions (conditions) Hoare triple: {P} S {R} If the assertion P is true before initiation of a program S, then the assertion R will be true on its completion. Questions: (1) Who is supposed to write P and R? (2) What axioms and inference rules do we need for a formal proof of the validity of a specific Hoare triple?

51 Axioms for Program Proving In order to prove the correctness of program S, we first need to establish necessary axioms to define the semantics of each program construct. Program constructs: (1) Assignment x := f (2) Sequence S1; S2 (3) Alternation if B then S1 if B then S1 else S2 (4) Iteration while B do S (5) Block begin end

52 Concepts and notations used in expressing axioms and rules: (1) Q[e/x] where Q is an expression or formula, x is a variable, and e is an expression. Explanation: the result of replacing all free occurrences of x in Q by e. Example: (x + y * z > y * u)[t+1/y] = x + (t + 1) * z > (t + 1) * u

53 (2) A, B C where A, B, and C are predicate formulae. Explanation: a rule of inference which states that if A and B have been proved, then C can be deduced. This expression is equivalent to: A and B => C (3) A, B C D where A, B, C, and D are predicate formulae. Explanation: a rule of inference which states that if A has been proved and C is deduced from B, then D can be deduced. This expression is equivalent to: A and (B C) => D

54 Axiom 1: Axiom of assignment {P[f/x]} x := f {P} Ass-D0 where x is a variable identifier f is an expression of a programming language without side effects, but possibly containing x. P[f/x] is a predicate resulting from P by substituting f for all occurrences of x in P.

55 Examples: (1) {(x + y) * 5 > z} {P} x := x + y S {x * 5 > z} {Q} (2) {add(x, z) + y * fact(z) > z} y := add(x, z) + y * fact(z) {y > z}

56 Class exercise Derive the pre-assertion for each of the following two assignment statements based on their post-assertion: (1) (2) x: = x + y; {x > y} y := x + y * (x + 5) {x = 2 and y * x = 10}

57 Two rules of consequence (1) {P} S {R}, R => Q {P} S {Q}, Con-D1 If the execution of program S ensures the truth of the assertion R under the preassertion P, then it also ensures the truth of every assertion logically implied by R.

58 (2) {P} S {R}, Q => P {Q} S {R}, Con-D2 If P is known to be a pre-assertion for a program S to produce result R, then so is any other assertion that logically implies P.

59 Axiom 2: Rule of composition {P} S1 {R1}, {R1} S2 {R} {P} S1; S2 {R} Com-D3 If the proven result of the first part of a program is identical with the precondition under which the second part of the program produces its intended result, then the whole program will produce the intended result, provided that the precondition of the first part is satisfied.

60 Take the following two steps to use the rule of composition: Step 1: Set the target Hoare triple for proof: {P} S1; S2 {R} Step 2: Try to find a predicate R1 such that the following two Hoare triples hold: {P} S1 {R1} and {R1} S2 {R} Challenge: how to find R1

61 Example: The target Hoare triple for proof: {x = 5 and y = 1} x: = x + 1; y := x + y {x = 6 and y = 7} Proof: Step 1: {x = 6 and x + y = 7} y := x + y {x = 6 and y = 7} (Ass-D0) This is equivalent to {x = 6 and y = 1} y := x + y {x = 6 and y = 7}

62 Step 2: {x + 1 = 6 and y = 1} (Ass-D0) x: = x + 1 {x = 6 and y = 1} This is equivalent to: { x = 5 and y = 1} x: = x + 1 {x = 6 and y = 1}

63 Step 3: { x = 5 and y = 1} (Com-D3) x: = x + 1; y := x + y {x = 6 and y = 7}

64 Class exercise Prove the validity of the following Hoare triple: {x = 5 and y = 2} x: = x * y; y := x + y * (x + 5) {x = 10 and y = 40}

65 Answer to the exercise {x = 5 and y = 2} {x * y = 10 and * y + y * 5 = 40} {x * y = 10 and x * y + y * (x * y + 5) = 40} x: = x * y; {x = 10 and x + y * (x + 5) = 40} y := x + y * (x + 5) {x = 10 and y = 40}

66 Axiom 3: Rules of alternation (selection, choice) (1) if B then S1 {P B} S1 {R}, P B => R {P} if B then S1 {R} Alt-D4 If the execution of S1 ensures the truth of R under the condition that both P and B are true, and the conjunction of P and the negation of B implies R, then the alternation statement will ensure the truth of R under the pre-assertion P.

67 (2) if B then S1 else S2 {P B} S1 {R}, {P B } S2 {R} {P} if B then S1 else S2 {R} Alt-D5 If the execution of S1 ensures the truth of R under the condition that both P and B are true, and the execution of S2 ensures the truth of R under the condition that the conjunction of P and the negation of B, then the alternation statement will ensure the truth of R under the pre-assertion P.

68 Important points on the rules of alternation: (1) The same post-assertion R is used. The following case is incorrect: {P B} S1 {R1}, {P B } S2 {R2} {P} if B then S1 else S2 {R} where neither R1 nor R2 is equivalent to R.

69 (2) The following alternative rule can be used. {P B} S1 {R1}, {P B } S2 {R2} {P} if B then S1 else S2 {R1 R2} Alt-D6 where neither R1 nor R2 is equivalent to R. Proof: H: {P B} S1 {R1} Infer: {P B} S1 {R1 R2} H: {P B } S2 {R2} Infer: {P B } S2 {R1 R2} Infer: {P} if B then S1 else S2 {R1 R2} (Con-D1, R1 => R1 R2) (Con-D1, R2 => R1 R2) (Alt-D5)

70 Example: The target Hoare triple for proof: {x <> y} if x > y then x := y 1 else x := y; {x = y x < y}

71 Proof: Step 1: Prove {x <> y x > y} x := y 1 {x = y x < y} Step 2: Prove {x <> y x <= y} x := y {x = y x < y} Step 3: Prove the target Hoare triple.

72 Step 1: Prove Proof: {x <> y x > y} x := y 1 {x = y x < y} {y 1 = y y 1 < y} (Ass-D0) x := y 1 {x = y x < y} This is equivalent to {y < y + 1} x := y 1 {x = y x < y}

73 Now the main task is to prove: x <> y x > y => y < y + 1 (L1) This can be easily proved, because y < y + 1 <=> true Therefore, we have {x <> y x > y} (L1, Con-D2) x := y 1 {x = y x < y}

74 Step 2: Prove Proof: {x <> y x <= y} x := y {x = y x < y} {y = y y < y} (Ass-D0) x := y {x = y x < y} This is equivalent to {true} x := y {x = y x < y}

75 Now the main task is to prove: x <> y x <= y => true (L2) This is true according to the rule of =>. Therefore, we have {x <> y x <= y} (L2, Con-D2) x := y {x = y x < y}

76 Step 3: Prove the target Hoare triple: {x <> y} if x > y then x := y 1 else x := y; {x = y x < y} Proof: {x <> y} (step 1, step 2, Alt-D5) if x > y then x := y 1 else x := y; {x = y x < y}

77 How can bugs be found by formal proof? Let s deliberately inject a bug in the previous alternation statement and form the following Hoare triple: {x <> y} if x > y then x := y + 1 (correct one: x := y 1) else x := y; {x = y x < y}

78 Proof: Step 1: Prove {x <> y x > y} x := y + 1 {x = y x < y} Step 2: Prove {x <> y x <= y} x := y {x = y x < y} Step 3: Prove the target Hoare triple.

79 Step 1: Prove Proof: {x <> y x > y} x := y + 1 {x = y x < y} {y + 1 = y y + 1 < y} (Ass-D0) x := y + 1 {x = y x < y} This is equivalent to {false} x := y + 1 {x = y x < y}

80 Now the main task is to prove: x <> y x > y => false (L3) This cannot be proved, because x <> y x > y is not equivalent to false. This case implies the existence of a bug in the program. But how to exactly locate the bug in general still remains an open problem.

81 Class exercise Prove the validity of the following Hoare triple: {x > 0} if x > y + 10 then x := y + 20 else y := x + 10 {x = y + 20 x < y}

82 Answer to the exercise Step 1: {x > 0 x > y + 10} x := y + 20 {x = y + 20 x < y} Step 2: {x > 0 x <= y + 10} y := x + 10 {x = y + 20 x < y}

83 Step 3: {x > 0} if x > y + 10 then x := y + 20 else y := x + 10 {x = y + 20 x < y}

84 Proof: Step 1: {y + 20 = y + 20 y + 20 < y} Ass-D0 x := y + 20 {x = y + 20 x < y} x > 0 x > y + 10 => y + 20 = y + 20 y + 20 < y (L1)

85 {x > 0 x > y + 10} (L1, Con-D2) x := y + 20 {x = y + 20 x < y} Step 2: {x = x + 30 x < x + 10} (Ass-D0) y := x + 10 {x = y + 20 x < y} x > 0 x <= y + 10 => x = x + 30 x < x + 10 (L2)

86 {x > 0 x <= y + 10 } (L2, Con-D2) y := x + 10 {x = y + 20 x < y} Step 3: {x > 0} (Step 1, Step 2, Alt-D5) if x > y + 10 then x := y + 20 else y := x + 10 {x = y + 20 x < y}

87 Axiom 4: Rule of iteration (while B do S) {P B} S {P} {P} while B do S {P B} Ite-D7 If P holds and B is true before the execution of statement S and its execution sustains the truth of P, then the execution of the iteration statement under the precondition P will sustain the truth of P and makes B false. P is called invariant of the loop.

88 Important points on the rule of iteration: (1) Deriving the invariant P is a process of abstracting the while-loop statement into a predicate expression that expresses its meaning (or function). (2) For the same while-loop, there may be more than one invariant. For example, true can be an invariant for any while-loop. (3) Deriving appropriate invariant P is the most challenging task in program proving, and there is no systematic method for this.

89 Example: A program of finding the quotient q and remainder r obtained on dividing x by y, where both x and y are non-zero natural numbers. r := x; q := 0; while y <= r do S begin r := r - y; q := 1 + q end

90 An important property of this program is when it terminates, we can recover the numerator x by adding to the remainder r the product of the divisor y and the quotient q (i.e., x = r + y q). Furthermore, the remainder is less than the divisor. These properties can be expressed formally: {true} S {x = r + y q y <=r} where S represents the program displayed above.

91 The proof can be conducted in two steps: Sept 1: {true} r := x; q := 0; {x = r + y q} Step 2: {x = r + y q} while y <= r do begin r := r - y; q := 1 + q end {x = r + y q y <=r}

92 A formal proof of the correctness of program S: 1 true => x = x + y 0 Lemma 1 2 {x = x + y 0} r := x {x = r + y 0 } Ass-D0 3 {x = r + y 0} q := 0 {x = r + y q} Ass-D0 4 {true} r := x {x = r + y 0 } Con-D2(1,2) 5 {true} r := x; q := 0 {x = r + y q} Com-D3(4,3) 6 x = r + y q y <= r => x = (r y) + y (1 + q) Lemma 2 7 {x = (r y) + y (1 + q)} r := r y {x = r + y (1 + q)} Ass-D0 8 {x = r + y (1 + q)} q := 1 + q {x = r + y q)} Ass-D0

93 9 {x = (r y) + y (1 + q)} r := r y; q := 1 + q {x = r + y q)} Com-D3(7, 8) 10 {x = r + y q) y <= r} r := r y; q := 1 + q {x = r + y q)} Con-D2(6,9) 11 {x = r + y q)} while y <= r do begin r := r y; q := 1 + q end {x = r + y q y <= r} Ite-D7(10)

94 12 {true} r := x; q := 0; while y <= r do begin r := r y; q := 1 + q end {x = r + y q y <= r} Com-D3(5, 11) Observation: This program should have used x > 0 and y > 0 in the preassertion, but since it only ensures the termination of the while loop, its absence in the pre-assertion does not affect the proof of the partial correctness.

95 Software development based on formal verification Construction Construction Construction... Spec Prog1 Prog2 Code verification verification verification

96 Application Examples of Formal Methods 1The company Praxis in the UK has used VDM,CSP, and Z to develop a toolset for the SSADM development method. 2.The IBM Hursley in the UK has collaborated with the PRG of Oxford university to apply Z to the development of a Customer Information Control System(CICS). 3.The Darlington Nuclear Generator System (Ontario Hydro) in Canada has used Parnas SCR (Software Cost Reduction) to verify the Shutdown System. 4.The company CSK in Japan has used VDM to develop a stock processing system. 5.The company FeliCa has applied VDM++ to the development of a mobile phone IC chip.

97 1.3 Challenges to formal methods The complexity of formal specifications grows rapidly as their scale increases. This makes evolution of specifications, which is an inevitable activity in real projects, very hard and costly. Formal methods only offer notations and rules, but not tell how each kind of technique (e.g., specification, refinement, verification) can be effectively applied in the context of practical software development.

98 The laws (e.g., weakening precondition and strengthening postcondition) of refinement do not ensure that the program developed is satisfactory. Example1: sqrt(x: int) y: real sqrt1(x: int) y: real pre x 0 pre x 0 post y² = x post y² = x y > 0 sqrt1 is a refinement of sqr2, but it may not be exactly what the user wants.

99 Example2: OP(x: int) y: int pre true post x 0 y = x + 1 x < 0 y = x - 1 OP1(x: int) y: int pre true post x 0 y = x + 1 OP1 is a refinement of OP, but OP1 does not provide all the functions defined in OP, and OP1 is also infeasible (which cannot be refined into code.)

100 Hoare logic {P} S {Q} for program correctness proof does not suit for programs with side effects. Example: x := y + f(y) + z + f(x), where the execution of function f definitely causes change of the global variable z.

101 Deriving invariants for iteration statements, especially deeply nested iteration statements, is extremely difficult, if not impossible. In Java, break and continue statements can be used in iterations. This situation increases significantly the difficulty for formal verification. Example: the rule for the proof of a while loop: {inv B} S {inv} {inv} while B do S end {inv B}

102 Formal verification is almost impossible for component-based programs, because the source code of many components are not available. The tool support is not good enough to make formal methods practical in industry.

103 There are many other technical challenges for specifying and verifying object-oriented programs. Reference: Specification and Verification Challenges for Sequential Object-Oriented Programs, by Gary T. Leavens, K. Rustand M. Leino, and Peter Muller, Formal Aspects of Computing (2007) 19:

104 There are many practical constraints as well. Examples: (1) Practitioners may lack the skills for abstraction in writing formal specifications. (2) Managers may not want to introduce formal methods before seeing hard evidence of the effectiveness of formal methods. (3) Budget, schedule, and company s environment may not allow practitioners to use formal methods.

105 View of David Parnas Proofs of realistic programs involve long complex expressions and require patience, time, and diligence that developers do not think they have. Inspection methods are more effective than informal reviews and require less effort than formal proof. Reference: The Role of Inspection in Software Quality Assurance, IEEE Transactions on Software Engineering, Vol. 29, No. 8, August 2003.

106 Software engineering dilemma Happy world Formal Methods Software practitioner Traditional SE

107 1.4 Formal Engineering Methods for the challenges Formal Engineering Methods (FEM) provide ways to integrate Formal Methods into the commonly used software engineering methods and approaches to improve their rigor, comprehensibility, effectiveness, and tool supportability for software productivity and quality.

108 Formal Methods Formal Engineering Methods Application of Formal Methods in Software Engineering

109 The difference between FM and FEM FM answers the question: what should we do and why? FEM answers the question: what can we do and how?

110 1.5 SOFL: a specific formal engineering method SOFL stands for Structured Object-Oriented Formal Language Started at the University of Manchester, UK in Completed at Hiroshima City University in Finalized at Hosei University in 2002.

111 SOFL = Language + Method + Process As a language, SOFL supports effective integration of graphical and formal notations for constructability, comprehensibility, and maintainability. As a method, SOFL adopts a three-step approach to constructing formal specifications, and specification-based inspection and testing for verification and validation. It also combines the structured method and object-oriented method for software development. As a process, SOFL adopts both evolution and refinement, and emphasizes the paradigm of first specification and then incremental implementation.

112 Comparison between FM and the SOFL method FM SOFL Formal Specification Gradual Formal Specification (three-step formal specification) Formal Refinement Transformation (from structured specifications to object-oriented implementations) Formal Verification Specification-Based Inspection Specification-Based Testing

113 The feature of SOFL The SOFL method strikes a good balance among the three qualities: Simplicity, Visualization, Preciseness communication communication

114 The structure of a SOFL specification: CDFDs + modules + classes class S1; const; type; var; inv; method Init; method P1; method P2; method P3; module SYSTEM; const; type; var; inv; process Init; process A1; process A2; end-module; A1 s A2 end-class; s B2 B1 class S2; const; type; var; inv; method Init; method Q1; method Q2; method Q3; end-class; module A2-decom; const; type; var; inv; process Init; process B1; process B2; process B3; end-module; B3

115 Component Architecture

116 The Textbook Formal Engineering for Industrial Software Development Using the SOFL Method, by Shaoying Liu, Springer-Verlag, 2004, ISBN 软件开发的形式化工程方法 结构化 + 面向对象 + 形式化 精華大学出版社