Unit-III

Software
design
Software design: Definition of Software Design,
Module, Stages in Design, Modularity, Cohesion
and Coupling. Design Approaches: overview of
Function-Oriented and Object-Oriented Design.
Structured Analysis and Design: Functional
Decomposition, Structured Analysis: Data Flow
Diagram, Data Dictionary. Structured Design:
Structure Chart.
 Software Design
Software design is the process of defining the architecture,
components, modules, interfaces, and data for a software
system. It is a critical phase in the software development
life cycle (SDLC) where developers translate system
requirements into a representation of the software
structure. The primary goal of software design is to create a
plan or blueprint that guides the development team in
constructing a high-quality, reliable, and maintainable
software product.

SRS Document Design Documents

Design Activities
 Items Designed During Design
Phase
During the design phase of software development, various items are created to
specify the structure, behavior, and implementation details of the software
system. The design phase is crucial for translating the requirements gathered
in the previous phases into a blueprint that developers can follow.
Here are common items designed during the design phase:
1. System Architecture:
• High-Level Design (HLD): Describes the overall system architecture, including major
components, their interactions, and how they fulfill the system requirements.
2. Database Design:
• Database Schema: Defines the structure of the database, including tables,
relationships, constraints, and data types.
• Data Flow Diagrams (DFD): Illustrate how data flows through the system, showing
processes, data stores, and data movement.
3. User Interface Design:
• User Interface Mockups or Prototypes: Visual representations of the user interface,
showcasing the layout, navigation, and interactions.
4. Component and Module Design:
• Low-Level Design (LLD): Provides detailed specifications for individual
components or modules, including data structures, algorithms, and interfaces.
• Class Diagrams: Represent the relationships and interactions between classes
in an object-oriented system.
5. Security Design:
• Security Architecture: Outlines the measures and protocols to ensure the
security of the system, including access controls, encryption, and authentication
mechanisms.
6. Deployment Diagram:
• Deployment Architecture: Describes how the software will be deployed
across different environments, including servers, databases, and other
infrastructure components.
7. Testing and Quality Assurance Plans:
• Test Cases: Detailed descriptions of test scenarios to validate the functionality
of the software.
• Quality Assurance (QA) Plan: Describes the overall strategy for ensuring
software quality, including testing methodologies and criteria.
 Module
A module is a self-contained unit of code that performs a specific
set of tasks or implements a particular functionality. Modules are
used to organize code into logical units, making it easier to
develop, understand, test, and maintain software systems.
Modules are designed to encapsulate a specific set of related
tasks, data, or functions.
 Stages in
Design
The design phase in software development is typically divided into
multiple stages, each focusing on specific aspects of the system's
architecture, functionality, and implementation. The stages in the design
phase may vary slightly depending on the software development
methodology being used (e.g., Waterfall, Agile).
Here is a generalized breakdown of the stages in software design:
High-Level Design (HLD)
• Objective: Define the overall architecture of the system.
• Activities: d1 d2

• Identify major components or modules.

• Define their interactions and relationships. d3 d4
d1
• Describe the high-level data flow and control flow.
 Low-Level Design (LLD)
• Objective: Provide detailed specifications for individual components or modules.
• Activities:
1. Break down high-level components into smaller units.
2. Specify data structures, algorithms, and interfaces for each module.
3. Create detailed class diagrams and other design artifacts.

User Interface (UI) Design

• Objective: Design the user interface to meet user requirements.
• Activities:
1. Create wireframes or prototypes to visualize the user interface.
2. Define navigation flows and user interactions.
3. Ensure a user-friendly and intuitive design.

Database Design
• Objective: Design the database structure and relationships.
• Activities:
1. Create a database schema specifying tables, fields, and relationships.
2. Optimize data storage and retrieval.
3. Consider normalization and indexing.
 Security Design
• Objective: Incorporate security measures into the system design.
• Activities:
1. Define access controls and permissions.
2. Implement encryption and secure communication protocols.
3. Address potential security vulnerabilities.

Network Design (if applicable)

• Objective: Plan the system's network architecture.
• Activities:
1. Determine the physical or logical layout of the network.
2. Identify servers, routers, and other network components.
3. Address issues related to scalability and performance.

Deployment Design
• Objective: Plan how the software will be deployed in different environments.
• Activities:
1. Create deployment diagrams illustrating the placement of software components.
2. Consider hardware and software requirements.
3. Plan for scalability and updates.
 Testing and Quality Assurance Design
1. Objective: Plan for testing and ensuring software quality.
2. Activities:
1. Develop test cases based on design specifications.
2. Define the testing methodologies (unit testing, integration testing, etc.).
3. Establish criteria for quality assurance.

These stages are often iterative, and adjustments may be made based
on feedback and changes in requirements throughout the software
development process. The goal is to create a solid foundation for the
implementation phase and to guide developers in building a system that
meets the specified requirements.
 Modularit
y
Modularity in software engineering refers to the practice of
dividing a software system into separate, independent, and
interchangeable modules or components. Each module is
designed to perform a specific set of functions, and it has a
well-defined interface through which it interacts with other
modules. Modularity is a fundamental attributes of any good
design.
Bad design
may look
like this…
Key characteristics associated with modularity
include
1. Encapsulation: Each module hides its internal details, exposing only a clearly
defined interface
2. Reusability: Well-designed modules are often reusable in different contexts or
projects
3. Abstraction: Modules provide a level of abstraction, allowing developers to focus
on the high-level functionality of a module without being concerned with its internal
implementation.
4. Independence: Modules should be independent units that can be developed,
tested, and modified without affecting other parts of the system.
5. Scalability: Modularity supports scalability by allowing developers to add, remove,
or modify modules to accommodate changes in requirements or to extend the
system's capabilities. New modules can be integrated without disrupting the entire
system.
6. Maintenance: Modularity contributes to ease of maintenance by localizing
changes. When a modification or bug fix is necessary, developers can focus on the
specific module without impacting the rest of the system.
 Cohesion and
Coupling
Cohesion and coupling are two important concepts in software
engineering that describe the relationships between modules in a
software system.
Coupling and cohesion are two parameters on which we can
understand the quality of modularity in the design of a software
Cohesion:
Definition: Cohesion refers to the degree to which the elements
(functions, classes, modules) within a module are related or
work together to achieve a common purpose.
Coupling:
Definition: Coupling refers to the degree of interdependence
between modules. It describes how much one module relies
on the functionality or implementation details of another
module.
 Cohesion
Cohesion refers to the degree to which the elements (functions,
classes, modules) within a module are related or work together to
achieve a common purpose.
Types of Cohesion:
1. Functional Cohesion: Elements perform a single, well-defined task.
2. Sequential Cohesion: Elements are related by the order of
execution.
3. Communicational Cohesion: Elements operate on the same input
data.
4. Procedural Cohesion: Elements are grouped together based on a
specific procedure.
5. Temporal Cohesion: Elements are grouped based on when they are
executed.
High Cohesion:
• A module with high cohesion has elements that are closely related
and work together efficiently.
• It promotes better maintainability, reusability, and understandability
of the code.

Low Cohesion:
• A module with low cohesion has loosely related elements.
• It may lead to difficulties in understanding, maintaining, and reusing
the code.
 Couplin
g
Coupling refers to the degree of interdependence between
modules. It describes how much one module relies on the
functionality or implementation details of another module.
Types of Coupling:
1. Data Coupling: Modules share data but do not depend on each other’s
internal structures.
2. Control Coupling: One module controls the behavior of another by
passing it information on what to do.
3. Stamp Coupling: Modules share a composite data structure but use
only part of it.
4. Common Coupling: Modules share global data, typically stored in a
common memory location.
5. Content Coupling: One module knows the internal details or
implementation of another.
Low Coupling:
• Low coupling implies that modules are independent and changes in
one module are less likely to affect others.
• It promotes better maintainability, reusability, and flexibility.

High Coupling:
• High coupling implies strong interdependence between modules.
• Changes in one module may require modifications in other modules,
making the system more brittle.
Relationship between Cohesion and Coupling:
• Ideal Scenario: Aim for high cohesion and low coupling in software
design.
Reasoning: High cohesion ensures that elements within a module work
together effectively, while low coupling ensures that modules are loosely
connected, making the system more flexible and maintainable.

In technical terms, modules should have:

• high cohesion
• low coupling.

In summary, designing software with high cohesion and low

coupling contributes to a more modular, understandable, and
maintainable system. It enhances code quality and facilitates future
 Design
Approaches
Design approaches refer to the methodologies and strategies used
in the process of designing systems, products, or solutions. These
approaches guide the way designers, engineers, or creators
conceptualize, plan, and implement their work.
Function-Oriented Design (FOD) and Object-Oriented Design (OOD) are
two distinct approaches to software design, each with its own principles
and methodologies.

• Function-Oriented Design (FOD)

• Object-Oriented Design (OOD)
 Function-Oriented Design
(FOD)
Function-Oriented Design (FOD) in software design is an approach
that revolves around breaking down a system or program into
smaller, manageable functions or procedures. The main goal is to
decompose a complex problem into smaller, more easily
understandable and solvable sub-problems.
 Key characteristics and principles of Function-Oriented Design include:
1. Focus on Functions:
• The primary organizational unit in FOD is the function or procedure.
• Each function is responsible for a specific, well-defined task or operation.
2. Procedural Programming:
• Function-Oriented Design is often used with procedural programming languages such as C.
• The program is organized as a series of functions that are executed sequentially.
3. Modularization:
• The approach emphasizes modularization, breaking down the software into modular components or
functions.
• Each module can be developed, tested, and maintained independently.
[Link] and Functions Separation:
• In FOD, there is a clear separation between data and functions.
• Data is often passed as parameters to functions for processing.
[Link]-Down Approach:
• Function-Oriented Design typically follows a top-down approach.
• The main problem is broken down into smaller sub-problems, and functions are developed to address each
sub-problem.
[Link] through Functions:
• Code reusability is achieved through the creation of reusable functions.
• Functions can be called from different parts of the program or even from different programs.
[Link] Execution:
• Execution of the program occurs in a sequential manner, with one function being executed after another.
 Object-Oriented Design
(OOD)
Object-Oriented Design (OOD) is a software design approach that
focuses on modeling real-world entities as objects, each
encapsulating data and behavior. The fundamental idea is to
structure software in a way that mirrors the relationships and
interactions between various components in the real world.
Object-oriented design is closely associated with object-oriented
programming languages such as Java, C++, and Python.
Key principles and concepts of Object-Oriented Design include:
1. Objects:
• Objects represent instances of real-world entities or concepts and are the building
blocks of an object-oriented system.
• Each object encapsulates data (attributes) and behavior (methods or functions).
2. Classes:
• Classes are blueprints or templates for creating objects.
• They define the common structure and behavior shared by a group of objects.
3. Encapsulation:
• Encapsulation involves bundling data and the methods that operate on the data into a
single unit (class).
• The internal details of an object are hidden from the outside world, and access is
[Link]:
• Inheritance allows a class to inherit attributes and behaviors from another class, forming
a hierarchy.
• It promotes code reuse and the creation of specialized classes based on existing ones.
[Link]:
• Polymorphism allows objects of different classes to be treated as objects of a common
base class.
• It enables flexibility and extensibility in the design by allowing methods to be overridden
in derived classes.
[Link]:
• Abstraction involves simplifying complex systems by modeling classes based on their
essential features.
• It focuses on what an object does rather than how it achieves it.
[Link]:
• Composition involves creating complex objects by combining simpler objects as
components.
[Link] Binding:
Function-Oriented Design versus
Object-Oriented
Function-Oriented Design Object-Oriented Design
• System is designed from a • System is viewed as a collection
functional viewpoint of objects(i.e. entities)
• Top-down decomposition • Bottom-up approach
• Divide & Conquer approach • UML is used
• DFD is used
 Structured Analysis and Design
(SAD)
Structured Analysis and Design (SAD) is a set of principles and
techniques used in software engineering for analyzing and
designing a computer system in a structured, modular way. The
primary goal of SAD is to create a clear and well-organized
blueprint for a software system that can be easily understood and
implemented. This approach is particularly useful for large and
complex systems.
Key components of Structured Analysis and Design include:
1. Modularity: Breaking down a complex system into smaller,
manageable modules or components. Each module is designed to
perform a specific function and is relatively independent of other
modules. This modular structure makes it easier to understand,
develop, and maintain the software.
[Link]: Organizing the system components in a hierarchical
structure, where each level of the hierarchy represents a different level
of abstraction. This top-down approach helps in managing complexity
and allows for a systematic design process.

[Link] Flow Diagrams (DFD): Using DFDs to represent the flow of

data within the system. DFDs provide a graphical representation of how
data moves through various processes, stores, and external entities.
This visualization helps in understanding the data flow and the
interactions between different components of the system.
[Link] Dictionary: Creating a data dictionary to define and document
data elements used in the system. The data dictionary contains
information about data structures, data types, and their relationships.
This ensures consistency in data representation throughout the system.
[Link]-Relationship Diagrams (ERD): ERDs are used to model the
relationships between different entities in a system. They help in
understanding the data requirements and relationships between various
data entities.

[Link] Specification: Developing detailed specifications for each

process or module, outlining the input, processing, and output requirements.
This provides a clear understanding of the functionality of each part of the
system.
 Functional
Decomposition

Functional Decomposition is a software engineering technique

used to break down a complex system or process into smaller,
more manageable parts or functions. This method involves dividing
a system into functional modules, each responsible for a specific
aspect of the overall functionality. The primary goals of functional
decomposition include improving the clarity, modularity, and
maintainability of a system.
• Example
 Key principles of Functional Decomposition:
1. Modularity: The system is divided into smaller functional modules, each
serving a particular purpose or carrying out a specific task. These
modules are designed to be relatively independent, making the system
more modular and easier to understand.
2. Reusability: Functions developed through functional decomposition are
often designed to be reusable. Once a function is created and tested, it
can be applied in different parts of the system or even in other projects,
promoting efficiency and reducing redundancy.
3. Parallel Development: Different teams or individuals can work on
different functions simultaneously, as long as the interfaces between
functions are clearly defined. This parallel development can lead to
faster project completion.
[Link]: Functional Decomposition often employs a hierarchical
structure, where functions are organized in a top-down fashion. This
hierarchy helps manage complexity by breaking down the system into
manageable levels of abstraction.
[Link]-Down Design: The design process starts with an overall view of the
system and then progressively breaks it down into smaller and more
detailed functions. This top-down approach allows for a systematic and
organized development process.
[Link] and Understandability: By decomposing the system into smaller,
focused functions, Functional Decomposition enhances clarity and makes it
easier for developers to comprehend the individual components. Each
function has a well-defined purpose and can be analyzed independently.

It's important to note that while Functional Decomposition has been a

traditional and widely used approach, modern software development
methodologies often integrate various techniques, including
object-oriented design, agile practices, and others, to address the evolving
needs and complexities of software systems.
 Structured Analysis: Data Flow
Diagram
A Data Flow Diagram (DFD) is a graphical representation that
illustrates how data moves through a system and how it is
processed. It is a visual tool used in system analysis and design
to represent the flow of data within a system and the processes
that transform or manipulate that data. DFDs are part of the
Structured Analysis and Design (SAD) methodology and are
helpful in understanding the data flow and interactions within a
system.

Elements of a Data Flow Diagram:

1. Processes (or Functions)
2. Data Flows
3. External Entities
1. Processes (or Functions): Represented by circles or ovals,
processes indicate the activities or functions that transform data within
the system

[Link] Flows: Represented by arrows, data flows depict the movement

of data between different processes, data stores, and external
entities. The direction of the arrow indicates the flow of data from a
source to a destination.
[Link] Entities: Represented by rectangles with lines
connecting to processes, external entities are sources or
destinations of data that are outside the system. These can be
users, other systems, or external data sources.

[Link] Stores: Represented by rectangles, data stores signify

where data is stored within the system. They can represent
databases, files, or any other storage mechanism.
Rules of Data Flow
Data can flow from Data cannot flow from
• External entity to Process • External entity to External entity

• Process to External entity • External entity to Data store

• Process to Data store • Data Store to External entity

• Process to Process • Data store to Data store

DFDs can be categorized into different levels of
detail, known as levels 0, 1, 2, etc.:

• Level 0 DFD: Provides an overview of the entire system, showing the

major processes, data stores, and external entities.
• Level 1 DFD: Breaks down the processes from the Level 0 DFD into
more detailed subprocesses.
• Level 2 DFD: Further decomposes the subprocesses from Level 1
into even more detailed processes, if necessary.
 Structured Analysis: Data Dictionary

In the context of Structured Analysis, a Data Dictionary serves as a

centralized repository of information about data elements used
within the system being analyzed or designed. It provides a
detailed description of each data element, including its properties,
attributes, and relationships with other data elements. The Data
Dictionary is often created and maintained collaboratively by
analysts, designers, and stakeholders involved in the software
development process.
Here are some key components and purposes of a Data
Dictionary:
1. Data Element Definitions: Each data element is defined in detail, including
its name, description, data type, length, format, and any constraints or
validation rules associated with it.
2. Data Relationships: The Data Dictionary may also describe relationships
between different data elements, such as foreign key relationships in a
database schema.
3. Data Usage and Constraints: It may provide guidance on how data
elements should be used within the system, including naming conventions,
data formatting standards, and coding guidelines.
4. Metadata: Metadata about data elements, such as creation date, last update
date, and ownership, can be included to track changes and maintain data
integrity.
5. Data Flow and Transformation: In more comprehensive Data Dictionaries,
information about how data flows through the system and how it is used by
different components or processes may also be documented.
6. Data Security and Access Controls: Depending on the system's
requirements, the Data Dictionary may include information about data
 Structured Design: Structure
Chart
Structured design is a software engineering methodology that aims
to create well-organized and maintainable software system. One of
the key techniques used in structured design is the creation of a
structure chart.

Structure Chart
A structure chart is a graphical representation of the modular
structure of a system, showing the hierarchical relationships
between modules or components. Each module is represented by a
box, and the connections between modules are represented by lines
indicating the flow of data or control between them. Typically,
modules are arranged hierarchically, with higher-level modules
calling lower-level modules to perform specific tasks.
Structure chart for Library management
system:
In this structure chart:
• The top-level box represents the overall system, which is the Library
Management System.
• The system is divided into three main modules: READER, BOOKS
and STAFF.
• All three module is further divided into different sub-modules.

This structure chart illustrates the hierarchical relationships between

modules. For example:
• The READER, BOOKS and STAFF modules are at the same level,
indicating they are main functions of the system.
• The Student, Text Book, Librarian, News Paper etc. modules are
sub-modules of READER, BOOKS and STAFF module, indicating
they are functions related to managing books and staff.
 The main objectives of using structure charts in
structured design are:
1. Modularity: Breaking down the system into smaller, manageable modules or
components.
2. Abstraction: Representing the system at different levels of detail, hiding
unnecessary complexity from higher-level modules.
3. Encapsulation: Encapsulating the functionality of each module so that it can
be developed, tested, and maintained independently.
4. Understanding: Providing a clear and visual representation of the system's
architecture, helping developers understand how different parts of the
system interact.
5. Maintenance: Facilitating maintenance and updates by clearly defining the
relationships between modules and making it easier to identify the impact of
changes.