Chapter 9Design Engineering

1

Software Engineering: A Practitioner’s Approach, 6th editionby Roger S. Pressman

Analysis → Design

2

Why is it important?

Design allows a software engineer to modelthe system or product that is to be built. Thismodel can be assessed for quality andimproved before code is generated, tests areconducted, and end‐users become involved inlarge numbers. Design is the place wheresoftware quality is established.

3

• The data / class design transforms analysis‐class models intodesign class realizations and the requisite data structures requiredto implement the software.

• The architectural design defines the relationship between majorstructural elements of the software, the architectural styles anddesign patterns that can be used to achieve the requirementsdefined for the system, and the constraints that affect the way inwhich architectural can be implemented.

4

• The interface design describes how the softwarecommunicates with systems that interoperate with it, andwith humans who use it. An interface implies a flow ofinformation and a specific type of behavior.

• The component‐level design transforms structuralelements of the software architecture into a proceduraldescription of software components. Informationobtained from the class‐based models, flow models, andbehavioral models serve as the basis for componentdesign.

5

Characteristics of a good design

1. A design should exhibit an architecture that,

(a) has been created using recognizable architectural styles or patterns

(b) is composed of components that exhibit good design characteristics

(c) can be implemented in an evolutionary fashion, thereby facilitating implementation and testing

2. A design should be modular, that is, the software should be logically partitioned into elements or subsystems.

6

Characteristics of a good design

3.A design should contain distinct representations ofdata, architecture, interfaces and components.

4. A design should lead to data structures that areappropriate for the classes to be implemented andare drawn from recognizable data patterns.

5. A design should lead to components that exhibitindependent functional characteristics.

7

Characteristics of a good design

6. A design should lead to interfaces that reduce thecomplexity of connections between componentsand with the external environment.

7. A design should be derived using a repeatablemethod that is driven by information obtainedduring software requirements analysis.

8. A design should be represented using a notationthat effectively communicates its meaning.8

Design Concepts ‐ 1

• A set of fundamental software designconcepts has evolved over the history ofsoftware engineering.

• Each provides the software designer with afoundation from which more sophisticateddesign methods can be applied

9

Abstraction ‐ 2

• A modular solution to any problem, many levels of abstraction can be posed.

• A procedural abstraction refers to a sequence of instructions that have a specific and limited function.

• A data abstraction is a named collection of data that describes a data object.

10

Architecture ‐ 3

• Software architecture alludes to “the overallstructure of the software and the ways in whichthat structure provides conceptual integrity for asystem”

• Structural models, framework models, dynamicmodels, process models and functional modelsare number of different models in thearchitectural design. 11

Patterns ‐ 4

• “A pattern is a named nugget of insight whichconveys the essence of a proven solution to arecurring problem within a certain contextamidst competing concerns”

• Pattern is applicable to the current work, savingdesign time and serve as a guide for developinga similar, but functionally or structurally differentpattern. 12

Modularity ‐ 5

• Some architecture and design patterns embodymodularity; that is software id divided intoseparately named and addressable components,sometimes called modules, that are integrated tosatisfy problem requirements.

• “Modularity is the single attribute of softwarethat allows a program to be intellectuallymanageable” 13

Information Hiding ‐ 6

• The principle of information hiding suggests thatmodules be “characterized by design decisionsthat hides from all others”

• A design criterion for modular systems providesthe greatest benefits when modifications arerequired during testing and later, during softwaremaintenance.

14

Functional Independence ‐ 7

• The concept of functional independence is adirect outgrowth of modularity and the conceptsof abstraction and information hiding.

• functional independence is achieved bydeveloping modules with “single‐minded”function and an “aversion” to excessiveinteraction with other modules.

15

Refinement ‐ 8

• A program is developed by successively refininglevels of procedural detail.

• Refinement is actually a process of elaboration.

• Abstraction and refinement are complementaryconcepts

16

Refactoring ‐ 9

• “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure”.

• Software is refectory, the existing design is examined for redundancy, unused design elements, inefficient or unnecessary algorithms.

17

Design classes ‐ 10

• User interface classes define all abstractions that are necessary for human‐computer interaction.

• Business domain classes are often refinements of the analysis classes defined earlier.

• Process classes implement lower‐level business abstractions required to fully manage the business domain classes

18

Modular Design

19

Modularity: Trade‐offs

20

What is the "right" number of modules for a specific software design?

optimal numberof modules

cost ofsoftware

number of modules

moduleintegration

cost

module development cost

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 dataleads to encapsulation—an attribute of high quality design

results in higher quality software

21

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

22