1. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 9 Design Engineering Software Engineering: A Practitioner’s Approach, 6/e Chapter 9 Design Engineering copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

2. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2 Analysis Model -> Design Model

3. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3 Design and Quality the design must implement all of the the design must implement all of the explicit requirements contained in the analysis model, explicit requirements contained in the analysis model, implicit requirements desired by the customer. implicit requirements desired by the customer. the design must be a readable, understandable guide for those who the design must be a readable, understandable guide for those who generate code generate code test test support the software. support the software. the design should provide a complete picture of the software, addressing the the design should provide a complete picture of the software, addressing the data, functional, and behavioral domains data, functional, and behavioral domains from an implementation perspective. from an implementation perspective.

4. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4 Quality Guidelines A design should exhibit an architecture A design should exhibit an architecture (1) created using recognizable architectural styles or patterns, (1) created using recognizable architectural styles or patterns, (2) composed of components with good design characteristics (2) composed of components with good design characteristics (3) can be implemented in an evolutionary fashion (3) can be implemented in an evolutionary fashion For smaller systems, design can sometimes be developed linearly. For smaller systems, design can sometimes be developed linearly. A design should be modular; A design should be modular; the software should be logically partitioned into elements or subsystems the software should be logically partitioned into elements or subsystems A design should contain distinct representations of A design should contain distinct representations of data, architecture, interfaces, and components. data, architecture, interfaces, and components. A design should lead to data structures that are A design should lead to data structures that are appropriate for the classes to be implemented appropriate for the classes to be implemented are drawn from recognizable data patterns. are drawn from recognizable data patterns.

5. Quality Guidelines (cont.) A design should lead to A design should lead to components that exhibit independent functional characteristics. components that exhibit independent functional characteristics. A design should lead to A design should lead to interfaces that reduce the complexity of connections between components and with the external environment. interfaces that reduce the complexity of connections between components and with the external environment. A design should be derived using a repeatable method A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis. that is driven by information obtained during software requirements analysis. A design should be represented using A design should be represented using a notation that effectively communicates its meaning. a notation that effectively communicates its meaning. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5

6. 6 Fundamental Concepts abstraction—data, procedure, control abstraction—data, procedure, control architecture—the overall structure of the software architecture—the overall structure of the software patterns—”conveys the essence” of a proven design solution patterns—”conveys the essence” of a proven design solution modularity—compartmentalization of data and function modularity—compartmentalization of data and function Information hiding—controlled interfaces Information hiding—controlled interfaces Functional independence—single-minded function and low coupling Functional independence—single-minded function and low coupling refinement—elaboration of detail for all abstractions refinement—elaboration of detail for all abstractions Refactoring—a reorganization technique that simplifies the design Refactoring—a reorganization technique that simplifies the design

7. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7 Data Abstraction door implemented as a data structure manufacturer model number type swing direction inserts lights type type number number weight opening mechanism Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

8. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8 Procedural Abstraction open implemented with a "knowledge" of the object that is associated with enter details of enter algorithm

9. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9 Architecture “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a] Structural properties. Defines the components of a system (e.g., modules, objects, filters) andDefines the components of a system (e.g., modules, objects, filters) and How the components are packaged and interact with one another.How the components are packaged and interact with one another. Extra-functional properties. How the design architecture achieves requirements for How the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics. performance, capacity, reliability, security, adaptability, and other system characteristics. Families of related systems. draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. The design should have the ability to reuse architectural building blocks. The design should have the ability to reuse architectural building blocks. Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

10. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10 Patterns Design Pattern enables a designer to determine whether the pattern : is applicable to the current work is applicable to the current work can be reused can be reused can serve as a guide for developing a similar, but functionally or structurally different pattern. can serve as a guide for developing a similar, but functionally or structurally different pattern. Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

11. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11 Modular Design Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

12. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12 Modularity: Trade-offs What is the "right" number of modules for a specific software design? optimal number of modules of modules cost of cost of software software number of modules moduleintegrationcost module development cost

13. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13 Information Hiding module controlled interface "secret" algorithm algorithm data structure data structure details of external interface details of external interface resource allocation policy resource allocation policy clients a specific design decision Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

14. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14 Why Information Hiding? reduces the likelihood of “side effects” reduces the likelihood of “side effects” limits the global impact of local design decisions limits the global impact of local design decisions emphasizes communication through controlled interfaces emphasizes communication through controlled interfaces discourages the use of global data discourages the use of global data leads to encapsulation—an attribute of high quality design leads to encapsulation—an attribute of high quality design results in higher quality software results in higher quality software

15. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15 Functional Independence Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

16. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16 Stepwise Refinement open walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

17. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17 Refactoring Fowler [FOW99] defines refactoring in the following manner: "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.” When software is refactored, the existing design is examined for redundancy unused design elements inefficient or unnecessary algorithms poorly constructed or inappropriate data structures or any other design failure that can be corrected to yield a better design. Abstraction-architecture-patterns-modularity-hiding-functional independence-refinement-refactoring

18. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18 OO Design Concepts Design classes Design classes Entity classes Entity classes Boundary classes Boundary classes Controller classes Controller classes Inheritance—all responsibilities of a superclass is immediately inherited by all subclasses Inheritance—all responsibilities of a superclass is immediately inherited by all subclasses Messages—stimulate some behavior to occur in the receiving object Messages—stimulate some behavior to occur in the receiving object Polymorphism—a characteristic that greatly reduces the effort required to extend the design Polymorphism—a characteristic that greatly reduces the effort required to extend the design

19. A well-formed design class Complete and sufficient Complete and sufficient Encapsulation of attributes and methods that are reasonably expected Encapsulation of attributes and methods that are reasonably expected Primitiveness Primitiveness Methods associated with a design class should be focused on accomplishing one service for the class Methods associated with a design class should be focused on accomplishing one service for the class And no other method to accomplish the same service And no other method to accomplish the same service High cohesion High cohesion A small, focused set of responsibilities A small, focused set of responsibilities single-mindedly applies attributes and methods to implement those responsibilities single-mindedly applies attributes and methods to implement those responsibilities Low coupling Low coupling Collaboration is necessary, but should be kept to an acceptable minimum. Collaboration is necessary, but should be kept to an acceptable minimum. Methods only send messages to neighboring classes Methods only send messages to neighboring classes 19

20. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20 The Design Model

21. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21 Design Model Elements Data elements Data elements Architectural elements (floor plan of a house) Architectural elements (floor plan of a house) Interface elements (detailed drawing for doors, windows, external utilities) Interface elements (detailed drawing for doors, windows, external utilities) Component elements (detailed drawing of each room, wiring, place of switches…) Component elements (detailed drawing of each room, wiring, place of switches…) Deployment elements Deployment elements

22. Design Model Elements Data elements Data elements Data model at component level --> data structures Data model at component level --> data structures Data model at architecture level --> database architecture Data model at architecture level --> database architecture Architectural elements (floor plan of a house) Architectural elements (floor plan of a house) Application domain Application domain Analysis classes, their relationships, collaborations and behaviors are transformed into design realizations Analysis classes, their relationships, collaborations and behaviors are transformed into design realizations Patterns and styles Patterns and styles Interface elements (detailed drawing for doors, windows, external utilities) Interface elements (detailed drawing for doors, windows, external utilities) the user interface (UI) the user interface (UI) external interfaces to other systems, devices, networks or other producers or consumers of information external interfaces to other systems, devices, networks or other producers or consumers of information internal interfaces between various design components internal interfaces between various design components. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22

23. Component elements (detailed drawing of each room, wiring, place of switches…) Component elements (detailed drawing of each room, wiring, place of switches…) Internal details of each software component Internal details of each software component Data structures, Data structures, algorithmic details, algorithmic details, interface to access component operation (behavior) interface to access component operation (behavior) Deployment elements Deployment elements How software functionality and subsystems will be allocated within the physical computing environment How software functionality and subsystems will be allocated within the physical computing environment These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23

24. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24 Interface Elements

25. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25 Component Elements

26. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26 Deployment Elements

27. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 27 Design Patterns The best designers in any field have an uncanny ability to see patterns that characterize a problem and corresponding patterns that can be combined to create a solution The best designers in any field have an uncanny ability to see patterns that characterize a problem and corresponding patterns that can be combined to create a solution A description of a design pattern may also consider a set of design forces. A description of a design pattern may also consider a set of design forces. Design forces describe non-functional requirements (e.g., ease of maintainability, portability) associated the software for which the pattern is to be applied. Design forces describe non-functional requirements (e.g., ease of maintainability, portability) associated the software for which the pattern is to be applied. The pattern characteristics (classes, responsibilities, and collaborations) indicate the attributes of the design that may be adjusted to enable the pattern to accommodate a variety of problems. The pattern characteristics (classes, responsibilities, and collaborations) indicate the attributes of the design that may be adjusted to enable the pattern to accommodate a variety of problems.