5 Software Design

Software Engineering
Software Design
Software Design
Slide 1
Software Design
Deriving a solution which

satisfies software requirements
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 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 Design
Slide 4
Phases in the Design Process

Re quire m e nts
spe c if iction
a
De sign a cvitie
ti s
Arc hite c tur
al
design
Abstra ct
spe c if ictio
a
n
I nter fa c e
design
Com pone nt
design
Data
struc tur
e
design
Algorithm
design
Sy stem
a rc hite c tur
e
Sof twa re
spe c if iction
a
I nter fa c e
spe c if iction
a
Com pone nt
spe c if iction
a
Data
struc tur
e
spe c if iction
a
Algorithm
spe c if iction
a
De sign pr
oduc ts
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 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 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 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 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
application domains
- e.g., compilers
Less well-suited to distributed, nonterminating systems

- e.g., process control systems, operating
systems like WinNT, ATM machines
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 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 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: subproblems will be divided still further
Top-down design methods fulfil this criterion;
stepwise refinement is an example of such method
Software Design
Slide 13
Hierarchical Design Structure

System level
Sub-system
level
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 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 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 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; its 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 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 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 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 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 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 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 Design
Slide 24
Few Interfaces
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 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 Design
Slide 27
Tight Coupling
Module A
Module B
Module C
Module D
Shared data
area
Software Design
Slide 28
Loose Coupling
Module A
As data
Module B
Module C
Bs data
Cs data
Module D
Ds data
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 Design
Slide 30
Reusability
A major obstacle to the production of cheap quality
software is the intractability of the reusability issue.
Why isnt 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 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 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 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 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 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 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 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 Design
Slide 38

5 Software Design

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

5 Software Design

Uploaded by

Copyright:

Available Formats

Software Engineering

Deriving a solution which

Identify one or more solutions

Describe solution abstractions

Repeat process for each identified abstraction

The Design Process

Phases in the Design Process

Architectural design: Identify sub-systems.

This is called procedural abstraction

the program is viewed as a function from a set I of legal

Less well-suited to distributed, nonterminating systems

Five Criteria for Design Methods

Hierarchical Design Structure

This is because top-down design leads to modules which

Can the component be understood on its own?

Informally, high complexity means many

Five principles for Good Design

Linguistic modular units;

Linguistic Modular Units

EXAMPLE. Java methods and classes

So, in the system with n modules, there may be

Small Interfaces (Loose Coupling)

COUNTER EXAMPLE. Declaring all instance

Coupling and Inheritance

Why? If we change a module, we need to see

Thus each module should have some interface, which

Logical association (weak)

Temporal cohesion (weak)

Sequential cohesion (medium)

Functional cohesion (strong)

Object cohesion (strong)

Cohesion as a Design Attribute

You might also like