SE UNIT-3

Software Design
Software design is a phase that comes after the requirement analysis of the software. In
this phase, the requirements of the software are represented in a form that is suitable as
per the customer’s demand, and that can easily be implemented through any coding
language by the software developers.
The software design is like a blueprint of the software. This can be related to the
construction of a building. Before constructing any building, a blueprint of that building
is created and according to that blueprint, further construction is carried out. For a similar
purpose, in the case of software development, we make software design. After the design
phase, the software undergoes the coding and implementation phase. In this phase,
different developers work on different modules. So, for any kind of reference or any help,
they refer to this software design.

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.
Generally, there are 3 major activities in Software Design –
1. External Design
2. Architectural Design
3. Detailed Design
The Architectural design and Detailed design are collectively known as Internal Design.
 External Design – External design involves conceiving, planning out and
specifying the externally observable characteristics of Software Product such as
User interface, report formats, data sources, functional characteristics and
performance requirements.
 Internal Design – Internal design involves conceiving, planning out and specifying
the internal structure and processing details of the software product. The goals of

1
 internal design are to specify internal structure and processing details, to record
design, to elaborate the test plan and to provide alternatives, provide the blueprint
design for implementation, specifying using and maintenance activities.
Architectural Design – Architectural Design involves the refining of the conceptual
view of the system, identifying data entities, attributes, internal processing flows and
their relationships.
Detailed Design – Detailed design include specifications of algorithms/activity flows and
detailed class diagrams that provide detailed blueprints for concrete implementation of
data models/objects and their interrelationships.

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.

2
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 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.

3
1. 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.
2. 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.
3. 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.
4. Refinement: Refinement means removing any impurities and improving the quality
of something. The software design refinement idea is a process of building or presenting

4
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.
5. 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.
6. 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.
7. 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.

Preliminary Design and Detailed Design

While designing any software, we do it mainly in two different phases. They are:
1. Preliminary Design
2. Detailed Design
1) Preliminary Design: In the preliminary design, a rough design of the software is
proposed by several designers according to the customer requirements. In the preliminary
design, various designs of the software are made, accepted, rejected and modified. After

5
reaching a stage in which the design seems to fulfill all the customer requirements, a set
of trained software designers make the final design of the software.
2) Detailed Design: The final design that is made at the end of the preliminary design
phase is called the detailed design. After this design is made, no further changes are made
in the design of the software, and the design is sent to the development team for further
work.
The design phase of the software is very crucial in the software development process.
This is because if the design of the software is not accurate to fulfill all the requirements
of the user, then the software that will be developed will also look those things because
the software will follow the design only. So, for making good quality software, the design
of the software should also be proper and accurate. So, each design in the preliminary
stage must be evaluated in every manner before being finalized as the design for the
software.
3 Software Design Levels
1) Architectural Design
2) Preliminary (High-Level) Design
3) Detailed Design
1) Architectural Design: The architectural design is the highest summarize
(abstract) version of the system. It identifies the software as a system with many
components interacting with each other. At this level, the designers get the idea of
proposed solution domain.
2) Preliminary (High-Level) Design: High-level design means identification of
different modules and the control relationships among them and the definition of the
interfaces among these modules. The outcome of the high-level design is called software
architecture or the program structure. Many different types of notations have been used
to represent a high-level design. A popular way is to use a tree-like diagram called the
Structure Chart to represent the control hierarchy in the high-level design.
3) Detailed Design: In this level of software design, the data structures and
algorithms are designed for different modules. Thus at this stage, the design includes
principal components (also called modules or sub-systems), relationships between them,

6
and how they are distributed along with the data structures and algorithms. The outcome
in this stage is also known as the module specification document.

Difference between Analysis and Design

 The aim of analysis is to understand the problem with a view to eliminate any
deficiencies in the requirement specification such as incompleteness,
inconsistencies, etc.
 The aim of design is to produce a model that will provide a seamless transition to
the coding phase, i.e. once the requirements are analyzed and found to be
satisfactory, a design model is created which can be easily implemented.

Characteristics of a good software design | Software Engineering

For good quality software to be produced, the software design must also be of good
quality. Now, the matter of concern is how the quality of good software design is
measured? This is done by observing certain factors in software design. These factors are:
1. Correctness
2. Understandability
3. Efficiency
4. Maintainability
1) Correctness: First of all, the design of any software is evaluated for its correctness.
The evaluators check the software for every kind of input and action and observe the
results that the software will produce according to the proposed design. If the results are
correct for every input, the design is accepted and is considered that the software
produced according to this design will function correctly.
2) Understandability: The software design should be understandable so that the
developers do not find any difficulty to understand it. Good software design should be
self- explanatory. This is because there are hundreds and thousands of developers that
develop different modules of the software, and it would be very time consuming to
explain each design to each developer. So, if the design is easy and self- explanatory, it

7
would be easy for the developers to implement it and build the same software that is
represented in the design.
3) Efficiency: The software design must be efficient. The efficiency of the software
can be estimated from the design phase itself, because if the design is describing software
that is not efficient and useful, then the developed software would also stand on the same
level of efficiency. Hence, for efficient and good quality software to be developed, care
must be taken in the designing phase itself.
4) Maintainability: The software design must be in such a way that modifications
can be easily made in it. This is because every software needs time to time modifications
and maintenance. So, the design of the software must also be able to bear such changes. It
should not be the case that after making some modifications the other features of the
software start misbehaving. Any change made in the software design must not affect the
other available features, and if the features are getting affected, then they must be handled
properly.

Features of a Design Document

In order to facilitate understandability, the design should have the following features:
 It should use consistent and meaningful names for various design components.
 The design should be modular. The term modularity means that it should use a
cleanly decomposed set of modules.
 It should neatly arrange the modules in a hierarchy, e.g. in a tree-like diagram.

SOFTWARE DESIGN DOCUMENT (SDD)

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.
A software design document (SDD) is sometimes called software design specification
or software development document—is a detailed plan for developing a piece of
software. An SDD should outline the finished software’s functionality (specs) and your
team’s plans to build it (timeline, goals, etc.).

8
Software design documents break down nearly every aspect of a software development
project: What problem will the software solve? What will the final product look like?
How does the internal architecture function? When you create your SDD, you'll plan all
these factors in advance.

Why are SDDs important?

If you’re a developer, you might have been here before: You’ve written thousands of
lines of code only to realize you and your client had completely different visions for the
project. That’s hours upon hours of work you might have to scrap.
By creating a software design document, your engineering team and other stakeholders
can establish exact expectations for the project before you start coding. While there’s no
surefire way to avoid reworking elements of your project, an SDD is a good place to
start.
SDDs also help streamline the coding process. To create an SDD, you have to think
through your entire system architecture before writing any code. This allows you to
anticipate any snags or roadblocks and plan around them. As various team members work
to build out their respective parts of the software, there’s a centralized document that
outlines features, dependencies, and other useful bits of information.
A good software design document usually includes these crucial components:
1. Introduction and overview 5. Component design
2. System architecture 6. User interface design
3. Data design 7. Assumptions and dependencies
4. Interface design 8. Glossary of terms
1. Introduction and overview: The introduction and overview section sets the
stage for the entire software design document. It should provide a high-level project
summary, including goals, project scope, and primary features. This section should also
explain the document's purpose and who it's for, making sure readers understand why the
information is essential.
A strong introduction typically includes the following:
 A brief description of the software system
 The project's objectives and key requirements

9
  An overview of what's in the document
 Any important background information
2. System architecture: The system architecture section is a crucial part of a
software design document. It describes the overall structure of the software system,
including its major components and subsystems and how they relate to each other. This
section shows how different system parts work together to achieve the desired
functionality.
Key elements to include in the system architecture section are:
 A high-level diagram of the architecture
 Description of major components and what they do
 Explanation of design patterns and architectural styles used
 Discussion of important design decisions and trade-offs
3. Data design: The data design section focuses on how the software system stores,
manages, and processes information, including details about the database structure, data
models, and data processing techniques.
Essential aspects to cover in the data design section include:
 Database structure and table layouts
 Data flow diagrams
 Data validation and integrity rules
 How data will be stored and retrieved
4. Interface design : The interface design section describes how different parts of the
system will communicate with each other and interact with external systems or services.
This includes both internal interfaces between modules and external APIs or integration
points.
Key elements to include in the interface design section are:
 API specifications and protocols
 Message formats and data structures
 How errors and exceptions will be handled
 Security and authentication methods

10
5. Component design : The component design section provides detailed information
about individual modules or components within the system. This includes their specific
functionality, what inputs they need and outputs they produce, and any algorithms or data
structures they use.
For each major component, consider including:
 Purpose and responsibilities
 Input and output specifications
 Algorithms and processing logic
 Dependencies on other components or external systems
6. User interface design : The user interface design section focuses on how users
interact with the software system. This includes details about the user interface's layout,
navigation, functionality, and specific design considerations or usability requirements.
Key elements to include in this section are:
 Wireframes or mockups of key screens
 Description of user workflows and interactions
 Accessibility considerations
7. Assumptions and dependencies: This section outlines any assumptions made
during the design process and any external dependencies or constraints that may impact
the system's implementation.
Consider including:
 Technical assumptions about the development environment
 Dependencies on external libraries or services
 Constraints related to hardware, software, or infrastructure
 Any regulatory or compliance requirements
8. Glossary of terms: A glossary of terms is essential to any software design
document, especially for complex systemas or those with industry-specific terminology.
This section should provide clear definitions for:
 Technical terms
 Acronyms
 Jargon

11
To create an effective software design document, consider these best practices:
 Use clear, simple language: Avoid jargon and overly technical terms when
possible. When technical language is necessary, explain clearly or include
definitions in the glossary.
 Include visuals: Use diagrams, flowcharts, and other visual aids to illustrate
complex concepts and relationships between components.
 Be consistent: Use the same formatting, terminology, and structure throughout
the document to make it easier to read and understand.
 Keep it current: Regularly review and update the design document as the project
evolves to ensure accuracy.
 Make it easy to access: Store the document in a central location where all team
members can easily find and reference it.
 Encourage teamwork: Use tools that support collaboration with editing and
commenting to make it easy for team members to provide input and discuss ideas.
This promotes knowledge sharing across the team, ensuring that insights and
expertise are distributed effectively throughout the project lifecycle.
 Consider future growth: Consider how the system might need to expand or
change and design with flexibility.
 Include traceability: Improve the design decision-making process by
establishing clear links between requirements, design choices, and
implementation details. This can help you understand why specific decisions were
made.

Importance of Design Documentation:

1. Requirements are well understood: With proper documentation, we can remove
inconsistencies and conflicts about the requirements. Requirements are well understood
by every team member.
2. Architecture/Design of product: Architecture/Design documents give us a complete
overview of how the product look like and better insight to the customer/user about their
product.

12
3. New Person can also work on the project: New person to the project can very easily
understand the project through documentations and start working on it. So, developers
need to maintain the documentation and keep upgrading it according to the changes made
in the product/software.
4. Everything is well Stated: This documentation is helpful to understand each and
every working of the product. It explains each and every feature of the product/software.
5. Proper Communication: Through documentation, we have good communication with
every member who is part of the project/software. Helpful in understanding role and
contribution of each and every member

Modularity
The module simply means the software components that are been created by dividing the
software. The software is divided into various components that work together to form a
single functioning item but sometimes they can perform as a complete function if not
connected with each other. This process of creating software modules is known as
Modularity in software engineering. It simply measures the degree to which these
components are made up than can be combined. Some of the projects or software designs
are very complex that it’s not easy to understand its working and functioning. In such
cases, modularity is a key weapon that helps in reducing the complexity of such software
or projects.
Example
Consider a web application with modules for user authentication, data management, and
user interface components. Each module handles distinct aspects of the application and
communicates with the others through predefined interfaces. This way, changes to the
data management logic, for example, do not affect user authentication or interface
modules, assuming the interface remains consistent.
Benefits of Modularity
1. Maintainability: Changes in one module typically do not affect others, making bugs
easier to track down and fix without risking other parts of the system.
2. Reusability: Modules designed for one project can often be used in another, saving
development time and reducing errors by reusing proven code.

13
3. Scalability: Modular systems can be scaled more readily by adding new modules or
enhancing existing ones without impacting the rest of the system.
4. Parallel Development: Different teams can work on different modules
simultaneously, decreasing development time.
5. Simplicity: Modularity divides complex issues into smaller, more manageable
components, making them less overwhelming. Complex problems may be intimidating.
The software's structure has been simplified, making it simpler to comprehend, create,
and maintain.
6. Testing: It also allows for more focused and effective testing of modules at an
individual level. Issues that must be addressed should be identified early in development
to ensure a higher-quality final product.

Real-World Examples of Modular Design

 Modular buildings: Buildings that are prefabricated, built off-site, and then put
together on-site using standardized parts.
 Modular cars: Vehicles that are easily modified or changed because of their
interchangeable parts, like engines and transmissions.
Modular electronics: Replaceable camera modules and cell phones with detachable
batteries are examples of electronic gadgets composed of replaceable modules.
 Modular software: Software that is divided into independent modules that can be
developed and tested separately and then integrated into the overall system.
 Video Games: In game development, modular building blocks come for
gameplay, visuals, physics, sound and music. To shorten the development time,
developers can use various modular elements available in game systems such as
Unity and Unreal Engine.

Characteristics of Modularity: The key characteristics of modularity include:

Flexibility: Allows for easy customization and adaptation to changing requirements.
Abstraction: Modules provide clear, high-level interfaces abstracting complex
functionality.

14
 Collaboration: allows teams to operate independently on various modules, which
promotes parallel development.
 Testing: Modular systems are easier to test as each module can be tested
separately, promoting robustness.
 Documentation: Encourages better documentation practices as module interfaces
need to be well-defined and documented.
 Interchangeability: Modules can be swapped or upgraded without affecting the
overall system functionality, promoting interoperability.

What are Interfaces?

An interface is a set of rules or standards used in system design that specify how various
system components communicate with one another. Interfaces define a component’s
behaviors, inputs, and outputs as well as how other system components can utilize it.
Characteristics of Interfaces
Abstraction: Interfaces provide a way to define a contract for functionality without
specifying the implementation details. They define what operations are available
without specifying how those operations are carried out.
Encapsulation: Interfaces encapsulate the essential behavior of an entity. They hide
the internal details of how a class or module achieves its functionality, allowing
for a clear separation of concerns and promoting modular design.
Polymorphism: Objects of various classes can be treated interchangeably if they
implement the same interface, which is made possible by interfaces. This
encourages code flexibility and reusability.
 Contract: The implementing class and the rest of the system enter into a contract
through interfaces. In order to maintain consistency and predictability, any class
that implements an interface must supply implementations for every method
specified in that interface.
 Flexibility: By enabling classes to communicate with one another based on the
interfaces they implement rather than their actual types, interfaces help to promote
loose coupling between components. This facilitates software system evolution,
testing, and maintenance.

15
Real-World Example of Interface
.USB (Universal Serial Bus) standard. USB defines a set of protocols and
specifications for communication between devices and a host controller
The interface specification, or USB standard, specifies the guidelines and procedures
that devices must adhere to in order to connect with one another.
Various devices such as keyboards, mice, printers, cameras, and storage devices
implement this interface specification.
Every gadget complies with the USB standard, guaranteeing compatibility and
interoperability with other gadgets that share that standard.
Regardless of the particular features or manufacturer of any device, the host
controller (such as a computer or smartphone) communicates with these devices
over the universal interface offered by the USB standard.
 This abstraction allows the host controller to communicate with a wide range of
devices without needing to know the intricate details of each device’s
implementation.

How Modularity and Interfaces work together?

Interfaces and modularity work together to promote flexible, maintainable, and scalable
software systems through clear separation of concerns and well-defined points of
interaction.
1. Encapsulation:
 Interfaces define the external contract for modules or components, specifying the
methods or operations they must implement. This encapsulation hides the internal
details of each module.
 Modularity, on the other hand, breaks down the system into smaller, more
manageable modules.
2. Loose Coupling:
 Modularity aims to minimize dependencies between modules, reducing the risk
of ripple effects when making changes to the system.

16
  Interfaces play a crucial role in achieving loose coupling by defining well-
defined points of interaction between modules. This allows modules to
communicate with each other based on contracts defined by interfaces.
3. Flexibility and Reusability:
 Interfaces enable polymorphism, allowing different modules to be substituted or
replaced with alternative implementations as long as they adhere to the same
interface.
 Modularity further enhances this flexibility by allowing modules to be
developed, tested, and maintained independently, facilitating easier integration
and evolution of the system over time.
4. Standardization and Documentation:
 Interfaces serve as standardized communication channels between modules,
providing clear documentation of the expected behavior and interactions.
 Modularity, by breaking down the system into modular components, facilitates
the organization and management of these interfaces, making it easier for
developers to understand and work with the system.

Scalability:
Software systems’ scalability is supported by both interfaces and modularity.
By adding or changing modules, modularity enables the gradual evolution
and inclusion of new functionalities.
As long as they follow the defined interface contracts, interfaces guarantee
that new modules can be easily integrated with preexisting ones, allowing
the system to expand and change to meet evolving needs without
compromising its overall architecture.

The principles of modularity: When implementing modularity in software

engineering, certain principles need to be followed to ensure its effectiveness.
Two fundamental principles are
1. cohesion
2. coupling.

17
 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. Both coupling and cohesion are
important factors in determining the maintainability, scalability, and reliability of a
software systems.
Coupling represents the relationships between modules, and cohesion defines the
relationships within them.
What is Coupling and Cohesion?
A) 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.

Coupling is the measure of the degree of interdependence between the modules. A good
software will have low coupling.

18
Types of Coupling:

1. Data Coupling: When data of one module is passed to another module, this is
called data coupling. Each module maintains its own data and does not exactly access or
modify the data of other modules

19
2. Stamp Coupling : In stamp coupling, the complete data structure is passed from
one module to another module. 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.
3 . Control Coupling: Control coupling is one of the types of coupling in software
engineering occurs when one module controls the behavior of another module. This type
of coupling implies that one module has knowledge of internal workings & decisions or
another module, that makes the code more difficult to maintain.
4. External Coupling: In external coupling, the modules depend on other modules,
external to the software being developed or to a particular type of hardware. Ex- protocol,
external file, device format, etc.
5. Common Coupling: Common coupling occurs when two or more modules in the
system share global data. The modules can access & manipulate the same global
variables & the data structures. The changes in global data mean tracing back to all
modules which access that data to evaluate the effect of the change. So it has got
disadvantages like difficulty in reusing modules, reduced ability to control data accesses,
and reduced maintainability.

6. Content Coupling: In a content coupling, one module can modify the data of another
module, or control flow is passed from one module to the other module. This is the worst
form of coupling and should be avoided.

B. 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.

20
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. This type of cohesion is considered the most desirable &
strongest. Examples - reading transaction records, cosine angle computation, seat
assignment to an airline passenger, etc
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: Two elements operate on the same input data or
contribute towards the same output data. Example- update record in the database and
send it to the printer. Or

21
The elements within the module work together by passing data to each other. It is weaker
than sequential cohesion. Like, usage of a customer account number, finding the name of
the customer, the loan balance of the customer, etc.
4. Procedural Cohesion: Procedural cohesion occurs when the elements within a
module are grouped based on a specific sequence of actions or steps. This type of
cohesion is weaker than the communicational cohesion.
Examples - Read, write, edit of the module, zero padding to the numeric fields, returning
records, etc.
5. Temporal Cohesion: Temporal cohesion occurs when the elements within a
module are executed at the same time or within the same timeframe. It is considered
weaker than the procedural cohesion.
Examples - Setting the counter to zero, opening the student file, clearing the variables of
error messages, initializing the array, etc.
6. Logical Cohesion: Logical cohesion occurs when the elements within a module
are logically related, but do not fit into any other cohesion types. It is not strong as other
cohesion types.
Examples - When a component reads inputs from tape, disk, and network, etc.
7. Coincidental Cohesion: Coincidental cohesion occurs when the elements are not
related to each other.
Examples - Module for miscellaneous functions, customer record usage, displaying of
customer records, calculation of total sales, and reading the transaction record, etc.

Advantages of low coupling

1. Improved maintainability: Low coupling reduces the impact of changes in one
module on other modules, making it easier to modify or replace individual components
without affecting the entire system.
2. Enhanced modularity: Low coupling allows modules to be developed and tested in
isolation, improving the modularity and reusability of code.
3. Better scalability: Low coupling facilitates the addition of new modules and the
removal of existing ones, making it easier to scale the system as needed.

22
Advantages of high cohesion
1. Improved readability and understandability: High cohesion results in clear, focused
modules with a single, well-defined purpose, making it easier for developers to
understand the code and make changes.
2. Better error isolation: High cohesion reduces the likelihood that a change in one part
of a module will affect other parts, making it easier to
3. Improved reliability: High cohesion leads to modules that are less prone to errors and
that function more consistently, leading to an overall improvement in the reliability of
the system.

Disadvantages of high coupling

1. Increased complexity: High coupling increases the interdependence between
modules, making the system more complex and difficult to understand.
2. Reduced flexibility: High coupling makes it more difficult to modify or replace
individual components without affecting the entire system.
3. Decreased modularity: High coupling makes it more difficult to develop and test
modules in isolation, reducing the modularity and reusability of code.

Disadvantages of low cohesion

1. Increased code duplication: Low cohesion can lead to the duplication of code, as
elements that belong together are split into separate modules.
2. Reduced functionality: Low cohesion can result in modules that lack a clear purpose
and contain elements that don’t belong together, reducing their functionality and making
them harder to maintain.
3. Difficulty in understanding the module: Low cohesion can make it harder for
developers to understand the purpose and behavior of a module, leading to errors and a
lack of clarity.

23
Explanation
High Cohesion: User Module: The User Module is designed to handle all user-
related functionalities:
 Attributes: It has attributes like id, name, and email.
 Functions: It includes functions such as register(), login(), and logout().
Why is it high cohesion?
Single Purpose: All the functions in the User Module are related to managing users.
This means everything in this module is focused on one specific task – handling
user operations.
Low Coupling: Book and Member Modules: The Library System consists of two
separate modules: Book and Member.
Book Module:
 Attributes: It has attributes like title and author.
 Functions: It includes functions such as addBook() and removeBook().
Member Module:
o Attributes: It has attributes like memberId and memberName.
o Functions: It includes functions such as addMember() and
removeMember().

24
 Differences between Coupling and Cohesion
Aspect Cohesion Coupling

Coupling refers to the degree of

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

Module Cohesion is the concept of an intro-

Coupling is the concept of inter-module.
Dependency module.

Cohesion represents the relationship Coupling represents the relationships

Purpose
within a module. between modules.

Increasing coupling is avoided for

Quality Increasing cohesion is good for software.
software.

Cohesion represents the functional Coupling represents the independence

Focus
strength of modules. among modules.

Whereas loosely coupling gives the best

Relationship Highly cohesive gives the best software.
software.

In cohesion, the module focuses on a In coupling, modules are connected to

Example
single thing. the other modules.

Cohesion is created between the same Coupling is created between two

Creation
module. different modules.

Types of Cohesion Types of Coupling

1. Functional Cohesion. Data Coupling
2. Procedural Cohesion. Stamp Coupling
Types 3. Temporal Cohesion. Control Coupling
4. Sequential Cohesion. External Coupling
5. Layer Cohesion. Common Coupling
6. Communication Cohesion. Content Coupling

25
 TOP-DOWN AND BOTTOM-UP APPROACH
What is Top-Down Approach?
Top-Down Approach is an approach to design algorithms in which a bigger problem is
broken down into smaller parts. Thus, it uses the decomposition approach. This approach
is generally used by structured programming languages such as C, COBOL,FORTRAN.
The top-down approach, also known as the “divide and conquer” approach.

How the Top-Down Approach Works?

The working of top-down approach is as follows:
 Identify the goal or problem: The goal or problem needs to be clearly identified
and measurable.
 Break it down into sub-goals: The sub-goals/sub-problems are what the top-up
approach is all about.
 Solve each sub-goal/sub-problem: Using the same top-up approach, the sub-
problems/sub-goals/problems are broken down into smaller manageable parts.
 Repeat steps 2 and 3 until the overall goal/problems are resolved: The top-up
approach may involve multiple iterations.
Advantages
 Each module of code is to be tested separately.
 Breaking a problem down into smaller chunks makes it far easier to understand,
solve and manage.
 Testing and debugging are efficient and easier.
 Project implementation is smoother and shorter.

26
Disadvantages of Top-Down Approach
 Specification tends to change over time and in a top-down approach, all decisions
made from the beginning of the project depend directly or indirectly on the high-
level specification.
 In Dynamic Programming, the top-down approach is slow as compared to the
bottom-up approach, as it involves recursion.
 There is a chance of stack overflow here.
 It takes more memory space as it involves recursion.

What is Bottom-Up Approach?

Bottom-Up Approach is one in which the smaller problems are solved, and then these
solved problems are integrated to find the solution to a bigger problem. Therefore, it uses
composition approach. It is generally used with object oriented programming paradigm
such as C++, Java, and Python. Data encapsulation and data hiding is also implemented
in this approach. The bottom-up approach is generally used in testing modules.

The steps in this approach are:

 Identify Basic Elements: Start with the smallest, most basic units or modules that
can be developed independently.
 Develop Basic Elements: Write and test the code for these basic elements.
 Combine Elements: Combine the basic elements to form larger components or
modules.
 Continue Building Up: Keep combining these larger components until you've
built the entire system.

27
Advantages of Bottom-Up Approach
 Test conditions are easier to create.
 Observation of test results is easier.
 Contains less redundancy due to the presence of data encapsulation and data-
hiding.
 Reusability of the code.

Disadvantages of Bottom-Up Approach

 In the Bottom-Up approach, we solve all sub-problems (even though some of the
solutions of the subproblems aren’t needed to solve), which requires additional
calculations.
 In the Bottom-Up approach, sometimes it is difficult to identify the overall
functionality of the system in the initial stages.
 As this is an iterative approach, more code needs to be written.
 It is more difficult to implement.

Difference between Top-Down Approach and Bottom-Up Approach

S.No. Top-Down Approach Bottom-Up Approach

In this approach, the problem is In this approach, the smaller

1.
broken down into smaller parts. problems are solved.

It is generally used by structured It is generally used with object

2. programming languages such as C, oriented programming paradigm such
COBOL, FORTRAN, etc. as C++, Java, Python, etc.

It is generally used with It is generally used in testing

3. documentation of module and modules.
debugging code.

It does not require communication It requires relatively more

4.
between modules. communication between modules.

28
 Decomposition approach is used Composition approach is used here.
5.
here.

The implementation depends on the Data encapsulation and data hiding is

6.
programming language and platform. implemented in this approach.

Structured Analysis and Structured Design (SA/SD)

Structured Analysis and Structured Design (SA/SD) is a diagrammatic notation that is
designed to help people understand the system. The basic goal of SA/SD is to improve
quality and reduce the risk of system failure. It focuses on the solidity, pliability, and
maintainability of the system.
Structured Analysis and Structured Design (SA/SD) is a software development method
that was popular in the 1970s and 1980s. The method is based on the principle of
structured programming, which emphasizes the importance of breaking down a software
system into smaller, more manageable components.
In SA/SD, the software development process is divided into two phases:
1. Structured Analysis and
2. Structured Design.
During the Structured Analysis phase, the problem to be solved is analyzed and the
requirements are gathered. The Structured Design phase involves designing the system to
meet the requirements that were gathered in the Structured Analysis phase.
Basically, the approach of SA/SD is based on the Data Flow Diagram. It is easy to
understand SA/SD but it focuses on well-defined system boundary whereas the JSD
approach is too complex and does not have any graphical representation.
SA/SD is combined known as SAD and it mainly focuses on the following 3 points:
1. System 2. Process 3. Technology
SA/SD involves 2 phases:
1. Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State Transition
diagram and ER diagram.

29
 2. Design Phase: It uses Structure Chart and Pseudo Code.

1. Analysis Phase: : Analysis Phase involves data flow diagram, data dictionary, state
transition diagram, and entity-relationship diagram.
1) Data Flow Diagram: In the data flow diagram, the model describes how the data
flows through the system. We can incorporate the Boolean operators and & or link data
flow when more than one data flow may be input or output from a process.
For example, if we have to choose between two paths of a process we can add an operator
or and if two data flows are necessary for a process we can add an operator. The input of
the process “check-order” needs the credit information and order information whereas the
output of the process would be a cash-order or a good-credit-order.

2) Data Dictionary: The content that is not described in the DFD is described in the data
dictionary. It defines the data store and relevant meaning. A physical data dictionary for
data elements that flow between processes, between entities, and between processes and
entities may be included. This would also include descriptions of data elements that flow
external to the data stores.
A logical data dictionary may also be included for each such data element. All system
names, whether they are names of entities, types, relations, attributes, or services, should
be entered in the dictionary.

3) State Transition Diagram: State transition diagram is similar to the dynamic model.
It specifies how much time the function will take to execute and data access triggered by
events. It also describes all of the states that an object can have, the events under which
an object changes state, the conditions that must be fulfilled before the transition will
occur and the activities were undertaken during the life of an object.

4) ER Diagram: ER diagram specifies the relationship between data store. It is basically

used in database design. It basically describes the relationship between different entities.

30
 Structured Analysis
Structured Analysis is a development method that allows the analyst to understand the
system and its activities in a logical way.
It is a systematic approach, which uses graphical tools that analyze and refine the
objectives of an existing system and develop a new system specification which can be
easily understandable by user.
It has following attributes −
 It is graphic which specifies the presentation of application.
 It divides the processes so that it gives a clear picture of system flow.
 It is logical rather than physical i.e., the elements of system do not depend on
vendor or hardware.
 It is an approach that works from high-level overviews to lower-level details.

Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system
development. They are −
 Data Flow Diagrams
 Data Dictionary
 Decision Trees
 Decision Tables
 Structured English
 Pseudocode

31
1. DFD : It is a technique developed by Larry Constantine to express the requirements
of system in a graphical form. In the data flow diagram, the model describes how the data
flows through the system.
It gives an overview of what data a system processes, what transformations are
performed, what data are stored, what results are produced and where they flow.
Its graphical nature makes it a good communication tool between user and analyst or
analyst and system designer.

Basic Elements of DFD: DFD is easy to understand and quite effective when the
required design is not clear and the user wants a notational language for communication.
However, it requires a large number of iterations for obtaining the most accurate and
complete solution.
The following table shows the symbols used in designing a DFD and their significance −

Types of DFD: DFDs are of two types: Physical DFD and Logical DFD.
Physical DFD Logical DFD
It is implementation dependent. It shows It is implementation independent. It focuses
which functions are performed. only on the flow of data between processes.
It provides low level details of hardware, It explains events of systems and data
software, files, and people. required by each event.
It depicts how the current system operates It shows how business operates; not how the
and how a system will be implemented. system can be implemented.

32
Context Diagram: A context diagram helps in understanding the entire system
by one DFD which gives the overview of a system. It starts with mentioning major
processes with little details and then goes onto giving more details of the
processes with the top-down approach.
The context diagram of mess management is shown below.

2. Data Dictionary: A data dictionary is a structured repository of data

elements in the system. It stores the descriptions of all DFD data elements that
is, details and definitions of data flows, data stores, data stored in data stores,
and the processes. A data dictionary improves the communication between the
analyst and the user. It plays an important role in building a database. Most
DBMSs have a data dictionary as a standard feature. For example, refer the
following table −

3. Decision Trees: Decision trees are a method for defining complex

relationships by describing decisions and avoiding the problems in

33
communication. A decision tree is a diagram that shows alternative actions and
conditions within horizontal tree framework. Thus, it depicts which conditions to
consider first, second, and so on.
Decision trees depict the relationship of each condition and their permissible actions. A
square node indicates an action and a circle indicates a condition. It forces analysts to
consider the sequence of decisions and identifies the actual decision that must be made.

The major limitation of a decision tree is that it lacks information in its format to describe
what other combinations of conditions you can take for testing. It is a single
representation of the relationships between conditions and actions.

For example, refer the following decision tree −

34
4. Decision Tables: Decision tables are a method of describing the complex
logical relationship in a precise manner which is easily understandable.
It is useful in situations where the resulting actions depend on the occurrence of one
or several combinations of independent conditions.
It is a matrix containing row or columns for defining a problem and the actions.

Components of a Decision Table

1. Condition Stub − It is in the upper left quadrant which lists all the condition to be
checked.
2. Action Stub − It is in the lower left quadrant which outlines all the action to be carried
out to meet such condition.
3. Condition Entry − It is in upper right quadrant which provides answers to questions
asked in condition stub quadrant.
4. Action Entry − It is in lower right quadrant which indicates the appropriate action
resulting from the answers to the conditions in the condition entry quadrant

The entries in decision table are given by Decision Rules which define the relationships
between combinations of conditions and courses of action. In rules section,
Y shows the existence of a condition.
N represents the condition, which is not satisfied.
A blank - against action states it is to be ignored.

35
 X (or a check mark will do) against action states it is to be carried out.
For example, refer the following table −
CONDITIONS Rule 1 Rule 2 Rule 3 Rule 4
Advance payment
Y N N N
made

Purchase amount =
- Y Y N
Rs 10,000/-

Regular Customer - Y N -

ACTIONS

Give 5% discount X X - -

Give no discount - - X X

5. Structured English: Structured English is the use of the English language with the
syntax of structured programming to communicate the design of a computer program to
non-technical users by breaking it down into logical steps using straightforward English
words.
 It is best used when sequences and loops in a program must be considered and the
problem needs sequences of actions with decisions.
 It does not have strict syntax rule. It expresses all logic in terms of sequential
decision structures and iterations.

6. Pseudocode: A pseudocode does not conform to any programming language and

expresses logic in plain English.
 It may specify the physical programming logic without actual coding during and
after the physical design.
 It is used in conjunction with structured programming.
 It replaces the flowcharts of a program.

36
Advantages of Structured Analysis
1. Clear and straightforward: Structured Analysis is a clear and straightforward
methodology that is easy to understand and implement.
2. Top-down approach: The top-down approach of Structured Analysis makes it easy to
identify the high-level functions and processes involved in a software system, and to
break them down into smaller, more manageable components.
3. Emphasis on data: Structured Analysis places a strong emphasis on the data that a
software system manipulates, making it easier to understand the relationships between
data and processes.
4. Well-suited for small to medium-sized systems: Structured Analysis is well-suited
for small to medium-sized systems, where the focus is on breaking down complex
systems into simpler, more manageable components.

Disadvantages of Structured Analysis

1. Limited scalability: Structured Analysis is limited in its scalability, and may become
cumbersome when dealing with complex, large-scale systems.
2. Lack of object orientation: Structured Analysis does not provide the object
orientation and encapsulation benefits of OOA, making it more difficult to manage and
maintain large systems over time.
3. Limited ability to model complex relationships: Structured Analysis has a limited
ability to model complex relationships between objects, making it less suitable for
modeling large, complex systems.

Difference between Structured and Object-Oriented Analysis

Structured Analysis Object-Oriented Analysis
The main focus is on the process and The main focus is on data structure and real-
procedures of the system. world objects that are important.
It uses System Development Life Cycle
It uses Incremental or Iterative methodology
(SDLC) methodology for different
to refine and extend our design.
purposes like planning, analyzing,

37
 Structured Analysis Object-Oriented Analysis
designing, implementing, and supporting
an information system.
It is suitable for well-defined projects with It is suitable for large projects with changing
stable user requirements. user requirements.
Risk while using this analysis technique is Risk while using this analysis technique is
high and reusability is also low. low and reusability is also high.
Structuring requirements include DFDs Requirement engineering includes the Use
(Data Flow Diagram), Structured case model (find Use cases, Flow of events,
Analysis, ER (Entity Relationship) Activity Diagram), the Object model (find
diagram, CFD (Control Flow Diagram), Classes and class relations, Object
Data Dictionary, Decision table/tree, and interaction, Object to ER mapping),
the State transition diagram. Statechart Diagram, and deployment diagram.
This technique is old and is not preferred
This technique is new and is mostly preferred.
usually.

Advantages of Object-Oriented Analysis (OOA)

1. Reusable code: OOA enables the creation of reusable objects and design patterns,
reducing the amount of code that needs to be written and improving the quality and
consistency of the software.
2. Scalability: OOA is more scalable than Structured Analysis, making it better suited for
large, complex systems.
3. Object orientation: OOA provides the benefits of object orientation, including
encapsulation, inheritance, and polymorphism, making it easier to manage and maintain
large systems over time.
4. Better modeling of complex relationships: OOA enables better modeling of complex
relationships between objects, making it better suited for modeling large, complex
systems.

Disadvantages of Object-Oriented Analysis (OOA)

38
1. Steep learning curve: OOA can be more difficult to understand and implement than
Structured Analysis, especially for those who are not familiar with object-oriented
programming.
2. Bottom-up approach: The bottom-up approach of OOA can make it difficult to
understand the high-level functions and processes involved in a software system, and to
break them down into smaller, more manageable components.
3. Emphasis on objects: OOA places a strong emphasis on objects, making it more
difficult to understand the relationships between data and processes.

FUNCTION ORIENTED DESIGN

Function Oriented Design is a software design method in which the model is broken into
a series of interacting pieces or modules, each with a distinct function. As a result, the
system is functionally designed.
Generic Procedure
Start with a high-level description of what the software/program does. Refine each part of
the description by specifying in greater detail the functionality of each part. These points
lead to a Top-Down Structure.

Problem in Top-Down Design Method

Mostly each module is used by at most one other module and that module is called its
Parent module.
Solution to the Problem
Designing of reusable module. It means modules use several modules to do their required
functions.

39
Function Oriented Design Strategies: Function Oriented Design Strategies
are as follows:
1) Data Flow Diagram (DFD): A data flow diagram (DFD) maps out the flow of
information for any process or system. It uses defined symbols like rectangles, circles and
arrows, plus short text labels, to show data inputs, outputs, storage points and the routes
between each destination.

2) Data Dictionaries: Data dictionaries are simply repositories to store information about
all data items defined in DFDs. At the requirement stage, data dictionaries contains data
items. Data dictionaries include Name of the item, Aliases (Other names for items),

40
Description / purpose, Related data items, Range of values, Data structure definition /
form.
3) Structure Charts: Structure chart is the hierarchical representation of system which
partitions the system into black boxes (functionality is known to users, but inner details
are unknown). Components are read from top to bottom and left to right. When a module
calls another, it views the called module as a black box, passing required parameters and
receiving results.

The following notations are used in structured chart:

4) Pseudo Code: Pseudo Code is system description in short English like phrases
describing the function. It uses keyword and indentation. Pseudocodes are used as
replacement for flow charts. It decreases the amount of documentation required.

41
Example: Pseudo Code for the addition of two numbers
Step 1: Read A, B
Step 2: Compute C = A + B
Step 3: Print C
Step 4: Stop

OBJECT ORIENTED DESIGN (OOD)

What is Object-Oriented Design (OOD)?
Object-oriented design (OOD) is a programming technique that solves software problems
by building a system of interrelated objects. It makes use of the concepts of classes and
objects, encapsulation, inheritance, and polymorphism to model real-world entities and
their interactions. A system architecture that is modular, adaptable, and simple to
understand and maintain is produced using OOD.

Importance of Object-Oriented Design (OOD) in System Design

Object-Oriented Design (OOD) is important in system design due to several key reasons:
Modularity: OOD simplifies development and maintenance by decomposing
complicated structures into smaller, more manageable components.
 Reusability: Objects and classes can be reused across different projects, reducing
redundancy and saving time.
 Scalability: OOD facilitates system growth by making it simple to incorporate
new objects without interfering with already-existing functionality.
 Maintainability: Encapsulation of data and behavior within objects simplifies
troubleshooting and updates, enhancing system reliability.
 Clear Mapping to Real-World Problems: By modeling software after real-
world entities and their interactions, OOD makes systems more intuitive and
easier to understand.
 Flexibility and Extensibility: Through inheritance and polymorphism, OOD
allows for extending and adapting systems with minimal changes, accommodating
future requirements efficiently.

42
Key Elements of OOD:

1. Objects: Objects are all the entities involved in the solution design. Persons, banks,
companies, and users are all examples of objects. Every object has some properties
associated with it, along with some methods for performing operations on those
attributes.
2) Class: Classes are generic descriptions of objects. An object is a class instance. A
class defines all the properties an object can have and the methods that represent the
object's functionality.
3) Messages: Objects communicate by passing messages. Messages contain the target
object's integrity, the name of the requested operation, and any other action required to
complete the function. Messages are frequently implemented through procedure or
function calls.
4) Abstraction: Abstraction is used in object-oriented design to deal with complexity.
Abstraction involves hiding the complex implementation details and showing only the
essential features of the object

Example: An Animal class can represent general properties and behaviors common to all
animals without detailing the specific implementation for each type of animal.
5) Encapsulation: It is also known as information concealing. Encapsulation is the
bundling of data (attributes) and methods (functions) that operate on the data into a single

43
unit called a class.Encapsulation not only groups together an object's vital information
but also restricts access to the data and operations from the outside world.

Example: Consider a Car class with private attributes speed and fuelLevel and public
methods accelerate(), brake(), and refuel(). The internal state of speed and fuelLevel can
only be modified through these methods, ensuring controlled access.

6) Inheritance: Inheritance is a mechanism where a new class inherits properties and

behaviors (methods) from an existing class. This promotes code reuse and establishes a
natural hierarchy between classes.

Example: A Vehicle class can be a parent class with common attributes like make and
model, and child classes like Car and Bike can inherit these attributes and have additional
specific properties

44
7) Polymorphism: OOD languages give a technique for assigning the same name to
methods that perform similar functions but differ in arguments. This is referred to as
polymorphism, and it allows a single interface to perform functions for multiple types.
The relevant piece of the code is run depending on how the service is invoked.

Example: Both Dog and Cat classes inherit from Animal and implement the
make_sound method. A function can take an Animal object and call make_sound,
regardless of whether it’s a Dog or Cat.

UML Diagrams for Visualizing OOD

Diagrams created using the Unified Modeling Language (UML) are useful tools for
understanding and clarifying object-oriented system structure. They serve as a blueprint,
showing the interactions between many components of a system, which makes difficult
concepts simpler to understand and communicate.

45
Here are some common UML diagrams and how they contribute to object-oriented
design:
 Class Diagrams: These diagrams show the structure of a system by highlighting
the classes, their attributes, and relationships. This is useful in visualizing how
data and behaviors are organized, which is the foundation of object-oriented
design.
 Sequence Diagrams: Sequence diagrams illustrate how objects in a system
interact over time. They show the flow of messages and actions, helping designers
see the order in which things happen. This makes it easier to understand the
dynamic behavior of a system.
 State Diagrams: State diagrams represent the various states of an object and the
transitions between them. They help designers understand how objects respond to
different events, which is key for designing systems that change over time.
By using these diagrams, developers can make sure everyone has a clear picture of the
system’s structure and behavior, making it easier to collaborate and avoid
misunderstandings.

Difference Between Function Oriented Design and Object Oriented

Design
COMPARISON FUNCTION ORIENTED
OBJECT ORIENTED DESIGN
FACTORS DESIGN
The basic abstractions are not the
The basic abstractions, which
real world functions but are the data
Abstraction are given to the user, are real
abstraction where the real world
world functions.
entities are represented.
Function are grouped together on the
Functions are grouped together
basis of the data they operate since
Function by which a higher level
the classes are associated with their
function is obtained.
methods.

execute carried out using structured Carried out using UML

46
 COMPARISON FUNCTION ORIENTED
OBJECT ORIENTED DESIGN
FACTORS DESIGN
analysis and structured design
i.e, data flow diagram
In this approach the state
In this approach the state
information is not represented in a
information is often
State information centralized memory but is
represented in a centralized
implemented or distributed among
shared memory.
the objects of the system.

Approach It is a top down approach. It is a bottom up approach.

Begins by considering the use
Begins by identifying objects and
Begins basis case diagrams and the
classes.
scenarios.
In function oriented design we
Decompose decompose in We decompose in class level.
function/procedure level.
This approach is mainly used This approach is mainly used for
Use for computation sensitive evolving system which mimics a
application. business or business case.

Data flow DIAGRAM (DFD)

DFD is the abbreviation for Data Flow Diagram. The flow of data in a system or
process is represented by a Data Flow Diagram (DFD). It also gives insight into the
inputs and outputs of each entity and the process itself. Data Flow Diagram (DFD) does
not have a control flow and no loops or decision rules are present. Specific operations,
depending on the type of data, can be explained by a flowchart. It is a graphical tool,
useful for communicating with users, managers and other personnel. it is useful for
analyzing existing as well as proposed systems.
It should be pointed out that a DFD is not a flowchart. In drawing the DFD, the designer
has to specify the major transforms in the path of the data flowing from the input to the

47
output. DFDs can be hierarchically organized, which helps in progressively partitioning
and analyzing large systems.
It provides an overview of
What data is system processes.
 What transformation are performed.
 What data are stored.
 What results are produced , etc.
Data Flow Diagram can be represented in several ways. The Data Flow Diagram (DFD)
belongs to structured-analysis modeling tools. Data Flow diagrams are very popular
because they help us to visualize the major steps and data involved in software-system
processes.
Characteristics of Data Flow Diagram (DFD)
Below are some characteristics of Data Flow Diagram (DFD):
1. Graphical Representation: Data Flow Diagram (DFD) use different symbols and
notation to represent data flow within system. That simplify the complex model.
2. Problem Analysis: Data Flow Diagram (DFDs) are very useful in understanding a
system and can be effectively used during analysis. Data Flow Diagram (DFDs) are quite
general and are not limited to problem analysis for software requirements specification.
3. Abstraction: Data Flow Diagram (DFD) provides a abstraction to complex model i.e.
DFD hides unnecessary implementation details and show only the flow of data and
processes within information system.
4. Hierarchy: Data Flow Diagram (DFD) provides a hierarchy of a system. High- level
diagram i.e. 0-level diagram provides an overview of entire system while lower-level
diagram like 1-level DFD and beyond provides a detailed data flow of individual process.
5. Data Flow: The primary objective of Data Flow Diagram (DFD) is to visualize the
data flow between external entity, processes and data store. Data Flow is represented by
an arrow Symbol.
6. Ease of Understanding: Data Flow Diagram (DFD) can be easily understand by both
technical and non-technical stakeholders.

48
7. Modularity: Modularity can be achieved using Data Flow Diagram (DFD) as it breaks
the complex system into smaller module or processes. This provides easily analysis and
design of a system.

Types of Data Flow Diagram (DFD)

There are two types of Data Flow Diagram (DFD)
1. Logical Data Flow Diagram
2. Physical Data Flow Diagram

1. Logical Data Flow Diagram (DFD): Logical data flow diagram mainly focuses
on the system process. It illustrates how data flows in the system. Logical Data
Flow Diagram (DFD) mainly focuses on high level processes and data flow
without diving deep into technical implementation details. Logical DFD is used in
various organizations for the smooth running of system. Like in a Banking
software system, it is used to describe how data is moved from one entity to
another.

2. Physical Data Flow Diagram: Physical data flow diagram shows how the
data flow is actually implemented in the system. In the Physical Data Flow

49
Diagram (DFD), we include additional details such as data storage, data
transmission, and specific technology or system components. Physical DFD is
more specific and close to implementation.

Levels of Data Flow Diagram (DFD)

1) 0-level DFD: Level 0 is the highest-level Data Flow Diagram (DFD), which
provides an overview of the entire system. It shows the major processes, data
flows, and data stores in the system, without providing any details about the
internal workings of these processes. It is also known as a context diagram. It’s
designed to be an abstraction view, showing the system as a single process with
its relationship to external entities. It represents the entire system as a single
bubble with input and output data indicated by incoming/outgoing arrows.

50
1) 2-Level Data Flow Diagram (DFD): 2-Level provides an even more
detailed view of the system by breaking down the sub-processes identified in the
level 1 Data Flow Diagram (DFD) into further sub-processes. Each sub-process
is depicted as a separate process on the level 2 DFD. The data flows and data
stores associated with each sub-process are also shown.
2-Level Data Flow Diagram (DFD) goes one step deeper into parts of 1-level DFD. It can
be used to plan or record the specific/necessary detail about the system’s functioning.

2) 3-Level Data Flow Diagram (DFD): 3-Level is the most detailed level of
Data Flow Diagram (DFDs), which provides a detailed view of the processes,
data flows, and data stores in the system. This level is typically used for complex
systems, where a high level of detail is required to understand the system. Each
process on the level 3 DFD is depicted with a detailed description of its input,
processing, and output. The data flows and data stores associated with each
process are also shown.

51
Advantages of Data Flow Diagram (DFD)
1) It helps us to understand the functioning and the limits of a system.
2) It is a graphical representation which is very easy to understand as it helps visualize
contents.
3) Data Flow Diagram represent detailed and well explained diagram of system
components.
4) It is used as the part of system documentation file.
5) Data Flow Diagrams can be understood by both technical or nontechnical person
because they are very easy to understand.

Disadvantages of Data Flow Diagram (DFD)

1) Can be time-consuming: Creating DFDs can be a time-consuming process, especially
for complex systems.

52
2) Limited focus: DFDs focus primarily on the flow of data in a system, and may not
capture other important aspects of the system, such as user interface design, system
security, or system performance.
3) Can be difficult to keep up-to-date: DFDs may become out-of-date over time as the
system evolves and changes.
4) Requires technical expertise: While DFDs are easy to understand, creating them
requires a certain level of technical expertise and familiarity with the system being
analyzed.

How to Draw Data Flow Diagram?

Following are the steps to Draw Data Flow Diagram
 Understand the System
 Identify External Entities
 Identify Processes
 Identify Data Stores
 Use Standard Symbols
 Create Level 0 Diagram
 Based on Complexity Draw Further Level Diagram like Level 1, 2 and so on.
 Identify Data Flows:
 Number Processes and Data Stores
 Review and Validate

What is an Entity Relationship Diagram (ERD)?

An entity relationship diagram (ER diagram or ERD) is a visual representation of
how items in a database relate to each other. Entity Relationship Diagram, also known as
ERD, ER Diagram or ER model.
Symbols Used in ER Model : ER Model is used to model the logical view of
the system from a data perspective which consists of these symbols:
 Rectangles: Rectangles represent Entities in the ER Model.
 Ellipses: Ellipses represent Attributes in the ER Model.

53
  Diamond: Diamonds represent Relationships among Entities.
 Lines: Lines represent attributes to entities and entity sets with other relationship
types.
Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
Double Rectangle: Double Rectangle represents a Weak Entity.

Components of ER Diagram: ER Model consists of Entities, Attributes, and

Relationships among Entities in a Database System.

What is Entity?
An Entity may be an object with a physical existence – a particular person, car, house, or
employee – or it may be an object with a conceptual existence – a company, a job, or a
university course.

54
What is Entity Set?
An Entity is an object of Entity Type and a set of all entities is called an entity set. For
Example, E1 is an entity having Entity Type Student and the set of all students is called
Entity Set. In ER diagram, Entity Type is represented as:

We can represent the entity set in ER Diagram but can’t represent entity in ER Diagram
because entity is row and column in the relation and ER Diagram is graphical
representation of data.
Types of Entity: There are two types of entity.
1. Strong Entity: A Strong Entity is a type of entity that has a key Attribute.
Strong Entity does not depend on other Entity in the Schema. It has a primary
key, that helps in identifying it uniquely, and it is represented by a rectangle.
These are called Strong Entity Types.
2. Weak Entity: An Entity type has a key attribute that uniquely identifies each
entity in the entity set. But some entity type exists for which key attributes can’t
be defined. These are called Weak Entity types .
For Example, A company may store the information of dependents (Parents, Children,
Spouse) of an Employee. But the dependents can’t exist without the employee. So
Dependent will be a Weak Entity Type and Employee will be Identifying Entity type for
Dependent, which means it is Strong Entity Type .
A weak entity type is represented by a Double Rectangle. The participation of weak
entity types is always total. The relationship between the weak entity type and its
identifying strong entity type is called identifying relationship and it is represented by a
double diamond.

55
What is Attributes?
Attributes are the properties that define the entity type. For example, Roll_No, Name,
DOB, Age, Address, and Mobile_No are the attributes that define entity type Student. In
ER diagram, the attribute is represented by an oval.

Types of Attributes
1. Key Attribute : The attribute which uniquely identifies each entity in the
entity set is called the key attribute. For example, Roll_No will be unique for each
student. In ER diagram, the key attribute is represented by an oval with
underlying lines.

2. Composite Attribute : An attribute composed of many other attributes is

called a composite attribute. For example, the Address attribute of the student
Entity type consists of Street, City, State, and Country. In ER diagram, the
composite attribute is represented by an oval comprising of ovals.

56
3. Multivalued Attribute : An attribute consisting of more than one value for a
given entity. For example, Phone_No (can be more than one for a given student).
In ER diagram, a multivalued attribute is represented by a double oval .

4. Derived Attribute : An attribute that can be derived from other attributes of the
entity type is known as a derived attribute. e.g.; Age (can be derived from DOB).
In ER diagram, the derived attribute is represented by a dashed oval.

The Complete Entity Type Student with its Attributes can be represented as:

Relationship Type and Relationship Set

A Relationship Type represents the association between entity types. For example,
‘Enrolled in’ is a relationship type that exists between entity type Student and Course. In

57
ER diagram, the relationship type is represented by a diamond and connecting the entities
with lines.

A set of relationships of the same type is known as a relationship set. The following
relationship set depicts S1 as enrolled in C2, S2 as enrolled in C1, and S3 as registered in
C3.

Degree of a Relationship Set:

The number of different entity sets participating in a relationship set is called the
degree of a relationship set.
1. Unary Relationship: When there is only ONE entity set participating in a relation, the
relationship is called a unary relationship. For example, one person is married to only one
person.

2. Binary Relationship: When there are TWO entities set participating in a relationship,
the relationship is called a binary relationship. For example, a Student is enrolled in a
Course.

58
3. Ternary Relationship: When there are three entity sets participating in a relationship,
the relationship is called a ternary relationship.

4. N-ary Relationship: When there are n entities set participating in a relationship, the
relationship is called an n-ary relationship.

What is Cardinality?
The number of times an entity of an entity set participates in a relationship set is
known as cardinality .
Cardinality can be of different types:
1. One-to-One: When each entity in each entity set can take part only once in the
relationship, the cardinality is one-to-one. Let us assume that a male can marry one
female and a female can marry one male. So the relationship will be one-to-one.
the total number of tables that can be used in this is 2

Using Sets, it can be represented as:

2. One-to-Many: In one-to-many mapping as well where each entity can be related to

more than one entity and the total number of tables that can be used in this is 2. Let us

59
assume that one surgeon department can accommodate many doctors. So the Cardinality
will be 1 to M. It means one department has many Doctors.
total number of tables that can used is 3.

Using sets, one-to-many cardinality can be represented as:

3. Many-to-One: When entities in one entity set can take part only once in the
relationship set and entities in other entity sets can take part more than once in the
relationship set, cardinality is many to one. Let us assume that a student can take only one
course but one course can be taken by many students. So the cardinality will be n to 1. It
means that for one course there can be n students but for one student, there will be only
one course.
The total number of tables that can be used in this is 3.

Using Sets, it can be represented as:

60
In this case, each student is taking only 1 course but 1 course has been taken by many
students.
4. Many-to-Many: When entities in all entity sets can take part more than once in the
relationship cardinality is many to many. Let us assume that a student can take more than
one course and one course can be taken by many students. So the relationship will be
many to many.
the total number of tables that can be used in this is 3.

Using Sets, it can be represented as:

61
In this example, student S1 is enrolled in C1 and C3 and Course C3 is enrolled by S1, S3,
and S4. So it is many-to-many relationships.

How to Draw ER Diagram?

 The very first step is Identifying all the Entities, and place them in a Rectangle,
and labeling them accordingly.
 The next step is to identify the relationship between them and place them
accordingly using the Diamond, and make sure that, Relationships are not
connected to each other.
 Attach attributes to the entities properly.
 Remove redundant entities and relationships.
 Add proper colors to highlight the data present in the database.

62
ER Diagram of Bank Management System:

ER diagram of Bank has the following description :

 Bank have Customer.
 Banks are identified by a name, code, address of main office.
 Banks have branches.
 Branches are identified by a branch_no., branch_name, address.
 Customers are identified by name, cust-id, phone number, address.
 Customer can have one or more accounts.
 Accounts are identified by account_no., acc_type, balance.
 Customer can avail loans.
 Loans are identified by loan_id, loan_type and amount.
 Account and loans are related to bank’s branch.

63
Following are the differences between SA and SD
Aspect Structural Analysis Structural Design

- Individual components and modules are

Definition -High-level software system structure.
meticulously designed.

-System-level issues include components, - Component-level concerns specify how each

Focus
modules, and their interactions. system component will be implemented.

Concentrates on individual modules or

Scope Encompasses the entire system.
components.

Abstraction High-level abstraction. Abstraction levels range from low to medium.

Major structural decisions include selecting

Detailed decisions about algorithms, data
Decisions the architectural style, patterns, and
structures, and code styles.
components.

Establishes the system's overall structure and Converts the high-level architecture into
Purpose behaviour while meeting high-level detailed requirements for each component or
requirements module.

Architectural diagrams (such as UML Detailed design documentation includes class

Artifacts
diagrams) and architectural papers. diagrams, sequence diagrams, and so forth.

Example Archi, Enterprise Architect. Visual Studio, Eclipse, and Rational Rose

64