capture business processes involving concurrency and synchronization good for analyzing dependencies between tasks Class Diagrams Recap on definitions for V V 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 Validation Techniques Statecharts Inspection see lecture 6 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 Model Checking see lecture 16 Prototyping Use Cases Verification Techniques 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 Consistency Checking Sequence Diagrams collaboration diagrams are similar Making Specifications Traceable see lecture 21 Independent V V 1 Easterbrook 2004 University of Toronto 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 operations University of Toronto Department of Computer Science The story so far part 2 Problem Situation Validation Are we building the right system 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 Does our problem statement accurately capture the real problem as an example risk analysis technique Problem Statement Did we account for the needs of all the stakeholders 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 Verification Are we building the system right Entity Relationship Models Does our design meet the spec Mode Class Tables Event Tables and Condition Tables SCR Does the delivered system do what we said it would do Capture the relational structure of information to be stored Good for understanding constraints and assumptions about the subject domain Good basis for database design Does our implementation meet the spec 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 reasoning Easterbrook 2004 Department of Computer Science Verification and Validation We ve looked at the following non UML diagrams Fault Tree Models 2 Easterbrook 2004 Are our requirements models consistent with one another 3 Easterbrook 2004 Validation We ve looked at the following UML diagrams Activity diagrams Some Refreshers Summary of Modelling Techniques seen so far Department of Computer Science The story so far Lecture 19 Verification and Validation University of Toronto Department of Computer Science Verification University of Toronto Implementation Statement System 4 1 University of Toronto University of Toronto Department of Computer Science Department of Computer Science Refresher V V Criteria Application Domain V V Example Machine Domain 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 Some distinctions Specification S 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 in order to meet the requirements Reverse thrust enabled if and only if wheel pulses on Does the flight software P running on the aircraft flight computer C correctly implement S Two verification criteria The Program running on a particular Computer satisfies the Specification The Specification given the Domain properties satisfies the Requirements Does S in the context of assumptions D satisfy R Two validation criteria University of Toronto Are the requirements R what is really needed Did we miss any 5 Source Adapted from Jackson 1995 p170 171 Validation Are our assumptions D about the domain correct Did we miss any Did we discover and understand all the important Requirements Did we discover and understand all the relevant Domain properties Easterbrook 2004 Verification Department of Computer Science University of Toronto Inquiry Cycle Prior Knowledge Initial hypotheses Observe Department of Computer Science Shortcuts in the inquiry cycle Note similarity with process of scientific investigation e g customer feedback 6 Easterbrook 2004 Prior Knowledge e g customer feedback Requirements models are theories about the world Designs are tests of those theories Observe what is wrong with thethe current prototype system the model what is wrong with the current system Look for anomalies what can t the current theory explain Model Intervene replace the old system Carry out the experiments manipulate the variables Easterbrook 2004 Design experiments to test the new theory Intervene Check Check properties properties of of the the model model Get users to to try try itit Get users replace the old system describe explain the observed problems Create refine a better theory Design invent a better system Analyze Analyze the the model model Build Build aa Prototype Prototype Design Model describe explain the observed problems invent a better system 7 Easterbrook 2004 8 2 University of Toronto Department of Computer Science University of Toronto Prototyping Throwaway or Evolve A software prototype is a partial implementation constructed primarily to enable customers users or developers to learn more about a problem or its solution Davis 1990 Throwaway Use Approach Advantages Learning medium for better convergence Early delivery early testing less cost Successful even if it fails Exploratory Prototypes used to determine problems elicit needs clarify goals compare design options informal unstructured and thrown away Disadvantages Breadboards or Experimental Prototypes Wasted effort if reqts
View Full Document
Unlocking...