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 9.1 Analysis Model -> Design Model

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 9.2 Design Process and Quality The design process should not suffer from ‘tunnel vision.’ The design process should not suffer from ‘tunnel vision.’ The design should be traceable to the analysis model. The design should be traceable to the analysis model. The design should not reinvent the wheel. 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 “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 exhibit uniformity and integration. The design should be structured to accommodate change. 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. 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. 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 assessed for quality as it is being created, not after the fact. The design should be reviewed to minimize conceptual (semantic) errors. The design should be reviewed to minimize conceptual (semantic) errors. From Davis [DAV95]

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 9.3 Design Concepts abstraction—data, procedure abstraction—data, procedure 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 hiding—controlled interfaces 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

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 Data Abstraction door implemented as a data structure manufacturer model number type swing direction inserts lights type type number number weight opening mechanism

5. 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 Procedural Abstraction open implemented with a "knowledge" of the object that is associated with open details of open algorithm

6. 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 6Architecture “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a] Structural models Structural models Framework models Framework models Dynamic models Dynamic models Process models Process models Functional models Functional models

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 Patterns Design Pattern Template Pattern name—describes the essence of the pattern in a short but expressive name Intent—describes the pattern and what it does Also-known-as—lists any synonyms for the pattern Motivation—provides an example of the problem Applicability—notes specific design situations in which the pattern is applicable Structure—describes the classes that are required to implement the pattern Participants—describes the responsibilities of the classes that are required to implement the pattern Collaborations—describes how the participants collaborate to carry out their responsibilities Consequences—describes the “design forces” that affect the pattern and the potential trade-offs that must be considered when the pattern is implemented Related patterns—cross-references related design patterns

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 Modular Design

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 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

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 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

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 Functional Independence

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 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

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 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.

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 9.4 The Design Model

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 Design Model Elements Data elements Data elements Architectural elements (Chapter 10) Architectural elements (Chapter 10) 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 (Chapter 12) Interface elements (Chapter 12) 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. Component elements Component elements Deployment elements Deployment elements

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 9.5 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.