Ch.

5 Analysis and Design Tools

Content:
5.1 Decision Tree and Decision Table
5.2 Data Flow Diagrams (DFD) (Up to 2nd level)
5.3 Data Dictionary
5.4 Elements of DD
5.5 Advantages and Disadvantages of DD
5.6 Input and Output Design
5.7 Structured Design Concepts
5.8 Structure Chart
5.9 Coupling and Cohesion
5.10 Compulsory Case Studies on above topics

5.1 Decision Tree and Decision Table:

 Decision Table:
 A Decision Table is a visual means for showing how a rule (or set of rules) applies to
repetitive situations.
 The DT is a tool of the programmer as well as that of the systems analyst.
 It can be used either as a substitute for the flowchart or used to supplement the
flowchart.
 When the solution to a problem involves substantial logical decisions, the various
conditions and possible actions involved can be represented in the form of table.
This table is known as Decision Table.
 The physical layout of a DT is as given below:
 Header Rule (R)
(H) Identifiers

Condition
Condition Statements
Entry
OR
Stub
Conditions
(CS)
(SE)

Action Statements Action

OR Entry
Action Stub
(AS) (AE)

Notes:
(NB)

 Components of a Decision Table:

 Condition Stub − It is in the upper left quadrant which lists all the condition to be
checked.
 Action Stub − It is in the lower left quadrant which outlines all the action to be
carried out to meet such condition.
 Condition Entry − It is in upper right quadrant which provides answers to
questions asked in condition stub quadrant.
 Action Entry − It is in lower right quadrant which indicates the appropriate action
resulting from the answers to the conditions in the condition entry quadrant.

 The entries in decision table are given by Decision Rules which define the
relationships between combinations of conditions and courses of action. In rules
section,
 Y shows the existence of a condition.
 N represents the condition, which is not satisfied.
 A blank - against action states it is to be ignored.
 X (or a check mark will do) against action states it is to be carried out
 Decision Tree:
 Decision trees are a graphical representation of decision tables.
 Their purpose is to aid the construction of decision tables.
 In fact decision tables and decision trees are means of expressing process logic.
 They my therefore be used in conjunction with or in place of flow chart or pseudo
code.

 For Example:
 A co-operative bank XYZ will grant loans under the following conditions:
1. If a customer has an account with the bank and has no loan outstanding, then
loan will be granted.
2. If a customer has an account with the bank but some amount is outstanding
from previous loans, then loan will be granted if special management approval
is obtained.
3. Reject loan applications in all other cases.
Ans:

We can translate this into a Decision Table.

Method to Draw Decision Table:

Step – 1 List all conditions and actions.

Conditions:
1. The existence of a bank account with the Bank XYZ
2. A) The customer’s previous loan status.
B) Management approval
Actions:
1. Grant Loan
2. Reject loan application.

Step – 2 Combine conditions which only describe the only two possibilities of a single
condition.
There are four possible combinations in this case:
 Rules Condition Action

Customer has account and no dues from previous

1 Grant Loan
loan
Customer has account and some dues are there from
2 Grant Loan
previous loan and he has management approval
Customer has account and some dues are there from Reject Loan
3
previous loan and he has no management approval application
Reject loan
4 Customer has no account
application

Note: The maximum number of rules is in general 2n where n is the number of

conditions. E.g., one condition leads 21 = 2 rules, two conditions lead of 22 = 4 rules
and so on.
However, an analysis of the conditions and actions depicted in a decision table often
shows that many rules are irrelevant. One has to use his own judgment to ward off
irrelevant rules.

Placing these in our Decision Table, we have:

(H) Decision Table R1 R2 R3 R4

C1: Customer has bank A/C Y Y Y N
C2: Customer has no dues Y N N -
(CS)
C3: Customer has management approval Y N -

(CE)

A1: Grant Loan X X - -

(AS) A2: Reject Loan application - - X X

(AE)

Note 1: Y stands for “Yes”,

N stands for “No” and
X stands for ‘Applicable’
Note 2: Now we can understand the layout of a decision table in a better way
H: This gives the decision table name of number.
R: This gives you the rule entry such as Rule 1, Rule 2, Rule 3, Rule 4, etc.
NB: In case any additional information is to be provided then it is useful.
CS: Condition Stub: There are statements which introduce on or more conditions.
These can be identified as C1, C2, C3, ……..
CE: Condition Entry: Entries that complete condition statements. Generally symbols
used for conditions entries are:
Y (Yes), N(No), > (Greater than), = (Equal to), - (Blank)
AS: Action Stub: Statements which induce one or more action. Actions can be
identified as A1, A2, A3,……..
AE: Action Entries: Entries that complete the action statements. Symbols used are:
X (applicable)
- (blank)

Types of Decision Tables:

Decision Tables are mainly of two types:
1. Limited Entry Decision Table
2. Extended Entry Decision Table.

Limited Entry Decision Table:

In a limited entry table, the entries give simple ‘Yes’ and ‘No’ answers to condition and
action statements.

Yes (Y) or
For each No (N) or
condition in the Irrelevant (-)
condition stub in the condition
entry

then it is ‘ Limited Condition entry D.

Similarly,

X (Applicable)
For each action or
in the action -(Blank)
stub in the action
entry
then it is ‘ Limited Action entry D. T.’
Note: With a limited entry table the statement of condition or action is completely
contained in the appropriate stubs themselves.

Extended Entry Decision Table:

In an extended entry decision table, the statement made in the stub portions are
incomplete.
Both the stub and entry portions of any particular row in the table must be considered
together to decide if a condition or action is relevant to a given rule .
An extended condition entry is either descriptive or in quantified form.

For Example:
The discount policy of a manufacturer producing two products:
1. Mechanical Typewriter and
2. Electronic typewriter and who has three types of customers (R) Retailers, (D)
Dealers, (I) institutions is given below.
Rules:
1. If the order is from retailer for amount up to Rs. 5000/- he allows 6% discount
2. If the order is from dealer for amount up to Rs. 5000/-, 7.5% discount is given.
3. On retail order exceeding Rs. 5000/-, 7.5 % discount is given
4. If the order exceeding for an amount exceeding Rs. 5000/-, 11% discount is allowed.
5. In all the above cases a flat discount of 7.5% is given to institutions.
6. In the case of electronic typewriter a flat discount of 6% is given regardless of amount
or customer.
Ans:
Limited Entry Decision Table for Discount Policy

Decision Table for Discount Policy R1 R2 R3 R4 R5 R6

C1: PRODUCT = 1? Y Y Y Y Y N

C2: CUSTOMER = R? Y - Y - - -

C3: CUSTOMER = D? - Y - Y - -

C4: ORDER AMOUNT <= 5000? Y Y N N - -

A1: DISCOUNT 6% X - - - - X

A2: DISCOUNT 7.5% - - - - X -

A3: DISCOUNT 7.5% - X X - - -

A4: DISCOUNT 11% - - - X - -

Extended Entry Decision Table for Discount Policy

Decision Table for Discount

R1 R2 R3 R4 R5 R6
Policy

C1: PRODUCT CODE 1 1 1 1 1 2

C2: CUSTOMER CODE R D R D I -

C3: ORDER AMOUNT <= 5000 <= 5000 >5000 > 5000 - -

DISCOUNT 6% 7.5% 7.5% 11% 7.5% 6%

Mixed Entry Decision Table for Discount Policy

Decision Table for Discount Policy R1 R2 R3 R4 R5 R6

C1: PRODUCT CODE = 1? Y Y Y Y Y N

C2: CUSTOMER CODE = R? R D R D I -

C3: ORDER AMOUNT <= 5000 Y Y N N - -

DISCOUNT 6% 7.5% 7.5% 11% 7.5% 6%

Note: Limited entry format and extended entry format can both be used in single
table for individual conditions or actions. Where a table contains both type of
format, it is called a “MIXED ENTRY D.T.”

Difference between Decision Table and Decision Tree:

Sr.
Decision Table Decision Tree
No.
Decision Trees are a graphical
Decision Tables are a tabular
1. representation of every possible
representation of conditions and actions.
outcome of a decision.
We can derive a decision table from the We cannot derive a decision tree from
2.
decision tree. the decision table.
It helps to take into account the possible
3. It helps to clarify the criteria.
relevant outcomes of the decision.
In Decision Tables, we can include more In Decision Trees, we cannot include
4.
than one ‘or’ condition. more than one ‘or’ condition.
It is used when there are small number of It is used when there are more number
5.
properties. of properties.

6. It is used for simple logic only. It can be used for complex logic as well.

7. It is constructed of rows and tables. It is constructed of branches and nodes.

 A decision tree’s objective is to provide
The goal of using a decision table is the an effective means to visualize and
8. generation of rules for structuring logic on understand a decision’s available
the basis of data entered in the table. possibilities and range of possible
outcomes.

5.2 Data Flow Diagrams (DFD):

Data Flow Diagram is a graphical aid for defining systems input, processes and outputs.
It represents flow of data through the system.
The DFDs are used in modern methods of System Analysis.
They are simple to extent that the types of symbols and rules are very few.
DFDs serve two purposes:
i) Provide a graphic tool which can be used by the analyst to explain his understanding
of the system to the user.
ii) They can be readily converted into a structured chart which can be used in design.
The use of DFDs as modeling tools was popularized by De Macro (1978) & Gane and
Sarson (1979) through their structured system analysis methodologies.

Symbols used in DFDs:

 Most DFDs use four types of symbols which represent system components such as :
External Entities, Processes, Data Flows and Data Stores.
 The use of specific items associated with each element depends on whether
Yourdon (Demacro, Weinberg, Page-jones) or Gane and Sarson approach is used.
 Symbols are as follows:
A Process:
 Here flow of data is transformed. Eg. Verify credits, update inventory file.
External Entity:
 A source or destination of data which is external to the system.
 Eg. Supplier, customer etc.
Data Flow:
 It is a packet of data. It may be in the form of document letter, telephone call etc.
Data Store:
 Any stored data but with no reference to the physical method of storing.
 Eg. Inventory master file, customer master file etc.

 Note – 1 :
 These symbols are not standardized. Different books use different symbols with
minor variations.
 Note – 2:
 The process represented by a circle is also known as “BUBBLE”. (Hence DFDs are
sometimes referred as “BUBBLE DIAGRAMS”)

The following thumb rules may be used while constructing DFDs:

 Processes should be named and numbered for easy reference.
 The direction of flow is from top to bottom and from left to right. Data
traditionally flow from the source (upper left corner) to the destination (lower
right corner) although they may flow back to the source.
 When a process is exploded into lower level details, they are numbered.
  The names of data stores, sources and destinations are written in capital letters.
Process and data flow names have the first letter of each word capitalized.

Examples:
2. DFD For Library Management System:
Level 0 DFD –

Level 1 DFD –
At this level, the system has to show or exposed with more details of processing.
The processes that are important to be carried out are:
 Book delivery
 Search by topic
List of authors, List of Titles, List of Topics, the bookshelves from which books can be
located are some information that is required for these processes. Data store is used to
represent this type of information.
Level 2 DFD –

DFD for College Management System:

 0 Level DFD – College Management System

The DFD level 0 (context diagram) portrays the systems’ abstract view or the single
process with its external parties. It depicts the overall structure as a single bubble that
comes with incoming and outgoing indicators showing input and output data.
 0 Level DFD – College Management System

This diagram serves as the main idea that reveals the main process, users, and data that
roam the system. The college system’s external entities are as follows:
 College Administrator
 Teacher
 Students

 1 Level DFD – College Management System:

The context diagram is used to derive the DFD Level 1 content, which is then split
down into sub-processes. This is to inform the programmer about the system’s
included operations and data inputs.

1 Level DFD – College Management System

The illustration demonstrates that the data processing and flow expand while the
external entities remain unchanged. When the project was completed, the revealed
external entities were the intended users.
The 1st level of the college management system DFD is composed of the following sub-
processes:
 Manage Student Information
 Assign Courses
 Assign class Rooms
 Manage Teachers
In addition to knowing the general context words, you will also be familiar with DFD
level 1. This is also a reference to how the system manages the college management
system’s inputs or data. You will also be informed of the outcomes the system generates.
Remember: These procedures are all based on the College Management System
notion.

 2 Level DFD – College Management System:

DFD level 2 describes where data inputs are routed and where they originate inside
the project. Once you know how to use a data flow diagram, you can figure out how
important it is to break down operations in more detail.

2 Level DFD – College Management System

Level 2 is the most abstract level of the data flow diagram for the college administration
system. Also emphasized is data management, including data storage (database).
Databases were responsible for storing the data that entered the system and serving as
the source of data outputs.
Know more about the college system’s databases through the College Management
System Project Entity Relationship Diagram.
The system’s database (data store) includes the following:
 Student Database
 Class Rooms Database
 Teachers Database
 Courses Database
DFD level 2 does not only reveal the system analysis and design but also reveals the
precise destination of data that passes through the system.
As can be seen, as the levels of data flow diagrams are constructed, the relationships
between the transactions and data expand and get more explicit.
Note: The last level (DFD level 2) is not required all the time. It is only needed
when more of the included sub-processes need to be talked about. Moreover,
everything in the Data Flow Diagram is based on the idea of the College
Management System.

5.3 Data Dictionary:

A data dictionary is a file or a set of files that includes a database's metadata. The data
dictionary hold records about other objects in the database, such as data ownership,
data relationships to other objects, and other data. The data dictionary is an essential
component of any relational database. Ironically, because of its importance, it is
invisible to most database users. Typically, only database administrators interact with
the data dictionary.

Features of Data Dictionary:

Here, we will discuss some features of the data dictionary as follows.
 It helps in designing test cases and designing the software.
 It is very important for creating an order list from a subset of the items list.
  It is very important for creating an order list from a complete items list.
 The data dictionary is also important to find the specific data item object from
the list.

Uses of Data Dictionary:

Here, we will discuss some use cases of the data dictionary as follows:
 Used for creating the ordered list of data items
 Used for creating the ordered list of a subset of the data items
 Used for Designing and testing software in Software Engineering
 Used for finding data items from a description in Software Engineering

Importance of Data Dictionary:

 It provides developers with standard terminology for all data.
 It provides developers to use different terms to refer to the same data.
 It provides definitions for different data
 Query handling is facilitated if a data dictionary is used in RDMS.

5.4 Elements of DD:

The Elements of data dictionary are as follows:

 Name of the data item

 Aliases
 Description/purpose
 Related data items
 Range of values
 Data structure definition/Forms
Name of Data item: The name of the data item is self-explanatory.
Aliases: It include other names by which this data item is called DEO for Data Entry
Operator and DR for Deputy Registrar.
Description/purpose: It is a textual description of what the data item is used for or
why it exists.
Related data items: Related data items capture relationships between data items e.g.,
total_marks must always equal to internal_marks plus external_marks.
Range of values: Range of values records all possible values, e.g. total marks must be
positive and between 0 to 100.
Data structure Forms: Data flows capture the name of processes that generate or
receive the data items. If the data item is primitive, then data structure form captures
the physical structures of the data item. If the data is itself a data aggregate, then data
structure form capture the composition of the data items in terms of other data items.

5.5 Advantages and Disadvantages of DD:

Advantages of Data Dictionary:
 Consistency and Standardization: A data dictionary helps to ensure that all
data elements and attributes are consistently defined and named across the
organization, promoting standardization and consistency in data management
practices.
 Data Quality: A data dictionary can help improve data quality by providing a
single source of truth for data definitions, allowing users to easily verify the
accuracy and completeness of data.
 Data Integration: A data dictionary can facilitate data integration efforts by
providing a common language and framework for understanding data elements
and their relationships across different systems.
 Improved Collaboration: A data dictionary can help promote collaboration
between business and technical teams by providing a shared understanding of
data definitions and structures, reducing misunderstandings and communication
gaps.
 Improved Efficiency: A data dictionary can help improve efficiency by reducing
the time and effort required to define, document, and manage data elements and
attributes.

Disadvantages of Data Dictionary:

 Implementation and Maintenance Costs: Implementing and maintaining a
data dictionary can be costly, requiring significant resources in terms of time,
money, and personnel.
 Complexity: A data dictionary can be complex and difficult to manage,
particularly in large organizations with multiple systems and data sources.
  Resistance to Change: Some stakeholders may be resistant to using a data
dictionary, either due to a lack of understanding or because they prefer to use
their own terminology or definitions.
 Data Security: A data dictionary can contain sensitive information, and
therefore, proper security measures must be in place to ensure that
unauthorized users do not access or modify the data.
 Data Governance: A data dictionary requires strong data governance practices
to ensure that data elements and attributes are managed effectively and
consistently across the organization.

5.6 Input and Output Design:

 Input Design:

In an information system, input is the raw data that is processed to produce output.
During the input design, the developers must consider the input devices such as PC,
MICR, OMR, etc.
Therefore, the quality of system input determines the quality of system output. Well-
designed input forms and screens have following properties −
 It should serve specific purpose effectively such as storing, recording, and
retrieving the information.
 It ensures proper completion with accuracy.
 It should be easy to fill and straightforward.
 It should focus on user’s attention, consistency, and simplicity.
 All these objectives are obtained using the knowledge of basic design principles
regarding −
 What are the inputs needed for the system?
 How end users respond to different elements of forms and screens.

Objectives for Input Design:

The objectives of input design are −
 To design data entry and input procedures
 To reduce input volume
  To design source documents for data capture or devise other data capture
methods
 To design input data records, data entry screens, user interface screens, etc.
 To use validation checks and develop effective input controls.

Data Input Methods:

It is important to design appropriate data input methods to prevent errors while
entering data. These methods depend on whether the data is entered by customers in
forms manually and later entered by data entry operators, or data is directly entered by
users on the PCs.
 A system should prevent user from making mistakes by −
 Clear form design by leaving enough space for writing legibly.
 Clear instructions to fill form.
 Clear form design.
 Reducing key strokes.
 Immediate error feedback.

Some of the popular data input methods are −

 Batch input method (Offline data input method)
 Online data input method
 Computer readable forms
 Interactive data input

Input Integrity Controls

Input integrity controls include a number of methods to eliminate common input errors
by end-users. They also include checks on the value of individual fields; both for format
and the completeness of all inputs.
Audit trails for data entry and other system operations are created using transaction
logs which gives a record of all changes introduced in the database to provide security
and means of recovery in case of any failure.
 Output Design:

The design of output is the most important task of any system. During output design,
developers identify the type of outputs needed, and consider the necessary output
controls and prototype report layouts.
Objectives of Output Design
The objectives of output design are −
 To develop output design that serves the intended purpose and eliminates the
production of unwanted output.
 To develop the output design that meets the end users requirements.
 To deliver the appropriate quantity of output.
 To form the output in appropriate format and direct it to the right person.
 To make the output available on time for making good decisions.
Let us now go through various types of outputs −

External Outputs:

Manufacturers create and design external outputs for printers. External outputs enable
the system to leave the trigger actions on the part of their recipients or confirm actions
to their recipients.

Some of the external outputs are designed as turnaround outputs, which are
implemented as a form and re-enter the system as an input.

Internal outputs:

Internal outputs are present inside the system, and used by end-users and managers.
They support the management in decision making and reporting.
There are three types of reports produced by management information −
 Detailed Reports − They contain present information which has almost no
filtering or restriction generated to assist management planning and control.
 Summary Reports − They contain trends and potential problems which are
categorized and summarized that are generated for managers who do not want
details.
 Exception Reports − They contain exceptions, filtered data to some condition or
standard before presenting it to the manager, as information.
Output Integrity Controls:
Output integrity controls include routing codes to identify the receiving system, and
verification messages to confirm successful receipt of messages that are handled by
network protocol.
Printed or screen-format reports should include a date/time for report printing and the
data. Multipage reports contain report title or description, and pagination. Pre-printed
forms usually include a version number and effective date.

5.7 Structured Design Concepts:

Structured design is a conceptualization of problem into several well-organized
elements of solution. It is basically concerned with the solution design. Benefit of
structured design is, it gives better understanding of how the problem is being solved.
Structured design also makes it simpler for designer to concentrate on the problem
more accurately.
Structured design is mostly based on ‘divide and conquer’ strategy where a problem is
broken into several small problems and each small problem is individually solved until
the whole problem is solved.
The small pieces of problem are solved by means of solution modules. Structured design
emphasis that these modules be well organized in order to achieve precise solution.
These modules are arranged in hierarchy. They communicate with each other. A good
structured design always follows some rules for communication among multiple
modules, namely -
Cohesion - grouping of all functionally related elements.
Coupling - communication between different modules.
A good structured design has high cohesion and low coupling arrangements.

5.8 Structure Chart:

Structure Chart represent hierarchical structure of modules. It breaks down the entire
system into lowest functional modules, describe functions and sub-functions of each
module of a system to a greater detail. Structure Chart partitions the system into black
boxes (functionality of the system is known to the users but inner details are unknown).
Inputs are given to the black boxes and appropriate outputs are generated.
Modules at top level called modules at low level. Components are read from top to
bottom and left to right. When a module calls another, it views the called module as
black box, passing required parameters and receiving results.

Symbols used in construction of structured chart:

1. Module:
It represents the process or task of the system. It is of three types.
 Control Module: A control module branches to more than one sub module.
 Sub Module: Sub Module is a module which is the part (Child) of another module.
 Library Module: Library Module are reusable and invokable from any module.

2. Conditional Call:
 It represents that control module can select any of the sub module on the basis of
some condition.
3. Loop (Repetitive call of module)
 It represents the repetitive execution of module by the sub module.
 A curved arrow represents loop in the module.

 All the sub modules cover by the loop repeat execution of module.
4. Data Flow:
 It represents the flow of data between the modules. It is represented by directed
arrow with empty circle at the end.

5. Control Flow:
 It represents the flow of control between the modules. It is represented by directed
arrow with filled circle at the end.
6. Physical Storage
 Physical Storage is that where all the information are to be stored.

Example: Structure chart for an Email server

 Types of Structure Chart:

 Transform Centered Structure:

These type of structure chart are designed for the systems that receives an input which
is transformed by a sequence of operations being carried out by one module.

 Transaction Centered Structure:

These structure describes a system that processes a number of different types of

transaction.
5.9 Coupling and Cohesion:
Coupling and Cohesion are two key concepts in software engineering that are used to
measure the quality of a software system’s design.

Both coupling and cohesion are important factors in determining the maintainability,
scalability, and reliability of a software system. High coupling and low cohesion can
make a system difficult to change and test, while low coupling and high cohesion make a
system easier to maintain and improve.

 Coupling:
Coupling refers to the degree of interdependence between software modules. High
coupling means that modules are closely connected and changes in one module may
affect other modules. Low coupling means that modules are independent and changes in
one module have little impact on other modules.

Coupling is the measure of the degree of interdependence between the modules. A good
software will have low coupling.

Types of Coupling:
 Data Coupling:
If the dependency between the modules is based on the fact that they communicate by
passing only data, then the modules are said to be data coupled. In data coupling, the
components are independent of each other and communicate through data. Module
communications don’t contain tramp data. Example-customer billing system.
 Stamp Coupling:
In stamp coupling, the complete data structure is passed from one module to another
module. Therefore, it involves tramp data. It may be necessary due to efficiency factors-
this choice was made by the insightful designer, not a lazy programmer.
 Control Coupling:
If the modules communicate by passing control information, then they are said to be
control coupled. It can be bad if parameters indicate completely different behavior and
good if parameters allow factoring and reuse of functionality. Example- sort function
that takes comparison function as an argument.
 External Coupling:
In external coupling, the modules depend on other modules, external to the software
being developed or to a particular type of hardware. Ex- protocol, external file, device
format, etc.
 Common Coupling:
The modules have shared data such as global data structures. The changes in global data
mean tracing back to all modules which access that data to evaluate the effect of the
change. So it has got disadvantages like difficulty in reusing modules, reduced ability to
control data accesses, and reduced maintainability.
 Content Coupling:
In a content coupling, one module can modify the data of another module, or control
flow is passed from one module to the other module. This is the worst form of coupling
and should be avoided.
 Temporal Coupling:
Temporal coupling occurs when two modules depend on the timing or order of events,
such as one module needing to execute before another. This type of coupling can result
in design issues and difficulties in testing and maintenance.
 Sequential Coupling:
Sequential coupling occurs when the output of one module is used as the input of
another module, creating a chain or sequence of dependencies. This type of coupling can
be difficult to maintain and modify.
 Communicational Coupling:
Communicational coupling occurs when two or more modules share a common
communication mechanism, such as a shared message queue or database. This type of
coupling can lead to performance issues and difficulty in debugging.
 Functional Coupling:
Functional coupling occurs when two modules depend on each other’s functionality,
such as one module calling a function from another module. This type of coupling can
result in tightly-coupled code that is difficult to modify and maintain.
 Data-Structured Coupling:
Data-structured coupling occurs when two or more modules share a common data
structure, such as a database table or data file. This type of coupling can lead to
difficulty in maintaining the integrity of the data structure and can result in
performance issues.
 Interaction Coupling:
Interaction coupling occurs due to the methods of a class invoking methods of other
classes. Like with functions, the worst form of coupling here is if methods directly
access internal parts of other methods. Coupling is lowest if methods communicate
directly through parameters.
 Component Coupling:
Component coupling refers to the interaction between two classes where a class has
variables of the other class. Three clear situations exist as to how this can happen.
A class C can be component coupled with another class C1, if C has an instance variable
of type C1, or C has a method whose parameter is of type C1,or if C has a method which
has a local variable of type C1. It should be clear that whenever there is component
coupling, there is likely to be interaction coupling.
 Cohesion:
Cohesion is a measure of the degree to which the elements of the module are
functionally related.
It is the degree to which all elements directed towards performing a single task are
contained in the component.
Basically, cohesion is the internal glue that keeps the module together. A good software
design will have high cohesion.
Types of Cohesion:
 Functional Cohesion:
Every essential element for a single computation is contained in the component. A
functional cohesion performs the task and functions. It is an ideal situation.
 Sequential Cohesion:
An element outputs some data that becomes the input for other element, i.e., data flow
between the parts. It occurs naturally in functional programming languages.
 Communicational Cohesion:
Two elements operate on the same input data or contribute towards the same output
data. Example- update record in the database and send it to the printer.
 Procedural Cohesion:
Elements of procedural cohesion ensure the order of execution. Actions are still weakly
connected and unlikely to be reusable. Ex- calculate student GPA, print student record,
calculate cumulative GPA, print cumulative GPA.
 Temporal Cohesion:
The elements are related by their timing involved. A module connected with temporal
cohesion all the tasks must be executed in the same time span. This cohesion contains
the code for initializing all the parts of the system. Lots of different activities occur, all at
unit time.
 Logical Cohesion:
The elements are logically related and not functionally. Ex- A component reads inputs
from tape, disk, and network. All the code for these functions is in the same component.
Operations are related, but the functions are significantly different.
 Coincidental Cohesion:
The elements are not related(unrelated). The elements have no conceptual relationship
other than location in source code. It is accidental and the worst form of cohesion. Ex-
print next line and reverse the characters of a string in a single component.
 Procedural Cohesion:
This type of cohesion occurs when elements or tasks are grouped together in a module
based on their sequence of execution, such as a module that performs a set of related
procedures in a specific order. Procedural cohesion can be found in structured
programming languages.
 Communicational Cohesion:
Communicational cohesion occurs when elements or tasks are grouped together in a
module based on their interactions with each other, such as a module that handles all
interactions with a specific external system or module. This type of cohesion can be
found in object-oriented programming languages.
 Temporal Cohesion:
Temporal cohesion occurs when elements or tasks are grouped together in a module
based on their timing or frequency of execution, such as a module that handles all
periodic or scheduled tasks in a system. Temporal cohesion is commonly used in real-
time and embedded systems.
 Informational Cohesion:
Informational cohesion occurs when elements or tasks are grouped together in a
module based on their relationship to a specific data structure or object, such as a
module that operates on a specific data type or object. Informational cohesion is
commonly used in object-oriented programming.
 Functional Cohesion:
This type of cohesion occurs when all elements or tasks in a module contribute to a
single well-defined function or purpose, and there is little or no coupling between the
elements. Functional cohesion is considered the most desirable type of cohesion as it
leads to more maintainable and reusable code.
 Layer Cohesion:
Layer cohesion occurs when elements or tasks in a module are grouped together based
on their level of abstraction or responsibility, such as a module that handles only low-
level hardware interactions or a module that handles only high-level business logic.
Layer cohesion is commonly used in large-scale software systems to organize code into
manageable layers.
Advantages of low coupling:
 Improved maintainability:
Low coupling reduces the impact of changes in one module on other modules, making it
easier to modify or replace individual components without affecting the entire system.
 Enhanced modularity:
Low coupling allows modules to be developed and tested in isolation, improving the
modularity and reusability of code.
 Better scalability:
Low coupling facilitates the addition of new modules and the removal of existing ones,
making it easier to scale the system as needed.

Advantages of high cohesion:

 Improved readability and understandability:
High cohesion results in clear, focused modules with a single, well-defined purpose,
making it easier for developers to understand the code and make changes.
 Better error isolation:
High cohesion reduces the likelihood that a change in one part of a module will affect
other parts, making it easier to isolate and fix errors.
 Improved reliability:
High cohesion leads to modules that are less prone to errors and that function more
consistently, leading to an overall improvement in the reliability of the system.
Disadvantages of high coupling:
 Increased complexity:
High coupling increases the interdependence between modules, making the system
more complex and difficult to understand.
 Reduced flexibility:
High coupling makes it more difficult to modify or replace individual components
without affecting the entire system.
 Decreased modularity:
High coupling makes it more difficult to develop and test modules in isolation, reducing
the modularity and reusability of code.
Disadvantages of low cohesion:
 Increased code duplication:
Low cohesion can lead to the duplication of code, as elements that belong together are
split into separate modules.
 Reduced functionality:
Low cohesion can result in modules that lack a clear purpose and contain elements that
don’t belong together, reducing their functionality and making them harder to maintain.
 Difficulty in understanding the module:
Low cohesion can make it harder for developers to understand the purpose and
behavior of a module, leading to errors and a lack of clarity.