2. Software Engineering Software Design Slide 2
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
• 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
• 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
6. Software Engineering Software Design Slide 6
• Architectural design: Identify sub-systems.
• Abstract specification: Specify sub-systems.
• Interface design: Describe sub-system interfaces.
• Component design: Decompose sub-systems
• Data structure design: Design data structures to hold
• Algorithm design: Design algorithms for problem
7. Software Engineering Software Design Slide 7
• Computer systems are not monolithic: they are usually
composed of multiple, interacting modules.
• Modularity has long been seen as a key to cheap, high
• 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
• 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
– coherent and
9. Software Engineering Software Design Slide 9
• The most obvious design methods involve
• 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:
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
– The system is viewed as a collection of
– 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
• 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
• 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
• 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
16. Software Engineering Software Design Slide 16
• A method satisfies this criterion if it leads to the production
of modules that may be freely combined to produce new
• 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
• The Numerical Algorithm Group (NAG)
libraries contain a wide range of routines for
solving problems in linear algebra, differential
• 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
• 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
• 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
20. Software Engineering Software Design Slide 20
• 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
• 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
• EXAMPLE. Validating input at source prevents
errors from propagating throughout the
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
– Modules must correspond to linguistic units in the
• EXAMPLE. Java methods and classes
24. Software Engineering Software Design Slide 24
• 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
25. Software Engineering Software Design Slide 25
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.
28. Software Engineering Software Design Slide 28
Module A Module B
Module C Module D
29. Software Engineering Software Design Slide 29
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
Coupling and Inheritance
31. Software Engineering Software Design Slide 31
• 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?
32. Software Engineering Software Design Slide 32
• The simplest realistic design method, widely used in
• 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
• 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
34. Software Engineering Software Design Slide 34
• 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
A measure of how well a component “fits
• 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.