University of Toronto University of Toronto Department of Computer Science Formal Methods in RE Lecture 11 How Much Formality What Last Last Week Week Change Changeand and Evolution Evolution Software SoftwareEvolution Evolution Traceability Traceability Inconsistency Inconsistency Why Why formalize formalize inin RE RE To Toremove removeambiguity ambiguityand andimprove improve precision precision Allows Allowsus usto toreason reasonabout aboutthe the requirements requirements Properties of formal requirements models Properties of formal requirements models can be checked automatically can be checked automatically Can test for consistency explore the Can test for consistency explore the consequences etc consequences etc Helps with visualization and validation Helps with visualization and validation Will Willhave haveto toformalize formalizeeventually eventuallyanyway anyway RE is all about bridging from the informal RE is all about bridging from the informal world to a formal machine domain world to a formal machine domain 2000 2003 Steve Easterbrook 1 They force you to include too much detail They force you to include too much detail Formal FormalMethods Methodstend tendto toconcentrate concentrateon on consistent consistent correct correctmodels models but most of the time your models are but most of the time your models are inconsistent incorrect incomplete inconsistent incorrect incomplete People Peopleget getconfused confusedabout aboutwhich whichtools tools are areappropriate appropriate E g modeling program behaviour vs E g modeling program behaviour vs modeling the requirements modeling the requirements formal methods advocates get too attached formal methods advocates get too attached to one tool to one tool Formal Formalmethods methodsrequire requiremore moreeffort effort and the payoff is deferred and the payoff is deferred 2000 2003 Steve Easterbrook University of Toronto Department of Computer Science What are Formal Methods 2 Department of Computer Science Varieties of formal analysis Broad View Leveson Consistency analysis and typechecking Is the formal model well formed application of discrete mathematics to software engineering involves modeling and analysis with an underlying mathematically precise notation assuming that we only use modeling languages where well formedness is a useful thing to check Narrow View Wing Validation Animation of the model on small examples Use of a formal language Formal challenges a set of strings over some well defined alphabet with rules for distinguishing which strings belong to the language if the model is correct then the following property should hold Formal reasoning about formulae in the language What if questions E g formal proofs use axioms and proof rules to demonstrate that some formula is in the language Formal FormalMethods Methodstend tendto tobe belower lowerlevel level than thanother otheranalysis analysistechniques techniques Allows Allowsus usto toanimate execute animate executethe the requirements requirements The End University of Toronto Why Why people people don t don t formalize formalize inin RE RE Provides Providesaabasis basisfor forverification verificationthat that the therequirements requirementshave havebeen beenmet met How How much much formality formality Formal FormalModeling ModelingTechniques Techniques Appropriate AppropriateUses Usesof ofFM FM Tips on formal modeling Tips on formal modeling to formalize in RE models of requirements knowledge so we can reason about them specifications of requirements so we can document them precisely This This Week Week Department of Computer Science reasoning about the consequences of particular requirements reasoning about the effect of possible changes For requirements modeling State exploration E g use a model checking to find traces that satisfy some property A notation is formal if Checking application properties 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 syntactically well formed or to prove properties about them will the system ever do the following Verifying design refinement does the design meet the requirements 2000 2003 Steve Easterbrook 3 2000 2003 Steve Easterbrook 4 1 University of Toronto University of Toronto Department of Computer Science Three different models FM in practice D inconsistent interfaces incorrect requirements system does the wrong thing in response to an input clarity maintainability problems constrains a model of the requirements Formalization forces you to be precise and explicit hence reveals problems Formal analysis then finds fewer but more subtle problems Typical errors found include acts upon is satisfied by From Shuttle Study Crow DiVito 1996 More errors found in the process of formalizing the requirements than were found in the formal analysis a model of the environment R Issue Severity With FM Existing High Major 2 0 Low Major 5 1 High Minor 17 3 Low Minor 6 0 Totals 30 4 S a model of the software behaviour 2000 2003 Steve Easterbrook 5 University of Toronto Department of Computer Science 2000 2003 Steve Easterbrook Formal Specification Languages Grew out of work on program verification Spawned many general purpose specification languages first order predicate logic e g RML temporal logic e g Albert II SCR KAOS multi valued logic e g Xchek Suitable for specifying the behaviour of program units Key technologies Type checking Theorem proving Other Reactive System Modeling algebraic languages e g Larch set theory e g Z Grew out of a need to capture dynamic models of system behaviour Focus is on reactive systems e g real time embedded control systems Ontology fixed support reasoning about safety liveness performance provide a precise requirements specification language states events actions e g SCR entities activities assertions e g RML Formal Conceptual Modeling meta language for defining new concepts e g Telos Grew out of a concern for capturing real world knowledge in RE Focus is on modeling domain entities activities agents assertions Treatment of Time State event models time as a discrete sequence of events e g SCR time as quantified intervals e g KAOS provide a formal ontology for domain modeling use first order predicate logic as the underlying formalism Time as a first class object Key technologies inference engines default reasoning KBS shells meta level class to represent time e g Telos 2000 2003 Steve Easterbrook