Lecture 8: Decision Tables 2018-05-28 Prof. Dr. Andreas Podelski, - PDF document

Softwaretechnik / Software-Engineering Lecture 8: Decision Tables 2018-05-28 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universität Freiburg, Germany – 8 – 2018-05-28 – 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 • Decision Tables VL 7 • Syntax, Semantics . . • Completeness, Consistency, ... . • Scenarios VL 8 . • User Stories, Use Cases . . • Live Sequence Charts – 8 – 2018-05-28 – Sblockcontent – VL 9 • Syntax, Semantics . . . • Definition: Software & SW Specification VL 10 . • Wrap-Up . . 2 /48

Risks Implied by Bad Requirements Speci � cations preparation of tests , • without a description of allowed outcomes, tests are design and implementation , randomly searching for generic errors (like crashes) • without specification, � systematic testing hardly possible programmers may just “ask around” when in doubt, possibly yielding different interpretations acceptance by � difficult integration customer, resolving later negotiation objections or regress (with customer, claims, require- marketing ments design / design / quality quality acceptance acceptance negotiation negotiation speci- implemen- implemen- assurance assurance fication tation tation • without specification, it department, or is unclear at delivery ...) time whether behaviour customer developer is an error (developer docu- docu- needs to fix) or correct mentation mentation (customer needs to accept and pay) � re-use re-use nasty disputes , additional effort documentation , e.g., the user’s manual , • without specification, the user’s manual author can only re-use , describe what the system does , not what it should do ( “every observation is a feature” ) • without specification, re-use needs to be based on – 6 – 2018-05-07 – Sreintro – re-reading the code � risk of unexpected changes • later re-implementations . – 8 – 2018-05-28 – main – • the new software may need to adhere to requirements of the old software; if not properly specified, the new software needs to be a 1:1 re-implementation of the old � additional effort 6 /42 3 /48 Requirements on Requirements Speci � cations A requirements specification should be • correct • neutral , abstract — it correctly represents the wishes/needs of — a requirements specification does not the customer, constrain the realisation more than necessary, • complete — all requirements (existing in somebody’s head, or a document, or ...) should be present, • traceable , comprehensible — the sources of requirements are documented, • relevant requirements are uniquely identifiable, — things which are not relevant to the project should not be constrained, • consistent , free of contradictions • testable , objective — each requirement is compatible with all other — the final product can objectively be checked requirements; otherwise the requirements are for satisfying a requirement. not realisable , • Correctness and completeness are defined relative to something which is usually only in the customer’s head . � is is difficult to be sure of correctness and completeness . – 6 – 2018-05-07 – Sre – • “Dear customer, please tell me what is in your head!” is in almost all cases not a solution ! It’s not unusual that even the customer does not precisely know...! – 8 – 2018-05-28 – main – For example, the customer may not be aware of contradictions due to technical limitations. 14 /42 4 /48

Structure of Topic Areas Example : Requirements Engineering Vocabulary e.g. consistent, complete, tacit, etc. In the course: Techniques e.g. “Whenever a crash...” Use Cases informal Pattern Language e.g. “Always, if h crash i at t ...” semi-formal Decision Tables e.g. “ � t, t � � Time • ...” formal Live Sequence Charts – 1 – 2018-04-16 – Sccontent – – 8 – 2018-05-28 – main – 28 /45 5 /48 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 – 8 – 2018-05-28 – Scontent07 – • Discussion 6 /48

Decision Tables – 8 – 2018-05-28 – main – 7 /48 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 c 1 description of condition 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 . . . . ... . . . . . . . . a k description of action 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 – 2018-05-14 – Scoreet – • ( v 1 ,i , . . . , v m,i ) is called premise of rule r i , – 8 – 2018-05-28 – main – ( w 1 ,i , . . . , w k,i ) is called effect of r i . 24 /64 8 /48

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 . . . . ... . . . . . . . . a k description of action 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 ) | {z } | {z } =: F pre ( r ) =: F e � ( r ) where – 7 – 2018-05-14 – Scoreet – � , if v = × x � � F ( v, x ) = ¬ x , if v = � – 8 – 2018-05-28 – main – � , if v = � true � 25 /64 9 /48 Decision Table Semantics: Example � x , if v = × F ( r ) := F ( v 1 , c 1 ) � · · · � F ( v m , c m ) � � F ( v, x ) = ¬ x , if v = � � 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 – 2018-05-14 – Scoreet – – 8 – 2018-05-28 – main – 26 /64 10 /48

Decision Tables as Requirements Specification – 8 – 2018-05-28 – main – 11 /48 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 button pressed? × × − Ventilation system of b off ventilation off? × − ∗ lecture hall 101-0-026. ventilation on? − × ∗ on start ventilation × − − go stop stop ventilation − × − • 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 ) . – 8 – 2018-05-28 – 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 ) . 12 /48