Software Design
 Deriving
a solution which
satisfies software requirements
©Ian Sommerville 1995
Software Design
Slide 1
Topics covered



The design process and design methods
Design strategies including object-oriented design
and functional decomposition - briefly
Design quality attributes
©Ian Sommerville 1995
Software Design
Slide 2
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
©Ian Sommerville 1995
Software Design
Slide 3
Phases in the design process
Requirements
specification
Design acti
vities
Architectur
al
design
Abstract
specificatio
n
Interface
design
Component
design
Data
structur
e
design
Algorithm
design
System
architectur
e
Software
specification
Interface
specifica
tion
Component
specification
Data
structur
e
specification
Algorithm
specifica
tion
Design pr
oducts
©Ian Sommerville 1995
Software Design
Slide 4
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
©Ian Sommerville 1995
Software Design
Slide 5
Hierarchical design structure
System level
Sub-system
level
©Ian Sommerville 1995
Software Design
Slide 6
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
©Ian Sommerville 1995
Software Design
Slide 7
Design methods




Structured methods are sets of notations for
expressing a software design and guidelines for
creating a design
Well-known methods include Structured Design
(Yourdon), and JSD (Jackson Method)
Can be applied successfully because they
support standard notations and ensure
designs follow a standard form
Structured methods may be supported with
CASE tools
©Ian Sommerville 1995
Software Design
Slide 8
Method components




Many methods support comparable views of a
system
A data flow view (data flow diagrams) showing
data transformations
An entity-relation view describing the logical
data structures
A structural view showing system components
and their interactions
©Ian Sommerville 1995
Software Design
Slide 9
Method deficiencies


They are guidelines rather than methods in the
mathematical sense. Different designers create
quite different system designs
They do not help much with the early, creative
phase of design. Rather, they help the designer
to structure and document his or her design
ideas
©Ian Sommerville 1995
Software Design
Slide 10
Design description




Graphical notations. Used to display
component relationships
Program description languages. Based on
programming languages but with more flexibility
to represent abstract concepts
Informal text. Natural language description.
All of these notations may be used in large
systems design
©Ian Sommerville 1995
Software Design
Slide 11
Design strategies

Functional design
•

The system is designed from a functional viewpoint.
The system state is centralised and shared between the
functions operating on that state
Object-oriented design
•
The system is viewed as a collection of interacting
objects.
The system state is de-centralised and each object
manages its own state. Objects may be instances of an
object class and communicate by exchanging methods
©Ian Sommerville 1995
Software Design
Slide 12
Functional or DFD view of a compiler
Poor example, see Safe Home Alarm System instead
Source
program
Tokens
Scan
source
Syntax
tree
Tokens
Build
symbol
table
Symbols
Analyse
Symbols
Object
code
Generate
code
Error
indicator
Output
errors
Symbol
table
Error
messages
©Ian Sommerville 1995
Software Design
Slide 13
Object-oriented view of a compiler
Notice the main difference between this and previous diagram?
Scan
Source
program
Add
Token
stream
Symbol
table
Check
Syntax
tree
Get
Gr ammar
Build
Print
Err or
messages
Generate
Object
code
Abstract
code
Generate
©Ian Sommerville 1995
Software Design
Slide 14
Mixed-strategy design


Although it is sometimes suggested that one
approach to design is superior, in practice, an
object-oriented and a functional-oriented
approach to design are complementary
Good software engineers should select the
most appropriate approach for whatever
sub-system is being designed
©Ian Sommerville 1995
Software Design
Slide 15
Design quality




Design quality is an elusive concept. Quality
depends on specific organisational priorities
A 'good' design may be the most efficient, the
cheapest, the most maintainable, the most
reliable, etc.
The attributes discussed here are concerned
with the maintainability of the design
Quality characteristics are equally applicable to
function-oriented and object-oriented designs
©Ian Sommerville 1995
Software Design
Slide 16
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 localised in a single cohesive component
Various levels of cohesion have been identified
©Ian Sommerville 1995
Software Design
Slide 17
Cohesion levels

Coincidental cohesion (weak)
•

Parts of a component are simply bundled together
Logical association (weak)
•
•
Components which perform similar functions are
grouped
For example:
output text to screen
output line to printer
output record to file
•
•
•
Seems ok
Problem is it carries out a range of similar but
different actions
No single well defined action
©Ian Sommerville 1995
Software Design
Slide 18
Cohesion levels

Temporal cohesion (weak)
•
•
Components which are activated at the same time are
grouped
For example:
clear screen
open file
Initialise total
•
•
again not related
solution is to make initialisation module all other
specialised modules:
call init_terminal
call init_files
call init_calculations
©Ian Sommerville 1995
Software Design
Slide 19
Cohesion levels

Communicational cohesion (medium)
•
•

All the elements of a component operate on the same
data
e.g. display and log temperature
Sequential cohesion (medium)
•
The output for one part of a component is the input to
another part
©Ian Sommerville 1995
Software Design
Slide 20
Cohesion levels

Functional cohesion (strong)
•
•
•
•

optimal type of cohesion
performs a single well-defined action on a single data
object
e.g. calculate average
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
©Ian Sommerville 1995
Software Design
Slide 21
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
©Ian Sommerville 1995
Software Design
Slide 22
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
decentralisation (as in objects) and component
communication via parameters or message
passing
©Ian Sommerville 1995
Software Design
Slide 23
Tight coupling
Module A
Module B
Module C
Module D
Shared data
area
©Ian Sommerville 1995
Software Design
Slide 24
Loose coupling
Module A
A’s data
Module B
Module C
B’s data
C’s data
Module D
D’s data
©Ian Sommerville 1995
Software Design
Slide 25
Coupling levels


Altering another modules code (LISP, Assembler)
Modifying data within another module
•
•
•

fault that appears in one module may be due to another
complicated understanding and debugging
can be done via global variables or pointers or call be
reference in C++ / Java
Shared or global data
©Ian Sommerville 1995
Software Design
Slide 26
Coupling levels

Procedure call with a parameter that is a switch (or a
function pointer in C)
• io (command, device buffer, length);
• where command is 0,1,2 for read, write open; better to
use
• read( device, buffer, length);

Procedure call with parameters that are pure data
•
•
ideal is call by value, where a small number of
parameters are used and a copy of the data is passed to
the procedure invoked
clear what information is being communicated
©Ian Sommerville 1995
Software Design
Slide 27
Coupling levels

Passing a serial data stream
•
•
•
•
•
•
most ideal situation
one module passes stream of data to another
once passed data is outside control of process/module
like piping in UNIX
data can be thought of as a temporary intermediate file
only possible in languages that support concurrency
such as Ada and Erlang and Parallel C
©Ian Sommerville 1995
Software Design
Slide 28
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. Such changes must be carefully
controlled
©Ian Sommerville 1995
Software Design
Slide 29
Cohesion, Coupling & Testing


High Cohesion ensures each unit provides a set of
related capabilities and makes the tests of those
capabilities easier to maintain
Low Coupling allows each unit to be effectively
tested in isolation
©Ian Sommerville 1995
Software Design
Slide 30
Understandability

Related to several component characteristics
•
•
•
•


Cohesion. Can the component be understood on its
own?
Naming. Are meaningful names used?
Documentation. Is the design well-documented?
Complexity. Are complex algorithms used?
Informally, high complexity means many
relationships between different parts of the design.
hence it is hard to understand
Most design quality metrics are oriented
towards complexity measurement. They are of
limited use
©Ian Sommerville 1995
Software Design
Slide 31
Adaptability

A design is adaptable if:
•
•
•
•

Its components are loosely coupled
It is well-documented and the documentation is up to
date
There is an obvious correspondence between design
levels (design visibility)
Each component is a self-contained entity (tightly
cohesive)
To adapt a design, it must be possible to trace the
links between design components so that change
consequences can be analysed
©Ian Sommerville 1995
Software Design
Slide 32
Design traceability
C
F
B
Object interaction
level
D
A
D
P
©Ian Sommerville 1995
O
R
Software Design
Object decomposition
level
Slide 33
Adaptability and inheritance


Inheritance dramatically improves adaptability.
Components may be adapted without change
by deriving a sub-class and modifying that
derived class
However, as the depth of the inheritance
hierarchy increases, it becomes increasingly
complex. It must be periodically reviewed and
restructured
•
new trend in this area known as refactoring, associated
with the lightweight process of Extreme Programming
(XP)
©Ian Sommerville 1995
Software Design
Slide 34
Advantages of inheritance



It is an abstraction mechanism which may be
used to classify entities - polymorphism
It is a reuse mechanism at both the design and the
programming level - very useful in framework
The inheritance graph is a source of
organisational knowledge about domains and
systems
Slide 35
Problems with inheritance



Object classes are not self-contained. they cannot
be understood without reference to their superclasses
Designers have a tendency to reuse the
inheritance graph created during analysis. Can
lead to significant inefficiency
The inheritance graphs of analysis, design and
implementation have different functions and
should be separately maintained
Slide 36
Inheritance and OOD

There are differing views as to whether
inheritance is fundamental to OOD.
•
•

View 1. Identifying the inheritance hierarchy or network is a
fundamental part of object-oriented design. Obviously this can
only be implemented using an OOPL.
View 2. Inheritance is a useful implementation concept which
allows reuse of attribute and operation definitions. Identifying
an inheritance hierarchy at the design stage places unnecessary
restrictions on the implementation
Inheritance introduces complexity and this is
undesirable, especially in critical systems
Slide 37
UML associations





Objects and object classes participate in relationships with
other objects and object classes
In the UML, a generalised relationship is indicated by an
association
Associations may be annotated with information that
describes the association
Associations are general but may indicate that an attribute
of an object is an associated object or that a method relies
on an associated object
Be careful to distinguish between a UML dependemcy
and an association
Slide 38
An association model
Employee
is-member-of
Department
is-managed-by
manages
Manager
Slide 39