Softwaretechnik / Software-Engineering Lecture 07: Formal Methods for Requirements Engineering 2015-05-21 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal – 07 – 2015-05-21 – main – Albert-Ludwigs-Universit¨ at Freiburg, Germany
– 07 – 2015-05-21 – main – You Are Here 2 /54
– 07 – 2015-05-21 – main – L 1: 20.4., Mo Introduction T 1: 23.4., Do L 2: 27.4., Mo Development L 3: 30.4., Do L 4: 4.5., Mo Process, Metrics T 2: 7.5., Do L 5: 11.5., Mo - 14.5., Do Requirements L 6: 18.5., Mo L 7: 21.5., Do Engineering - 25.5., Mo - 28.5., Do T 3: 1.6., Mo - 4.6., Do L 8: 8.6., Mo Design Modelling L 9: 11.6., Do & Analysis L 10: 15.6., Mo T 4: 18.6., Do L 11: 22.6., Mo Implementation, L 12: 25.6., Do L 13: 29.6., Mo Testing T 5: 2.7., Do L 14: 6.7., Mo Formal L 15: 9.7., Do L 16: 13.7., Mo Verification T 6: 16.7., Do L 17: 20.7., Mo The Rest L 18: 23.7., Do 3 /54
Contents & Goals Last Lecture: • requirements engineering basics, “the natural language case” This Lecture: • Educational Objectives: Capabilities for following tasks/questions. • What is a rule, a decision table? • What is the interleaving, collecting, update semantics? • Analyse this rule for: vacuous, redundant, complete, consistent • In what sense can decision tables serve as requirements specification language? • Formalise this requirement with a decision table. • What does this have to do with the previous lecture? • Content: – 07 – 2015-05-21 – Sprelim – • definition decision table syntax and interleaving semantics, • definition tables as requirements specification, • interesting/useful properties of decision tables 4 /54
Recall: Formal Methods Formal Methods (in the Software Development Domain) ... back to “ ‘technological paradise’ where ‘no acts of God can be permitted’ and everything happens according to the blueprints”. (Kopetz, 2011; Lovins and Lovins, 2001) Definition. [ Bjørner and Havelund (2014) ] A method is called formal method if and only if its techniques and tools can be explained in mathematics. Example : If a method includes, as a tool, a specification language, then that language has – 1 – 2015-04-20 – main – • a formal syntax , Formal, Rigorous, or Systematic Development • a formal semantics , and “The techniques of a formal method help • a formal proof system . • construct a specification, and/or 20 /37 • analyse a specification, and/or • transform ( refine ) one (or more) specification(s) into a program . Decision tables (DT) are one example for a formal requirements specification language: The techniques of a formal method, (besides the specification languages) are typically software packages that help developers use the techniques and other • we give a formal syntax and semantics, – 07 – 2015-05-21 – Srefm – tools. • requirements quality criteria , e.g. The aim of developing software, either completeness, can be formally defined , • formally (all arguments are formal) or • thus for a DT we can formally argue • rigorously (some arguments are made and they are formal) or – 1 – 2015-04-20 – main – whether it is complete or not, • systematically (some arguments are made on a form that can be made formal) • (some) formal arguments can be done is to (be able to) reason in a precise manner about properties of what is automatically ( → tool support). being developed.” (Bjørner and Havelund, 2014) 21 /37 5 /54
... so, off to “ ‘technological paradise’ where [...] everything happens according to the blueprints”. (Kopetz, 2011; Lovins and Lovins, 2001) – 07 – 2015-05-21 – Srefm – 6 /54
Formal Specification and Analysis of Requirements: Decision Tables for Example – 07 – 2015-05-21 – main – 7 /54
Decision Tables Definition. [ Decision Table ] Let C be a set of (atomic) conditions and A a set of actions . (i) The set Φ( C ) of premises over C consists of the terms defined by the following grammar: ϕ ::= true | c | ¬ ϕ 1 | ϕ 1 ∨ ϕ 2 , c ∈ C . (ii) A rule r (over C and A ) is a pair ( ϕ, α ) , written ϕ → α , which comprises • a premise ϕ ∈ Φ( C ) and • a finite set α ⊆ A of actions (the effect ). (iii) Any finite set T of rules (over C and A ) is called decision table (over C and A ). – 07 – 2015-05-21 – Set – 8 /54
Decision Tables: Example This might’ve been the specification of lecture hall 101-0-026’s ventilation system : • Conditions : C = { button pressed , ventilation on , ventilation off } shorthands : { b, on , off } . • Actions : A = { do ventilate , stop ventilate } shorthands : { go , stop } . • Rules : • r 1 = b ∧ off → { go } • r 2 = b ∧ on → { stop } • Decision table : T = { r 1 , r 2 } . – 07 – 2015-05-21 – Set – 9 /54
And Where’s The Table? Decision tables can be written in tabular form: T : room ventilation r 1 r 2 × × b button pressed? ventilation off? × - off ventilation on? - × on × go start ventilation - stop ventilation - × stop From the table to the rules: • r 1 = b ∧ on ∧ ¬ off → { go } • r 2 = b ∧ ¬ on ∧ off → { stop } – 07 – 2015-05-21 – Set – 10 /54
And Where’s The Table? Decision tables can be written in tabular form: T : room ventilation r 1 r 2 r 3 × × ∗ b button pressed? ventilation off? × - - off ventilation on? - × - on × go start ventilation - - stop ventilation - × - stop From the table to the rules: • r 1 = b ∧ on ∧ ¬ off → { go } • r 2 = b ∧ ¬ on ∧ off → { stop } • r 3 = ¬ on ∧ ¬ off → ∅ – 07 – 2015-05-21 – Set – 10 /54
Decision Tables vs. Rules In General T : decision table · · · r 1 r n description condition 1 · · · c 1 v 1 , 1 v 1 ,n . . . . ... . . . . . . . . description condition m · · · c m v m, 1 v m,n description action 1 · · · a 1 w 1 , 1 w 1 ,n . . . . ... . . . . . . . . description action k · · · a k w k, 1 w k,n v i,j ∈ {− , × , ∗} , w i,j ∈ {− , ×} • C = { c 1 , . . . , c m } , A = { a 1 , . . . , a k } c , if v = × • r i = F ( v 1 ,i , c i ) ∧ · · · ∧ F ( v m,i , c m ) → { a j | w j,i = ×}} , F ( v, c ) = ¬ c , if v = − , if v = ∗ true – 07 – 2015-05-21 – Set – Recall : � 1 ≤ j ≤ m F ( v j,i , c i ) = true by definition. • T = { r 1 , . . . , r n } (multiple tables T 1 , . . . , T n denote one set of rules) • From rules to table: use disjunctive normal form of ϕ . 11 /54
By the Way: Decision Tables as Business Rules T 1 : cash a cheque else r 1 r 2 c 1 credit limit exceeded? × × c 2 payment history ok? × - c 3 overdraft < 500 e ? - ∗ cash cheque × - × a 1 a 2 do not cash cheque - × - a 3 offer new conditions × - - (Balzert, 2009) • One customer session at the bank: { a 1 ,a 3 } → σ ′ − − − − − σ if σ = { c 1 �→ 1 , c 2 �→ 1 , c 3 �→ 0 } . – 07 – 2015-05-21 – Set – • clerk checks database state σ , • database says: credit limit exceeded over 500 e , but payment history ok, • clerk cashes cheque but offers new conditions. 12 /54
Decision Table Standard Semantics • Let C be a set of conditions and A a set of actions. • Let Σ := ( C → B ) be the set of valuations of C , B := { 0 , 1 } . • Let ϕ ∈ Φ( C ) be a premise and σ ∈ Σ . Set: • σ | = true , for all σ ∈ Σ , • σ | = c , if and only if σ ( c ) = 1 , • σ | = ¬ ϕ 1 , if and only if σ �| = ϕ , • σ | = ϕ 1 ∨ ϕ 2 , if and only if σ | = ϕ 1 or σ | = ϕ 2 . Note : In the following, we may use ∧ , = ⇒ , ⇐ ⇒ as abbreviations as usual. • We call a rule r = ϕ → α over C and A enabled in σ if and only if σ | = ϕ . • Let T be a decision table over C and A . The set � T � interleave , the (standard) interleaving semantics/interpretation of T , consists of the finite or infinite computation paths – 07 – 2015-05-21 – Set – α 1 α 2 π = σ 0 − → σ 1 − → σ 2 · · · , σ i ∈ Σ , i ∈ N 0 , where ∀ i ∈ N 0 ∃ r = ϕ → α ∈ T • σ i | = ϕ ∧ α i +1 = α. 13 /54
Decision Tables: Example Back to lecture hall 101-0-026’s ventilation system : • C = { button pressed , ventilation on , ventilation off } shorthands : { b, on , off } . • A = { do ventilate , stop ventilate } shorthands : { go , stop } . • r 1 = b ∧ ventilation off → { go } , r 2 = b ∧ ventilation on → { stop } , T = { r 1 , r 2 } . What’s in � T � interleaving ? Naja, for example { go } { stop } { go } { go } • π 1 = σ 0 − − − → σ 1 − − − − → σ 2 • also π 4 = σ 0 − − − → σ 1 − − − → σ 2 . . . σ 0 = { b �→ 1 , off �→ 1 , on �→ 0 } , σ i = { b �→ 1 , off �→ 1 , on �→ 0 } , i ∈ N 0 σ 1 = { b �→ 1 , off �→ 0 , on �→ 1 } { go } { go , stop } • but not σ 0 − − − → σ 1 − − − − − − → σ 2 • π 2 = σ 0 σ 0 = { b �→ 0 , off �→ 1 , on �→ 0 } , σ 0 = { b �→ 0 , off �→ 1 , on �→ 0 } – 07 – 2015-05-21 – Set – { go } { go } • and also π 3 = σ 0 − − − → σ 1 − − − → σ 2 σ 0 = { b �→ 1 , off �→ 1 , on �→ 0 } , σ 1 = { b �→ 1 , off �→ 1 , on �→ 0 } 14 /54
Recommend
More recommend
