WHAT IS DESIGN ?
The design activity begins when the requirements
document for the software to be developed is available.
The requirement specification activity is entirely in the
problem domain, while design is the first step towards the
solution domain.
Design is essentially the bridge between the requirements
specification and the final solution for satisfying the
requirements.
The goal of design system is to produce a model or
representation of a system which can be used later to build
that system.
The design of a system is essentially a
blueprint or a plan for a solution for the
system.
A system is the set of components with clearly defined
behavior that interacts with each other in a fixed defined
manner to produce some behavior or services for its
environment.
In a software system, these components are known as
software modules.
SOFTWARE MODULES : A software module consists of a
single block of code that can be invoked in the way that a
function or method is invoked.
SOFTWARE DESIGN
PROCESS
System Design or
Top-Level Design
Detailed Design or Logic
Design
LEVELS OF SOFTWARE DESIGN
PROCESS
SYSTEM DESIGN OR TOP-LEVEL DESIGN :
At this level, the focus is on deciding which modules are
needed for the system, the specifications of these
modules, and how the modules should be
interconnected. It has major impact on system testability
and modifiability, and it impacts its efficiency.
DETAILED DESIGN OR LOGIC DESIGN : At
this level, the internal design of the modules, or how the
specifications of the module can be satisfied, is decided.
Detailed design essentially expands the system design to
contain a more detailed description of the processing
logic and data structures so that the design is sufficiently
complete for coding.
DESIGN
OBJECT ORIENTED FUNCTION ORIENTED
In this design, the modules In this design, a system is
represent data abstraction. viewed as a transformation
function, transforming the
inputs to the desired
outputs.
DESIGN PRINCIPLES
A design should be clearly verifiable, complete (implements
all specifications) and traceable (design elements can be traced
to some requirements).
A design should be efficient. Efficiency of a system is
concerned with proper use of scarce resources by the system.
A design should be simple. If the software design is simple,
then the maintainer has a thorough understanding of different
modules of the system and how they are interconnected and thus
the modification and maintenance can take place easily
MODULARITY
A system is considered modular, if it consists of discrete
components so that each component can be implemented
separately, and a change on one component has a minimal
impact on the other component.
Modularity helps in system debugging, system repair and
in system building.
For modularity, each module needs to support a well
defined abstraction and have a clear interface through which
it can interact with other modules.
FUNCTION ORIENTED DESIGN
What do you mean by Module?
-A module is a logically separable part of a program.
-It is a program unit that is discreet and Identifiable with respect
to compiling and loading.
-In terms of common programming language constructs, a module
can be a macro, a function, a procedure (or subroutine), a process,
or a package.
In a system using functional abstraction, Coupling and Cohesion
are two modularization criteria, which are often used together to
produce modular design.
Coupling
Independent modules : if one can function completely without the
presence of other.
• they are solvable and modifiable separately
In a system all modules cannot be independent
• more connections between modules the more dependent they
are
• more knowledge about one module is required to understand or
solve the other module
Coupling between modules is the strength of interconnection
between modules or a measure of interdependence among
modules.
Major factors influencing coupling
• type of connection between modules
• complexity of interface
• type of information flow
Range of coupling
Highly coupled
These types of system have interconnections, with program units
dependent on each other.
A B
C D
Loosely coupled
Loose coupled systems are made up of modules which are
independent or almost independent
A B
C D
Uncoupled
Uncoupled modules have no interconnection at all.
No dependencies
A B
C D
COMPLEXITY OF INTERFACE
complexity and the obscurity of interface increase
coupling
to keep coupling low we would minimize the number
of interfaces per module and the complexity of each
interface.
coupling is minimized if
• only the defined entry interface of module is used by
others e.g. information is passed exclusively through
parameters
coupling increases if
• indirect or obscure(unknown) interface is used like
Internals of a module is directly used or
shared variables employed for communication
some level of complexity of interface is required to support the
communication needed between modules
e.g. if a field of record is needed by a procedure, often the
entire record is passed rather than just passing that field of the
record. By passing the record we are increasing the coupling
unnecessarily.
Hence we should keep the interface of a module as simple and
small as possible
Types of Coupling
HIGH COUPLING
HYBRID COUPLING
CONTENT COUPLING
COMMON COUPLING
LOOSE CUPLING
CONTROL COUPLING
STAMP COUPLING
DATA COUPLING LOW COUPLING
CONTENT COUPLING
Content coupling (also known as Pathological coupling) is
when one module modifies or relies on the internal
workings of another module (e.g., accessing local data of
another module).
Therefore changing the way the second module produces
data (location, type, timing) will lead to changing the
dependent module.
It is the worst type of coupling
COMMON COUPLING
Common coupling (also known as Global coupling) is when two
modules share the same global data (e.g., a global
variable).Changing the shared resource implies changing all the
modules using it.
CONTROL COUPLING
When one module passes a piece of data or a signal to
control the actions of another module, the two are said to be
control coupled. The control information tells the recipient
module what actions it should perform. control information
also be passes from a subordinate to super ordinate module.
Such a practice is referred as inversion
STAMP COUPLING
Stamp coupling is when modules share a composite data
structure and use only a part of it, possibly a different part
(e.g., passing a whole record to a function that only needs
one field of it).This may lead to changing the way a module
reads a record because a field that the module doesn't need
has been modified.
DATA COUPLING
Data coupling is when modules share data through, for
example, parameters. Each datum is an elementary piece, and
these are the only data shared (e.g., passing an integer to a
function that computes a square root).
This is the best kind of coupling.
In general, interfaces with only data communication result in the
lowest degree of coupling, followed by interfaces that only transfer
control data.
Coupling is considered highest if the data is hybrid i.e. some data
items and some control item are passed between modules.
Cohesion
What is cohesion ?
Cohesion is another modularization criteria besides coupling, in other words,
it’s an intra-module property.
Cohesion of a module represents how tightly bound the internal elements of
a module are to one another. It reflects the design consideration for integrating
various components of a module into one unit.
As mentioned previously, coupling is reduced when elements in different
modules have little or no bonds between them.
Another way of achieving this effect is by maximizing the relationship between
elements of the same module by strengthening the bonds between those
elements, which implies achieving high cohesion.
Why is it important?..
Cohesion is a measure of the logical strength of a software
module and of how strongly-related or focused the responsibilities
(elements) of a single module are. If the responsibilities under a
given module tend to share strong relation, then high cohesion has
been achieved. This is beneficial since it:
Increases code readability
Increases likelihood of reuse
Reduces complexity, and
Makes the system robust and reliable.
Cohesion is furthermore required since it gives the designer an
idea about whether the different elements of a module belong
together in the same module.
For instance, let two elements or line of codes X and Y belong
to the same module. Then they are said to be cohesive when a
change to A allows B to change so that both add new values.
Cohesion exists in different degrees and has been categorized
in several levels on the basis of functionality.
Different levels of cohesion are:
Cohesion Level Cohesion Attribute Module Strength
• Coincidental • LOWEST COHESION • WEAKEST
• Logical
• Temporal
• Procedural
• Communicational
• Sequential
• Functional • HIGHEST COHESION • STRONGEST
Coincidental Cohesion:
This level represents the lowest degree of cohesion. It occurs
when there’s no meaningful relationship among the elements
of a module.
Coincidental cohesion can occur if an existing program is
modularized by being chopped and segregated into different
units, viz. modules.
– Example: If a module is created to save duplicate code by
combining some part of code that occurs at many different places,
that module is likely to have coincidental cohesion, since the
statements in the module have no relationship with each other.
Logical-bundling Cohesion:
A module has logical correlation if there is some logical
relationship between the elements of the module, and the
elements perform functions that fall in the same logical class.
The elements perform similar function by passing a special
kind of status flag, which are used to determine the
statements to execute in the module. In other words, this
function behaves like a huge if-else/switch operator.
Such modules have a tricky and clumsy code and it also results
in hybrid information flow between modules (an unwanted
type of coupling).
Temporal Cohesion:
It’s the same as logical cohesion, except that the elements
are also related in time and are executed together.
Modules that perform activities like “initialization”, “clean
up” and “termination” are usually temporally bound.
Temporal cohesion is of higher degree than the logical
cohesion since all the elements are executed together.
Hence, the code is usually simpler.
Procedural Cohesion:
This cohesive module contains elements that belong to a
common procedural unit. i.e. The elements of the
module are involved in different activities but those
activities are sequential.
Procedural cohesion often cuts along functional lines. A
module with only procedural cohesion may contain only
part of a complete function or parts of several functions.
- Example: A loop or a sequence of decision statements in a module
maybe be combined to form a separate module.
Communicational Cohesion or Action-bundling Cohesion:
A communicational cohesion module has elements that are related
by a reference to the same input or output data. i.e. The elements
are together because they operate on the same input or output
data.
Communicational cohesion is sufficiently high as to be generally
acceptable if higher cohesion alternative structures cannot be
achieved.
These modules can perform more than one function.
– Example: A module to “print and punch record”.
Action
1
Action
Data 2 Transferred Data
Action
3
Sequential Cohesion or Data Flow Cohesion:
When the elements are together in a module because the output of
one forms the input to another, we get sequential cohesion. It
describes the inter-dependencies among the different elements of the
module.
However, sequential cohesion does not provide any guidelines on how
to combine those sequence of elements into modules. There may exist
several combinations. The general criteria for linking the elements is
that a piece of data, undergoing a transformation, be used in another
transformation.
– Viz. Combine all in one module, First half in one and second half in another, etc.
A sequentially bound module may contain several functions or parts of
different functions.
E.g. A module constructed to read, calculate and write the sum of two values.
Action Action Action
Data
1 2 3
Transformed data
Functional Cohesion:
It’s the strongest cohesion. In a functionally bound module, all
the elements of the module are related to performing a single
function. The more focused the module goal, the greater is its
functional cohesion.
Modules with functional cohesion can also be described by a
simple sentence. If we cannot describe it using a simple
sentence, this module is not likely to have functional cohesion.
However, if the description is a compound sentence, that
doesn’t imply the absence of functional cohesion, since these
modules can be described using compound sentences.
– Example: “compute square root”, “sort the array”, etc.
C&C
PROPERTIES
Relation between coupling and cohesion-C&C Property
• Cohesion and coupling are highly related and share a very contrasting
relation (negative correlation).
• The greater the cohesion of each module in the system, the lower is
the coupling between the modules, and vice versa. The correlation
isn’t perfect but very high.
• C&C property being highly qualitative, could not be measured in a
definite manner until the development of Quantitative models which
established a method to identify module errors for software
improvement.
– In 1989, Ott and Thuss at Michigan Technological
Institute developed a quantitative model of cohesion Coupling
using a slice-based method.
– In 1992, Zage built a model of module coupling to
demonstrate increased module errors with increased
coupling, etc. Cohesion
• The C&C properties of any software have a great impact on the
software quality. Some of the primary software qualities tested using
C&C (identified by Rome Laboratories) are:
– Correctness -Maintainability
– Reliability -Verifiability
– Efficiency -Flexibility
– Integrity -Portability
– Usability - Reusability
– Survivability - Interoperability
– Expandability
C&C metric can be used for:-
– Forecasting testing costs and reliability.
– Allocating the testing effort according to the error proneness of
the module.
– Software quality assurance.
– Assessing the quality of reusable software.
Qualitative Tests to determine the Degree of Cohesion:
Though there exists no Mathematical formula to determine the
degree of cohesion since it’s a qualitative value, the techniques are
based on certain judgments, in which the technique involves writing
a sentence which describes fully and accurately, the function or
purpose of the module. The following tests can be made:
– If a sentence must be a compound sentence, if it contains comma or
contains more than one verb, the module is probably performing more
than one function, and hence, probably has sequential or
communicational cohesion.
– If the sentence contains words related to time, like “first”, “next”, “when”
and “after”, the module probably has sequential or temporal cohesion.
– Words like “initialize” and “clean up” imply temporal cohesion.
– If the predicate of the sentence does not contain a single specific object
following the verb (e.g. “edit all data”), the module probably has Logical
cohesion.
Quantitative Models for Measuring Cohesion
• There are only a few quantitative models in the software metrics
area, of which, only a handful have been verified.
• In the following built quantitative models, cohesion has been
divided into - functional, data-flow, action-bundling and logical
bundling cohesion.
Similarly, coupling has been divided into- data and control flow,
global and environmental coupling.
• The table in the end of the presentation shows the results of the
hand applications of C&C formulae to two different
implementations/modules of a ‘selection sort’ algorithm.
• The two implementations are:
– MODULE1, which consists of a single module.
– MODULE2, which consists of 4 sub-modules but uses the same
algorithm.
When a module contains a number of other sub modules, we
calculate the C&C values of each of the sub-modules, and their
average is taken to determine the C&C value of the containing
module, i.e. Module2.
• These modules have satisfied the objectives for a quantitative
model since-
– It has been observed that the C&C formulas are sensitive
enough to distinguish between the two modules.
– The obtained quantitative values agree with the qualitative
assessment of these modules.
