2. Software Engineering Software Design Slide 2
Software Design
Deriving a solution which
satisfies software requirements
3. Software Engineering Software Design Slide 3
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.
4. Software Engineering Software Design Slide 4
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.
5. Software Engineering Software Design Slide 5
Phases in the Design Process
Architectural
design
Abstract
specificatio
n
Interface
design
Component
design
Data
structure
design
Algorithm
design
System
architecture
Software
specification
Interface
specification
Component
specification
Data
structure
specification
Algorithm
specification
Requirements
specification
Design activities
Design products
6. Software Engineering Software Design Slide 6
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.
7. Software Engineering Software Design Slide 7
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
8. Software Engineering Software Design Slide 8
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
9. Software Engineering Software Design Slide 9
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
10. Software Engineering Software Design Slide 10
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
11. Software Engineering Software Design Slide 11
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.
12. Software Engineering Software Design Slide 12
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.
13. Software Engineering Software Design Slide 13
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
15. Software Engineering Software Design Slide 15
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.
16. Software Engineering Software Design Slide 16
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
17. Software Engineering Software Design Slide 17
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.
18. Software Engineering Software Design Slide 18
Modular Understandability
• A design method satisfies this criterion if it
encourages the development of modules which
are easily understandable.
• EXAMPLE. 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.
19. Software Engineering Software Design Slide 19
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.
20. Software Engineering Software Design Slide 20
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
21. Software Engineering Software Design Slide 21
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.
22. Software Engineering Software Design Slide 22
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.
23. Software Engineering Software Design Slide 23
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
24. Software Engineering Software Design Slide 24
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
a minimum of n-1 and a maximum of links;
your system should stay closer to the minimum
2
)1( −nn
26. Software Engineering Software Design Slide 26
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!
27. Software Engineering Software Design Slide 27
• 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.
Coupling
29. Software Engineering Software Design Slide 29
Loose Coupling
Module A
A’s data
Module B
B’s data
Module D
D’s data
Module C
C’s data
30. Software Engineering Software Design Slide 30
• 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.
Coupling and Inheritance
31. Software Engineering Software Design Slide 31
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;
32. Software Engineering Software Design Slide 32
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.
33. Software Engineering Software Design Slide 33
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.
34. Software Engineering Software Design Slide 34
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
35. Software Engineering Software Design Slide 35
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.