Chapter 8DesignAnalysis Model -> Design ModelDesign and QualityQuality GuidelinesDesign PrinciplesFundamental ConceptsData AbstractionProcedural AbstractionArchitecturePatternsSeparation of ConcernsModularityModularity: Trade-offsInformation HidingWhy Information Hiding?Stepwise RefinementSizing Modules: Two ViewsFunctional IndependenceAspectsAspects—An ExampleRefactoringOO Design ConceptsDesign ClassesThe Design ModelDesign Model ElementsArchitectural ElementsInterface ElementsComponent ElementsDeployment ElementsThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 1Chapter 8Design ConceptsSlide Set to accompanySoftware Engineering: A Practitioner’s Approach, 7/e by Roger S. PressmanSlides copyright © 1996, 2001, 2005, 2009 by Roger S. PressmanFor non-profit educational use onlyMay be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author.All copyright information MUST appear if these slides are posted on a website for student use.These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 2DesignMitch Kapor, the creator of Lotus 1-2-3, presented a “software design manifesto” in Dr. Dobbs Journal. He said:Good software design should exhibit:Firmness: A program should not have any bugs that inhibit its function. Commodity: A program should be suitable for the purposes for which it was intended. Delight: The experience of using the program should be pleasurable one.These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 3Analysis Model -> Design ModelAnalysis Modeluse-cases - text use-case diagrams activity diagrams swim lane diagramsdata flow diagrams control-flow diagrams processing narrativesf low- oriented elementsbehavioralelementsc lass- basedelementsscenario- basedelementsclass diagrams analysis packages CRC models collaboration diagrams state diagrams sequence diagramsDat a/ Class DesignArc hit ec t ural DesignInt erfac e DesignComponent - L evel DesignDesign ModelThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 4Design and Qualitythe design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.the design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.the design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 5Quality GuidelinesA design should exhibit an architecture that (1) has been created using recognizable architectural styles or patterns, (2) is composed of components that exhibit good design characteristics and (3) can be implemented in an evolutionary fashion For smaller systems, design can sometimes be developed linearly.A design should be modular; that is, the software should be logically partitioned into elements or subsystemsA design should contain distinct representations of data, architecture, interfaces, and components.A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns.A design should lead to components that exhibit independent functional characteristics.A design should lead to interfaces that reduce the complexity of connections between components and with the external environment.A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.A design should be represented using a notation that effectively communicates its meaning.These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 6Design PrinciplesThe design process should not suffer from ‘tunnel vision.’ The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should “minimize the intellectual distance” [DAV95] between the software and the problem as it exists in the real world. The design should exhibit uniformity and integration. The design should be structured to accommodate change. The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Design is not coding, coding is not design. The design should be assessed for quality as it is being created, not after the fact. The design should be reviewed to minimize conceptual (semantic) errors.From Davis [DAV95]These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 7Fundamental ConceptsAbstraction—data, procedure, controlArchitecture—the overall structure of the softwarePatterns—”conveys the essence” of a proven design solutionSeparation of concerns—any complex problem can be more easily handled if it is subdivided into piecesModularity—compartmentalization of data and functionHiding—controlled interfacesFunctional independence—single-minded function and low couplingRefinement—elaboration of detail for all abstractionsAspects—a mechanism for understanding how global requirements affect designRefactoring—a reorganization technique that simplifies the designOO design concepts—Appendix IIDesign Classes—provide design detail that will enable analysis classes to be implementedThese slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 8Data Abstractiondoordoorimplemented as a data structuremanufacturermanufacturermodel