Software Design Principles

“Producing the software blueprint”

1
Lecture Objectives
 To understand the importance of design in
developing quality software
 To describe the translation from the
requirements analysis model to the design
model
 To understand the principles that guide
proper design of software

2
Designing A House
 If you are asked to design a house…
D W W

Kitchen
Room 2

D
WC
D
Living
Room Room 1

D W W

3
What Is Design?
 Explaining the idea/concept of something
 Usually with graphical diagrams
 With the intention to build from the
explanation
 The design is a representation of a
product or a system with sufficient detail
for implementation

4
The Second Task
Problem
Analysis

Design
Models

Development

Solution
Testing

5
Designing Software
 From our understanding of the problem,
we start building the software
 Translate the analysis model into the
design model
 Map the information from the analysis
model to the design representations - data
design, architectural design, interface
design, procedural design

6
Translation Model

Entity-
Relationship Procedural
Data Flow
Diagram design
Diagram
Data Dictionary Interface
design

State-Transition Architectural design

Data design

7
Design Principles
 Design process should not suffer from
“tunnel vision”
 The design should be traceable to the
analysis model
 The design should not reinvent the wheel;
Time is short

 The design should “minimize intellectual

9
Design Principles (Continued)
 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 errors

10
Design Concepts
Fundamental concepts which provide
foundation to design correctly:
 Abstraction  Structural
 Refinement Partitioning
 Modularity  Data Structure

 Software  Software Procedure

Architecture  Information Hiding

11
Abstraction
 Identifying important features for
representation
 There are many levels of abstraction
depending on how detailed the
representation is required
 Data abstraction - representation of data
objects
 Procedural abstraction - representation of
instructions
12
Refinement
 Stepwise refinement - top-down design
strategy by Niklaus Wirth
 Starting at the highest level of abstraction,
every step of refinement ‘decompose’
instructions into more detailed instructions
 Complementary to abstraction

13
Modularity
 Software is divided into separately named
and addressable modules
 “Divide and conquer” approach - problem
is broken into manageable pieces
 Solutions for the separate pieces then
integrated into the whole system

14
Divide And Conquer
S1
S2

P1
P2
S5

P5

P4
P3

S3
S4

15
Software Architecture
 Modules can be integrated in many ways to
produce the system
 Software architecture is the overall
structure of the software
 The hierarchy of components and how they
interact, and the structure of data used by
the components
 Use of framework models, and possible
reuse of architectural patterns
16
Software Architecture Patterns
 Recurring pattern help designers reuse
successful designs by basing new designs
on prior experience.
 A designer who is familiar with such
patterns can apply them immediately to
design problems without having to
rediscover them.

17
Control Hierarchy
 Hierarchy of modules representing the control
relationships
 A super-ordinate module controls another
module
 A subordinate module is controlled by another
module
 Measures relevant to control hierarchy: depth,
width, fan-in, fan-out

18
Structure Terminology
M
Fan-out

a b c
Depth

d e f g h

Fan-in

Width
19
Structural Partitioning
 Program structure partitioned horizontally and
vertically
 Horizontal partitioning defines separate
branches for each major program function -
input, process, output
 Vertical partitioning (aka factoring) defines
control (decision-making) at the top and work
at the bottom

20
Software Procedure
 Processing details of individual modules
 Precise specification of processing,
including sequence of events, exact decision
points, repetitive operations, and data
organization/structure
 Procedure is layered - subordinate modules
must be referenced in processing details

21
Information Hiding
 Information (procedure and data) contained
within a module is inaccessible to other
modules that have no need for such
information
 Effective modularity is achieved by
independent modules, that communicate
only necessary information
 Ease of maintenance - testing, modification
localized and less likely to propagate
22
Why use Design Patterns?
 Reuse successful practices.
 Not new – recognised that this is something
that engineers have done for years.
 Improve communication
 Step towards a software engineer’s
handbook

23
References
 “Software Engineering: A Practitioner’s
Approach” 5th Ed. by Roger S. Pressman,
Mc-Graw-Hill, 2001
 “Software Engineering” by Ian Sommerville,
Addison-Wesley, 2001

24