Coupling and Cohesion

Module Coupling
In software engineering, the coupling is the degree of interdependence between
software modules. Two modules that are tightly coupled are strongly dependent on
each other. However, two modules that are loosely coupled are not dependent on each
other. Uncoupled modules have no interdependence at all within them.

The various types of coupling techniques are shown in fig:

A good design is the one that has low coupling. Coupling is measured by the number of
relations between the modules. That is, the coupling increases as the number of calls
between modules increase or the amount of shared data is large. Thus, it can be said
that a design with high coupling will have more errors.
Types of Module Coupling

1. No Direct Coupling: There is no direct coupling between M1 and M2. Skip 10sPlay
VideoForward Skip 10s
In this case, modules are subordinates to different modules. Therefore, no direct
coupling.

2. Data Coupling: When data of one module is passed to another module, this is called
data coupling.

3. Stamp Coupling: Two modules are stamp coupled if they communicate using
composite data items such as structure, objects, etc. When the module passes non-
global data structure or entire structure to another module, they are said to be stamp
coupled. For example, passing structure variable in C or object in C++ language to a
module.

4. Control Coupling: Control Coupling exists among two modules if data from one
module is used to direct the structure of instruction execution in another.

5. External Coupling: External Coupling arises when two modules share an externally
imposed data format, communication protocols, or device interface. This is related to
communication to external tools and devices.

6. Common Coupling: Two modules are common coupled if they share information
through some global data items.

7. Content Coupling: Content Coupling exists among two modules if they share code,
e.g., a branch from one module into another module.
Module Cohesion
In computer programming, cohesion defines to the degree to which the elements of a
module belong together. Thus, cohesion measures the strength of relationships
between pieces of functionality within a given module. For example, in highly cohesive
systems, functionality is strongly related.

Cohesion is an ordinal type of measurement and is generally described as "high

cohesion" or "low cohesion."
Types of Modules Cohesion

1. Functional Cohesion: Functional Cohesion is said to exist if the different

elements of a module, cooperate to achieve a single function.
 2. Sequential Cohesion: A module is said to possess sequential cohesion if the
element of a module form the components of the sequence, where the output
from one component of the sequence is input to the next.
3. Communicational Cohesion: A module is said to have communicational
cohesion, if all tasks of the module refer to or update the same data structure,
e.g., the set of functions defined on an array or a stack.
4. Procedural Cohesion: A module is said to be procedural cohesion if the set of
purpose of the module are all parts of a procedure in which particular sequence
of steps has to be carried out for achieving a goal, e.g., the algorithm for
decoding a message.
5. Temporal Cohesion: When a module includes functions that are associated by
the fact that all the methods must be executed in the same time, the module is
said to exhibit temporal cohesion.
6. Logical Cohesion: A module is said to be logically cohesive if all the elements of
the module perform a similar operation. For example Error handling, data input
and data output, etc.
7. Coincidental Cohesion: A module is said to have coincidental cohesion if it
performs a set of tasks that are associated with each other very loosely, if at all.

Differentiate between Coupling and

Cohesion

Coupling Cohesion

Coupling is also called Inter-Module Cohesion is also called Intra-Module Binding.

Binding.

Coupling shows the relationships between Cohesion shows the relationship within the
modules. module.

Coupling shows the Cohesion shows the module's

relative independence between the relative functional strength.
modules.
 While creating, you should aim for low While creating you should aim for high cohesion,
coupling, i.e., dependency among modules i.e., a cohesive component/ module focuses on a
should be less. single function (i.e., single-mindedness) with little
interaction with other modules of the system.

In coupling, modules are linked to the In cohesion, the module focuses on a single thing.
other modules.

Function Oriented Design

Function Oriented design is a method to software design where the model is
decomposed into a set of interacting units or modules where each unit or module has a
clearly defined function. Thus, the system is designed from a functional viewpoint.

Design Notations
Design Notations are primarily meant to be used during the process of design and are
used to represent design or design decisions. For a function-oriented design, the design
can be represented graphically or mathematically by the following:
Data Flow Diagram
Data-flow design is concerned with designing a series of functional transformations that
convert system inputs into the required outputs. The design is described as data-flow
diagrams. These diagrams show how data flows through a system and how the output is
derived from the input through a series of functional transformations.

Data-flow diagrams are a useful and intuitive way of describing a system. They are
generally understandable without specialized training, notably if control information is
excluded. They show end-to-end processing. That is the flow of processing from when
data enters the system to where it leaves the system can be traced. orward Skip 10s

Data-flow design is an integral part of several design methods, and most CASE tools
support data-flow diagram creation. Different ways may use different icons to represent
data-flow diagram entities, but their meanings are similar.

The notation which is used based on the following symbols:

The report generator produces a report which describes all of the named entities in a
data-flow diagram. The user inputs the name of the design represented by the diagram.
The report generator then finds all the names used in the data-flow diagram. It looks up
a data dictionary and retrieves information about each name. This is then collated into a
report which is output by the system.

Data Dictionaries
A data dictionary lists all data elements appearing in the DFD model of a system. The
data items listed contain all data flows and the contents of all data stores looking on the
DFDs in the DFD model of a system.

A data dictionary lists the objective of all data items and the definition of all composite
data elements in terms of their component data items. For example, a data dictionary
entry may contain that the data grossPay consists of the
parts regularPay and overtimePay.

grossPay = regularPay + overtimePay

For the smallest units of data elements, the data dictionary lists their name and their
type.

A data dictionary plays a significant role in any software development process because
of the following reasons:

o A Data dictionary provides a standard language for all relevant information for
use by engineers working in a project. A consistent vocabulary for data items is
essential since, in large projects, different engineers of the project tend to use
different terms to refer to the same data, which unnecessarily causes confusion.
o The data dictionary provides the analyst with a means to determine the definition
of various data structures in terms of their component elements.

Structured Charts
It partitions a system into block boxes. A Black box system that functionality is known to
the user without the knowledge of internal design.
Structured Chart is a graphical representation which shows:

o System partitions into modules

o Hierarchy of component modules
o The relation between processing modules
o Interaction between modules
o Information passed between modules

The following notations are used in structured chart:

Pseudo-code
Pseudo-code notations can be used in both the preliminary and detailed design phases.
Using pseudo-code, the designer describes system characteristics using short, concise,
English Language phases that are structured by keywords such as If-Then-Else, While-
Do, and End.
Object-Oriented Design
In the object-oriented design method, the system is viewed as a collection of objects
(i.e., entities). The state is distributed among the objects, and each object handles its
state data. For example, in a Library Automation Software, each library representative
may be a separate object with its data and functions to operate on these data. The tasks
defined for one purpose cannot refer or change data of other objects. Objects have their
internal data which represent their state. Similar objects create a class. In other words,
each object is a member of some class. Classes may inherit features from the superclass.

The different terms related to object design are:

1. Objects: All entities involved in the solution design are known as objects. For
example, person, banks, company, and users are considered as objects. Every
entity has some attributes associated with it and has some methods to perform
on the attributes.
2. Classes: A class is a generalized description of an object. An object is an instance
of a class. A class defines all the attributes, which an object can have and
methods, which represents the functionality of the object.
3. Messages: Objects communicate by message passing. Messages consist of the
integrity of the target object, the name of the requested operation, and any other
 action needed to perform the function. Messages are often implemented as
procedure or function calls.
4. Abstraction In object-oriented design, complexity is handled using abstraction.
Abstraction is the removal of the irrelevant and the amplification of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept. The
data and operations are linked to a single unit. Encapsulation not only bundles
essential information of an object together but also restricts access to the data
and methods from the outside world.
6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner
where the lower or sub-classes can import, implement, and re-use allowed
variables and functions from their immediate [Link] property of OOD
is called an inheritance. This makes it easier to define a specific class and to
create generalized classes from specific ones.
7. Polymorphism: OOD languages provide a mechanism where methods
performing similar tasks but vary in arguments, can be assigned the same name.
This is known as polymorphism, which allows a single interface is performing
functions for different types. Depending upon how the service is invoked, the
respective portion of the code gets executed.

Difference Between Function Oriented Design and Object Oriented

Design :
COMPARISON FUNCTION
FACTORS ORIENTED DESIGN OBJECT ORIENTED DESIGN

The basic abstractions are not the

The basic abstractions, which
real world functions but are the
Abstraction are given to the user, are real
data abstraction where the real
world functions.
world entities are represented.

Function are grouped together on

Functions are grouped
the basis of the data they operate
Function together by which a higher
since the classes are associated
level function is obtained.
with their methods.

execute carried out using structured Carried out using UML

COMPARISON FUNCTION
FACTORS ORIENTED DESIGN OBJECT ORIENTED DESIGN

analysis and structured

design i.e, data flow diagram

In this approach the state

In this approach the state information is not represented is
information is often not represented in a centralized
State information
represented in a centralized memory but is implemented or
shared memory. distributed among the objects of
the system.

Approach It is a top down approach. It is a bottom up approach.

Begins by considering the

Begins by identifying objects and
Begins basis use case diagrams and the
classes.
scenarios.

In function oriented design

Decompose we decompose in We decompose in class level.
function/procedure level.

This approach is mainly used This approach is mainly used for

Use for computation sensitive evolving system which mimics a
application. business or business case.
Software Metrics
A software metric is a measure of software characteristics which are measurable or
countable. Software metrics are valuable for many reasons, including measuring
software performance, planning work items, measuring productivity, and many other
uses.

Within the software development process, many metrics are that are all connected.
Software metrics are similar to the four functions of management: Planning,
Organization, Control, or Improvement.

Classification of Software Metrics

Software metrics can be classified into two types as follows:

1. Product Metrics: These are the measures of various characteristics of the software
product. The two important software characteristics are:

1. Size and complexity of software.

2. Quality and reliability of software.

These metrics can be computed for different stages of SDLC.

Process Metrics: These are the measures of various characteristics of the

software development process. For example, the efficiency of fault detection.
They are used to measure the characteristics of methods, techniques, and tools
that are used for developing software.

Types of Metrics
1. Internal metrics: Internal metrics are the metrics used for measuring
properties that are viewed to be of greater importance to a software
developer. For example, Lines of Code (LOC) measure.
2. External metrics: External metrics are the metrics used for measuring
properties that are viewed to be of greater importance to the user, e.g.,
portability, reliability, functionality, usability, etc.
3. Hybrid metrics: Hybrid metrics are the metrics that combine product, process,
and resource metrics. For example, cost per FP where FP stands for Function
Point Metric.
4. Project metrics: Project metrics are the metrics used by the project manager to
check the project's progress. Data from the past projects are used to collect
various metrics, like time and cost; these estimates are used as a base of new
software. Note that as the project proceeds, the project manager will check its
progress from time-to-time and will compare the effort, cost, and time with the
original effort, cost and time. Also understand that these metrics are used to
decrease the development costs, time efforts and risks. The project quality can
also be improved. As quality improves, the number of errors and time, as well as
cost required, is also reduced.
Advantage of Software Metrics
Comparative study of various design methodology of software systems.

For analysis, comparison, and critical study of different programming language

concerning their characteristics.

In comparing and evaluating the capabilities and productivity of people involved in

software development.

In the preparation of software quality specifications.

In the verification of compliance of software systems requirements and specifications.

In making inference about the effort to be put in the design and development of the
software systems.

In getting an idea about the complexity of the code.

In taking decisions regarding further division of a complex module is to be done or not.

In guiding resource manager for their proper utilization.

In comparison and making design tradeoffs between software development and

maintenance cost.

In providing feedback to software managers about the progress and quality during
various phases of the software development life cycle.

In the allocation of testing resources for testing the code.

Disadvantage of Software Metrics

The application of software metrics is not always easy, and in some cases, it is difficult
and costly.

The verification and justification of software metrics are based on historical/empirical

data whose validity is difficult to verify.

These are useful for managing software products but not for evaluating the
performance of the technical staff.
The definition and derivation of Software metrics are usually based on assuming which
are not standardized and may depend upon tools available and working environment.

Most of the predictive models rely on estimates of certain variables which are often not
known precisely.

[Link] is a token count?

In these metrics, a computer program is considered to be a collection of tokens, which may be
classified as either operators or operands. All software science metrics can be defined in terms
of these basic symbols. These symbols are called as a token. The basic measures are.
n1 = count of unique operators.

Halstead’s Software Metrics

Halstead’s software metrics is a set of measures proposed by Maurice Halstead to
evaluate the complexity of a software program. These metrics are based on the number of
distinct operators and operands in the program, and are used to estimate the effort
required to develop and maintain the program.

The Halstead metrics include the following:

1. Program length (N): This is the total number of operator and operand occurrences in
the program.
2. Vocabulary size (n): This is the total number of distinct operators and operands in the
program.
3. Program volume (V): This is the product of program length (N) and logarithm of
vocabulary size (n), i.e., V = N*log2(n).
4. Program level (L): This is the ratio of the number of operator occurrences to the
number of operand occurrences in the program, i.e., L = n1/n2, where n1 is the
number of operator occurrences and n2 is the number of operand occurrences.
5. Program difficulty (D): This is the ratio of the number of unique operators to the total
number of operators in the program, i.e., D = (n1/2) * (N2/n2).
6. Program effort (E): This is the product of program volume (V) and program difficulty
(D), i.e., E = V*D.
7. Time to implement (T): This is the estimated time required to implement the program,
based on the program effort (E) and a constant value that depends on the
programming language and development environment.
Halstead’s software metrics can be used to estimate the size, complexity, and effort
required to develop and maintain a software program. However, they have some
limitations, such as the assumption that all operators and operands are equally important,
and the assumption that the same set of metrics can be used for different programming
languages and development environments.
Overall, Halstead’s software metrics can be a useful tool for software developers and
project managers to estimate the effort required to develop and maintain software
programs.
A computer program is an implementation of an algorithm considered to be a collection
of tokens that can be classified as either operators or operands. Halstead’s metrics are
included in a number of current commercial tools that count software lines of code. By
counting the tokens and determining which are operators and which are operands, the
following base measures can be collected:
n1 = Number of distinct operators.
n2 = Number of distinct operands.
N1 = Total number of occurrences of operators.
N2 = Total number of occurrences of operands.
In addition to the above, Halstead defines the following :
n1* = Number of potential operators.
n2* = Number of potential operands.
Halstead refers to n1* and n2* as the minimum possible number of operators and
operands for a module and a program respectively. This minimum number would be
embodied in the programming language itself, in which the required operation would
already exist (for example, in C language, any program must contain at least the
definition of the function main()), possibly as a function or as a procedure: n1* = 2, since
at least 2 operators must appear for any function or procedure : 1 for the name of the
function and 1 to serve as an assignment or grouping symbol, and n2* represents the
number of parameters, without repetition, which would need to be passed on to the
function or the procedure.

Halstead metrics –

Halstead metrics are:

 Halstead Program Length – The total number of operator occurrences and the total
number of operand occurrences.
N = N1 + N2
And estimated program length is, N^ = n1log2n1 + n2log2n2
The following alternate expressions have been published to estimate program length:
 NJ = log2(n1!) + log2(n2!)
 NB = n1 * log2n2 + n2 * log2n1
 NC = n1 * sqrt(n1) + n2 * sqrt(n2)
 NS = (n * log2n) / 2
 Halstead Vocabulary – The total number of unique operator and unique operand
occurrences.
n = n1 + n2
 Program Volume – Proportional to program size, represents the size, in bits, of space
necessary for storing the program. This parameter is dependent on specific algorithm
implementation. The properties V, N, and the number of lines in the code are shown
to be linearly connected and equally valid for measuring relative program size.
V = Size * (log2 vocabulary) = N * log2(n)
The unit of measurement of volume is the common unit for size “bits”. It is the actual
size of a program if a uniform binary encoding for the vocabulary is used. And error =
Volume / 3000
 Potential Minimum Volume – The potential minimum volume V* is defined as the
volume of the most succinct program in which a problem can be coded.
V* = (2 + n2*) * log2(2 + n2*)
Here, n2* is the count of unique input and output parameters
 Program Level – To rank the programming languages, the level of abstraction
provided by the programming language, Program Level (L) is considered. The higher
the level of a language, the less effort it takes to develop a program using that
language.
L = V* / V
The value of L ranges between zero and one, with L=1 representing a program written
at the highest possible level (i.e., with minimum size).
And estimated program level is L^ =2 * (n2) / (n1)(N2)
 Program Difficulty – This parameter shows how difficult to handle the program is.
D = (n1 / 2) * (N2 / n2)
D=1/L
As the volume of the implementation of a program increases, the program level
decreases and the difficulty increases. Thus, programming practices such as redundant
usage of operands, or the failure to use higher-level control constructs will tend to
increase the volume as well as the difficulty.
 Programming Effort – Measures the amount of mental activity needed to translate
the existing algorithm into implementation in the specified program language.
E = V / L = D * V = Difficulty * Volume

 Language Level – Shows the algorithm implementation program language level. The
same algorithm demands additional effort if it is written in a low-level program
language. For example, it is easier to program in Pascal than in Assembler.
L’ = V / D / D
lambda = L * V* = L2 * V
 Intelligence Content – Determines the amount of intelligence presented (stated) in
the program This parameter provides a measurement of program complexity,
independently of the program language in which it was implemented.
I=V/D
 Programming Time – Shows time (in minutes) needed to translate the existing
algorithm into implementation in the specified program language.
T = E / (f * S)
The concept of the processing rate of the human brain, developed by the psychologist
John Stroud, is also used. Stoud defined a moment as the time required by the human
brain requires to carry out the most elementary decision. The Stoud number S is
therefore Stoud’s moments per second with:
5 <= S <= 20. Halstead uses 18. The value of S has been empirically developed from
psychological reasoning, and its recommended value for programming applications is
18.
Stroud number S = 18 moments / second
seconds-to-minutes factor f = 60
Advantages of Halstead Metrics:
 It is simple to calculate.
 It measures overall quality of the programs.
 It predicts the rate of error.
 It predicts maintenance effort.
 It does not require the full analysis of programming structure.
 It is useful in scheduling and reporting projects.
 It can be used for any programming language.
 Easy to use: The metrics are simple and easy to understand, and can be calculated
quickly using automated tools.
 Quantitative measure: The metrics provide a quantitative measure of the complexity
and effort required to develop and maintain a software program, which can be useful
for project planning and estimation.
 Language independent: The metrics can be used for different programming languages
and development environments.
 Standardization: The metrics provide a standardized way to compare and evaluate
different software programs.

Disadvantages of Halstead Metrics:

 It depends on the complete code.

 It has no use as a predictive estimating model.
 Limited scope: The metrics focus only on the complexity and effort required to
develop and maintain a software program, and do not take into account other
important factors such as reliability, maintainability, and usability.
 Limited applicability: The metrics may not be applicable to all types of software
programs, such as those with a high degree of interactivity or real-time requirements.
 Limited accuracy: The metrics are based on a number of assumptions and
simplifications, which may limit their accuracy in certain situations.