SOFTWARE DESIGN

CONCEPTS
MODULE III
Introduction of design process
Software design is a step-by-step process where we take the requirements for a project and
turn them into a detailed plan or "blueprint" for building the software.
At first, this plan gives a broad, overall picture of the software.
 As the process continues, the design becomes more detailed, breaking down the data,
functionality, and behaviour needed to meet the specific requirements.
software quality guidelines
The design must be a readable, understandable guide for those who generate code for those
who test and subsequently support the software.
The design should provide a complete picture of the software, addressing the data,
functional, and behavioral domains.
The design must include everything clearly stated in the requirements document and also
take into account any unstated needs or expectations that stakeholders (people involved in the
project) might have.
Quality Guidelines
To judge how good a software design is, we and our team need to set clear technical
standards or guidelines. These criteria help ensure the design meets quality expectations and
works as intended.
A good software design should have three key qualities:
1. It should follow well-known architectural styles or patterns, making it easier to
understand and maintain.
2. The components (or building blocks) of the design should follow good practices, ensuring
they are efficient, reliable, and easy to work with.
3. The design should allow for step-by-step development, so it can be built and tested
gradually.
A design should be modular; that is, the software should be logically partitioned into elements
or subsystems.
 Data: How information is stored, organized, and accessed.
 Architecture: The overall structure of the software, including how different parts work together.
 Interfaces: How different parts of the software or the user interact with each other.
 Components: The individual parts or modules that make up the software.
A design should contain distinct representations of data, architecture, interfaces, and components.
A design should lead to components that exhibit independent functional characteristics.
A good design should create parts of the software (called components) that can work on their own,
each handling a specific function or task without depending too much on other parts.
A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.
A design should be derived using a repeatable method that is driven by information obtained
during software requirements analysis.
 Quality Attributes
Hewlett-Packard developed a set of software quality attributes that has been given the
abbreviation FURPS - Functionality, Usability, Reliability, Performance, and
Supportability.
1. Functionality: refers to the features and capabilities a software system provides to meet
the needs of its users. It describes what the software is designed to do, including the tasks
it can perform, the problems it can solve, and how it responds to user inputs
2. Usability: refers to how easy and efficient it is for users to interact with a software
application.
3. Reliability: It means is how dependable and stable the program is. How often it fails
and how serious those failures are. The accuracy of its results, ensuring it produces correct
outputs. Mean-Time-to-Failure (MTTF), which measures how long the software runs
before it fails.
4. Performance: It is measured by considering processing speed, response time, resource
consumption, throughput, and efficiency.
5. Supportability: in software refers to how easy it is to manage, improve, and adapt the
software over time. It includes:
•Extensibility: How easily new features can be added to the software.
•Adaptability: How well the software can be adjusted to work in different environments or
situations.
•Serviceability: How easily issues or bugs can be fixed.
 The Evolution of Software Design
 The evolution of software design refers to how the approach to creating software has
changed and improved over time.
 In the early days, software was often built in a very simple and straightforward way,
with fewer tools and techniques available.
 As technology advanced, software design became more complex and structured.
 New methods and principles were developed to make software easier to build, maintain,
and scale.
 Today, software design is an ongoing process, with teams using modern tools, frameworks,
and best practices to create high-quality, adaptable software that meets the needs of users and
businesses.
 Example: In the early days of the internet, websites were simple static pages, with basic
HTML and minimal interactivity.

 As the internet grew, web applications became more interactive and complex. The
introduction of technologies like JavaScript allowed for dynamic content, enabling
websites to react to user inputs without reloading the page. Developers began focusing on
better design practices, such as separating the structure (HTML), style (CSS), and
behavior (JavaScript).

 More recently, frameworks like React, Angular, and Vue have been developed to make
building web applications more efficient and maintainable.
 Design Concepts
Over the years, a group of key software design ideas has developed in the field of software
engineering.
While the focus on each of these ideas has changed at different times, all of them have remained
important and useful in creating software.
These concepts have stood the test of time because they are still relevant and help guide the
design of software today.
Each helps you answer the following questions:
1. What criteria can be used to partition software into individual components?
2. How is function or data structure detail separated from a conceptual representation of the
software?
3. What uniform criteria define the technical quality of a software design?
A real-life example of the concept of modularity is the design of
a smartphone.
Think of a smartphone as a collection of independent modules or
parts: the camera, the battery, the screen, the operating
system, and various apps. Each of these parts has its own specific
function and can be updated or replaced without affecting the
entire phone.
This modular design makes it easier to improve or repair specific
features without disrupting the whole system. Similarly, in
software development, modularity allows developers to work
on individual parts of a program without affecting the entire
application.
 Types of design concepts
1. Abstraction

2. Architecture

3. Patterns

4. Separation of concerns

5. Modularity

6. Information hiding

7. Functional Independence

8. Refinement

9. Aspects

10. Refactoring
1.ABSTRACTION
Abstraction in software engineering means simplifying complex systems by focusing on the
most important parts and ignoring unnecessary details.
It helps developers understand and work with software more easily by showing only what’s
needed while hiding how things work behind the scenes.
This makes the software easier to manage, read, and improve over time.
How Abstraction Works?
•Removes unnecessary details: Abstraction focuses on the essential features of a system, while
ignoring less relevant details.
•Simplifies large data structures: Abstraction breaks large data sets into smaller, more
manageable chunks.
•Creates models and interfaces: Abstraction allows developers to create models or interfaces
that represent the underlying functionality
A procedural abstraction refers to a sequence of instructions that have a specific and limited
function. The name of a procedural abstraction implies these functions, but specific details are
suppressed. Example: When you use an ATM, you just insert your card, enter your PIN, and
perform transactions like withdrawing money or checking balance. You don’t need to know how
the ATM processes your request, communicates with the bank, or verifies your PIN.
A data abstraction is a named collection of data that describes a data object. In other words,
data abstraction is hiding the internal details of data and exposing only the necessary parts.
Example: A Car class has a method to start the engine, but the user doesn’t see how the engine
works internally.
2.ARCHITECTURE
Software architecture is like a blueprint for building a software system. Just like a house has a
structure with rooms, walls, and electrical connections, software also has a structure made up of
different components (modules) that work together.
 It defines how different parts of the software (modules) are arranged and connected.It explains
how different parts communicate with each other, like how different departments in a company
work together.
It shows how information moves between different parts of the system, like how money
transfers between bank accounts.
Instead of looking at small code details, architecture focuses on how major parts of the system
work together as a whole.
One of the main purposes of designing software is to create a well-structured and organized
system that is easy to maintain, understand, and scale.
A set of properties that should be specified as part of an architectural design.
Structural properties: Structural properties in software architecture define the building blocks of
a system and how they work together. These building blocks, called components (like modules,
objects, or filters), are like different parts of a machine, each having a specific role.
Extra-functional properties: It refers to the qualities that make a software system efficient,
secure, and reliable. While the main focus of software design is on building the system’s structure,
it is equally important to ensure that the system performs well under different conditions. For
example, a system should be fast (performance), handle a large number of users (capacity), run
without crashing (reliability), protect user data (security), and adapt to changes (adaptability).
Families of related systems: It refers to software systems that share common features and design
patterns. Instead of creating a new design from scratch for each system, developers reuse proven
architectural building blocks to save time and effort.
3. Patterns - A pattern is a tried-and-tested solution to a common problem that keeps appearing
in similar situations. It is like a shortcut that helps developers solve issues efficiently without
reinventing the wheel. Each pattern has a name and describes how to solve a specific problem in
a particular context while balancing different needs.
4. Separation of Concerns - Separation of concerns is a design concept that suggests that any
complex problem can be more easily handled if it is subdivided into pieces that can each be
solved and/or optimized independently. A concern is a feature or behavior that is specified as part
of the requirements model for the software. By separating concerns into smaller, and therefore
more manageable pieces, a problem takes less effort and time to solve.
5. Modularity – It is the most common manifestation of separation of concerns. Software is
divided into separately named and addressable components, sometimes called modules, that are
integrated to satisfy problem requirements. You modularize a design (and the resulting program)
so that development can be more easily planned; software increments can be defined and
delivered; changes can be more easily accommodated; testing and debugging can be conducted
more efficiently, and long-term maintenance can be conducted without serious side effects.
6. Information Hiding - Modules in software should be designed in a way that keeps their
internal details private and only shares the necessary information with other modules. This
means that each module works independently, and other modules cannot access its internal
algorithms or data unless needed. This concept, called hiding, ensures that different parts of the
software interact only through controlled communication, improving security and reducing
errors. Abstraction helps define what each module does, while hiding protects the internal
workings, making the software more organized, easier to maintain, and less prone to bugs.
Example: A login system consists of different modules that handle user input, authentication,
and database management. Each module performs its task without exposing unnecessary
details to others.
7. Functional Independence
Functional independence means that each module in a software system should focus on a single
task and minimize unnecessary connections with other modules.
This makes the software easier to understand, test, and modify. Instead of one big, complex
program, the system is divided into small, self-contained modules, each handling a specific
requirement.
These modules should only communicate when necessary, using simple and clear interfaces.
For example, in an online shopping app, the payment module should only handle payments,
while the order module manages orders. This way, changes to one module do not affect others,
making the software more efficient and easier to maintain.
Independence is assessed using two qualitative criteria: cohesion and coupling.
1. A cohesion module is one that focuses on a single task and doesn’t rely much on other parts
of the program. In simple terms, a module should do one thing well. For example, C, D, E
from Module B are independent, It is passing information in one particular module termed as
cohesion.
2. Coupling refers to how dependent different modules are on each other in a software system.
If modules are tightly connected, changes in one module can affect others, making the
software harder to maintain. On the other hand, loose coupling means modules interact only
when necessary and have simple connections, making the system more flexible and easier to
update.
8. Refinement
Stepwise refinement is a top-down approach to designing software, where a big task is broken
down into smaller, more detailed steps until it becomes simple enough to be written in actual
programming code. This method, introduced by Niklaus Wirth, helps developers move from a
general idea to a fully detailed program step by step.
Stepwise Refinement Example: Adding Two Numbers
We start with a high-level task and gradually break it down into smaller, more detailed steps.
Step 1: High-Level Task
👉 Add two numbers
Step 2: Break It Down into Key Steps
•Get the first number
•Get the second number
•Add both numbers
•Display the result
9. Aspects – It refers to concerns in software development that affect multiple parts of a system
and cannot be easily separated into individual modules. When analyzing requirements, different
concerns like security, logging, performance, and error handling may be identified. Some of
these can be handled independently, but others—like security or error handling—are needed
across multiple modules of the system. These cross-cutting concerns are called aspects
because they span the entire system rather than staying within a single module. Managing
aspects properly ensures the system is well-organized, efficient, and easier to maintain.
10. Refactoring – It is the process of improving the structure of code without changing how it
works. It helps make the code cleaner, more efficient, and easier to understand. Think of it
like reorganizing a messy room—you don’t remove anything important, but you arrange things
better so it's easier to find and use. For example, in a program, refactoring might involve
renaming confusing variables, simplifying complex logic, or breaking big functions into
smaller ones. This makes the software easier to maintain, debug, and extend without affecting
how it functions.
THE DESIGN
MODEL
The Design Model
The design model can be viewed in two different dimensions:
1. Process Dimension
2. Abstract Dimension
The process dimension(horizontal) represents how a design model evolves over time as various
design tasks are carried out during the software development process. This evolution occurs
iteratively, incorporating refinements, optimizations, and adaptations based on feedback, testing,
and implementation constraints.
The abstraction dimension(vertical) in software design refers to the level of detail at which a
system is described. As elements of the analysis model (which focuses on what the system
should do) are transformed into their design equivalents (which focus on how the system will do
it), the details become more refined through iterative improvements.
The elements of the design model use many of the same UML diagrams that were used in the
analysis model.
The difference is that these diagrams are refined and elaborated as part of design; more
implementation-specific detail is provided, and architectural structure and style, components that
reside within the architecture, and interfaces between the components and with the outside world
are all emphasized
1. Data Design Elements
Data Design Elements focus on how data is organized, stored, and processed in a software
system.
It starts with a high-level data model, which represents how users see and interact with data.
This model is then refined step by step into a detailed format that the computer can process
efficiently.
The way data is structured affects the overall software design, as the system must be built to
handle, retrieve, and manipulate data smoothly.
 At a deeper level, choosing the right data structures and algorithms is crucial for making
software fast, reliable, and efficient. In short, good data design ensures the system runs
smoothly and meets user needs effectively.
Example:
Flipkart, like any e-commerce platform, handles vast amounts of data efficiently through proper
data design.
From a user's perspective, data includes products, users, orders, and sellers, where each has
specific details like product name, price, category, and stock availability.
To process this data effectively, Flipkart structures it into database tables, such as a Products
Table storing product details, a Users Table for customer information, an Orders Table linking
users to purchases. To ensure fast processing, Flipkart uses hash tables for quick lookups, tree
structures for organizing product categories, graphs for optimizing delivery routes, and queues
for handling customer support and payment processing.
With a well-designed data system, Flipkart enables fast product searches, smooth order
processing, real-time tracking, and personalized recommendations, ensuring a seamless
shopping experience for millions of users.
2. Architectural Design Elements
Architectural design in software is like a floor plan for a house. Just as a floor plan shows the layout
of rooms, doors, and windows, architectural design shows how different parts of the software are
structured and connected.
It gives a clear overall view of how the system will function.
The architectural model is created based on three key factors:
(1) The type of software being built, which helps define its purpose and features,
(2) The requirements model, which includes diagrams and relationships that show how data flows
through the system.
(3) Existing architectural styles, which provide proven design patterns to follow. A well-designed
software architecture ensures the system is organized, efficient, and easy to maintain.
3. Interface Design Elements
There are three important elements of interface design:
(1) The user interface (UI)
(2) External interfaces to other systems, devices, networks, or other producers or consumers of
information.
(3) Internal interfaces between various design components.

These interface design elements allow the software to communicate externally and enable
internal communication and collaboration among the components that populate the software
architecture.
1. UI (User Interface) design, also known as usability design, focuses on making software
easy to use and visually appealing. It includes Aesthetic elements, like colors, layout, and
graphics, to make the interface look good. Ergonomic elements, such as how information is
arranged and how users navigate the system, ensuring a smooth experience.
2. External interfaces are the connections between a software system and other systems,
devices, or users. These interfaces need clear and accurate details about where data is sent
or received. For example, a website might connect to a payment gateway to process
transactions or a mobile app.
3. Internal interfaces define how different parts (components) of a software system interact
with each other. This is important in component-level design, where different modules or
classes need to communicate. internal interfaces ensure they can exchange messages and
work together smoothly. For example, in an e-commerce website, the order processing
module must communicate with the payment module to complete a purchase.
 4. Component-Level Design
Elements
Component-level design focuses on the detailed design of each individual part of the
software.
It describes how each component works internally, including the data it stores, the processes
it performs, and how other parts of the system can interact with it.
This involves defining data structures (how information is stored), algorithms (how tasks are
processed), and interfaces (how other components can access its functions).
For example, in a banking app, the transaction processing component would have its own
logic for validating payments, updating balances, and recording history, while allowing other
parts of the app (like the user dashboard) to access this information securely.
A well-structured component-level design ensures efficiency, reliability, and easy maintenance
of the software.
Architectural
Design
Defining Architecture
An architectural description of a software-based system must exhibit a unique characteristics.
When they write:
1. Developers want clear, decisive guidance on how to proceed with design.
2. Customers want a clear understanding on the environmental changes that must occur and
assurances that the architecture will meet their business needs.
3. Other architects want a clear, salient understanding of the architecture’s key aspects.
4. Each of these “wants” is reflected in a different view represented using a different viewpoint.
The IEEE standard defines an architectural description as “a collection of products to document
an architecture.” The description itself is represented using multiple views, where each view is
“a representation of a whole system from the perpective of a related set of [stakeholder]
concerns.” A view is created according to rules and conventions.
 Why Is Architecture Important?
1. Representations of software architecture are an enabler for communication between all
parties (stakeholders) interested in the development of a computer-based system -
Software architecture diagrams or models help people understand how a system is built.,
including developers, project managers, and clients. These representations make it easier to
share ideas, spot potential problems, and ensure everyone agrees on how the system should
work. By having a clear picture of the architecture, teams can plan better, reduce mistakes,
and build a more reliable system.
2. The architecture highlights early design decisions that will have a profound impact on
all software engineering work that follows and, as important, on the ultimate success of
the system as an operational entity - The architecture of a software system includes
important design choices made early in the project. These decisions affect everything that
comes after, including how the software is developed, tested, and maintained. A good
architecture helps ensure the system works well and meets its goals. If the design is strong,
the final system will be more reliable and successful when it is actually used.
3. Architecture “constitutes a relatively small, intellectually graspable model of how the
system is structured and how its components work together” - Software architecture is like a
simplified blueprint of a system that shows how it is built and how its parts work together. It
gives a clear, easy-to-understand view of the system’s structure, making it easier for people to
design, develop, and manage it. Instead of focusing on every small detail, architecture provides a
big-picture view that helps teams understand how different components connect and function as a
whole.
Software architecture is crucial because it serves as the foundation of a system, guiding its
design, development, and future growth. A well-planned architecture ensures that the system is
organized, scalable, and maintainable, making it easier to add new features and fix issues over
time.
Architectural STYLES
An architectural style is a transformation that is imposed on the design of an entire system. The
intent is to establish a structure for all components of the system. In the case where an existing
architecture is to be reengineered, the imposition of an architectural style will result in fundamental
changes to the structure of the software including a reassignment of the functionality of components.
An architectural pattern, like an architectural style, imposes a transformation on the design of an
architecture. However, a pattern differs from a style in a number of fundamental ways:
(1) the scope of a pattern is less broad, focusing on one aspect of the architecture rather than the
architecture in its entirety.
(2) a pattern imposes a rule on the architecture, describing how the software will handle some aspect
of its functionality at the infrastructure level.
(3) architectural patterns tend to address specific behavioral issues within the context of the
architecture.
 Categories of Architectural
Styles
1. Data-centered architectures: A data store (e.g., a file or database) resides at the center of this
architecture and is accessed frequently by other components that update, add, delete, or otherwise
modify. Data-centered architectures promote integrability. That is, existing
componentscanbechangedandnewclientcomponentsaddedtothearchitecture without concern about
other clients (because the client components operate independently).
2. Data-flow architectures: This architecture is applied when input data are to be transformed
through a series of computational or manipulative components into output data. A pipe-and-filter
pattern has a set of components, called filters, connected by pipes that transmit data from one
component to the next. Each filter works independently. If the data flow degenerates into a single
line of transforms, it is termed batch sequential.
3. Layered architecture: A number of different layers are defined, each accomplishing
operations that progressively become closer to the machine instruction set. At the outer layer,
components service user interface operations. At the inner layer, components perform operating
system interfacing. Intermediate layers provide utility services and application software
functions.
Architectural Patterns
Pattern in architecture refers to the concept of capturing architectural design concepts as iconic and
reusable descriptions.
When creating a software plan, you will see that some problems affect the whole system. These are
big challenges that need to be solved for the software to work properly.
For example, in an online banking applications. A common challenge is ensuring that users can
securely access their accounts, check balances, transfer money, and pay bills while protecting
their personal and financial information. The software must handle security threats, user
authentication, and smooth transaction processing to provide a safe and reliable banking experience.
Addressing these challenges early in the design helps create a secure and user-friendly system.
Architectural patterns help solve specific problems in software design based on the needs of the
application and any limitations, such as performance, security, or scalability. These patterns provide a
ready-made solution that developers can use as a starting point to build the system’s architecture.
 Component level design –
Coupling
Coupling is a qualitative measure of the degree to which classes are connected to one another. As
classes (and components) become more interdependent, coupling increases. An important
objective in component-level design is to keep coupling as low as is possible.
Example of Coupling in a Company: Departments in an Organization
1. Loose Coupling (Good Design) – Independent Departments
In a well-structured company, different departments like HR, Finance, Sales, and IT work
independently but communicate when needed. For example:
•The HR department manages employee records and hiring.
•The Finance department handles payroll and budgets.
•If HR needs to process salaries, it sends necessary employee data to Finance without sharing
all internal HR details.
2. Tight Coupling (Bad Design) – Overdependent Departments
If the HR and Finance systems are directly linked and share all their data without clear
separation, a small change in HR could disrupt Finance. For example:
•If HR changes how employee records are stored, Finance might stop working properly because
it relies on HR’s exact data format.
•Updating or replacing one system becomes difficult and risky because they are too dependent
on each other.
coupling categories:
1. Content coupling: It occurs when one part of program directly depend on the hidden
details of another part. In other words, Content coupling happens when one module directly
accesses or modifies the internal details of another module instead of using a proper interface.
This makes the system highly dependent and difficult to change or maintain.
2. Common coupling: Common coupling happens when multiple parts of a system share the
same global data. This means different modules depend on the same set of data, which can
create problems if one module changes the data unexpectedly, affecting all the others.
3. Control coupling: Occurs when operation A() invokes operation B() and passes a control flag
to B. The problem with this form of coupling is that an unrelated change in B, this type is termed
as control coupling.
4. Data coupling: Data coupling happens when two software modules share only necessary data
to communicate, without depending too much on each other’s internal details. This is considered a
good design practice because it keeps modules independent and flexible while allowing them to
work together efficiently. It occurs when operations pass long strings of data arguments.
5. Routine call coupling: Routine call coupling happens when one function (or module) calls
another function directly in a program. This means the first function depends on the second
function to complete its task. It occurs when one operation invokes another. This level of
coupling is common and is often quite necessary.
6. Inclusion coupling: Inclusion coupling (also called import coupling) happens when one
component (A) directly imports or includes another component (B), making A highly dependent
on B. This means if B changes, A might also need modifications, which reduces flexibility and
makes updates harder.
7. External coupling: Occurs when a component communicates or collaborates with
infrastructure components (e.g., operating system functions, database capability,
telecommunication functions).