Software Design

Software design is a mechanism to transform user requirements into some suitable

form, which helps the programmer in software coding and implementation. It deals
with representing the client's requirement, as described in SRS (Software
Requirement Specification) document, into a form, i.e., easily implementable using
programming language.

The software design phase is the first step in SDLC (Software Design Life Cycle),
which moves the concentration from the problem domain to the solution domain. In
software design, we consider the system to be a set of components or modules with
clearly defined behaviors & boundaries.

Objectives of Software Design

Following are the purposes of Software design:
 1. Correctness: Software design should be correct as per requirement.
2. Completeness: The design should have all components like data structures,
modules, and external interfaces, etc.
3. Efficiency: Resources should be used efficiently by the program.
4. Flexibility: Able to modify on changing needs.
5. Consistency: There should not be any inconsistency in the design.
6. Maintainability: The design should be so simple so that it can be easily
maintainable by other designers.

Software Design Principles

Software design principles are concerned with providing means to handle the
complexity of the design process effectively. Effectively managing the complexity will
not only reduce the effort needed for design but can also reduce the scope of
introducing errors during design.

Following are the principles of Software

Design
Problem Partitioning
For small problem, we can handle the entire problem at once but for the significant
problem, divide the problems and conquer the problem it means to divide the
problem into smaller pieces so that each piece can be captured separately.

For software design, the goal is to divide the problem into manageable pieces.

Benefits of Problem Partitioning

1. Software is easy to understand
2. Software becomes simple
3. Software is easy to test
4. Software is easy to modify
5. Software is easy to maintain
6. Software is easy to expand

These pieces cannot be entirely independent of each other as they together form the
system. They have to cooperate and communicate to solve the problem. This
communication adds complexity.

Note: As the number of partition increases = Cost of partition and complexity

increases

Abstraction
An abstraction is a tool that enables a designer to consider a component at an
abstract level without bothering about the internal details of the implementation.
Abstraction can be used for existing element as well as the component being
designed.

Here, there are two common abstraction mechanisms

1. Functional Abstraction
2. Data Abstraction

Functional Abstraction
i. A module is specified by the method it performs.
ii. The details of the algorithm to accomplish the functions are not visible to the user of
the function.

Functional abstraction forms the basis for Function oriented design approaches.

Data Abstraction

Details of the data elements are not visible to the users of data. Data Abstraction
forms the basis for Object Oriented design approaches.

AD

Modularity
Modularity specifies to the division of software into separate modules which are
differently named and addressed and are integrated later on in to obtain the
completely functional software. It is the only property that allows a program to be
intellectually manageable. Single large programs are difficult to understand and read
due to a large number of reference variables, control paths, global variables, etc.

The desirable properties of a modular system are:

o Each module is a well-defined system that can be used with other applications.
o Each module has single specified objectives.
o Modules can be separately compiled and saved in the library.
o Modules should be easier to use than to build.
o Modules are simpler from outside than inside.
Advantages and Disadvantages of Modularity

In this topic, we will discuss various advantage and disadvantage of Modularity.

Advantages of Modularity

There are several advantages of Modularity

o It allows large programs to be written by several or different people

o It encourages the creation of commonly used routines to be placed in the library and
used by other programs.
o It simplifies the overlay procedure of loading a large program into main storage.
o It provides more checkpoints to measure progress.
o It provides a framework for complete testing, more accessible to test
o It produced the well designed and more readable program.

AD

Disadvantages of Modularity

There are several disadvantages of Modularity

o Execution time maybe, but not certainly, longer

o Storage size perhaps, but is not certainly, increased
o Compilation and loading time may be longer
o Inter-module communication problems may be increased
o More linkage required, run-time may be longer, more source lines must be written,
and more documentation has to be done

Modular Design

Modular design reduces the design complexity and results in easier and faster
implementation by allowing parallel development of various parts of a system. We
discuss a different section of modular design in detail in this section:

1. Functional Independence: Functional independence is achieved by developing

functions that perform only one kind of task and do not excessively interact with
other modules. Independence is important because it makes implementation more
accessible and faster. The independent modules are easier to maintain, test, and
reduce error propagation and can be reused in other programs as well. Thus,
functional independence is a good design feature which ensures software quality.
AD

It is measured using two criteria:

o Cohesion: It measures the relative function strength of a module.

o Coupling: It measures the relative interdependence among modules.

2. Information hiding: The fundamental of Information hiding suggests that

modules can be characterized by the design decisions that protect from the others,
i.e., In other words, modules should be specified that data include within a module is
inaccessible to other modules that do not need for such information.

The use of information hiding as design criteria for modular system provides the
most significant benefits when modifications are required during testing's and later
during software maintenance. This is because as most data and procedures are
hidden from other parts of the software, inadvertent errors introduced during
modifications are less likely to propagate to different locations within the software.

Strategy of Design
A good system design strategy is to organize the program modules in such a
method that are easy to develop and latter too, change. Structured design methods
help developers to deal with the size and complexity of programs. Analysts generate
instructions for the developers about how code should be composed and how pieces
of code should fit together to form a program.

To design a system, there are two possible approaches:

AD

1. Top-down Approach
2. Bottom-up Approach

1. Top-down Approach: This approach starts with the identification of the main
components and then decomposing them into their more detailed sub-components.
2. Bottom-up Approach: A bottom-up approach begins with the lower details and
moves towards up the hierarchy, as shown in fig. This approach is suitable in case of
an existing system.

Software Design Process – Software

Engineering



The design phase of software development deals with transforming the customer
requirements as described in the SRS documents into a form implementable using a
programming language. The software design process can be divided into the following
three levels or phases of design:
1. Interface Design
2. Architectural Design
 3. Detailed Design
Elements of a System
1. Architecture: This is the conceptual model that defines the structure,
behavior, and views of a system. We can use flowcharts to represent and
illustrate the architecture.
2. Modules: These are components that handle one specific task in a system.
A combination of the modules makes up the system.
3. Components: This provides a particular function or group of related
functions. They are made up of modules.
4. Interfaces: This is the shared boundary across which the components of a
system exchange information and relate.
5. Data: This is the management of the information and data flow.

Software Design Process

Interface Design
Interface design is the specification of the interaction between a system and its
environment. This phase proceeds at a high level of abstraction with respect to the
inner workings of the system i.e, during interface design, the internal of the systems
are completely ignored, and the system is treated as a black box. Attention is focused
on the dialogue between the target system and the users, devices, and other systems
with which it interacts. The design problem statement produced during the problem
analysis step should identify the people, other systems, and devices which are
collectively called agents.
Interface design should include the following details:
1. Precise description of events in the environment, or messages from agents
to which the system must respond.
2. Precise description of the events or messages that the system must produce.
3. Specification of the data, and the formats of the data coming into and going
out of the system.
4. Specification of the ordering and timing relationships between incoming
events or messages, and outgoing events or outputs.
Architectural Design
Architectural design is the specification of the major components of a system, their
responsibilities, properties, interfaces, and the relationships and interactions between
them. In architectural design, the overall structure of the system is chosen, but the
internal details of major components are ignored. Issues in architectural design
includes:
1. Gross decomposition of the systems into major components.
2. Allocation of functional responsibilities to components.
3. Component Interfaces.
4. Component scaling and performance properties, resource consumption
properties, reliability properties, and so forth.
5. Communication and interaction between components.
The architectural design adds important details ignored during the interface design.
Design of the internals of the major components is ignored until the last phase of the
design.
Detailed Design
Design is the specification of the internal elements of all major system components,
their properties, relationships, processing, and often their algorithms and the data
structures. The detailed design may include:
1. Decomposition of major system components into program units.
2. Allocation of functional responsibilities to units.
3. User interfaces.
4. Unit states and state changes.
5. Data and control interaction between units.
6. Data packaging and implementation, including issues of scope and visibility
of program elements.
7. Algorithms and data structures.

pattern based software design in software

engineering
Pattern-based software design in software engineering refers to the practice of using
design patterns to solve common problems and to create reusable and scalable
software solutions. Design patterns are proven solutions to recurring design problems
in software development. They provide templates or blueprints that can be applied
to various design challenges, helping developers structure their code effectively and
efficiently.

Here are key aspects of pattern-based software design:

1. **Problem Solving**: Design patterns encapsulate solutions to specific design

problems encountered during software development. They address common issues
such as object creation, structuring relationships between classes, managing
algorithms, and handling communication between objects.

2. **Reusable Solutions**: Patterns promote reusable and modular design practices.

Once a pattern is established and understood, it can be applied to different contexts
and projects. This reduces the need to reinvent the wheel for similar problems.

3. **Scalability and Flexibility**: Patterns encourage designs that are flexible and
scalable. They provide guidelines for creating software components that can evolve
and adapt to changing requirements without significant rework.

4. **Common Language**: Design patterns establish a common language and

vocabulary among developers. This facilitates communication and collaboration
within development teams, as well as sharing of design knowledge across the
software community.

5. **Classification**: Patterns are categorized into different types based on their

purpose and structure. Some common categories include creational patterns (dealing
with object creation), structural patterns (managing class composition), and
behavioral patterns (handling communication and interaction between objects).

6. **Examples of Patterns**: Examples of design patterns include Singleton (ensuring

a class has only one instance), Factory Method (deferring object instantiation to
subclasses), Observer (defining a one-to-many dependency between objects), and
MVC (Model-View-Controller for separating data, presentation, and user interaction).
By leveraging design patterns, software engineers can build robust, maintainable, and
extensible software systems that adhere to best practices and industry standards.
Understanding and applying patterns effectively requires knowledge and experience
in software design principles and methodologies.

Difference Between Architectural Style,

Architectural Patterns and Design Patterns
In software engineering, understanding the distinctions between architectural styles,
architectural patterns, and design patterns is crucial for designing robust and scalable
systems. Here’s a detailed breakdown of each concept:

### Architectural Style

**Definition**:

An architectural style is a high-level, abstract set of principles and guidelines for

structuring a software system. It defines the overall structure and organization of the
system, focusing on the relationships and interactions between components.

**Key Characteristics**:

- **Scope**: Broad and high-level.

- **Focus**: The overall system structure and its components' interaction.

- **Purpose**: To provide a framework within which specific system architectures

can be designed.

- **Examples**:
 - **Client-Server**: Divides the system into two major components: clients
(requesters of services) and servers (providers of services).

- **Layered (n-tier)**: Organizes the system into layers, each with specific
responsibilities, promoting separation of concerns.

- **Event-Driven**: Uses events as the primary means of communication between

decoupled components.

- **Microservices**: Decomposes a system into a collection of loosely coupled

services that can be developed, deployed, and scaled independently.

### Architectural Patterns

**Definition**:

An architectural pattern provides a reusable solution to a common problem

encountered within a given context in software architecture. It offers a more specific
approach to structuring systems compared to architectural styles.

**Key Characteristics**:

- **Scope**: More detailed and specific than architectural styles, but still high-level.

- **Focus**: Solving a particular architectural problem or challenge.

- **Purpose**: To provide a template or best practice for addressing specific

architectural concerns.

- **Examples**:

- **Model-View-Controller (MVC)**: Separates the application into three

interconnected components to separate internal representations of information from
the ways that information is presented and accepted.
 - **Repository**: Centralizes data access logic to handle data storage and retrieval
concerns.

- **Broker**: Manages communication and coordination between multiple clients

and servers.

- **Pipe and Filter**: Breaks down a task into a series of processing steps (filters)
connected by data streams (pipes).

### Design Patterns

**Definition**:

Design patterns are solutions to recurring design problems at a more granular level,
typically within the scope of individual components or classes in the system.

**Key Characteristics**:

- **Scope**: Detailed and specific, focusing on individual parts of the system rather
than the system as a whole.

- **Focus**: Addressing specific design issues related to object creation, interaction,

and composition.

- **Purpose**: To provide a common vocabulary and proven solutions for recurring

design problems.

- **Examples**:

- **Creational Patterns**: Deal with object creation mechanisms.

- **Singleton**: Ensures a class has only one instance and provides a global point
of access to it.
 - **Factory Method**: Defines an interface for creating an object, but allows
subclasses to alter the type of object that will be created.

- **Structural Patterns**: Deal with object composition and typically identify simple
ways to realize relationships between entities.

- **Adapter**: Allows incompatible interfaces to work together.

- **Decorator**: Adds additional responsibilities to an object dynamically.

- **Behavioral Patterns**: Deal with object interaction and responsibility.

- **Observer**: Defines a one-to-many dependency between objects so that when

one object changes state, all its dependents are notified and updated automatically.

- **Strategy**: Defines a family of algorithms, encapsulates each one, and makes

them interchangeable.

### Summary

- **Architectural Style**: Broad, high-level guidelines for system structure and

interaction (e.g., client-server, layered).

- **Architectural Pattern**: Specific, high-level solutions to common architectural

problems (e.g., MVC, repository).

- **Design Pattern**: Detailed solutions to common design issues at the component

or class level (e.g., singleton, adapter).

Each of these concepts operates at different levels of abstraction and scope within the
system design process, and understanding their differences helps in applying them
appropriately to create well-structured, maintainable, and scalable software systems.

Architectural Design – Software Engineering

Last Updated : 22 Apr, 2024



The software needs an architectural design to represent the design of the software.
IEEE defines architectural design as “the process of defining a collection of
hardware and software components and their interfaces to establish the framework
for the development of a computer system.” The software that is built for
computer-based systems can exhibit one of these many architectural styles.
System Category Consists of
 A set of components(eg: a database, computational modules) that will
perform a function required by the system.
 The set of connectors will help in coordination, communication, and
cooperation between the components.
 Conditions that how components can be integrated to form the system.
 Semantic models that help the designer to understand the overall
properties of the system.
The use of architectural styles is to establish a structure for all the components of
the system.
Taxonomy of Architectural Styles
1] Data centered architectures:
 A data store will reside at the center of this architecture and is accessed
frequently by the other components that update, add, delete, or modify
the data present within the store.
 The figure illustrates a typical data-centered style. The client software
accesses a central repository. Variations of this approach are used to
transform the repository into a blackboard when data related to the client
or data of interest for the client change the notifications to client
software.
 This data-centered architecture will promote integrability. This means
that the existing components can be changed and new client components
can be added to the architecture without the permission or concern of
other clients.
 Data can be passed among clients using the blackboard mechanism.
Advantages of Data centered architecture:
 Repository of data is independent of clients
 Client work independent of each other
 It may be simple to add additional clients.
 Modification can be very easy
 Data centered architecture

2] Data flow architectures:

 This kind of architecture is used when input data is transformed into
output data through a series of computational manipulative components.
 The figure represents pipe-and-filter architecture since it uses both pipe
and filter and it has a set of components called filters connected by lines.
 Pipes are used to transmitting data from one component to the next.
 Each filter will work independently and is designed to take data input of
a certain form and produces data output to the next filter of a specified
form. The filters don’t require any knowledge of the working of
neighboring filters.
 If the data flow degenerates into a single line of transforms, then it is
termed as batch sequential. This structure accepts the batch of data and
then applies a series of sequential components to transform it.
Advantages of Data Flow architecture:
 It encourages upkeep, repurposing, and modification.
 With this design, concurrent execution is supported.
Disadvantage of Data Flow architecture:
 It frequently degenerates to batch sequential system
 Data flow architecture does not allow applications that require greater
user engagement.
 It is not easy to coordinate two different but related streams

Data Flow architecture

3] Call and Return architectures
It is used to create a program that is easy to scale and modify. Many sub-styles
exist within this category. Two of them are explained below.
 Remote procedure call architecture: This components is used to
present in a main program or sub program architecture distributed among
multiple computers on a network.
 Main program or Subprogram architectures: The main program
structure decomposes into number of subprograms or function into a
control hierarchy. Main program contains number of subprograms that
can invoke other components.

4] Object Oriented architecture

The components of a system encapsulate data and the operations that must be
applied to manipulate the data. The coordination and communication between the
components are established via the message passing.
Characteristics of Object Oriented architecture:
 Object protect the system’s integrity.
 An object is unaware of the depiction of other items.
Advantage of Object Oriented architecture:
 It enables the designer to separate a challenge into a collection of
autonomous objects.
 Other objects are aware of the implementation details of the object,
allowing changes to be made without having an impact on other objects.
5] Layered architecture
 A number of different layers are defined with each layer performing a
well-defined set of operations. Each layer will do some operations that
becomes closer to machine instruction set progressively.
 At the outer layer, components will receive the user interface operations
and at the inner layers, components will perform the operating system
interfacing(communication and coordination with OS)
 Intermediate layers to utility services and application software functions.
 One common example of this architectural style is OSI-ISO (Open
Systems Interconnection-International Organisation for Standardisation)
communication system.
Component Based Software Engineering
Last Updated : 21 Jun, 2022



Component-Based Software Engineering (CBSE) is a process that focuses on
the design and development of computer-based systems with the use of reusable
software components.
It not only identifies candidate components but also qualifies each component’s
interface, adapts components to remove architectural mismatches, assembles
components into a selected architectural style, and updates components as
requirements for the system change.
The process model for component-based software engineering occurs concurrently
with component-based development.
Component-based development:
Component-based development (CBD) is a CBSE activity that occurs in parallel
with domain engineering. Using analysis and architectural design methods, the
software team refines an architectural style that is appropriate for the analysis
model created for the application to be built.
CBSE Framework Activities:
Framework activities of Component-Based Software Engineering are as follows:
1. Component Qualification: This activity ensures that the system
architecture defines the requirements of the components for becoming a
reusable components. Reusable components are generally identified
through the traits in their interfaces. It means “the services that are given
and the means by which customers or consumers access these services ”
are defined as a part of the component interface.
 2. Component Adaptation: This activity ensures that the architecture
defines the design conditions for all components and identifies their
modes of connection. In some cases, existing reusable components may
not be allowed to get used due to the architecture’s design rules and
conditions. These components should adapt and meet the requirements of
the architecture or be refused and replaced by other, more suitable
components.
3. Component Composition: This activity ensures that the Architectural
style of the system integrates the software components and forms a
working system. By identifying the connection and coordination
mechanisms of the system, the architecture describes the composition of
the end product.
4. Component Update: This activity ensures the updation of reusable
components. Sometimes, updates are complicated due to the inclusion of
third-party (the organization that developed the reusable component may
be outside the immediate control of the software engineering
organization accessing the component currently).
What are Design Guidelines?
Design guidelines are a set of principles and recommendations intended to guide
developers and designers in creating consistent, usable, and effective software
systems. These guidelines help ensure that the design process follows best
practices and aligns with the overall objectives of the project, such as usability,
accessibility, maintainability, and performance.

### Key Characteristics of Design Guidelines

1. **Principles and Recommendations**:

- Design guidelines provide general principles that help shape the design
process, such as simplicity, consistency, and clarity.

- They also offer specific recommendations and best practices for addressing
common design challenges.

2. **Consistency**:

- Guidelines promote a uniform approach to design, ensuring that all parts of

the system follow a coherent style and structure.
 - This consistency is crucial for usability, as it helps users understand and
navigate the system more easily.

3. **Usability and Accessibility**:

- Effective design guidelines emphasize the importance of creating user-friendly

interfaces that are easy to navigate and interact with.

- They also address accessibility, ensuring that the system is usable by people
with a wide range of abilities and disabilities.

4. **Maintainability**:

- Guidelines often include recommendations for making the system easier to

maintain and extend, such as using modular design and clear, well-documented
code.

5. **Performance**:

- They may also cover performance considerations, ensuring that the system is
efficient and responsive.

### Examples of Design Guidelines

1. **User Interface (UI) Design Guidelines**:

- **Simplicity**: Keep the interface simple and uncluttered, avoiding

unnecessary elements that do not add value to the user.

- **Consistency**: Use consistent design patterns, colors, and typography

throughout the application to create a cohesive experience.

- **Feedback**: Provide immediate and clear feedback for user actions to

ensure users understand the results of their interactions.

- **Accessibility**: Design for inclusivity by supporting screen readers,

keyboard navigation, and high-contrast color schemes.
2. **Code Design Guidelines**:

- **Modularity**: Break down the system into smaller, reusable components or

modules to improve maintainability and scalability.

- **Naming Conventions**: Use clear and consistent naming conventions for

variables, functions, classes, and other code elements.

- **Documentation**: Write comprehensive documentation for the codebase,

including comments, README files, and API documentation.

- **Testing**: Implement thorough testing practices, including unit tests,

integration tests, and end-to-end tests, to ensure code quality.

3. **Architectural Design Guidelines**:

- **Layered Architecture**: Separate concerns by organizing the system into

distinct layers, such as presentation, business logic, and data access.

- **Service-Oriented Architecture**: Design the system as a collection of

services that communicate over a network, promoting scalability and flexibility.

- **Security**: Incorporate security best practices into the design, such as

input validation, authentication, and authorization mechanisms.

### Importance of Design Guidelines

- **Improved User Experience**: By following usability and accessibility

guidelines, designers can create interfaces that are intuitive and user-friendly.

- **Enhanced Collaboration**: Guidelines provide a common framework for

designers and developers, facilitating better communication and collaboration.

- **Reduced Development Time**: Consistent design practices can streamline

the development process, reducing the time and effort required to build and
maintain the system.
- **Higher Quality Software**: Adhering to best practices in design helps ensure
that the software is robust, maintainable, and scalable, leading to higher quality
outcomes.

### Conclusion

Design guidelines play a crucial role in the software development process,

providing a structured approach to creating effective and efficient systems. They
cover various aspects of design, from user interfaces to code structure and
architecture, ensuring that the final product meets the desired standards of
usability, maintainability, and performance. By following these guidelines,
developers and designers can create software that not only meets functional
requirements but also provides a positive user experience.

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.

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 Cohesion shows the relationship within the module.
between modules.

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 i.e., a cohesive component/ module focuses on a
modules 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.