Software Design is the process of transforming user requirements into a suitable form, which

helps the programmer in software coding and implementation. During the software design
phase, the design document is produced, based on the customer requirements as
documented in the SRS document. Hence, this phase aims to transform the SRS document
into a design document.

The following items are designed and documented during the design phase:

1. Different modules are required.

2. Control relationships among modules.

3. Interface among different modules.

4. Data structure among the different modules.

5. Algorithms are required to be implemented among the individual modules.

Objectives of Software Design

1. Correctness: A good design should be correct i.e., it should correctly implement all
the functionalities of the system.

2. Efficiency: A good software design should address the resources, time, and cost
optimization issues.

3. Flexibility: A good software design should have the ability to adapt and
accommodate changes easily. It includes designing the software in a way, that allows
for modifications, enhancements, and scalability without requiring significant rework
or causing major disruptions to the existing functionality.

4. Understandability: A good design should be easily understandable, it should be

modular, and all the modules are arranged in layers.

5. Completeness: The design should have all the components like data structures,
modules, external interfaces, etc.

6. Maintainability: A good software design aims to create a system that is easy to

understand, modify, and maintain over time. This involves using modular and well-
structured design principles e.g.,(employing appropriate naming conventions and
providing clear documentation). Maintainability in Software and design also enables
developers to fix bugs, enhance features, and adapt the software to changing
requirements without excessive effort or introducing new issues.

Design Modeling Principles. The software design model is analogous to an architect’s plans
for a house. It begins by representing the totality of the thing to be built (e.g., a three-
dimensional rendering of the house) and slowly refines the thing to provide guidance for
constructing each detail (e.g., the plumbing layout). Similarly, the design model that is
created for software provides a variety of different views of the system. There is no shortage
of methods for deriving the various elements of a software design. Some methods are data
driven, allowing the data structure to dictate the program architecture and the resultant
processing components. Others are pattern driven, using information about the problem
domain (the requirements model) to develop architectural styles and processing patterns.
Still others are object oriented, using problem domain objects as the driver for the creation
of data structures and the methods that manipulate them. Yet all embrace a set of design
principles that can be applied regardless of the method that is used:

Principle 1. Design should be traceable to the requirements model. The requirements

model describes the information domain of the problem, user-visible functions, system
behaviour, and a set of requirements classes that package business objects with the
methods that service them. The design model translates this information into an
architecture, a set of subsystems that implement major functions, and a set of components
that are the realization of requirements classes. The elements of the design model should be
traceable to the requirements model.

Principle 2. Always consider the architecture of the system to be built. Software

architecture (Chapter 9) is the skeleton of the system to be built. It affects interfaces, data
structures, program control flow and behavior, the manner in which testing can be
conducted, the maintainability of the resultant system, and much more. For all of these
reasons, design should start with architectural considerations. Only after the architecture
has been established should component-level issues be considered.

Principle 3. Design of data is as important as design of processing functions. Data design is

an essential element of architectural design. The manner in which data objects are realized
within the design cannot be left to chance. A well-structured data design helps to simplify
program flow, makes the design and implementation of software components easier, and
makes overall processing more efficient.

Principle 4. Interfaces (both internal and external) must be designed with care. The
manner in which data flows between the components of a system has much to do with
processing efficiency, error propagation, and design simplicity. A well-designed interface
makes integration easier and assists the tester in validating component functions.

Principle 5. User interface design should be tuned to the needs of the end user. However,
in every case, it should stress ease of use. The user interface is the visible manifestation of
the software. No matter how sophisticated its internal functions, no matter how
comprehensive its data structures, no matter how well designed its architecture, a poor
interface design often leads to the perception that the software is “bad.”

Principle 6. Component-level design should be functionally independent. Functional

independence is a measure of the “single-mindedness” of a software component. The
functionality that is delivered by a component should be cohesive—that is, it should focus
on one and only one function or subfunction.
Principle 7. Components should be loosely coupled to one another and to the external
environment. Coupling is achieved in many ways— via a component interface, by
messaging, through global data. As the level of coupling increases, the likelihood of error
propagation also increases and the overall maintainability of the software decreases.
Therefore, component coupling should be kept as low as is reasonable.

Principle 8. Design representations (models) should be easily understandable. The purpose

of design is to communicate information to practitioners who will generate code, to those
who will test the software, and to others who may maintain the software in the future. If the
design is difficult to understand, it will not serve as an effective communication medium.

Principle 9. The design should be developed iteratively. With each iteration, the designer
should strive for greater simplicity. Like almost all creative activities, design occurs iteratively.
The first iterations work to refine the design and correct errors, but later iterations should
strive to make the design as simple as is possible.

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.

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.

Cohesion refers to the degree to which elements within a module work together to fulfill a
single, well-defined purpose. High cohesion means that elements are closely related and
focused on a single purpose, while low cohesion means that elements are loosely related
and serve multiple purposes.
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.

Differences between Coupling and Cohesion

The differences between cohesion and coupling are given below:

Aspect Cohesion Coupling

Coupling refers to the degree of

Cohesion refers to the degree to interdependence between software
which elements within a module modules. High coupling means that
work together to fulfill a single, modules are closely connected and
well-defined purpose. changes in one module may affect
Definition other modules.

Module Cohesion is the concept of an Coupling is the concept of inter-

Dependency intro-module. module.

Cohesion represents the Coupling represents the

Purpose relationship within a module. relationships between modules.

Quality Increasing cohesion is good for Increasing coupling is avoided for

Aspect Cohesion Coupling

software. software.

Cohesion represents the Coupling represents the

Focus functional strength of modules. independence among modules.

Highly cohesive gives the best Whereas loosely coupling gives the
Relationship software. best software.

In cohesion, the module focuses In coupling, modules are connected

Example on a single thing. to the other modules.

Cohesion is created between the Coupling is created between two

Creation same module. different modules.

Types of Cohesion Types of Coupling

1. Functional Cohesion. 1. Data Coupling

2. Procedural Cohesion. 2. Stamp Coupling

3. Temporal Cohesion. 3. Control Coupling

4. Sequential Cohesion. 4. External Coupling

5. Layer Cohesion. 5. Common Coupling

Types 6. Communication Cohesion. 6. Content Couplin