Slide 13.1 Object-Oriented And Classical Software

Slide 13.1Object-Oriented andClassical SoftwareEngineeringFifth Edition, WCB/McGraw-Hill, 2002Stephen R. Schachsrs@vuse.vanderbilt.edu The McGraw-Hill Companies, 2002

CHAPTER 13DESIGN PHASE The McGraw-Hill Companies, 2002Slide 13.2

OverviewzzzzzzzDesign and abstractionAction-oriented designData flow analysisTransaction analysisData-oriented designObject-oriented designElevator problem: object-oriented design The McGraw-Hill Companies, 2002Slide 13.3

Overview (contd)zzzzzzzSlide 13.4Formal techniques for detailed designReal-time design techniquesTesting during the design phaseCASE tools for the design phaseMetrics for the design phaseAir Gourmet Case Study: object-oriented designChallenges of the design phase The McGraw-Hill Companies, 2002

Data and ActionszTwo aspects of a product– Actions that operate on data– Data on which actions operatezThe two basic ways of designing a product– Action-oriented design– Data-oriented designzThird way– Hybrid methods– For example, object-oriented design The McGraw-Hill Companies, 2002Slide 13.5

Design ActivitieszzzArchitectural designDetailed designDesign testing The McGraw-Hill Companies, 2002Slide 13.6

Architectural DesignzzzInput:SpecificationsOutput: Modular decompositionAbstraction The McGraw-Hill Companies, 2002Slide 13.7

Detailed DesignzEach module is designed– Specific algorithms– Data structures The McGraw-Hill Companies, 2002Slide 13.8

Action-Oriented Design MethodszzSlide 13.9Data flow analysisWhen to use it– With most specification methods (Structured SystemsAnalysis here)zKey point: We have detailed action informationfrom the DFD The McGraw-Hill Companies, 2002

Data Flow AnalysiszzProduct transforms input into outputDetermine– “Point of highest abstraction of input”– “Point of highest abstract of output” The McGraw-Hill Companies, 2002Slide 13.10

Data Flow Analysis (contd)zzSlide 13.11Decompose into three modulesRepeat stepwise until each module has highcohesion– Minor modifications may be needed to lower the coupling The McGraw-Hill Companies, 2002

Data Flow Analysis (contd)zSlide 13.12ExampleDesign a product which takes as input a file name, andreturns the number of words in that file (like UNIX wc ) The McGraw-Hill Companies, 2002

Data Flow Analysis Example (contd)zzSlide 13.13First refinementNow refine the two modules of communicationalcohesion The McGraw-Hill Companies, 2002

Data Flow Analysis Example (contd)Slide 13.14zSecond refinementzAll eight modules now have functional cohesion The McGraw-Hill Companies, 2002

Multiple Input and Output StreamsSlide 13.15zPoint of highest abstraction for each streamzContinue until each module has high cohesion– Adjust the coupling if needed The McGraw-Hill Companies, 2002

Transaction AnalysiszDFA poor for transaction processing products– Example: ATM (automated teller machine)zSlide 13.16Poor design– Logical cohesion, control coupling The McGraw-Hill Companies, 2002

Corrected Design Using Transaction AnalysisSlide 13.17zzzSoftwarereuseHave onegeneric editmodule, onegeneric updatemoduleInstantiatethem 5 times The McGraw-Hill Companies, 2002

Data-Oriented DesignzSlide 13.18Basic principle– The structure of a product must conform to the structureof its datazThree very similar methods– Warnier– Orr– JacksonzData-oriented design– Has never been as popular as action-oriented design– With the rise of OOD, data-oriented design has largelyfallen out of fashion The McGraw-Hill Companies, 2002

Object-Oriented Design (OOD)zSlide 13.19Aim– Design the product in terms of the classesextracted during OOAzIf we are using a language without inheritance(C, Ada 83)– Use abstract data type designzIf we are using a language without a typestatement (FORTRAN, COBOL)– Use data encapsulation The McGraw-Hill Companies, 2002

Object-Oriented Design StepszSlide 13.20OOD consists of four steps:––––1.2.3.4.Construct interaction diagrams for each scenarioConstruct the detailed class diagramDesign the product in terms of clients of objectsProceed to the detailed design The McGraw-Hill Companies, 2002

Elevator Problem: OODzzzStep 1. Construct interaction diagrams foreach scenarioSequence diagramsCollaboration diagrams– Both show the same thing– Objects and messages passed between them– But in a different way The McGraw-Hill Companies, 2002Slide 13.21

Elevator Problem: OOD (contd)zNormal scenario The McGraw-Hill Companies, 2002Slide 13.22

Elevator Problem: OOD (contd)zSequence diagram The McGraw-Hill Companies, 2002Slide 13.23

Elevator Problem: OOD (contd)zCollaborationdiagram The McGraw-Hill Companies, 2002Slide 13.24

Elevator Problem: OOD (contd)zzzStep 2. Construct the detailed class diagramDo we assign an action to a class or to a client ofthat class?Criteria– Information hiding– Reducing number of copies of each action– Responsibility-driven designzSlide 13.25Examplesis assigned to Elevator Doorsmove one floor down is assigned to Elevatorclose doors The McGraw-Hill Companies, 2002

Elevator Problem: OOD (contd)zDetailedclassdiagram The McGraw-Hill Companies, 2002Slide 13.26

Elevator Problem: OOD (contd)zzzSlide 13.27Step 3. Design the product in terms of clients ofobjectsDraw an arrow from an object to a client of thatobjectObjects that are not clients of any object have tobe initiated, probably by the main method– Additional methods may be needed The McGraw-Hill Companies, 2002

Elevator Problem: OOD (contd)zC client-object relations The McGraw-Hill Companies, 2002Slide 13.28

Elevator Problem: OOD (contd)zJava client-object relations The McGraw-Hill Companies, 2002Slide 13.29

Elevator Problem: OOD (contd)zSlide 13.30needs method elevator control loop so thatmain (or elevator application) can call itelevator controller The McGraw-Hill Companies, 2002

Elevator Problem: OOD (contd)zzStep 4. Performthe detaileddesignDetailed designof method elevatorcontroller loop The McGraw-Hill Companies, 2002Slide 13.31

Formal Techniques for Detailed DesignzzSlide 13.32Implementing a complete product and thenproving it correct is hardHowever, use of formal techniques during detaileddesign can help– Correctness proving can be applied to module-sizedpieces– The design should have fewer faults if it is developed inparallel with a correctness proof– If the same programmer does the detailed design andimplementation» The programmer will have a positive attitude to the detaileddesign» This should lead to fewer faults The McGraw-Hill Companies, 2002

Design of Real-Time SystemszSlide 13.33Difficulties associated with real-time systems– Inputs come from the real world» Software has no control over the timing of the inputs– Frequently implemented on distributed software» Communications implications» Timing issues– Problems of synchronization» Race conditions» Deadlock (deadly embrace)zMajor difficulty in the design of real-time systems– Determining whether the timing constraints are met bythe design The McGraw-Hill Companies, 2002

Real-Time Design MethodszzzSlide 13.34Usually, extensions of nonreal-time methods toreal-timeWe have limited experience in use of any real-timemethodsThe state-of-the-art is not where we would like it tobe The McGraw-Hill Companies, 2002

Testing during the Design PhasezSlide 13.35Design reviews– The design must correctly reflect the specifications– The design itself must be correct– Transaction-driven inspections The McGraw-Hill Companies, 2002

CASE Tools for the Design PhasezUpperCASE tools–––––Built around a data dictionaryConsistency checkerScreen, report generatorsModern tools represent OOD using UMLExamples:» Software through Pictures» Rose The McGraw-Hill Companies, 2002Slide 13.36

Metrics for the Design PhasezzThe five basic metricsCyclomatic complexity is problematic– Data complexity is ignored– Not used much with the object-oriented paradigm The McGraw-Hill Companies, 2002Slide 13.37

Air Gourmet Case Study: Object-Oriented DesignSlide 13.38zOOD consists of four steps:––––1.2.3.4.Construct interaction diagrams for each scenarioConstruct the detailed class diagramDesign the product in terms of clients of objectsProceed to the detailed design The McGraw-Hill Companies, 2002

Step 1. Interaction DiagramszExtended scenario for making a reservation The McGraw-Hill Companies, 2002Slide 13.39

Step 1. Interaction Diagrams (contd)zSequence diagram formaking a reservation The McGraw-Hill Companies, 2002Slide 13.40

Step 1. Interaction Diagrams (contd)zSlide 13.41Collaboration diagram for sending and returninga postcard The McGraw-Hill Companies, 2002

Step 2. Detailed Class DiagramC version The McGraw-Hill Companies, 2002Java versionSlide 13.42

Step 3. Client–Object RelationsC versionJava version The McGraw-Hill Companies, 2002Slide 13.43

Step 4. Detailed DesignzThe detailed design can be found in– Appendix H (for implementation in C )– Appendix I (for implementation in Java) The McGraw-Hill Companies, 2002Slide 13.44

Challenges of the Design PhasezThe design team should not do too much– The detailed design should not become codezThe design team should not do too little– It is essential for the design team to produce acomplete detailed designzWe need to grow great designers The McGraw-Hill Companies, 2002Slide 13.45

Data-Oriented Design zBasic principle – The structure of a product must conform to the structure of its data zThree very similar methods – Warnier – Orr – Jackson zData-oriented design – Has never been as popular as action-oriented design – With the rise of OOD, data-oriented design has largely fallen out of fashion