1 an Introduction to Formal Modeling in Requirements Engineering

Home , Formal specification

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?

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

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?

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!) ‹‹ Causes:Causes: Application Domain Machine Domain ƒ ƒ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

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

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

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?

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 the boundaries are known ƒ they force you to include too much detail ƒ you have to have decided the system boundaries already ‹ E.g. the four variable model: ƒ Fixes the input/output devices ‹ FM tend to concentrate on consistent, correct models ƒ Uses I/O data items as proxies for the monitored and controlled variables ƒ …but most of the time your models are inconsistent, incorrect, incomplete… System ‹ Confusion about which tools are appropriate: ƒ Are we modeling program behavior or modeling the requirements? Environ- Monitored Input input output Output Controlled Environ- devices software devices ƒ formal methods advocates get too attached to one tool! ment Variables data data Variables ment ƒ false expectations about scaleability of research prototypes

‹ FM require more effort S - Specification of s/w in ƒ “they slow you down” terms of inputs & outputs ƒ “they require lots of mathematical training” ƒ ...and the payoff is deferred R - Requirements: what control actions the system must take in which circumstances. D - Domain Properties that constrain how the environment can behave ‹ FM are not appropriate in many projects… © 2000-2002, Steve Easterbrook 17 © 2000-2002, Steve Easterbrook 18

3 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Three different models?? Modeling… ‹ Modeling can guide elicitation: D: ƒ Does the modeling process help you figure out what questions to ask? a model of the ƒ Does the modeling process help to surface hidden requirements? environment ÿ i.e. does it help you ask the right questions? ‹ Modeling can provide a measure of progress: is ƒ Does completeness of the model imply completeness of the elicitation? satisfied R: ÿ i.e. if we’ve filled in all the pieces of the model, are we done? a model by of the ‹

acts upon Modeling can help to uncover problems constrains requirements ƒ Does inconsistency in the model reveal interesting things…? ÿ e.g. inconsistency could correspond to conflicting or infeasible requirements S: ÿ e.g. inconsistency could mean confusion over terminology, scope, etc a model of ÿ e.g. inconsistency could reveal disagreements between stakeholders the software ‹ behaviour Modeling can help us check our understanding ƒ Can we test that the model has the properties we expect? ƒ Can we reason over the model to understand its consequences? ƒ Can we animate the model to help us visualize/validate the requirements? © 2000-2002, Steve Easterbrook 19 © 2000-2002, Steve Easterbrook 20

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Type of Model Desiderata for Modeling Languages

Modeling is necessary. But we can choose how: ‹ Implementation Independence ‹ Ease of analysis ƒ does not model data representation, ƒ ability to analyze for ambiguity, ‹ natural language internal organization, etc. incompleteness, inconsistency,… ƒ extremely expressive and flexible ‹ Abstraction ‹ Traceability ƒ very poor at capturing the semantics of the model ƒ extracts essential aspects ƒ ability to cross-reference elements ƒ good for elicitation, and to annotate models for communication ÿe.g. things not subject to frequent ƒ ability to link to design, change implementation, etc. ‹ semi-formal notation ƒ supports “big picture” views ‹ Executability ƒ captures structure and some semantics ‹ Formality ƒ can animate the model, to compare it ƒ ƒ can perform (some) reasoning, consistency checking, animation, etc. unambiguous syntax to reality ÿ E.g.s: diagrams, tables, structured English, etc. ƒ rich semantic theory ‹ Minimality ‹ Constructability ‹ formal notation ƒ No redundancy of concepts in the ƒ ƒ very precise semantics, extensive reasoning possible can compose pieces of the model to modeling scheme handle complexity and size ÿi.e. no extraneous choices of how to ƒ long way removed from the application domain ƒ construction should facilitate represent something ÿ note: requirements formalisms are geared towards cognitive considerations, communication hence differ from most computer science formalisms

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Meta-Modeling (excerpt from) KAOS meta-model ‹ Can compare modeling languages using meta-models: ƒ What phenomena does each language capture? ƒ What guidance is there for how to elaborate the models? ƒ What analysis can be performed on the models?

‹ Example meta-model: Propositions about the application domain

Facts modify acknowledge

Activities Events trigger

Actions inducing change State changes in the of facts in the application domain application domain

4 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Validating our models Formal Validation ‹ logical positivist view: ÿ “there is an objective world that can be modeled by building a consistent body of ‹ Consistency analysis and typechecking knowledge grounded in empirical observation” ƒ “Is the formal model well-formed?” ƒ In RE: “there is an objective problem that exists in the world” ÿ usually, well-formedness is needed before other validation can be done… ÿ Build a consistent model; make sufficient empirical observations to check validity ÿ well-formedness may also correspond to a useful real-world integrity property ÿ Use tools that test consistency and completeness of the model ÿ Use reviews, prototyping, etc to demonstrate the model is “valid” ‹ Validation: ‹ Popper’s modification to logical positivism: ƒ Animation of the model on small examples ÿ “theories can’t be proven correct, they can only be refuted by finding exceptions” ƒ Formal challenges: ƒ In RE: “requirements models must be refutable” ÿ “if the model is correct then the following property should hold...” ÿ Look for evidence that the model is wrong ƒ ‘What if’ questions: ÿ E.g. collect scenarios and check the model supports them ÿ reasoning about the consequences of particular requirements; ÿ reasoning about the effect of possible changes ‹ post-modern view: ƒ State exploration ÿ “there is no privileged viewpoint; all observation is value-laden; scientific ÿ E.g. use a model checker to find traces that satisfy some property investigation is culturally embedded” ÿ E.g. Kuhnian paradigms; Toulmin’s weltanschauungen ƒ Checking application properties: ƒ In RE: “validation is always subjective and contextualised” ÿ “will the system ever do the following...” ÿ Use stakeholder involvement so that they ‘own’ the requirements models ÿ Use ethnographic techniques to understand the weltanschauungen ‹ Verifying design refinement ÿ “does the design meet the requirements?”

University of Toronto Department of Computer Science University of Toronto Department of Computer Science FM in practice Outline

l From Shuttle Study [Crow & DiVito 1996] ‹ Why do we need Formal Methods in RE? ƒ More errors found in the process of formalizing the requirements than were found in the formal analysis ‹ What do formal methods have to offer? ÿ Formalization forces you to be precise and explicit, hence reveals problems ÿ Formal analysis then finds fewer, but more subtle problems ‹ A survey of existing techniques you are here! ƒ Typical errors found include: ÿ inconsistent interfaces ‹ Example modeling language: SCR ÿ incorrect requirements (system does the wrong thing in response to an input) ÿ clarity/maintainability problems ƒ The language ƒ Case study Issue Severity With FM Existing ƒ Advantages and disadvantages High Major 2 0 ‹ Example analysis technique: Model Checking Low Major 5 1 ƒ How it works High Minor 17 3 ƒ Case Study Low Minor 6 0 ƒ Advantages and disadvantages Totals 30 4 ‹ Where next?

University of Toronto Department of Computer Science University of Toronto Department of Computer Science How do FMs differ? Three traditions … ‹ Formal Specification Languages Ontology ApplicabilityApplicability toto RERE isis poorpoor ƒ Grew out of work on program verification ÿ ƒ fixed ÿNoNo abstraction abstraction or or structuring structuring ƒ Spawned many general purpose specification languages ÿ ÿ states, events, actions - e.g. SCR, RSML, Statecharts,… ÿcloselyclosely tied tied to to program program ÿ Suitable for specifying the behaviour of program units ÿ entities, activities, assertions - e.g. RML semanticssemantics ƒ Key technologies: Type checking, Theorem proving ƒ extensible Examples:Examples: Larch,Larch, Z, Z, VDM, VDM, … … ÿ meta language for defining new concepts - e.g. Telos Reactive System Modeling Applicability to RE is good ƒ Aim to capture dynamic models of system behaviour Applicability to RE is good ‹ Mathematical Foundation ÿ modeling languages were ƒ Focus on reactive systems (e.g. real-time, ÿ modeling languages were ƒ developed specifically for RE Logic embedded control systems) developed specifically for RE Examples: Statecharts, RSML, ÿ first order predicate logic - e.g. RML ÿ Examples: Statecharts, RSML, support reasoning about safety, liveness, performance(?) Parnas-tables, SCR, … ÿ temporal propositional logic - e.g. Albert II, SCR, KAOS ÿ provide a precise requirements specification language Parnas-tables, SCR, … ƒ Other ƒ Key technologies: Consistency checking, Model checking ÿ algebraic languages - e.g. Larch ÿ set theory - e.g. Z Formal Conceptual Modeling ƒ Concerned with capturing real-world knowledge in RE ApplicabilityApplicability toto RERE isis excellentexcellent ‹ ƒ Focus on modeling domain entities, activities, ÿ Treatment of Time ÿmodelingmodeling schemes schemes capture capture key key agents, assertions ƒ State/event models requirementsrequirements concepts concepts ÿ provide a formal ontology for domain modeling ÿ time as a discrete sequence of events - e.g. SCR Examples:Examples: ReqtsReqts Apprentice, Apprentice, RML, RML, ÿ use first order predicate logic as the underlying formalism ÿ time as quantified intervals - e.g. KAOS Telos,Telos, Albert Albert II, II, …… ƒ Key technologies: inference engines, default reasoning, ƒ Time as a first class object KBS-shells ÿ meta-level class to represent time - e.g. Telos © 2000-2002, Steve Easterbrook 29 © 2000-2002, Steve Easterbrook 30

5 University of Toronto Department of Computer Science University of Toronto Department of Computer Science (1) Formal Specification Languages (2) Reactive System Modeling ‹ Three basic flavours: ‹ Modeling how a system should behave ƒ Operational - specification is executable abstraction of the implementation ƒ General approach: ÿ good for rapid prototyping ÿ Model the environment as a state machine ÿ e.g., Lisp, Prolog, Smalltalk ÿ Model the system as a state machine ƒ State-based - views a program as a (large) data structures whose state ÿ Model safety, liveness properties of the machine as temporal logic assertions can be altered by procedure calls… ÿ Check whether the properties hold of the system interacting with its environment ÿ … using pre/post-conditions to specify the effect of procedures ÿ e.g., VDM, Z ‹ Examples: ƒ Algebraic - views a program as a set of abstract data structures with a set ƒ Statecharts of operations… ÿ Harel’s notation for modeling large systems ÿ … operations are defined declaratively by giving a set of axioms ÿ Adds parallelism, decomposition and conditional transitions to STDs ÿ e.g., Larch, CLEAR, OBJ ƒ RSML ÿ Heimdahl & Leveson’s Requirements State Machine Language ‹ Developed for specifying programs ÿ Adds tabular specification of complex conditions to Statecharts ƒ Programs are formal, man-made objects ƒ A7e approach ÿ … and can be modeled precisely in terms of input-output behaviour ÿ Major project led by Parnas to formalize A7e aircraft requirements spec ƒ But in RE we’re more concerned with: ÿ Uses tables to specify transition relations & outputs ÿ real-world concepts, stakeholders, goals, loosely define problems, environments ƒ SCR ƒ So these languages are NOT very appropriate for RE ÿ Heitmeyer et. al. “Software Cost Reduction” ÿ but people fail to realise that requirements specification ≠ program specification ÿ Extends the A7e approach to include dictionaries & support tables © 2000-2002, Steve Easterbrook 31 © 2000-2002, Steve Easterbrook 32

University of Toronto Department of Computer Science University of Toronto Department of Computer Science (3) Formal Conceptual Modeling From notations to methods… ‹ General approach ƒ model the world beyond functional specifications ‹ A notation: ÿ a specification is prescriptive, concentrating on desired properties of the machine ƒ a representation scheme (or language) for expressing things; ÿ but we also need to understand the application domain ÿ e.g., Z, first order logic, state transition diagrams, UML. ÿ hence build models of humans’ knowledge/beliefs about the world ƒ make use of abstraction & refinement as structuring primitives ‹ A technique: ‹ Examples: ƒ prescribes how to perform a particular activity - and, if necessary, how to describe a product of that activity in a particular notation; ƒ RML - Requirements Modeling Language ÿ e.g, SCR, VDM, ÿ Developed by Greenspan & Mylopoulos in mid-1980s ÿ First major attempt to use knowledge representation techniques in RE ‹ A method: ÿ Essentially object-oriented, with classes for activities, entities and assertions ƒ ÿ Uses First Order Predicate Language as an underlying reasoning engine a technical prescription for how to perform a collection of activities, focusing on integration of techniques and guidance about their use; ƒ Telos ÿ e.g., SADT, OMT, JSD, KAOS ÿ Extends RML by creating a fully extensible ontology ÿ meta-level classes define the ontology (the basic set is built in) ‹ A Process model: ƒ Albert II ƒ ÿ developed by Dubois & du Bois in the mid-1990s an abstract description of how to conduct a collection of activities, focusing ÿ Models a set of interacting agents that perform actions that change their state on resource usage and dependencies between activities. ÿ uses an object-oriented real-time temporal logic for reasoning

University of Toronto Department of Computer Science University of Toronto Department of Computer Science State Transition Diagram Statecharts

Off hook on hook / quiet busy

Lift receiver Dial (callee idle) Dial busy Called party on hook / idle Dial tone Ringing tone number / dial tone busy tone Dial Callee off hook / Called party off (callee lifts busy) Callee receiver dial tone dial Dial idle number / hook / idle ringing tone ringing connected replaces tone connected Replace receiver receiver Busy tone connected on hook / quiet on hook / quiet on hook / quiet state guard Super-state stimulus transition Sub-state state transition stimulus response Default entry state

6 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Outline SCR basics Four Variable Model: ‹ Why do we need Formal Methods in RE? System

‹ What do formal methods have to offer? Environ- Monitored input input output output Controlled Environ- software ment Variables devices data data devices Variables ment ‹ A survey of existing techniques items items

‹ Example modeling language: SCR you are here! ƒ The language Dictionaries: Tables: also: ƒ Case study Monitored/Controlled Mode Transition Tables Assertions, Variables CurrentModePoweredonToo ColdTemp OKToo HotNew ModeOff@T-t-Inactive@Tt--Heat@T--tACInactive@F---Off-@T--Heat---@TACHeat@F---Off--@T-InactiveAC@F---Off--Scenarios,@T-Inactive ƒ Advantages and disadvantages VariableTypeInitial ValueUnitsWarningFlagbooleanfalse-OtherFlagbooleantrueFudgelevelenumeratedoneCurrent-WaterlevelModePoweredreal0.0mtemperatureonToo ColdreTeaml0.0p dOeKgreTooes HotCBlipCounterNew ModeintegerOff@[email protected]@[email protected]/sec-Off-@T--Heat Tables---@TACHeat@F---Off--@T-InactiveTimeout@F---No Failure-ff@TACFailure CurrentModePoweredonToo ColdTemp OKToo HotNew ModeOff@T-t-Inactive@Tt--Heat@ModesT--tACEventsInactiveNoF@Failure---Off@T(INMODE)-@T--Heat---@neverTACSensorFailHeat@F---Off@T(reset=on)--@T-Inactive@T(INMODE)AC@[email protected] neverACFailure, HeatFailurenever@T(INMODE)Warning light =OffOn ModesEventsNoFailure@T(INMODE)neverBlah@T(thingy)@T(other)DoodahneveralwaysACFailure, HeatFailurenever@T(INMODE)Heater =OffOn ‹ Example analysis technique: Model Checking ModesEventsNoFailure@T(INMODE)neverBlah@T(thingy)@T(other)DoodahneveralwaysACFailure, HeatFailurenever@T(INMODE)ACpower =OffOn ƒ How it works Types TypeBaseTypeValuesUnitsWarningLevelenumeratedlow,med,high-Temperatureinteger-100..100degrees CWaterlevelinteger0..100metersFlagenumeratedon, off- ƒ Case Study ƒ Advantages and disadvantages Condition Tables Constants ModesEventsNoFailuretruefalseACFailuretemp > temp0temp <= temp0HeatFailurefalsewaterlevel =lowWarning light =OffOn ConstantTypeValueUnitsLowTempinteger15degrees CHighTempinteger23degrees CMaxTimeOutinteger300millisecReferenceSafetyLevelsafetytypelow-TempMargininteger5degrees C ModesEventsNoFailurefalsetrueACFailure, HeatFailuretruefalseBuzzer =OffOn ‹ Where next? SCR Specification

University of Toronto Department of Computer Science University of Toronto Department of Computer Science SCR basics SCR Tables

‹ Modes and Mode classes ‹ Mode Class Tables ƒ A mode class is a finite state machine, with states called system modes ƒ Define the set of modes (states) that the software can be in. ÿ Transitions in each mode class are triggered by events ƒ A complex system will have many different modes classes ƒ Complex systems are described using a number of mode classes operating in ÿ Each mode class has a mode table showing the conditions that cause transitions parallel between modes ƒ A mode table defines a partial function from modes and events to modes ‹ System State ƒ A (system) state is defined as: ‹ Event Tables ÿ the system is in exactly one mode from each mode class… ƒ An event table defines how a term or controlled variable changes in ÿ …and each variable has a unique value response to input events ƒ Defines a partial function from modes and events to variable values ‹ Events ƒ An event occurs when any system entity changes value ‹ Condition Tables ÿ An input event occurs when an input variable changes value ÿ Single input assumption - only one input event can occur at once ƒ A condition table defines the value of a term or controlled variable under ÿ Notation: @T(c) means “c changed from false to true” every possible condition ƒ A conditioned event is an event with a predicate ƒ Defines a total function from modes and conditions to variable values ÿ @T(c) WHEN d means: “c became true when c was false and d was true”

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Example: Temp Control System Failure modes

Mode transition table: Mode transition table: Current Powered Too Cold Temp OK Too Hot New Mode Mode on Current Powered Cold Too Warm Too New Mode on Heater Cold AC Hot Mode Off @T - t - Inactive NoFailure t @T t - - HeatFailure @T t - - Heat t - - @T t ACFailure @T - - t AC HeatFailure t @F t - - NoFailure ACFailure t - - @F t NoFailure Inactive @F - - - Off - @T - - Heat - - - @T AC Event table: Heat @F - - - Off - - @T - Inactive Modes AC @F - - - Off NoFailure @T(INMODE) never - - @T - Inactive ACFailure, HeatFailure never @T(INMODE) Warning light = Off On

7 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Consistency Checks in SCR Case Study Background

‹ Syntax ‹ Space Shuttle Flight Software ƒ did we use the notation correctly? ƒ Operational Increments (OI), approx every 12 - 18 months ‹ Type Checks ƒ Add new capabilities, correct anomalies, etc ƒ Change Requests = specification pages + handwritten annotations ƒ do we use each variable correctly? ƒ Manual review process

‹ Disjointness ‹ East Coast Abort Landing Change Request ƒ is there any overlap between rows of the mode tables? ƒ To automate entry guidance for emergency landing ÿ ensures we have a deterministic state machine ƒ To reduce crew training and increase survivability ƒ Main functions: ‹ Coverage ÿ Management of energy during descent ƒ does each condition table define a value for all possible conditions? ÿ Guidance to align the shuttle with runway ƒ 104 pages from 7 specifications ‹ Mode Reachability ‹ ƒ is there any mode that cannot ever happen? Source material ƒ Existing requirements use a functional decomposition: ‹ Cycle Detection ÿ 13 functions ƒ Expressed informally: ƒ have we defined any variable in terms of itself? ÿ natural language, equations, pseudo-code, tables of variables © 2000-2002, Steve Easterbrook 43 © 2000-2002, Steve Easterbrook 44

University of Toronto Department of Computer Science University of Toronto Department of Computer Science operational If IPHASE=6, the constant alpha recovery angle-of-attack command, ALPCMD, as well as the sequence 1 (launch) altitude rate de pe ndent inc remental NZ command, DGRN Z, for the load relief phase (IPHASE = 5) main engine 104 orbit cut-off (MECO) operational are compute d as shown in Equatio n Se t 1. sequence 6 (abort) 1.1 If C ONT=OFF then A LPCMD=ALPREC 1.2 If C ONT=ON then ALPCMD=MIDVAL(ALPRECS * MACH + ALPRECI, ALPRECU, ALPR ECL) Cannot enter 1.3 If HDOT=HDMAX) execute Equation Set 1.3 for 103 Can do this intact a borts (CONT=OFF) o r Equation S et 1 .4 f or contingenc y a borts ( CONT=ON) OPS 6 (abort) on 3EO 1.3 .1 DGRNZ= M IDVAL((HDNOM – HDMAX)* D HDNZ, DHDLL, DH DUL) until after 1.3 .2 DGRNZT= GRNZC1 + D GRNZ + 1 .0 SRB sep. 1.4 .1 DGRNZT= MIDVAL(DNZB – HDMAX * DHDN Z, D NZMIN, D NZMAX) SRB 1.4 .2 SMNZ1= ZDT1*DGRNZT separation iphase = 1.4 .3 DGRNZ= D GRNZT – GRNZC1 – 1.0 6; 5; 4 1.4 .4 NZSW= G RNZC1 – SMNZ1 – SMNZ2 + 1.0 601 iphase = Othe rwis e (IPH ASE /= 6), the angle-of-attac k command for the alpha transition phase is computed. 102 0 or 1; 2; 3 Equation Se t 2 te sts for the initial pass through the logic and initializes the command. 602 2.1 If I GRA=0, t hen ALPC MD=ALPHA and I GRA=1 ET Sep 603 Next, a test on IGRA is made. If IGRA = 1, Equation Set 3 is executed to compute the smoothed complete angle-of-attac k command and the functio n is exited. 3.1 DGRALP =MIDVAL(GRALP R–ALPHA, G RALL, GRALU) Land 3.2 ALPCMD=ALPCMD+DGRALP Powered flight or bailout 3.3 If (DGRALP < 0.0 and ALPCMD <= GRALPR) or (DGRALP > 0.0 and ALPCMD > GRALPR), then 101 RTLS (at least ALPCMD = G RALPR a nd IGRA = 2 (Pre- 1 engine burning) Otherwise (IGRA /= 1), Equation Set 4 is used to set the angle-of-attack command equal to the launch) reference angle of attac k 4.1 ALP CMD = GRALPR The functio n is exited. © 2000-2002, Steve Easterbrook 45 © 2000-2002, Steve Easterbrook 46

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Verification approach Results & Recommendations

‹ Modeling Approach ‹ Results ƒ Two steps: ƒ Systematic ambiguity in natural language/pseudo-code ÿ model the original requirements; ƒ Missing initial values ÿ modify as per change request. ƒ 1 modified constant ƒ Use the SCRtool consistency checker to ‘debug’ the model (We did not catch any of the errors in the Change Request!) ƒ SCR model stats: ÿ 30 types, 265 constants, 165 variables, 2 mode classes ‹ Comments ‹ ƒ Difficult abstraction step Verification Properties ÿ from imperative to state machine model ƒ Most properties were invariants. ƒ Restrictions from the semantic model: E.g. “The commanded roll angle will be zero during the alpha recovery and NZ hold ÿ completeness; dependency cycles; functional decomposition phases.” ÿ Needed deep understanding of SCR semantics iphase = 6 or iphase =5 Æ phic_at = 0 ÿ (Sometimes had to fudge it) ƒ Some properties cannot be verified (need simulator): ƒ Restrictions from the toolset: “A large peak immediately after MM603 may indicate an energy dump pull-up ÿ trig functions; slow consistency checking maneuver. There should be no difference between FSW and environment values.” ÿ (got through several versions) ‹ Caveat… ƒ …SCR was not designed for analysis of change in legacy systems! © 2000-2002, Steve Easterbrook 47 © 2000-2002, Steve Easterbrook 48

8 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Conclusions Outline

‹ Feasibility study: ‹ Why do we need Formal Methods in RE? ƒ Are automated verification techniques mature enough? ÿ FM in general, SCR in particular ‹ What do formal methods have to offer? ƒ large system, informal structured requirements ƒ very safety-critical ‹ A survey of existing techniques ƒ analysis of change ‹ Example modeling language: SCR ‹ Good news: ƒ The language ƒ SCR provides all the right modelling primitives ƒ Case study ƒ Tool scaleability does not appear to be a major issue ƒ Advantages and disadvantages

‹ Bad news: ‹ Example analysis technique: Model Checking ƒ Couldn’t model existing structure ƒ How it works you are here! ƒ Couldn’t isolate change ƒ Case Study ƒ Advantages and disadvantages

‹ Where next?

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Model Checking Model Checking Basics ‹ Has revolutionized formal verification: ‹ Build a finite state machine model ƒ emphasis on partial verification of partial models ƒ E.g. PROMELA - processes and message channels ƒ fully automated ƒ E.g. SCR - tables for state transitions and control actions ƒ applies at any stage of sofware development ƒ E.g. RSML - statecharts + truth tables for action preconditions ‹ What it does: ‹ ƒ Mathematically – computes the “satisfies” relation: Express validation property as a logic specification ÿ For a given temporal logic theory, checks whether a given finite state machine is ƒ Propositions in first order logic (for invariants) a model for that theory. ƒ Temporal Logic (for safety & liveness properties) ƒ Engineering view – checks whether properties hold: ÿ E.g. CTL, LTL, ... ÿ For a given model (expressed as a finite state machine), checks whether it obeys various safety and liveness properties ‹ Run the model checker: ‹ How to apply it in RE: ƒ Computes the value of: model |= property ƒ The model is an (operational) Specification ‹ Explore counter-examples ÿ Check whether particular requirements hold of the spec ƒ ƒ The model is (an abstracted portion of) the Requirements If the answer is ‘no ’ find out why the property doesn’t hold ÿ Carry out basic validity tests as the model is developed ƒ Counter-example is a trace through the model ƒ The model is a conjunction of the Requirements and the Domain ÿ Formalise assumptions and test whether the model respects them © 2000-2002, Steve Easterbrook 51 © 2000-2002, Steve Easterbrook 52

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Temporal Logic Example

‹ LTL (Linear Temporal Logic) ringtone Sample Properties ƒ Expresses properties of infinite traces through a state machine model OFFHOOK=T If you are connected you can LINE_SEL=T ƒ adds two temporal operators to propositional logic: CALLEE_FREE=T hang up: CONNECTED=F ◊p - p is true eventually (in some future state) AG(CONNECTED Æ op - p is true always (now and in the future) EX(ÿOFFHOOK) dialtone If you are connected, hanging up ‹ CTL (Computational Tree Logic) OFFHOOK=T LINE _SEL=F always disconnects you: ƒ branching-time logic - can quantify over possible futures CALLEE_FREE=T CONNECTED=F AG(CONNECTED Æ ƒ Each operator has two parts: AX(ÿOFFHOOK Æ ÿCONNECTED)) EX p - p is true in some next states busytone A connection doesn’t start until AX p - p is true in all next states OFFHOOK=T you pick up the phone: EF p - along some path, p is true in some future state LINE _SEL=T idle CALLEE_FREE=F connected AG(ÿCONNECTED Æ AF p - along all paths… OFFHOOK=F CONNECTED=F OFFHOOK=T A[ÿCONNECTED W OFFHOOK]) E[p U q] - along some path, p holds until q holds; LINE _SEL=F LINE _SEL=T CALLEE_FREE=T CALLEE_FREE=F If you make a call, the phone A[p U q] - along all paths… CONNECTED=F CONNECTED=T EG p - along some path, p holds in every state; ringing cannot ring without returning AG p - along all paths… OFFHOOK=F to idle first: LINE _SEL=T CALLEE_FREE=F AG((ringtone ⁄ busytone) Æ CONNECTED=T A[ÿringing W idle])

9 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Complexity Issues Case Study I - Background

‹ The problem: ‹ Dual Redundant Spacecraft Controller ƒ Model Checking is exponential in the size of the model and the property ƒ two identical hardware/software platforms 120 ƒ Current MC engines can explore 10 states… ƒ prime string controls the spacecraft ÿ using highly optimized data structures (BDDs) ƒ online string acts as warm backup during critical sequences ÿ …and state space reduction techniques ƒ prime string generates a 32-word State Table Broadcast (STB) once per ƒ …that’s roughly 400 propositional variables second ÿ integer and real variables cause real problems ƒ Realistic models are often to large to be model checked ‹ Markpoint & Rollback scheme ‹ The solution: ƒ Markpoints in the critical sequence represent completed subsequences ƒ When a fault occurs: ƒ Abstraction: ÿ Critical sequence is suspended ÿ Replace related groups of states with a single superstate ÿ Fault recovery is invoked ÿ Replace real & integer variables with propositional variables ÿ If the fault is repaired, both strings resume from the last markpoint ƒ Projection: ƒ 3 seconds delay to ‘age’ each markpoint, to allow mechanical operations to ÿ Slice the model to remove parts unrelated to the property complete. ƒ Compositional verification - break large model into smaller pieces ÿ (But it’s hard to verify that the composition preserves properties)

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Specified Behaviour (statecharts) State Space Size Estimation

PRIME ONLINE ‹ Initial model ƒ Assume each state in statechart needs 4 substates in the model Prime init suspend Online init ƒ Prime string: 16 major states, hence 416 ƒ Online string: 14 major states, hence 414 PRIME NOMINAL PRIME NOMINAL ƒ STB: 27 elements, each at least binary, hence 227 SEQUENCE IDLE SFP Response SEQUENCE IDLE ƒ Total: 287 states Active Power-up Fault Power-up Fault ‹ Model reduction strategies: Idle Idle SFP Idle Idle Response ƒ Projection - identified 5 fault classes, treated them separately: Resume Done SFP Critical Resume ƒ Done Activate Critical Active Symmetry - doesn’t matter which processor runs which string Sequence SFP Done Activate Critical in from aged Critical Sequence ƒ Partitioning - ignore cases where critical sequence is not executing Sequence ACTIVE Prime markpoint Sequence from aged markpoint String ƒ Abstraction - removed all data from the STB other than that needed for SEQUENCE CRITICAL SEQUENCE CRITICAL rollback ƒ Abstraction - simplest possible input data: minimal length critical sequence ƒ Projection - verify each LTL property separately

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Verification against requirements Results: 3 anomalies

‹ Requirements: ‹ Failure to Suspend (1) If a fault occurs when the last markpoint was at the start of the ƒ Occurs when prime string detects and corrects a fault between two sequence, the prime string shall roll back to the start, regardless of how consecutive rendezvous broadcasts (I.e. within 1 second) much time has expired since the program started running ƒ Online string never rolls back, hence gets out of synch. (2) If a fault occurs when the time, t, since the last markpoint was less than ƒ Repeated occurrence may cause loss of redundancy 3 seconds, and the last markpoint was not at the start of the sequence, the prime string shall roll back to the previous markpoint ‹ No rollback at end of critical sequence (3) If a fault occurs when the time t following the last markpoint was greater ƒ End of critical sequence is not designated a markpoint than or equal to 3 seconds, the prime string shall roll back to the last ƒ When online string reaches the end of the sequence, it returns to ‘Power markpoint. Up Idle’ ƒ Hence, if a fault occurs within 3 seconds of the end of the sequence, and ‹ In Linear Temporal Logic the prime rolls back, there is no longer a backup ƒ If p is the occurrence of a fault, and q is the correct response, then: ÷ p Ÿ £ (p Æ ÷ q) ‹ Fault occurs at t+2 E.g. p = (t<3) Ÿ (SFP=1) Ÿ (mp _current ≠ start) ƒ Prime string suspends its aging at t+2 seconds; q = (pc = mp_previous) Ÿ (SFP = 0) ƒ Online string does not receive the updated STB until the next second ƒ Six such properties (3 for prime rollback, 3 for online rollback) ƒ Result is that online rolls back to the last markpoint, prime rolls back to the previous one. © 2000-2002, Steve Easterbrook 59 © 2000-2002, Steve Easterbrook 60

10 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Outline Lessons Learned

‹ Why do we need Formal Methods in RE? ‹ Formal verification is effective for critical

‹ What do formal methods have to offer? components ƒ initial models developed fairly quickly (e.g. one week) ‹ A survey of existing techniques ƒ effort cost is similar to manual inspection ƒ always reveals ambiguities and minor documentation errors ‹ Example modeling language: SCR ƒ often reveals errors that cannot be detected through inspection and ƒ The language testing ƒ Case study ƒ But there are no studies of cost effectiveness vs. criticality tradeoff ƒ Advantages and disadvantages ‹ Emphasis on finding errors is appropriate ‹ Example analysis technique: Model Checking ƒ All existing methods used by verification/test teams have this focus ƒ How it works ƒ Hence, just another tool in the V&V toolbox ƒ Case Study ‹ Abstraction, partitioning & projection are important ƒ Advantages and disadvantages ƒ This is the hard part - producing an analyzable model you are here! ‹ ÿ Determine which verification properties you are interested in first; Where next? ÿ use these to guide the modeling process

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Technology Transfer Issues More Tech Transfer issues

‹ Expertise needed ‹ Cost effectiveness ƒ Knowing when and how to apply formal verification requires much expertise ƒ No models yet for ROI for formal verification of specifications ƒ Building a state machine model is straightforward ƒ Two expected benefits: ƒ Building a checkable state machine model is much harder ÿ some defects found earlier (before coding); Reduces cost of testing ÿ (Need training on how modeling features affect state space size) some defects would not be found at all otherwise; Increases quality of product ƒ Identifying appropriate properties to verify requires domain expertise ‹ Evolution of Models ƒ Expressing these properties formally is relatively straightforward ƒ Requirements and Design models must be evolvable ‹ Who performs the analysis? ƒ Evolution is difficult when the models have been carefully optimized for ƒ Programmers don’t like to program the same problem twice model checking (can models be extracted from code??) ƒ Regression testing is hard because properties are defined in terms of the ƒ V&V teams do modeling and defect detection routinely model ‹ Link to testing ƒ E.g. use traces from the requirements model as test cases ƒ E.g. embed the never clause as a runtime monitor

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Using Formal Methods Further Reading I

‹ Selective use of Formal Methods ‹ Introductions to Formal Methods: ƒ Amount of formality can vary ÿ Huth M. & Ryan, M. “Logic for Computer Science: Modeling and Reasoning about Systems”. Cambridge University Press, 1999 ƒ Need not build complete formal models ÿ Heitmeyer, C. and Mandrioli, D. "Formal Methods for Real-time Computing" Wiley, ÿ Apply to the most critical pieces 1996. ÿ Apply where existing analysis techniques are weak ÿ E.M. Clarke and J. Wing. “Formal Methods: State of the Art and Future Directions”. ƒ Need not formally analyze every system property ACM Computing Surveys, 28(4):626–643, December 1996. ÿ E.g. check safety properties only ÿ Jackson, D. and Wing, J. “Lightweight Formal Methods”. IEEE Computer, April 1996. ƒ Need not apply FM in every phase of development ÿ E.g. use for modeling requirements, but don’t formalize the specification ‹ On modeling in RE: ƒ Can choose what level of abstraction (amount of detail) to model ÿ M. Jackson, “Software Requirements and Specifications: A lexicon of Practice, Principles and Prejudices”, Addison Wesley, 1995. ‹ Lightweight Formal Methods ‹ On formal methods and technology transfer: ƒ Have become popular as a means of getting the technology transferred ÿ D. Craigen and S. Gerhart and T. Ralston, ”Formal Methods Reality Check: Industrial ƒ Two approaches Usage”, IEEE Transactions on Software Engineering, vol 21, no 2, pp90-98, Feb ÿ Lightweight use of FMs - selectively apply FMs for partial modeling 1995. ÿ Lightweight FMs - new methods that allow unevaluated predicates ÿ J.A. Hall, Seven Myths of Formal Methods. IEEE Software, 7(5):11-19, September 1990. ÿ J.P. Bowen and M.G. Hinchey, Seven More Myths of Formal Methods. IEEE Software, 12(4):34-41, July 1995

11 University of Toronto Department of Computer Science Further Reading II ‹ On the formal techniques described in this tutorial: SCR: ÿ C. L. Heitmeyer, R. D. Jeffords, and B. G. Labaw, “Automated Consistency Checking of Requirements Specifications,” IEEE Transactions on Software Engineering and Methodology, vol. 5, pp. 231-261, 1996. Model checking: ÿ E. Clarke, O. Grumberg, and D. Peled. “Model Checking”. MIT Press, 1999. ÿ M. Dwyer, G. Avrunin, and J. Corbett. “Patterns in Property Specifications for Finite-State Verification”. In Proceedings of 21st International Conference on Software Engineering, May 1999. ‹ Case Studies: ÿ T. Sreemani and J. M. Atlee. “Feasibility of Model Checking Software Requirements: A Case Study”. In Proceedings of COMPASS’96, Gaithersburg, Maryland, June 1996. ÿ S. M. Easterbrook, R. R. Lutz, R. Covington, J. Kelly, Y. Ampo and D. Hamilton, “Experiences Using Lightweight Formal Methods for Requirements Modeling”. IEEE Transactions on Software Engineering, vol. 24, (1), 1998. ÿ F. Schneider, S. M. Easterbrook, J. R. Callahan and G. J. Holzmann, “Validating Requirements for Fault Tolerant Systems using Model Checking”, Third IEEE Conference on Requirements Engineering, Colorado Springs, CO, April 6 - 10, 1998. ÿ V. Wiels and S. M. Easterbrook, “Formal Modeling of Space Shuttle Software Change Requests using SCR”, Proceedings, Fourth IEEE International Symposium on Requirements Engineering (RE’99), Limerick,Ireland, June 7-11, 1999. © 2000-2002, Steve Easterbrook 67