Software Design

Main issues:
 decompose system into parts
 many attempts to measure the results
 design as product  design as process
Overview

 Introduction

 Design principles

 Design methods

 Conclusion

SE, Design, Hans van Vliet, ©2008 2

Programmer’s Approach to
Software Engineering

Skip requirements engineering and design

phases;
start writing code

SE, Design, Hans van Vliet, ©2008 3

Point to ponder

Is this the same as eXtreme Programming?

Or is there something additional in XP?

SE, Design, Hans van Vliet, ©2008 4

Why this programmer’s approach?

 Design is a waste of time

 We need to show something to the customer real

quick

 We are judged by the amount of LOC/month

 We expect or know that the schedule is too tight

SE, Design, Hans van Vliet, ©2008 5

However, ...

The longer you postpone coding, the sooner you’ll

be finished

SE, Design, Hans van Vliet, ©2008 6

Up front remarks

 Design is a trial-and-error process

 The process is not the same as the outcome of

that process

 There is an interaction between requirements

engineering, architecting, and design

SE, Design, Hans van Vliet, ©2008 7

Software design as a “wicked” problem

 There is no definite formulation

 There is no stopping rule

 Solutions are not simply true or false

 Every wicked problem is a symptom of another

problem

SE, Design, Hans van Vliet, ©2008 8

Overview

 Introduction

 Design principles

 Design methods

 Conclusion

SE, Design, Hans van Vliet, ©2008 9

Design principles

 Abstraction
 Modularity, coupling and cohesion
 Information hiding
 Limit complexity
 Hierarchical structure

SE, Design, Hans van Vliet, ©2008 10

Abstraction

 procedural abstraction: natural consequence of

stepwise refinement: name of procedure denotes
sequence of actions

abstraction subproblems

time

SE, Design, Hans van Vliet, ©2008 11

Abstraction

 data abstraction: aimed at finding a hierarchy in

the data
application-oriented
data structures

simpler data
general structure
data structures

SE, Design, Hans van Vliet, ©2008 12

Modularity

 structural criteria which tell us something about

individual modules and their interconnections

 cohesion and coupling

 cohesion: the glue that keeps a module together

 coupling: the strength of the connection between

modules

SE, Design, Hans van Vliet, ©2008 13

Types of cohesion

 coincidental cohesion
 logical cohesion
 temporal cohesion
 procedural cohesion
 communicational cohesion
 sequential cohesion
 functional cohesion

 data cohesion (to cater for abstract data types)

SE, Design, Hans van Vliet, ©2008 14

How to determine the cohesion type?

 describe the purpose of the module in one sentence

 if the sentence is compound, contains a comma or more

than one verb  it probably has more than one function:
logical or communicational cohesion
 if the sentence contains time-related words like “first”,
“then”, “after”  temporal cohesion
 if the verb is not followed by a specific object  probably
logical cohesion (example: edit all data)
 words like “startup”, “initialize” imply temporal cohesion

SE, Design, Hans van Vliet, ©2008 15

Types of coupling

 content coupling
 common coupling
 external coupling
 control coupling
 stamp coupling
 data coupling

SE, Design, Hans van Vliet, ©2008 16

Coupling levels are technology dependent

 Data coupling assumes scalars or arrays, not

records
 control coupling assumes passing of scalar data

 nowadays:
 modules may pass complex data structures
 modules may allow some modules access to their data, and
deny nit to others (so there are many levels of visibility)
 coupling need not be commutative (AQ may be data coupled
to B, while B is control coupled to A)

SE, Design, Hans van Vliet, ©2008 17

strong cohesion & weak coupling 
simple interfaces 

 simpler communication
 simpler correctness proofs
 changes influence other modules less often
 reusability increases
 comprehensibility improves

SE, Design, Hans van Vliet, ©2008 18

Information hiding

 each module has a secret

 design involves a series of decision: for each
such decision, wonder who needs to know and
who can be kept in the dark
 information hiding is strongly related to
 abstraction: if you hide something, the user may abstract
from that fact
 coupling: the secret decreases coupling between a module
and its environment
 cohesion: the secret is what binds the parts of the module
together
SE, Design, Hans van Vliet, ©2008 19
Point to ponder

 How many lines of code is this:

#include <stdio.h>
#define NULL 0
main ()
{
int i;
for (i=0;i<10;i++) printf(%d”,i);
}

SE, Design, Hans van Vliet, ©2008 20

Complexity

 measure certain aspects of the software (lines of

code, # of if-statements, depth of nesting, …)
 use these numbers as a criterion to assess a
design, or to guide the design
 interpretation: higher value  higher complexity 
more effort required (= worse design)
 two kinds:
 intra-modular: inside one module
 inter-modular: between modules

SE, Design, Hans van Vliet, ©2008 21

intra-modular

 attributes of a single module

 two classes:
 measures based on size
 measures based on structure

SE, Design, Hans van Vliet, ©2008 22

Sized-based complexity measures

 counting lines of code

 differences in verbosity
 differences between programming languages
 a:= b versus while p^ <> nil do p:= p^

 Halstead’s “software science”, essentially

counting operators and operands

SE, Design, Hans van Vliet, ©2008 23

Software science basic entities

 n1: number of unique operators

 n2: number of unique operands
 N1: total number of operators
 N2: total number of operands

SE, Design, Hans van Vliet, ©2008 24

Example program

public static void sort(int x []) {

for (int i=0; i < x.length-1; i++) {
for (int j=i+1; j < x.length; j++)
{ operator, 1 occurrence
if (x[i] > x[j]) {
int save=x[i];
x[i]=x[j]; x[j]=save
}
}
} operator, 2 occurrences
}

SE, Design, Hans van Vliet, ©2008 25

operator # of occurrences

public 1
sort() 1
int 4
[] 7
{} 4
for {;;} 2
if () 1
= 5
< 2
… …
n1 = 17 N1 = 39

SE, Design, Hans van Vliet, ©2008 26

Example program

public static void sort(int x []) {

for (int i=0; i < x.length-1; i++) {
for (int j=i+1; j < x.length; j++)
{
if (x[i] > x[j]) {
int save=x[i];
x[i]=x[j]; x[j]=save
} operand, 2 occurrences
} operand, 2 occurrences
}
}

SE, Design, Hans van Vliet, ©2008 27

operand # of occurrences

x 9
length 2
i 7
j 6
save 2
0 1
1 2
n2 = 7 N2 = 29

SE, Design, Hans van Vliet, ©2008 28

Other software science formulas

 size of vocabulary: n = n1 + n2
 program length: N = N1 + N2
 volume: V = N log2n
 level of abstraction: L = V*/ V
approximation: L’ = (2/n1)(n2/N2)
 programming effort: E = V/L
 estimated programming time: T ’ = E/18
 estimate of N: N ’ = n1log2n2 : n2log2n2
 for this example: N = 68, N ’ = 89, L = .015, L’ = .028

SE, Design, Hans van Vliet, ©2008 29

Software science

 empirical studies: reasonably good fit

 critique:
 explanations are not convincing
 results from cognitive psychology used wrongly
 is aimed at coding phase only; assumes this is an
uninterrupted concentrated activity
 different definitions of “operand” and “operator”

SE, Design, Hans van Vliet, ©2008 30

Structure-based measures

 based on
 control structures
 data structures
 or both
 example complexity measure based on data
structures: average number of instructions
between successive references to a variable
 best known measure is based on the control
structure: McCabe’s cyclomatic complexity

SE, Design, Hans van Vliet, ©2008 31

 1

Example program
2

3
public static void sort(int x []) {
for (int i=0; i < x.length-1; i++) {
4
for (int j=i+1; j < x.length; j++) {
if (x[i] > x[j]) {
5
int save=x[i];
x[i]=x[j]; x[j]=save
11
} 6

}
} 7

}
8

10

SE, Design, Hans van Vliet, ©2008 32

 1

Cyclomatic complexity
2

e = number of edges (13)

n = number of nodes (11) 4

p = number of connected components (1) 5

11
CV = e - n + p + 1 (4) 6

10

SE, Design, Hans van Vliet, ©2008 33

Note: CV = e-n+p+1, CV  e-n+2p

e-n+p+1 = 13-13+3+1 = 4
e-n+p+1 = e-n+2p = 4
e-n+2p = 6

SE, Design, Hans van Vliet, ©2008 34

Intra-modular complexity measures,
summary

 for small programs, the various measures

correlate well with programming time
 however, a simple length measure such as LOC
does equally well
 complexity measures are not very context
sensitive
 complexity measures take into account few
aspects

 it might help to look at the complexity density

instead
SE, Design, Hans van Vliet, ©2008 35
System structure: inter-module complexity

 looks at the complexity of the dependencies

between modules
 draw modules and their dependencies in a graph
 then the arrows connecting modules may denote
several relations, such as:
 A contains B
 A precedes B
 A uses B
 we are mostly interested in the latter type of
relation

SE, Design, Hans van Vliet, ©2008 36

The uses relation

 In a well-structured piece of software, the

dependencies show up as procedure calls
 therefore, this graph is known as the call-graph
 possible shapes of this graph:
 chaos (directed graph)
 hierarchy (acyclic graph)
 strict hierarchy (layers)
 tree

SE, Design, Hans van Vliet, ©2008 37

 In a picture:

chaos hierarchy

strict
hierarchy tree

SE, Design, Hans van Vliet, ©2008 38

Measurements

} size
# nodes
# edges

width

height

SE, Design, Hans van Vliet, ©2008 39

 Deviation from a tree

hierarchy

strict
hierarchy tree

SE, Design, Hans van Vliet, ©2008 40

Tree impurity metric

 complete graph with n nodes has n(n-1)/2 edges

 a tree with n nodes has (n-1) edges

 tree impurity for a graph with n nodes and e

edges:
m(G) = 2(e-n+1)/(n-1)(n-2)

 this is a “good” measure, in the measurement

theory sense

SE, Design, Hans van Vliet, ©2008 41

Desirable properties of any tree impurity
metric

 m(G) = 0 if and only if G is a tree

 m(G1) > m(G2) if G1 = G2 + an extra edge

 if G1 and G2 have the same # of “extra” edges wrt

their spanning tree, and G1 has more nodes than
G2, then m(G1) < m(G2)

 m(G)  m(Kn) = 1, where G has n nodes, and Kn is

the (undirected) complete graph with n nodes
SE, Design, Hans van Vliet, ©2008 42
Information flow metric

 tree impurity metrics only consider the number of

edges, not their “thickness”
 Henri & Kafura’s information flow metric takes
this “thickness” into account

 based on notions of local and global flow

 we consider a later variant, developed by

Shepperd

SE, Design, Hans van Vliet, ©2008 43

Shepperd’s variant of
information flow metric

 there is a local flow from A to B if:

 A invokes B and passes it a parameter
 B invokes A and A returns a value
 there is a global flow from A to B if A updates some
global structure and B reads that structure
 fan-in(M) = # (local and global) flows whose sink is M
 fan-out(M) = # (local and global) flows whose source
is M
 complexity(M) = (fan-in(M) * fan-out(M)) 2

 still, all flows count the same

SE, Design, Hans van Vliet, ©2008 44

Point to ponder:
What does this program do?

procedure X(A: array [1..n] of int);

var i, k, small: int;
begin
for i:= 1 to n do
small:= A[i];
for k:= i to n-1 do
if small <= A[k]
then swap (A[k], A[k+1])
end
end
end
end

SE, Design, Hans van Vliet, ©2008 45

The role of previously acquired knowledge
during design

 programming plans, beacons

 chunks

 adverse influence of delocalized plans and false

beacons

SE, Design, Hans van Vliet, ©2008 46

Object-oriented metrics

 WMC: Weighted Methods per Class

 DIT: Depth of Inheritance Tree
 NOC: Number Of Children
 CBO: Coupling Between Object Classes
 RFC: Response For a Class
 LCOM: Lack of COhesion of a Method

SE, Design, Hans van Vliet, ©2008 47

Weighted Methods per Class

 measure for size of class

 WMC =  c(i), i = 1, …, n (number of methods)

 c(i) = complexity of method i

 mostly, c(i) = 1

SE, Design, Hans van Vliet, ©2008 48

Depth of Class in Inheritance Tree

 DIT = distance of class to root of its inheritance

tree

 DIT is somewhat language-dependent

 widely accepted heuristic: strive for a forest of

classes, a collection of inheritance trees of
medium height

SE, Design, Hans van Vliet, ©2008 49

Number Of Children

 NOC: counts immediate descendants

 higher values NOC are considered bad:

 possibly improper abstraction of the parent class
 also suggests that class is to be used in a variety of settings

SE, Design, Hans van Vliet, ©2008 50

Coupling Between Object Classes

 two classes are coupled if a method of one class

uses a method or state variable of another class

 CBO = count of all classes a given class is

coupled with

 high values: something is wrong

 all couplings are counted alike; refinements are

possible

SE, Design, Hans van Vliet, ©2008 51

Response For a Class

 RFC measures the “immediate surroundings” of a

class
 RFC = size of the “response set”
 response set = {M}  {Ri}

R1
M2
M1

M3

SE, Design, Hans van Vliet, ©2008 52

Lack of Cohesion of a Method

 cohesion = glue that keeps the module (class)

together
 if all methods use the same set of state variables:
OK, & that is the glue
 if some methods use a subset of the state
variables, and others use another subset, the class
lacks cohesion
 LCOM = number of disjoint sets of methods in a
class
 two methods in the same set share at least one
state variable

SE, Design, Hans van Vliet, ©2008 53

OO metrics

 WMC, CBO, RFC, LCOM most useful

 Predict fault proneness during design
 Strong relationship to maintenance effort

 Many OO metrics correlate strongly with size

SE, Design, Hans van Vliet, ©2008 54

Overview

 Introduction

 Design principles

 Design methods

 Conclusion

SE, Design, Hans van Vliet, ©2008 55

Design methods

 Functional decomposition

 Data Flow Design (SA/SD)

 Design based on Data Structures (JSD/JSP)

 OO is gOOd, isn’t it

SE, Design, Hans van Vliet, ©2008 56

Sample of design methods

 Decision tables  OOD

 E-R  PDL
 Flowcharts  Petri Nets
 FSM  SA/SD
 JSD  SA/WM
 JSP  SADT
 LCP  SSADM
 Meta IV  Statecharts
 NoteCards
 OBJ

SE, Design, Hans van Vliet, ©2008 57

Functional decomposition

bottom-up top-down

SE, Design, Hans van Vliet, ©2008 58

Functional decomposition (cnt’d)

 Extremes: bottom-up and top-down

 Not used as such; design is not purely rational:
 clients do not know what they want
 changes influence earlier decisions
 people make errors
 projects do not start from scratch
 Rather, design has a yo-yo character
 We can only fake a rational design process

SE, Design, Hans van Vliet, ©2008 59

Data flow design

 Yourdon and Constantine (early 70s)

 nowadays version: two-step process:

 Structured Analysis (SA), resulting in a logical design, drawn
as a set of data flow diagrams
 Structured Design (SD) transforming the logical design into a
program structure drawn as a set of structure charts

SE, Design, Hans van Vliet, ©2008 60

Entities in a data flow diagram

 external entities

 processes

 data flows

 data stores

SE, Design, Hans van Vliet, ©2008 61

Top-level DFD: context diagram

direction request
library
management client
system
report ack’ment

SE, Design, Hans van Vliet, ©2008 62

 First-level decomposition

client management
request
report direction
log data
prelim. prelim.
acknowledgement

doc doc
return
borrow
request
request log data

borrow prelim. log file

title doc
title title

catalog adm.

SE, Design, Hans van Vliet, ©2008 63

Second-level decomposition for
“preliminary processing”

data base log file

request client info log data

check OK
client process
data request
borrow return
not OK request request

SE, Design, Hans van Vliet, ©2008 64

Example minispec

Identification: Process request

Description:
1 Enter type of request
1.1 If invalid, issue warning and repeat step 1
1.2 If step 1 repeated 5 times, terminate transaction
2 Enter book identification
2.1 If invalid, issue warning and repeat step 2
2.2 If step 2 repeated 5 times, terminate transaction
3 Log client identification, request type and book
identification
4 ...

SE, Design, Hans van Vliet, ©2008 65

Data dictionary entries

borrow-request = client-id + book-id

return-request = client-id + book-id
log-data = client-id + [borrow | return] + book-id
book-id = author-name + title + (isbn) +
[proc | series | other]

Conventions:
[ ]: include one of the enclosed options
|: separates options
+: AND
(): enclosed items are optional

SE, Design, Hans van Vliet, ©2008 66

From data flow diagrams to structure charts

 result of SA: logical model, consisting f a set of

DFD’s, augmented by minispecs, data dictionary,
etc.
 Structured Design = transition from DFD’s to
structure charts
 heuristics for this transition are based on notions
of coupling and cohesion
 major heuristic concerns choice for top-level
structure chart, most often: transform-centered

SE, Design, Hans van Vliet, ©2008 67

Transform-centered design

A B D E F G

C H K

Do job

C D E F

A B G H

SE, Design, Hans van Vliet, ©2008 68

Design based on data structures
(JSP & JSD)

 JSP = Jackson Structured Programming (for

programming-in-the-small)

 JSD = Jackson Structured Design (for

programming-in-the-large)

SE, Design, Hans van Vliet, ©2008 69

JSP

 basic idea: good program reflects structure of its

input and output
 program can be derived almost mechanically from
a description of the input and output
 input and output are depicted in a structure
diagram and/or in structured text/schematic logic
(a kind of pseudocode)
 three basic compound forms: sequence, iteration,
and selection)

SE, Design, Hans van Vliet, ©2008 70

Compound components in JSP

sequence iteration selection

A A A

B C D B* Bo Co Do

SE, Design, Hans van Vliet, ©2008 71

A JSP example

input output

line * line *

until EOF
loop
read line
process line
write line
endloop

SE, Design, Hans van Vliet, ©2008 72

Another JSP example

input file

article

mutation

addition removal

SE, Design, Hans van Vliet, ©2008 73

Another JSP example (cnt’d)

output

heading body

net mutation

SE, Design, Hans van Vliet, ©2008 74

Another JSP example (cnt’d)

program

heading contents

do article and make row

do article make row

do mutation

do addition do removal

SE, Design, Hans van Vliet, ©2008 75

Structure clash

unsorted sorting sorted process

mutations program mutations mutations

SE, Design, Hans van Vliet, ©2008 76

Inversion

unsorted sorting sorted process

mutations program mutations mutations

write read
mutation mutation

SE, Design, Hans van Vliet, ©2008 77

Fundamental issues in JSP

 Model input and output using structure diagrams

 Merge diagrams to create program structure

 Meanwhile, resolve structure clashes, and

 Optimize results through program inversion

SE, Design, Hans van Vliet, ©2008 78

Difference between JSP and other methods

 Functional decomposition, data flow design:

Problem structure  functional structure 
program structure

 JSP:
Problem structure  data structure 
program structure

SE, Design, Hans van Vliet, ©2008 79

JSD:
Jackson Structured Design

 Problem with JSP: how to obtain a mapping from

the problem structure to the data structure?

 JSD tries to fill this gap

 JSD has three stages:

 modeling stage: description of real world problem in terms of
entities and actions
 network stage: model system as a network of communicating
processes
 implementation stage: transform network into a sequential
design

SE, Design, Hans van Vliet, ©2008 80

JSD’s modeling stage

 JSD models the UoD as a set of entities

 For each entity, a process is created which
models the life cycle of that entity
 This life cycle is depicted as a process structure
diagram (PSD); these resemble JSP’s structure
diagrams
 PSD’s are finite state diagrams; only the roles of
nodes and edges has been reversed: in a PSD, the
nodes denote transitions while the edges edges
denote states

SE, Design, Hans van Vliet, ©2008 81

OOAD methods

 three major steps:

1 identify the objects

2 determine their attributes and services

3 determine the relationships between objects

SE, Design, Hans van Vliet, ©2008 82

(Part of) problem statement

Design the software to support the operation of a

public library. The system has a number of
stations for customer transactions. These stations
are operated by library employees. When a book
is borrowed, the identification card of the client is
read. Next, the station’s bar code reader reads the
book’s code. When a book is returned, the
identification card isnot needed and only the
book’s code needs to be read.

SE, Design, Hans van Vliet, ©2008 83

Candidate objects

 software
 library
 system
 station
 customer
 transaction
 book
 library employee
 identification card
 client
 bar code reader
 book’s code

SE, Design, Hans van Vliet, ©2008 84

Carefully consider candidate list

 eliminate implementation constructs, such as “software”

 replace or eliminate vague terms: “system”  “computer”
 equate synonymous terms: “customer” and “client” 
“client”
 eliminate operation names, if possible (such as
“transaction”)
 be careful in what you really mean: can a client be a library
employee? Is it “book copy” rather than “book”?
 eliminate individual objects (as opposed to classes).
“book’s code”  attribute of “book copy”

SE, Design, Hans van Vliet, ©2008 85

Relationships

 From the problem statement:

 employee operates station
 station has bar code reader
 bar code reader reads book copy
 bar code reader reads identification card
 Tacit knowledge:
 library owns computer
 library owns stations
 computer communicates with station
 library employs employee
 client is member of library
 client has identification card

SE, Design, Hans van Vliet, ©2008 86

Result: initial class diagram

SE, Design, Hans van Vliet, ©2008 87

Usage scenario  sequence diagram

SE, Design, Hans van Vliet, ©2008 88

OO as middle-out design

 First set of objects becomes middle level

 To implement these, lower-level objects are

required, often from a class library

 A control/workflow set of objects constitutes the

top level

SE, Design, Hans van Vliet, ©2008 89

OO design methods

 Booch: early, new and rich set of notations

 Fusion: more emphasis on process

 RUP: full life cycle model associated with UML

SE, Design, Hans van Vliet, ©2008 90

Booch’ method

identify classes and objects

identify semantics of classes and

objects

identify relationships between

classes and objects

identify interface and implementation

of classes and objects

SE, Design, Hans van Vliet, ©2008 91

Fusion

Analysis
object model

interface model

Design
object interaction
visibility graphs
graphs

class descriptions inheritance graphs

SE, Design, Hans van Vliet, ©2008 92

RUP

 Nine workflows, a.o. requirements, analysis and

design
 Four phases: inception, elaboration, construction,
transition
 Analysis and design workflow:
 First iterations: architecture discussed in ch 11
 Next: analyze behavior: from use cases to set of design
elements; produces black-box model of the solution
 Finally, design components: refine elements into classes,
interfaces, etc.

SE, Design, Hans van Vliet, ©2008 93

Classification of design methods

 Simple model with two dimensions:

 Orientation dimension:
 Problem-oriented: understand problem and its solution
 Product-oriented: correct transformation from specification to
implementation
 Product/model dimension:
 Conceptual: descriptive models
 Formal: prescriptive models

SE, Design, Hans van Vliet, ©2008 94

Classification of design methods (cnt’d)

problem-oriented product-oriented

I II
conceptual ER modeling Structured design
Structured analysis

III IV
formal JSD Functional decomposition
VDM JSP

SE, Design, Hans van Vliet, ©2008 95

Characteristics of these classes

 I: understand the problem

 II: transform to implementation

 III: represent properties

 IV: create implementation units

SE, Design, Hans van Vliet, ©2008 96

Caveats when choosing a particular design
method

 Familiarity with the problem domain

 Designer’s experience

 Available tools

 Development philosophy

SE, Design, Hans van Vliet, ©2008 97

Object-orientation: does it work?

 do object-oriented methods adequately capture

requirements engineering?

 do object-oriented methods adequately capture

design?

 do object-oriented methods adequately bridge the

gap between analysis and design?

 are oo-methods really an improvement?

SE, Design, Hans van Vliet, ©2008 98

Design pattern

 Provides solution to a recurring problem

 Balances set of opposing forces
 Documents well-prove design experience
 Abstraction above the level of a single component
 Provides common vocabulary and understanding
 Are a means of documentation
 Supports construction of software with defined
properties

SE, Design, Hans van Vliet, ©2008 99

Example design pattern: Proxy

 Context:
 Client needs services from other component, direct access
may not be the best approach
 Problem:
 We do not want hard-code access
 Solution:
 Communication via a representative, the Proxy

SE, Design, Hans van Vliet, ©2008 100

Example design pattern: Command Processor

 Context:
 User interface that must be flexible or provides functionality
beyond handling of user functions
 Problem:
 Well-structured solution for mapping interface to internal
functionality. All ‘extras’ are separate from the interface
 Solution:
 A separate component, the Command Processor, takes care
of all commands Actual execution of the command is
delegated

SE, Design, Hans van Vliet, ©2008 101

Antipatterns

 Patterns describe desirable behavior

 Antipatterns describe situations one had better

avoid

 In agile approaches (XP), refactoring is applied

whenever an antipattern has been introduced

SE, Design, Hans van Vliet, ©2008 102

Example antipatterns

 God class: class that holds most responsibilities

 Lava flow: dead code
 Poltergeist: class with few responsibilities and a
short life
 Golden Hammer: solution that does not fit the
problem
 Stovepipe: (almost) identical solutions at different
places
 Swiss Army Knife: excessively complex class
interface

SE, Design, Hans van Vliet, ©2008 103

Overview

 Introduction

 Design principles

 Design methods

 Conclusion

SE, Design, Hans van Vliet, ©2008 104

Conclusion

 Essence of the design process: decompose

system into parts
 Desirable properties of a decomposition:
coupling/cohesion, information hiding, (layers of)
abstraction
 There have been many attempts to express these
properties in numbers
 Design methods: functional decomposition, data
flow design, data structure design, object-oriented
design

SE, Design, Hans van Vliet, ©2008 105