Software Engineering

Software Design

Software Engineering Software Design Slide 1

 Software Design

Deriving a solution which

satisfies software requirements

Software Engineering Software Design Slide 2

 Stages of Design
• Problem understanding
– Look at the problem from different angles to discover the
design requirements.
• Identify one or more solutions
– Evaluate possible solutions and choose the most appropriate depending on
the designer's experience and available resources.
• Describe solution abstractions
– Use graphical, formal or other descriptive notations to
describe the components of the design.
• Repeat process for each identified abstraction
until the design is expressed in primitive terms.

Software Engineering Software Design Slide 3

 The Design Process
• Any design may be modelled as a directed graph
made up of entities with attributes which participate
in relationships.
• The system should be described at several different
levels of abstraction.
• Design takes place in overlapping stages. It is
artificial to separate it into distinct phases but
some separation is usually necessary.

Software Engineering Software Design Slide 4

 Phases in the Design Process
Requirements
specifica
t ion

Design acti
vities

Architectur
al Abstract Interface Component Data Algorithm
design specifica
tio design design structur
e design
n design

Software Data
System Interface Component Algorithm
specifica
tion structure
architectur
e specifica
tion specifica
tion specifica
tion
specification

Design pr
oducts

Software Engineering Software Design Slide 5

 Design Phases
• Architectural design: Identify sub-systems.
• Abstract specification: Specify sub-systems.
• Interface design: Describe sub-system interfaces.
• Component design: Decompose sub-systems
into components.
• Data structure design: Design data structures to hold
problem data.
• Algorithm design: Design algorithms for problem
functions.
Software Engineering Software Design Slide 6
 Design
• Computer systems are not monolithic: they are usually
composed of multiple, interacting modules.
• Modularity has long been seen as a key to cheap, high
quality software.
• The goal of system design is to decode:
– What the modules are;
– What the modules should be;
– How the modules interact with one-another

Software Engineering Software Design Slide 7

 Modular programming

• In the early days, modular programming was

taken to mean constructing programs out of
small pieces: “subroutines”
• But modularity cannot bring benefits unless
the modules are
– autonomous,
– coherent and
– robust

Software Engineering Software Design Slide 8

 Procedural Abstraction
• The most obvious design methods involve
functional decomposition.
• This leads to programs in which procedures
represent distinct logical functions in a program.
• Examples of such functions:
– “Display menu”
– “Get user option”
• This is called procedural abstraction
Software Engineering Software Design Slide 9
 Programs as Functions
• Another view is programs as functions:
input output
x  f  f (x)
the program is viewed as a function from a set I of legal
inputs to a set O of outputs.
• There are programming languages (ML, Miranda, LISP)
that directly support this view of programming
Well-suited to certain Less well-suited to distributed, non-
application domains terminating systems
- e.g., compilers - e.g., process control systems, operating
systems like WinNT, ATM machines
Software Engineering Software Design Slide 10
 Object-oriented design

– The system is viewed as a collection of

interacting objects.
– The system state is decentralized and each
object manages its own state.
– Objects may be instances of an object class
and communicate by exchanging methods.

Software Engineering Software Design Slide 11

 Five Criteria for Design Methods

• We can identify five criteria to help evaluate

modular design methods:
– Modular decomposability;
– Modular composability;
– Modular understandability;
– Modular continuity;
– Modular protection.

Software Engineering Software Design Slide 12

 Modular Decomposability

• This criterion is met by a design method if the

method supports the decomposition of a problem
into smaller sub-problems, which can be solved
independently.
• In general method will be repetitive: sub-problems
will be divided still further
• Top-down design methods fulfil this criterion;
stepwise refinement is an example of such method

Software Engineering Software Design Slide 13

 Hierarchical Design Structure
System level

Sub-system
level

Software Engineering Software Design Slide 14

 Top-down Design

• In principle, top-down design involves starting

at the uppermost components in the hierarchy

and working down the hierarchy level by level.
• In practice, large systems design is never
truly top-down. Some branches are designed
before others. Designers reuse experience (and
sometimes components) during the design
process.
Software Engineering Software Design Slide 15
 Modular Composability

• A method satisfies this criterion if it leads to the production

of modules that may be freely combined to produce new
systems.
• Composability is directly related to the issue of reusability
• Note that composability is often at odds with
decomposability; top-down design,
– for example, tends to produce modules that may not be composed
in the way desired
• This is because top-down design leads to modules which
fulfil a specific function, rather than a general one

Software Engineering Software Design Slide 16

 Examples

• The Numerical Algorithm Group (NAG)

libraries contain a wide range of routines for
solving problems in linear algebra, differential
equations, etc.
• The Unix shell provides a facility called a pipe,
written “”, whereby
– the standard output of one program may be
redirected to the standard input of another; this
convention favours composability.

Software Engineering Software Design Slide 17

 Modular Understandability
• A design method satisfies this criterion if it
encourages the development of modules which
are easily understandable.

• COUNTER EXAMPLE 1. Take a thousand lines program,

containing no procedures; it’s just a long list of sequential
statements. Divide it into twenty blocks, each fifty statements
long; make each block a method.
• COUNTER EXAMPLE 2. “Go to” statements.

Software Engineering Software Design Slide 18

 Understandability
• Related to several component characteristics
– Can the component be understood on its own?
– Are meaningful names used?
– Is the design well-documented?
– Are complex algorithms used?
• Informally, high complexity means many
relationships between different parts of the
design.
Software Engineering Software Design Slide 19
 Modular Continuity

• A method satisfies this criterion if it leads to the

production of software such that a small change in the
problem specification leads to a change in just one (or a
small number of ) modules.
• EXAMPLE. Some projects enforce the rule that no
numerical or textual literal should be used in programs:
only symbolic constants should be used
• COUNTER EXAMPLE. Static arrays (as opposed to
open arrays) make this criterion harder to satisfy.

Software Engineering Software Design Slide 20

 Modular Protection

• A method satisfied this criterion if it yields

architectures in which the effect of an abnormal
condition at run-time only effects one (or very few)
modules
• EXAMPLE. Validating input at source prevents errors
from propagating throughout the program.
• COUNTER EXAMPLE. Using int types where
subrange or short types are appropriate.

Software Engineering Software Design Slide 21

 Five principles for Good Design

• From the discussion above, we can distil five

principles that should be adhered to:
– Linguistic modular units;
– Few interfaces;
– Small interfaces
– Explicit interfaces;
– Information hiding.

Software Engineering Software Design Slide 22

 Linguistic Modular Units
• A programming language (or design language) should
support the principle of linguistic modular units:
– Modules must correspond to linguistic units in the language used

• EXAMPLE. Java methods and classes

• COUNTER EXAMPLE. Subroutines in BASIC are called
by giving a line number where execution is to proceed
from; there is no way of telling, just by looking at a section
of code, that it is a subroutine.

Software Engineering Software Design Slide 23

 Few Interfaces

• This principle states that the overall number of

communication channels between modules
should be as small as possible:
– Every module should communicate with as few
others as possible.
• So, in the system with n modules, there may be
n(n  1)
a minimum of n-1 and a maximum of 2 links;
your system should stay closer to the minimum
Software Engineering Software Design Slide 24
 Few Interfaces

Software Engineering Software Design Slide 25

 Small Interfaces (Loose Coupling)

• This principle states:

– If any two modules communicate, they should
exchange as little information as possible.

• COUNTER EXAMPLE. Declaring all instance

variables as public!

Software Engineering Software Design Slide 26

 Coupling
• A measure of the strength of the inter-connections
between system components.
• Loose coupling means component changes are
unlikely to affect other components.
– Shared variables or control information exchange lead
to tight coupling.
– Loose coupling can be achieved by state
decentralization (as in objects) and component
communication via parameters or message passing.
Software Engineering Software Design Slide 27
 Tight Coupling

Module A Module B

Module C Module D

Shared data
area

Software Engineering Software Design Slide 28

 Loose Coupling
Module A

A’s data

Module B Module C

B’s data C’s data

Module D

D’s data

Software Engineering Software Design Slide 29

 Coupling and Inheritance

• Object-oriented systems are loosely coupled

because there is no shared state and objects
communicate using message passing.
• However, an object class is coupled to its
super-classes. Changes made to the attributes
or operations in a super-class propagate to all
sub-classes.

Software Engineering Software Design Slide 30

 Reusability
• A major obstacle to the production of cheap quality
software is the intractability of the reusability issue.
• Why isn’t writing software more like producing
hardware? Why do we start from scratch every time,
coding similar problems time after time after time?
• Obstacles:
– Economic;
– Organizational;
– Psychological.

Software Engineering Software Design Slide 31

 Stepwise Refinement

• The simplest realistic design method, widely used in

practice.
• Not appropriate for large-scale, distributed systems:
mainly applicable to the design of methods.
• Basic idea is:
– Start with a high-level spec of what a method is to achieve;
– Break this down into a small number of problems (usually no
more than 10)
– For each of these problems do the same;
– Repeat until the sub-problems may be solved immediately.

Software Engineering Software Design Slide 32

 Explicit Interfaces

• If two modules must communicate, they must do

it so that we can see it:
– If modules A and B communicate, this must be
obvious from the text of A or B or both.
• Why? If we change a module, we need to see
what other modules may be affected by these
changes.

Software Engineering Software Design Slide 33

 Information Hiding

• This principle states:

– All information about a module, (and particularly how the
module does what it does) should be private to the module
unless it is specifically declared otherwise.
• Thus each module should have some interface, which
is how the world sees it anything beyond that interface
should be hidden.
• The default Java rule:
– Make everything private

Software Engineering Software Design Slide 34

 Cohesion
A measure of how well a component “fits
together”.
• A component should implement a single logical
entity or function.
• Cohesion is a desirable design component
attribute as when a change has to be made, it
is localized in a single cohesive component.
• Various levels of cohesion have been identified.

Software Engineering Software Design Slide 35

 Cohesion Levels
• Coincidental cohesion (weak)
– Parts of a component are simply bundled together.
• Logical association (weak)
– Components which perform similar functions are
grouped.
• Temporal cohesion (weak)
– Components which are activated at the same time
are grouped.

Software Engineering Software Design Slide 36

 Cohesion Levels
• Communicational cohesion (medium)
– All the elements of a component operate on the same input or
produce the same output.
• Sequential cohesion (medium)
– The output for one part of a component is the input to another part.
• Functional cohesion (strong)
– Each part of a component is necessary for the execution of a single
function.
• Object cohesion (strong)
– Each operation provides functionality which allows object
attributes to be modified or inspected.

Software Engineering Software Design Slide 37

 Cohesion as a Design Attribute
• Not well-defined. Often difficult to classify
cohesion.
• Inheriting attributes from super-classes
weakens cohesion.
– To understand a component, the super-classes
as well as the component class must be
examined.
– Object class browsers assist with this process.

Software Engineering Software Design Slide 38