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.

Objectives of Software Design

Following are the purposes of Software design:

New Section 3 Page 1

 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.

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.

New Section 3 Page 2

Key Concepts in Software Design
1. Abstraction
○ Hides complex details from the user.
○ Makes it easier to build on top of simple ideas without knowing all the
underlying complexity.
2. Modularity
○ Breaks a system into smaller, independent parts (modules).
○ Reduces complexity and allows reuse across different systems.
3. Architecture
○ Defines the structure and behavior of a system.
○ Focuses on key aspects like security, scalability, and reliability.
○ Acts as a blueprint for development.
4. Refinement
○ Improves the quality of the design by eliminating errors.
○ Provides a detailed and polished version of the system.
5. Design Patterns
○ Reusable templates to solve common software problems.
○ Provides guidance on handling specific design challenges.
6. Information/Data Hiding
○ Protects sensitive data by restricting access to it.
○ Ensures that modules keep their data private.
7. Refactoring
○ Improves code structure without changing its functionality.
○ Makes code cleaner and easier to maintain.

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

New Section 3 Page 3

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
a. A module is specified by the method it performs.
b. 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.

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.
• Single large programs are difficult to understand and read due to a large number of
reference variables, control paths, global variables, etc.

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.

1. Functional Independence:

New Section 3 Page 4

 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.

It is measured using two criteria:

▪ Cohesion: It measures the relative function strength of a module.
▪ 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
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.

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:

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.

New Section 3 Page 5

What is Coupling?
Coupling refers to the degree of interdependence between different modules, classes, or
components of a software system.
It shows how closely these elements relate to each other and how much one element
depends on the behaviour, data or interfaces of another.
High coupling means strong interconnections where changes in one module can cascade
through others, while low coupling means greater independence and isolation between
modules.

Type of Coupling:

New Section 3 Page 6

Type of Coupling:
1. Content Coupling:
Modules share data directly through global variables or parameters.
This is the strongest coupling method and is not recommended because it tightly
couples the modules and makes them highly dependent on each other.

2. General Coupling:
Modules share global data or resources that are frequently used and modified by
different modules. Although not as direct as pooling content, it still represents tight
pooling through shared resources.

3. External Coupling:
Modules communicate by exchanging data through external interfaces such as
function parameters or method calls. Although external binding is more flexible than
content and general binding, it can still cause dependencies.
4. Control Coupling:
One module affects the behaviour of another by passing control information, often
through parameters. This type of connection may be less direct than a content
connection but still requires close communication.
5. Stamp Coupling:
Modules share a composite data structure such as a record or object without sharing.
Changes to the structure can affect several modules, but the connection is weaker
than in the content connection.
6. Data Coupling:
Modules share data through parameters, but there is no direct relationship between
functions. Compared to the previous types, it is a relatively loose form of connection.

7. No Coupling:
Modules work independently without direct communication. This is the ideal type of
connection to aim for as it encourages modular design and minimizes the impact of
changes.

New Section 3 Page 7

Advantages of Low Coupling
• Easier adaptability to new requirements.
• Clear module boundaries for focused development.
• Team members work independently with reduced conflicts.
• Modules can be tested in isolation, improving reliability.
• Easier debugging and refactoring, enhancing code quality.
• Supports seamless expansion and addition of features.
• Facilitates effective communication and teamwork.
Disadvantages of High Coupling
• Changes in one module lead to widespread impacts.
• Harder to isolate and fix bugs without affecting other modules.
• Modules are tightly tied, hindering standalone use.
• Difficult to adapt to new requirements or technologies.
• Changes can lead to unintended consequences in other parts.
• Developers can't work independently due to interdependencies.

What is Cohesion?
Cohesion in software engineering refers to the degree of interrelatedness and focus among
the elements within a module, class, or component.
It measures how well the internal components of a module work together to achieve a
single, well-defined purpose.
High cohesion indicates that the elements within a module are closely related and
contribute collectively to a specific functionality.
Low cohesion suggests that the elements are less focused and may serve multiple
unrelated purposes.

New Section 3 Page 8

Types of Cohesion:
1. Functional Cohesion:
Elements within a module are grouped based on a single, specific functionality or
task. This is the strongest form of cohesion, where all elements contribute to the
same goal.
2. Sequential Cohesion:
Elements are organized in a linear sequence, where the output of one element
becomes the input of the next. This type of cohesion is often seen in processes with
step-by-step execution.
3. Communicational Cohesion:
Elements within a module work together to manipulate a shared data structure. They
might not perform the same function, but their actions are closely related to a
common piece of data.
4. Procedural Cohesion:
Elements are grouped based on their involvement in a specific sequence of actions or
steps. They might share some data, but their primary focus is on the sequence of
operations.
5. Temporal Cohesion:
Elements are grouped because they need to be executed at the same time or during
the same phase. They might not share functional or data-related aspects.
6. Coincidental Cohesion:
Elements are grouped arbitrarily without a clear, meaningful relationship. This type of
cohesion is typically indicative of poor module design.
Advantages of High Cohesion
• Clear and specific module responsibilities.
• Code is more understandable and self-explanatory.
• Easier to locate and fix bugs or make enhancements.
• Supports modular design and reusability of components.
• Changes are contained within well-defined boundaries.
• Team members understand and collaborate on tasks more effectively.
Disadvantages of Low Cohesion
• Modules have mixed responsibilities, causing ambiguity.
• Code becomes harder to follow and understand.
• Changes can impact multiple, unrelated tasks.
• Testing becomes challenging due to scattered logic.
• Unrelated functionality intermixed can introduce bugs.
• Difficult to extend or modify without affecting other tasks.
• Unrelated code fragments increase codebase size.

New Section 3 Page 9

Structured Design:-
New Section 3 Page 10
Structured Design:-
Structured Design is a critical phase in the software development process that focuses on
creating a blueprint for the system based on the requirements gathered during the analysis
phase.

Steps in Structured Design

1. System Architecture Design:
○ Define the overall architecture, including hardware and software
platforms.
○ Identify major components and their interactions.
2. Component Design:
○ Break down the system into smaller modules or components, each with
specific functionality.
○ Ensure that each component can be developed independently.
3. Interface Design:
○ Specify how different components will interact with each other.
○ Clear interfaces help prevent issues when changes are made.
4. Data Structure Design:
○ Define the data structures to be used within the system.
○ Ensure that data structures are optimized for performance and meet
application requirements.
5. Algorithm Specification:
○ Outline algorithms that will be implemented within each component.
○ Use pseudocode to describe algorithms in a language-agnostic way for
clarity.
6. Input/Output Design:
○ Design user interfaces and reporting formats.
○ Specify how users will interact with the system and how information will
be presented.
7. Documentation:
○ Create comprehensive documentation detailing design decisions,
component specifications, and interfaces.
○ Documentation serves as a reference for developers during
implementation and future maintenance.
Key Concepts in Structured Design
• Modular Programming: Encourages dividing code into smaller, manageable
modules that can be developed, tested, and maintained independently.
• Structure Charts: Visual representations showing how processes are grouped
into tasks and allocated to resources without detailing internal workings.
• Pseudocode: An informal way of representing algorithms that outlines logic
without being tied to any specific programming language.
Benefits of Structured Design
1. Clarity and Simplicity: Breaking down complex systems into smaller
components makes them easier to understand and manage.
2. Better Communication: Provides a common framework for stakeholders to
discuss system design, ensuring alignment with user needs.
3. Improved Maintainability: A clear structure facilitates easier updates and
maintenance over time.
4. Enhanced Testability: Well-defined inputs and outputs simplify testing
processes, ensuring that the system meets its requirements.

New Section 3 Page 11

New Section 3 Page 12