1University of TorontoDepartment of Computer Science© Easterbrook 20041Lecture 19:Verification and Validation Some Refreshers: Summary of Modelling Techniques seen so far Recap on definitions for V&V Validation Techniques Inspection (see lecture 6) Model Checking (see lecture 16) Prototyping Verification Techniques Consistency Checking Making Specifications Traceable (see lecture 21) Independent V&VUniversity of TorontoDepartment of Computer Science© Easterbrook 20042The story so far We’ve looked at the following UML diagrams: Activity diagrams capture business processes involving concurrency and synchronization good for analyzing dependencies between tasks Class Diagrams capture the structure of the information used by the system good for analysing the relationships between data items used by the system good for helping you identify a modular structure for the system Statecharts capture all possible responses of an object to all uses cases in which it is involved good for modeling the dynamic behavior of a class of objects good for analyzing event ordering, reachability, deadlock, etc. Use Cases capture the view of the system from the view of its users good starting point for specification of functionality good visual overview of the main functional requirements Sequence Diagrams (collaboration diagrams are similar) capture an individual scenario (one path through a use case) good for modelling dialog structure for a user interface or a business process good for identifying which objects (classes) participate in each use case helps you check that you identified all the necessary classes and operationsUniversity of TorontoDepartment of Computer Science© Easterbrook 20043The story so far (part 2) We’ve looked at the following non-UML diagrams Goal Models Capture strategic goals of stakeholders Good for exploring ‘how’ and ‘why’ questions with stakeholders Good for analysing trade-offs, especially over design choices Fault Tree Models (as an example risk analysis technique) Capture potential failures of a system and their root causes Good for analysing risk, especially in safety-critical applications Strategic Dependency Models (i*) Capture relationships between actors in an organisational setting Helps to relate goal models to organisational setting Good for understanding how the organisation will be changed Entity-Relationship Models Capture the relational structure of information to be stored Good for understanding constraints and assumptions about the subject domain Good basis for database design Mode Class Tables, Event Tables and Condition Tables (SCR) Capture the dynamic behaviour of a real-time reactive system Good for representing functional mapping of inputs to outputs Good for making behavioural models precise, for automated reasoningUniversity of TorontoDepartment of Computer Science© Easterbrook 20044Verification and ValidationProblemStatementImplementationStatementSystemValidationVerification Validation: “Are we building the rightsystem?” Does our problem statementaccurately capture the realproblem? Did we account for the needs ofall the stakeholders? Verification: “Are we building the systemright?” Does our design meet the spec? Does our implementation meet thespec? Does the delivered system dowhat we said it would do? Are our requirements modelsconsistent with one another?ProblemSituation2University of TorontoDepartment of Computer Science© Easterbrook 20045Refresher: V&V Criteria Some distinctions: Domain Properties: things in the application domain that are true anyway Requirements: things in the application domain that we wish to be made true Specification: a description of the behaviours the program must have inorder to meet the requirements Two verification criteria: The Program running on a particular Computer satisfies the Specification The Specification, given the Domain properties, satisfies the Requirements Two validation criteria: Did we discover (and understand) all the important Requirements? Did we discover (and understand) all the relevant Domain properties?Source: Adapted from Jackson, 1995, p170-171Application DomainMachine DomainUniversity of TorontoDepartment of Computer Science© Easterbrook 20046V&V Example Example: Requirement R: “Reverse thrust shall only be enabled when the aircraft is moving on the runway” Domain Properties D: Wheel pulses on if and only if wheels turning Wheels turning if and only if moving on runway Specification S: Reverse thrust enabled if and only if wheel pulses on Verification Does the flight software, P, running on the aircraft flight computer, C,correctly implement S? Does S, in the context of assumptions D, satisfy R? Validation Are our assumptions, D, about the domain correct? Did we miss any? Are the requirements, R, what is really needed? Did we miss any?University of TorontoDepartment of Computer Science© Easterbrook 20047Inquiry CyclePrior Knowledge(e.g. customer feedback)Observe(what is wrong withthe current system?)Model(describe/explain theobserved problems)Design(invent a better system)Intervene(replace the old system)Note similarity withprocess of scientificinvestigation:Requirements models aretheories about the world;Designs are tests of thosetheoriesInitial hypothesesLook for anomalies - what can’tthe current theory explain?Create/refinea better theoryDesign experiments totest the new theoryCarry out theexperiments(manipulatethe variables)University of TorontoDepartment of Computer Science© Easterbrook 20048Shortcuts in the inquiry cyclePrior Knowledge(e.g. customer feedback)Observe(what is wrong withthe current system?)Model(describe/explain theobserved problems)Design(invent a better system)Intervene(replace the old system)Build aPrototypeBuild aPrototypeGet usersto try itGet usersto try it(what is wrong withthe prototype?)Analyzethe modelAnalyzethe modelCheck propertiesof the modelCheck propertiesof the model(what is wrong withthe model?)3University of TorontoDepartment of Computer Science© Easterbrook 20049Prototyping“A software prototype is a partial implementation constructed primarily toenable customers, users, or developers to learn more about a problem or itssolution.” [Davis 1990]“Prototyping is the
View Full Document
Unlocking...