1 an Introduction to Formal Modeling in Requirements Engineering
Total Page:16
File Type:pdf, Size:1020Kb
University of Toronto Department of Computer Science University of Toronto Department of Computer Science Outline An Introduction to ‹ Why do we need Formal Methods in RE? you are here! Formal Modeling ‹ What do formal methods have to offer? ‹ A survey of existing techniques in Requirements Engineering ‹ Example modeling language: SCR ƒ The language ƒ Case study Prof Steve Easterbrook ƒ Advantages and disadvantages Dept of Computer Science, ‹ Example analysis technique: Model Checking University of Toronto, Canada ƒ How it works ƒ Case Study [email protected] ƒ Advantages and disadvantages http://www.cs.toronto.edu/~sme ‹ Where next? © 2001, Steve Easterbrook 1 © 2000-2002, Steve Easterbrook 2 University of Toronto Department of Computer Science University of Toronto Department of Computer Science What are Formal Methods? Example formal system: Propositional Logic ‹ First Order Propositional Logic provides: ‹ Broad View (Leveson) ƒ a set of primitives for building expressions: ƒ application of discrete mathematics to software engineering variables, numeric constants, brackets ƒ involves modeling and analysis ƒ a set of logical connectives: ƒ with an underlying mathematically-precise notation and (Ÿ), or (⁄), not (ÿ), implies (Æ), logical equality (≡) ƒ the quantifiers: ‹ Narrow View (Wing) " - “for all” $ - “there exists” ƒ Use of a formal language ƒ a set of deduction rules ÿ a set of strings over some well-defined alphabet, with rules for distinguishing which strings belong to the language ‹ ƒ Formal reasoning about formulae in the language Expressions in FOPL ÿ E.g. formal proofs: use axioms and proof rules to demonstrate that some formula ƒ expressions can be true or false is in the language (x>y Ÿ y>z) Æ x>z x+1 < x-1 x=y y=x ≡ "x ($y (y=x+z)) x,y,z ((x>y y>z)) x>z) ‹ For requirements modeling… " Ÿ Æ x>3 ⁄ x<-6 ƒ A notation is formal if: ‹ Open vs. Closed Expressions ÿ …it comes with a formal set of rules which define its syntax and semantics. ÿ …the rules can be used to analyse expressions to determine if they are ƒ a variable that is quantified is bound (otherwise it is free) syntactically well-formed or to prove properties about them. ƒ if all the variables are bound, the formula is closed ƒ a closed formula is either true or false © 2000-2002, Steve Easterbrook 3 © 2000-2002, Steve Easterbrook 4 University of Toronto Department of Computer Science University of Toronto Department of Computer Science The Essential Software Process? What does correctness mean? Source: Adapted from Blum, 1992, p32 Application Domain Machine Domain Real World ‹ Some distinctions: Problem ƒ Domain Properties are things in the application domain that are true whether or not we ever build the proposed system Statement ƒ Requirements are things in the application domain that we wish to be made true by delivering the proposed system ƒ A specification is a description of the behaviours the program must have in order to meet the requirements Validation Correctness Implementation Verification ‹ Two correctness (verification) criteria: Correspondence Statement ƒ The Program running on a particular Computer satisfies the Specification ƒ The Specification, in the context of the given domain properties, satisfies the requirements ‹ Two completeness (validation) criteria: ƒ We discovered all the important requirements System ƒ We discovered all the relevant domain properties © 2000-2002, Steve Easterbrook © 2000-2002, Steve Easterbrook 5 Source: Adapted from Jackson, 1995, p170-171 6 1 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Understanding the distinctions… Another Example ‹ Requirement R: ‹ Requirement R: ƒ “Reverse thrust shall only be enabled when the aircraft is moving on the ƒ “The database shall only be accessible by authorized personnel” runway” ‹ Domain Properties D: ‹ Domain Properties D: ƒ Authorized personnel have passwords ƒ Wheel pulses on if and only if wheels turning ƒ Passwords are never shared with non-authorized personnel ƒ Wheels turning if and only if moving on runway ‹ Specification S: ‹ Specification S: ƒ Access to the database shall only be granted after the user types an ƒ Reverse thrust enabled if and only if wheel pulses on authorized password ‹ S + D imply R ‹ S + D imply R ƒ But what if the domain assumptions are wrong? ƒ But what if the domain assumptions are wrong? © 2000-2002, Steve Easterbrook © 2000-2002, Steve Easterbrook Source: Adapted from Jackson, 1995, p172 7 Source: Adapted from Jackson, 1995, p172 8 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Where do things go wrong? Where do things go wrong? ‹‹ ComputerComputer goesgoes wrongwrong (very(very rare!)rare!) ‹ Application Domain Machine Domain ‹ Causes:Causes: ƒ ƒPowerPower failure failure ƒ ƒCircuitCircuit or or Chip Chip failure failure ƒ ƒOperatingOperating System System Failure Failure ƒ ƒUnforeseenUnforeseen Device Device or or Network Network failure failure ‹‹ CaughtCaught by:by: ƒ ƒDesignDesign analysis, analysis, testing, testing, certification certification through through use, use, …… Application Domain Machine Domain ‹‹ ProgramProgram isis wrongwrong (rare?)(rare?) ‹‹ Causes:Causes: ƒ ƒLatentLatent bugs bugs (programmer (programmer error) error) ƒ ƒMisunderstoodMisunderstood specification specification ƒ ƒPoorPoor configuration configuration management management ƒ ƒPoorPoor change change control control ‹‹ CaughtCaught by:by: ƒ ƒTestTest to to specification; specification; Inspection Inspection and and Walkthroughs Walkthroughs © 2000-2002, Steve Easterbrook 9 © 2000-2002, Steve Easterbrook 10 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Where do things go wrong? Where do things go wrong? ‹‹ SpecificationSpecification isis wrongwrong (common)(common) Application Domain Machine Domain ‹‹ Causes:Causes: ƒ ƒMisunderstoodMisunderstood requirements requirements ƒ ƒPoorPoor choice choice of of specification specification language language ƒ ƒAmbiguous,Ambiguous, inconsistent inconsistent or or incomplete incomplete specification specification ‹‹ CaughtCaught by:by: ƒ ƒInspection,Inspection, formal formal verification, verification, end-to-end end-to-end testing testing Application Domain Machine Domain ‹‹ RequirementsRequirements areare wrongwrong (common)(common) ‹‹ Causes:Causes: ƒ ƒInsufficientInsufficient communication communication with with customers/users customers/users ƒ ƒLackLack of of analysis analysis ƒ ƒFailureFailure to to handle handle change change ‹‹ CaughtCaught by:by: ƒ ƒInspections,Inspections, customer customer reviews, reviews, ƒ ƒmodeling,modeling, formal formal validation, validation, prototyping prototyping © 2000-2002, Steve Easterbrook 11 © 2000-2002, Steve Easterbrook 12 2 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Where do things go wrong? Where do formal methods apply? ‹ Domain Properties are wrong (very common) ‹ Domain Properties are wrong (very common) ‹ Formalize S - the specification ‹ Causes: ‹ Causes: “I unquestioningly assume ƒ as a precise baseline to verify the program against ƒ Lack of domain expertise ƒ Lack of domain expertise that all assumptions must ÿ ƒ Unquestioned assumptions specification languages: Z, VDM, Larch, … ƒ Unquestioned assumptions be questioned” - Parnas ƒ ƒ ƒInsufficientInsufficient domain domain analysis analysis as an explicit model of program behavior to compare against requirements ‹ ‹ CaughtCaught by:by: ‹ ƒ Formalize D - the domain knowledge ƒFailureFailure analysis, analysis, talking talking to to the the right right experts, experts, off-nominal off-nominal testing testing ƒ so we can reason about: ÿ whether it is complete ÿ how it affects the proposed system Application Domain Machine Domain ƒ Formalization helps us to be precise and explicit about the environment ‹ Formalize R - the requirements ƒ so we can animate them ƒ so we can test logical coherence ƒ so we can check for completeness ÿ …against an underlying mathematical (semantic) model © 2000-2002, Steve Easterbrook 13 © 2000-2002, Steve Easterbrook 14 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Outline Why formalize in RE? ‹ Why do we need Formal Methods in RE? ‹ To remove ambiguity and improve precision ‹ What do formal methods have to offer? you are here! ‹ Provides a basis for verification: ƒ That a program meets its specification ‹ A survey of existing techniques ƒ That a that specification captures the requirements adequately ‹ Example modeling language: SCR ‹ Allows us to reason about the requirements ƒ The language ƒ Properties of formal requirements models can be checked automatically ƒ Case study ƒ Can test for consistency, explore the consequences, etc. ƒ Advantages and disadvantages ‹ Allows us to animate/execute the requirements ‹ Example analysis technique: Model Checking ƒ Helps with visualization and validation ƒ How it works ‹ Will have to formalize eventually anyway ƒ Case Study ƒ RE is all about bridging from the informal world to a formal machine domain ƒ Advantages and disadvantages ‹ Where next? © 2000-2002, Steve Easterbrook 15 © 2000-2002, Steve Easterbrook 16 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Why people don’t formalize in RE Setting the Boundaries ‹ FM tend to be lower level than other techniques ‹ Formal methods assume