What is Software Design?

Software design is a method that converts user requirements into a

suitable form for the programmer to employ in software coding and
implementation. It is concerned with converting the client's
requirements as defined in the SRS (Software Requirement
Specification) document into a form that can be easily implemented
using a programming language. A good software designer needs to
have knowledge of what software engineering is.

The software design phase is the first step in the SDLC (Software
Development Life Cycle) that shifts the focus from the problem
domain to the solution domain. In software design, the system is
viewed as a collection of components or modules with clearly defined
behaviors and bounds.

Objectives of Software Design

The following objectives describe what is software design in software
engineering.
Levels of Software Design

There are three levels of software design.

Architectural Design
A system's architecture can be defined as the system's overall
structure and how that structure offers conceptual integrity to the
system. The architectural design characterizes the software as a
system with numerous interconnected components. The designers
acquire an overview of the proposed solution domain at this level.
High-level Design
The high-level design deconstructs the architectural design's 'single
entity-multiple component' notion into a less abstract perspective of
subsystems and modules, depicting their interaction with one
another. High-level design is concerned with how the system and its
components can be implemented as modules. It recognizes the
modular structure of each subsystem, as well as their relationship and
interaction with one another.
Detailed Design
After the high-level design is completed, the detailed design begins.
Each module is extensively investigated at this level of software
design to establish the data structures and algorithms to be used.
Finally, a module specification document is used to document the
stage's outcome. It defines the logical structure of each module as
well as its interfaces with other modules.

Software Design Concepts

Let us look at some software design concepts that assist a software
engineer in creating the model of the system or software product to
be developed or built. The following ideas should be grasped before
designing a software system.
Abstraction
One of the fundamental concepts of object-oriented programming
(OOP) languages is an abstraction. Its primary purpose is to deal with
complexity by concealing internal details from the user. This allows
the user to build more complicated logic on top of the offered
abstraction without having to understand or even consider all the
hidden complexity.
Modularity

Modularity refers to breaking a system or project into smaller sections

to lessen the system's or project's complexity. Similarly, modularity in
design refers to the division of a system into smaller elements that
can be built independently and then used in multiple systems to
execute different purposes. Sometimes to deal with Monolithic
software, which is difficult to grasp for software engineers, it is
required to partition the software into components known as
modules. As a result, modularity in design has become a trend that is
also essential.
Architecture
A system's software architecture represents the design decisions
linked to the general structure and behavior of the
system. Architecture assists stakeholders in comprehending and
analyzing how the system will attain critical characteristics such
as modifiability, availability, and security. It specifies how
components of a software system are constructed, as well as their
relationships and communication. It acts as a software application
blueprint and a development foundation for the developer team.
Refinement
Refinement means removing any impurities and improving the quality
of something. The software design refinement idea is a process of
building or presenting the software or system in a detailed manner,
which implies elaborating on a system or software. In addition,
refinement is essential for identifying and correcting any possible
errors.
Design Patterns
A Software Design Pattern is a general, reusable solution to a
commonly occurring problem within a given context in software
design. They are templates to solve common software engineering
problems, representing some of the finest practices experienced
object-oriented software engineers utilize. A design pattern
systematically describes and explains a general design that handles a
recurring design challenge in object-oriented systems. It discusses the
problem, the remedy, when to use it, and the repercussions. It also
provides implementation guidance and examples.
Information/Data Hiding

Simply put, information hiding implies concealing information so that

an unauthorized entity cannot access it. In software
design, information hiding is accomplished by creating modules in
such a way that information acquired or contained in one module is
concealed and cannot be accessible by other modules.

 Refactoring
Refactoring is the process of reorganizing code without affecting its
original functionality. Refactoring aims to improve internal code by
making modest changes that do not affect the code's exterior
behavior. Computer programmers and software developers refactor
code to improve the software's design, structure, and
implementation. As a result, Refactoring increases code readability
while decreasing complications. Refactoring can also assist software
engineers in locating faults or vulnerabilities in their code.
 Refactoring

Refactoring or Code Refactoring is defined as systematic process of

improving existing computer code, without adding new functionality
or changing external behaviour of the code. It is intended to change
the implementation, definition, structure of code without changing
functionality of software. It improves extensibility, maintainability,
and readability of software without changing what it actually
does. Why should we refactor our code when it works fine? The goal
of refactoring is not to add new functionality or remove an existing
one. The main goal of refactoring is to make code easier to maintain
in future and to fight technical debt. We do refactor because we
understand that getting design right in first time is hard and also you
get the following benefits from refactoring:
 Code size is often reduced
 Confusing code is restructured into simpler code

Conclusion
  Software design is the process that converts user requirements
into a suitable form for the programmer to employ in software
coding and implementation.
 It is concerned with converting the client's requirements as
defined in the SRS (Software Requirement
Specification) document into a form that can be easily
implemented using a programming language.
 In the SDLC (Software Design Life Cycle), the focus shifts from
the problem domain to the solution domain during the software
design phase. It attempts to specify how to meet the
requirements outlined in the SRS.
 The objectives of the software design process are correctness,
completeness, efficiency, flexibility, consistency, and
maintainability.

 Coupling and Cohesion in Software Engineering

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.