Lecture 7: Formal Methods for Requirements Engineering 2017-05-29 - PowerPoint PPT Presentation

Softwaretechnik / Software-Engineering Lecture 7: Formal Methods for Requirements Engineering 2017-05-29 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universität Freiburg, Germany – 7 – 2017-05-29 – main –

Topic Area Requirements Engineering: Content • Introduction VL 6 • Requirements Specification • Desired Properties • Kinds of Requirements • Analysis Techniques . . . • Documents • Dictionary, Specification • Specification Languages • Natural Language VL 7 • Decision Tables . • Syntax, Semantics . . • Completeness, Consistency, ... VL 8 • Scenarios . • User Stories, Use Cases . . – 7 – 2017-05-29 – Sblockcontent – • Working Definition: Software VL 9 • Live Sequence Charts . • Syntax, Semantics . . • Discussion 2 /49

(A Selection of) Analysis Techniques Focus current desired innovation Analysis Technique situation situation consequences Analysis of existing data and documents Observation � closed � Questionning with questions structured open Interview Modelling Experiments Prototyping Participative development (Ludewig and Lichter, 2013) – 6 – 2017-05-22 – Sreana – – 7 – 2017-05-29 – main – 23 /41 3 /49

Topic Area Requirements Engineering: Content • Introduction VL 6 • Requirements Specification • Desired Properties • Kinds of Requirements • Analysis Techniques . . . • Documents • Dictionary, Specification • Specification Languages • Natural Language VL 7 • Decision Tables . • Syntax, Semantics . . • Completeness, Consistency, ... VL 8 • Scenarios . • User Stories, Use Cases . . – 7 – 2017-05-29 – Sblockcontent – • Working Definition: Software VL 9 • Live Sequence Charts . • Syntax, Semantics . . • Discussion 4 /49

Tell Them What You’ve Told Them. . . • Requirements Documents are important — e.g., for • negotiation, design & implementation, documentation, testing, delivery, re-use, re-implementation. • A Requirements Specification should be • correct, complete, relevant, consistent, neutral, traceable, objective. Note: vague vs. abstract. • Requirements Representations should be • easily understandable, precise, easily maintainable, easily usable • Distinguish • hard / soft, • functional / non-functional, • open / tacit. • It is the task of the analyst to elicit requirements. • Natural language is inherently imprecise, counter-measures: – 6 – 2017-05-22 – Sttwytt – • natural language patterns. – 7 – 2017-05-29 – main – • Do not underestimate the value of a good dictionary . 39 /41 5 /49

Topic Area Requirements Engineering: Content • Introduction VL 6 • Requirements Specification • Desired Properties • Kinds of Requirements • Analysis Techniques . . . • Documents • Dictionary, Specification • Specification Languages • Natural Language VL 7 • Decision Tables . • Syntax, Semantics . . • Completeness, Consistency, ... VL 8 • Scenarios . • User Stories, Use Cases . . – 7 – 2017-05-29 – Sblockcontent – • Working Definition: Software VL 9 • Live Sequence Charts . • Syntax, Semantics . . • Discussion 6 /49

Content • (Basic) Decision Tables • Syntax, Semantics • ...for Requirements Specification • ...for Requirements Analysis • Completeness, • Useless Rules, • Determinism Logic • Domain Modelling • Conflict Axiom, • Relative Completeness, • Vacuous Rules, • Conflict Relation • Collecting Semantics • Discussion – 7 – 2017-05-29 – Scontent – 7 /49

– 7 – 2017-05-29 – main – Decision Tables 8 /49

Decision Tables: Example T r 1 r 2 r 3 × × − c 1 × − ∗ c 2 − × ∗ c 3 × − − a 1 − × − a 2 – 7 – 2017-05-29 – Scoreet – 9 /49

Decision Table Syntax • Let C be a set of conditions and A be a set of actions s.t. C ∩ A = ∅ . • A decision table T over C and A is a labelled ( m + k ) × n matrix T : decision table · · · r 1 r n description of condition c 1 · · · c 1 v 1 , 1 v 1 ,n . . . . ... . . . . . . . . description of condition c m · · · c m v m, 1 v m,n description of action a 1 · · · a 1 w 1 , 1 w 1 ,n . . . . ... . . . . . . . . description of action a k · · · a k w k, 1 w k,n – 7 – 2017-05-29 – Scoreet – 10 /49

Decision Table Syntax • Let C be a set of conditions and A be a set of actions s.t. C ∩ A = ∅ . • A decision table T over C and A is a labelled ( m + k ) × n matrix T : decision table · · · r 1 r n description of condition c 1 · · · c 1 v 1 , 1 v 1 ,n . . . . ... . . . . . . . . description of condition c m · · · c m v m, 1 v m,n description of action a 1 · · · a 1 w 1 , 1 w 1 ,n . . . . ... . . . . . . . . description of action a k · · · a k w k, 1 w k,n • where • c 1 , . . . , c m ∈ C , • v 1 , 1 , . . . , v m,n ∈ {− , × , ∗} and • a 1 , . . . , a k ∈ A , • w 1 , 1 , . . . , w k,n ∈ {− , ×} . • Columns ( v 1 ,i , . . . , v m,i , w 1 ,i , . . . , w k,i ) , 1 ≤ i ≤ n , are called rules , • r 1 , . . . , r n are rule names . – 7 – 2017-05-29 – Scoreet – • ( v 1 ,i , . . . , v m,i ) is called premise of rule r i , ( w 1 ,i , . . . , w k,i ) is called effect of r i . 10 /49

Decision Table Semantics Each rule r ∈ { r 1 , . . . , r n } of table T T : decision table · · · r 1 r n description of condition c 1 · · · c 1 v 1 , 1 v 1 ,n . . . . ... . . . . . . . . c m description of condition c m v m, 1 · · · v m,n a 1 description of action a 1 w 1 , 1 · · · w 1 ,n . . . . ... . . . . . . . . description of action a k · · · a k w k, 1 w k,n is assigned to a propositional logical formula F ( r ) over signature C ˙ ∪ A as follows: • Let ( v 1 , . . . , v m ) and ( w 1 , . . . , w k ) be premise and effect of r . • Then F ( r ) := F ( v 1 , c 1 ) ∧ · · · ∧ F ( v m , c m ) ∧ F ( w 1 , a 1 ) ∧ · · · ∧ F ( w k , a k ) � �� � � �� � =: F pre ( r ) =: F eff ( r ) where  – 7 – 2017-05-29 – Scoreet – , if v = × x   F ( v, x ) = ¬ x , if v = −   true , if v = ∗ 11 /49

Decision Table Semantics: Example  , if v = × x  F ( r ) := F ( v 1 , c 1 ) ∧ · · · ∧ F ( v m , c m )  F ( v, x ) = , if v = − ¬ x ∧ F ( v 1 , a 1 ) ∧ · · · ∧ F ( v k , a k )  true , if v = ∗  T r 1 r 2 r 3 c 1 × × − × − ∗ c 2 c 3 − × ∗ a 1 × − − a 2 − × − • F ( r 1 ) = c 1 ∧ c 2 ∧ ¬ c 3 ∧ a 1 ∧ ¬ a 2 • F ( r 2 ) = c 1 ∧ ¬ c 2 ∧ c 3 ∧ ¬ a 1 ∧ a 2 • F ( r 3 ) = ¬ c 1 ∧ true ∧ true ∧ ¬ a 1 ∧ ¬ a 2 – 7 – 2017-05-29 – Scoreet – 12 /49

Decision Tables as Requirements Specification – 7 – 2017-05-29 – main – 13 /49

Yes, And? We can use decision tables to model (describe or prescribe) the behaviour of software ! Example : T : room ventilation r 1 r 2 r 3 × × − b button pressed? Ventilation system of × − ∗ off ventilation off? lecture hall 101-0-026. − × ∗ on ventilation on? start ventilation × − − go stop ventilation − × − stop • We can observe whether button is pressed and whether room ventilation is on or off , and whether (we intend to) start ventilation of stop ventilation . • We can model our observation by a boolean valuation σ : C ∪ A → B , e.g., set σ ( b ) := true , if button pressed now and σ ( b ) := false , if button not pressed now . σ ( go ) := true , we plan to start ventilation and σ ( go ) := false , we plan to stop ventilation . • A valuation σ : C ∪ A → B can be used to assign a truth value to a propositional formula ϕ over C ∪ A . As usual, we write σ | = ϕ iff ϕ evaluates to true under σ (and σ �| = ϕ otherwise). • Rule formulae F ( r ) are propositional formulae over C ∪ A thus, given σ , we have either σ | = F ( r ) or σ �| = F ( r ) . – 7 – 2017-05-29 – Setasspec – • Let σ be a model of an observation of C and A . We say, σ is allowed by decision table T if and only if there exists a rule r in T such that σ | = F ( r ) . 14 /49

Example T : room ventilation r 1 r 2 r 3 button pressed? × × − b × − ∗ off ventilation off? ventilation on? − × ∗ on start ventilation × − − go stop ventilation − × − stop F ( r 1 ) = b ∧ off ∧ ¬ on ∧ go ∧ ¬ stop F ( r 2 ) = b ∧ ¬ off ∧ on ∧ ¬ go ∧ stop F ( r 3 ) = ¬ b ∧ true ∧ true ∧ ¬ go ∧ ¬ stop (i) Assume : button pressed, ventilation off, we (only) plan to start the ventilation. – 7 – 2017-05-29 – Setasspec – 15 /49