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
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
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
application domains
- e.g., compilers
Software Engineering
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 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: subproblems 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