1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 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. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Slide 14 Chapter 13 Design Concepts and Principles

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

4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Where Do We Begin? Spec Prototype Design modeling

5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Design 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]

6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Fundamental Concepts  abstraction—data, procedure, control  refinement—elaboration of detail for all abstractions  modularity—compartmentalization of data and function  architecture—overall structure of the software  Structural properties  Extra-structural properties  Styles and patterns  procedure—the algorithms that achieve function  hiding—controlled interfaces

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

8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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

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

11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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

12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Sizing Modules: Two Views

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

14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Architecture “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a] Structural properties. This aspect of the architectural design representation defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods. Extra-functional properties. The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics. Families of related systems. The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability to reuse architectural building blocks.

15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Control Hierarchy  Represents the organization of program components & implies a hierarchy of control  Does not represent:  Procedural aspect of SW such as sequence, order, repetition  Applicability to all architectural styles ++

16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Representation – treelike diagram M a b c deklm f ghnop q i j Width depth Fan-out Fan-in r ++

17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Note on diagram…  Depth and width provide an indication of the number of levels of control and overall span of control, respectively  Fan-out is a measure of the number of modules that are directly controlled by another module  Fan-in indicates how many modules directly control a given modules  A module that control another module is said to be super- ordinate to it  A module controlled by another is said to be subordinate to the controller  Eg. M is super-ordinate to a, b & c  Eg. h is subordinate to e & ultimately to M ++

18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Structural Partitioning  Horizontal Partitioning  Vertical Partitioning (factoring) ++

19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Data Structure  A representation of the logical relationship among individual elements of data 1.Scalar item 2.Sequential vector 3.N-dimensional space (array) 4.Linked list  Hierarchical data structure – multi linked list  Different level of abstraction, eg. stack ++

20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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

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

22 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Design Heuristics  Reduce coupling, improve cohesion  Minimize fan-out, strive for fan-in  Keep the scope of effect within the scope of control  Evaluate module interface to reduce complexity and redundancy and improve consistency  Function is predictable, but not overly restrictive  Strive for “controlled entry” modules by avoiding “pathological connection” ++

23 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Design Model Data design Architectural design interface design Component-level design implementation test maintenance ++

24 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Design documentation  Scope of design effort  Derived from system specification & SW requirement specification  Data design  Architectural design  Interfaces  Components  Cross reference  Test plan  constraints  Supplementary data ++