Software Engineering

Software Design
Lecture 5

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
specifica
t ion

Design acti
vities

Architectur
al Abstract Interface Component Data Algorithm
design specifica
tio design design structur
e design
n design

Software Data
System Interface Component Algorithm
specifica
tion structure
architectur
e specifica
tion specifica
tion specifica
tion
specification

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 Less well-suited to distributed, non-
application domains terminating systems
- e.g., compilers - e.g., process control systems, operating
systems like WinNT, ATM machines
Software Engineering 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: sub-problems
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 a
minimum of n-1 and a maximum of n(n  1) links;
2
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.
• Class/Object cohesion (strong)
– Each operation provides functionality which allows object
attributes to be modified or inspected. Ideally, object-oriented
design units (classes) should exhibit the two types of cohesion
(functional or sequential)
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

 Interval Scales for Cohesion Measurement
Class cohesion metrics can be broadly classified into two groups:
1.Interface-based metrics: compute class cohesion from
information in method signatures
2.Code-based metrics: compute class cohesion in terms of attribute
accesses by methods
1. Disjoint component-based metrics count the number of disjoint sets of
methods or attributes in a given class.
2. Pairwise connection-based metrics compute cohesion as a function of
number of connected and disjoint method pairs
3. Connection magnitude-based metrics count the accessing methods per
attribute and indirectly find an attribute-sharing index in terms of the count
(instead of computing direct attribute-sharing between methods).
4. Decomposition-based metrics compute cohesion in terms of recursive
decompositions of a given class. The decompositions are generated by removal
of pivotal elements that keep the class connected.
Software Engineering Software Design Slide 39
 Interface-based metrics
• evaluate cohesion among methods of a class early in
the analysis and the design phase
• evaluate the consistency of methods in a class’s
interface using the lists of parameters of the methods.
• applied on class declarations that only contain method
prototypes (method types and parameter types)
• One of UI-based metric : Cohesion Among Methods
of Classes (CAMC) based on the assumption that the
parameters of a method reasonably define the types of
interaction that method may implement.
Software Engineering Software Design Slide 40
 CAMCM
To compute the CAMC metric value, we determine a
union of all parameters of all the methods of a class.
• A set Mi of parameter object types for each method is also
determined.
• An intersection (set Pi) of Mi with the union set T is
computed for all methods in the class.
• A ratio of the size of the intersection (Pi) set to the size of
the union set (T) is computed for all methods.
• The summation of all intersection sets Pi is divided by
product of the number of methods and the size of the union
set T, to give a value for the CAMC metric.

Software Engineering Software Design Slide 41

 CAMC’s Formular

Software Engineering Software Design Slide 42

 Cohesion Metrics using Disjoint Sets of Elements
• An early metric of this type is the Lack of Cohesion
of Methods (LCOM1)
• This metric counts the number of pairs of methods that do not
share their class attributes.
• It considers how many disjoint sets are formed by the
intersection of the sets of the class attributes used by each
method.
• Under LCOM1, the perfect cohesion is achieved when all
methods access all attributes. Because of perfect cohesion, we
expect the lack-of-cohesion value to be 0.
• At the opposite end of the spectrum, each method accesses only
a single attribute (assuming that m = a). In this case, we expect
LCOM = 1, which indicates extreme lack of cohesion.

Software Engineering Software Design Slide 43

 LCOM1’s Formular

Software Engineering Software Design Slide 44

 LCOM1 concl..
• This version of LCOM is labeled as LCOM1 to
allow for subsequent variations, LCOM2,
LCOM3, and LCOM4. Class cohesion,
• LCOM3, is measured as the number of
connected components in the graph.
• LCOM2 calculates the difference between the
number of method pairs that do or do not share
their class attributes. LCOM2 is classified as a
Pairwise Connection-Based metric
Software Engineering Software Design Slide 45
 Component Level Design
Modern WebApps deliver incresingly
sophisticated functions that :
–Perfom form localization processing to generate
content and navigation capability in a dynamic
fashion
–Provide computation or data processing capability
that are appropriate for the WebApp’s business
domain
–Provide sophisticated database query and access
–Establish data interfaces with external corporate
systems
e.g Joomla
Software Engineering Software Design Slide 46
 Object –oriented Hypermedia Design
Method(OOHDM)
Class Name

Conceptual design

Software Engineering Software Design Slide 47