Chapter-5(Software Design)

5.1 Introduction to Software Design

Software Design is the process of defining the architecture, components, interfaces, and other
characteristics of a system or application. It serves as a blueprint for building a software solution
that meets user needs and system requirements.

Why is Software Design Important?

 Improves Quality: A good design leads to efficient, reliable, and maintainable software.
 Reduces Cost: Detecting and fixing issues during the design phase is much cheaper than
in later stages.
 Enhances Scalability: Well-designed software can adapt to growing requirements and
technologies.
 Boosts Collaboration: A clear design helps team members understand the structure and
roles of different parts of the system.

Key Concepts in Software Design

1. Modularity: Dividing the system into separate modules that handle distinct
responsibilities.
2. Abstraction: Hiding complex implementation details and exposing only the necessary
parts.
3. Encapsulation: Keeping data safe within a module and only exposing necessary
functions.
4. Cohesion: Ensuring that each module or component focuses on a single task or purpose.
5. Coupling: Managing how tightly components are connected; loose coupling is preferred.

Common Design Methodologies

 Object-Oriented Design (OOD)

 Functional Design
 Service-Oriented Architecture (SOA)
 Component-Based Design
5.2 characteristics of software design
Here are the key characteristics of software design that define what makes a
good and effective design:

1. Correctness
 The design should fulfill all specified requirements.
 It must align with the functional and non-functional requirements of the
system.

2. Understandability
 The design should be easy to understand for developers, testers, and
maintainers.
 Clear documentation and logical structure help improve readability.

3. Efficiency
 The design should make optimal use of system resources (memory, CPU,
etc.).
 Efficient designs lead to better performance and faster execution.

4. Maintainability
 The design should support easy updates, bug fixes, and enhancements.
 Modular and loosely coupled components make maintenance easier.

5. Modularity
 The system should be divided into well-defined, independent modules.
 Each module should handle a specific functionality, promoting separation
of concerns.
6. Reusability
 Components should be designed to be reused in other parts of the system
or in different projects.
 Encourages the use of generic, flexible, and configurable components.

7. Scalability
 The design should be able to handle increasing loads or be easily expanded.
 This includes both vertical and horizontal scalability.

8. Robustness
 The system should handle errors and unexpected situations gracefully.
 A robust design can recover from or fail safely under stress.

9. Flexibility
 The design should accommodate changes with minimal impact on existing
components.
 This allows the software to adapt to new requirements or environments.

10. Security
 Sensitive data should be protected through secure design practices.
 Ensures that the system resists attacks and prevents unauthorized access.

11. Portability
 The software should be easily transferable across different platforms or
environments.
 Design should minimize dependencies on specific hardware or OS.
5.3 software design principal

Here’s a clear breakdown of Software Design Principles — the foundational guidelines that help create
clean, scalable, and maintainable software:

🔑 Core Software Design Principles

1. SOLID Principles (especially for Object-Oriented Design)

Principle Description

S – Single Responsibility A class should have only one reason to change. Each class should do one
Principle thing well.

Software entities should be open for extension but closed for

O – Open/Closed Principle
modification.

Subtypes should be substitutable for their base types without breaking

L – Liskov Substitution Principle
the app.

I – Interface Segregation
Clients shouldn’t be forced to depend on interfaces they don’t use.
Principle

D – Dependency Inversion
Depend on abstractions, not concrete implementations.
Principle

2. DRY – Don’t Repeat Yourself

 Avoid duplicating code.

 Abstract out common logic into functions or modules.

3. KISS – Keep It Simple, Stupid

 Design should be simple and straightforward.

 Avoid unnecessary complexity.
4. YAGNI – You Aren’t Gonna Need It

 Don’t implement something until it’s actually needed.

 Prevents overengineering.

5. Separation of Concerns

 Each part of the program should deal with one specific aspect.
 Improves modularity and maintainability.

6. High Cohesion & Low Coupling

 High Cohesion: Group related functionalities together.

 Low Coupling: Minimize dependencies between components.

7. Encapsulation

 Keep internal details hidden and expose only necessary parts.

 Protects the integrity of the data and the system.

8. Abstraction

 Focus on what an object does, not how it does it.

 Simplifies complexity by hiding low-level details.

9. Design for Change

 Anticipate change and design systems that are easy to adapt and extend.

10. Principle of Least Knowledge (Law of Demeter)

 A component should only talk to its immediate collaborators, not distant ones.
 Reduces dependencies and complexity.
5.4 Software Design Concepts

These are high-level ideas that help in organizing and structuring a software system effectively.

1. Abstraction

 Definition: Hiding complex details to show only the essential features of an object or function.
 Why it matters: Helps manage complexity and makes systems easier to understand and use.

2. Modularity

 Definition: Dividing the system into smaller, manageable, and independent parts called
modules.
 Why it matters: Makes development, testing, and maintenance easier and supports parallel
development.

3. Encapsulation

 Definition: Bundling data and methods that operate on that data within one unit, typically a
class.
 Why it matters: Protects data from outside interference and misuse, and helps enforce
boundaries in the system.

4. Separation of Concerns

 Definition: Dividing a program into distinct sections, each addressing a separate concern or
feature.
 Why it matters: Enhances maintainability, readability, and reusability.

5. Coupling

 Definition: The degree of interdependence between software modules.

 Goal: Aim for low coupling — modules should depend on each other as little as possible.
6. Cohesion

 Definition: The degree to which the elements inside a module belong together.
 Goal: Aim for high cohesion — each module should perform a single task or closely related tasks.

7. Reusability

 Definition: The ability to use components in different systems or scenarios without modification.
 Why it matters: Saves time and effort, and encourages consistency across projects.

8. Scalability

 Definition: The ability of the software to handle growth — more users, data, or complexity.
 Why it matters: Ensures that the design supports future expansion.

9. Maintainability

 Definition: How easily software can be modified to fix bugs, improve performance, or adapt to
changes.
 Why it matters: Good design reduces the time and cost of future changes.

10. Design Patterns

 Definition: General reusable solutions to common problems in software design (e.g., Singleton,
Observer).
 Why it matters: Provides proven templates for solving problems effectively and efficiently.
5.5 Software Design Strategy

A design strategy is a systematic plan to guide the software development process from problem analysis
to system implementation.

🔹 1. Top-Down Design (Stepwise Refinement)

 Idea: Start from the highest level of abstraction and break it down into smaller components.
 Use When: Requirements are well-understood and stable.
 Pros: Clear hierarchy, easy to understand.
 Cons: Might miss details early on.

🔧 Example: Start with the system as a whole, then divide into modules like UI, Database, and Logic.

🔹 2. Bottom-Up Design

 Idea: Start with small, low-level components and integrate them to build higher-level systems.
 Use When: You already have reusable components or libraries.
 Pros: Encourages reuse, focuses on building blocks.
 Cons: May lack big-picture view initially.

🔧 Example: Begin by designing login validation, then user authentication, then the whole login system.

🔹 3. Structured Design

 Idea: Use Data Flow Diagrams (DFDs) and functional decomposition.

 Focus: Processes, data flow, and transformation of input to output.
 Tools: DFDs, Structure Charts.
 Pros: Clear visualization, easy to analyze.
 Cons: Can be rigid, not suited for OOP.

🔹 4. Object-Oriented Design (OOD)

 Idea: Model the software as a collection of interacting objects.

 Core Concepts: Classes, objects, inheritance, polymorphism, encapsulation.
 Use When: Building complex systems with reusable components.
 Pros: Modular, easy to maintain and extend.
 Cons: Can be overkill for small projects.
🔹 5. Function-Oriented Design

 Idea: Focuses on functions and the sequence of tasks.

 Tools: Structure charts, HIPO diagrams.
 Pros: Simple for process-based problems.
 Cons: Less flexible compared to OOD.

🔹 6. Data-Centered Design

 Idea: Design revolves around how data is stored, processed, and accessed.
 Focus: Databases, data integrity, and data structures.
 Pros: Best for systems heavily dependent on data.
 Cons: Not ideal for highly interactive applications.

🔹 7. Event-Driven Design

 Idea: System behavior is driven by user or system-generated events.

 Use When: Building GUIs, games, or real-time systems.
 Pros: Interactive, responsive design.
 Cons: Harder to manage flow in large systems.

✅ Choosing the Right Strategy

Depends on:

 Nature and size of the project

 Development methodology (Agile, Waterfall, etc.)
 Team experience
 Reusability and maintainability requirements
5.6 Software design process and design quality
🔧 Software Design Process

The Software Design Process is a step-by-step approach used to transform requirements into a
blueprint for building software. It typically occurs after the requirements analysis phase and before
coding.

🔹 1. Requirement Analysis

 Understand what the system needs to do.

 Define functional and non-functional requirements.

🔹 2. System Design (Architectural Design)

 Focus on the overall structure of the software.

 Identify major components, their responsibilities, and how they interact.
 Output: High-level architecture diagrams, data flow diagrams.

🔹 3. Detailed Design (Low-Level Design)

 Dive into the internal logic of each component/module.

 Specify:
o Data structures
o Algorithms
o Interface details
 Output: Pseudocode, class diagrams, sequence diagrams.

🔹 4. Design Review & Validation

 Ensure the design meets requirements and follows best practices.

 Peer reviews, walkthroughs, and design documentation are used to validate the design before
implementation.
✅ Software Design Quality

Design Quality refers to how well a software design meets the goals of correctness, efficiency,
maintainability, and usability.

🔑 Attributes of High-Quality Software Design

Attribute Description

Correctness Meets all functional and non-functional requirements.

Maintainability Easy to update, fix, or enhance.

Understandability Easy for others to read, review, and work on.

Reusability Design components can be reused in different parts or projects.

Modularity System is broken into independent, focused modules.

Flexibility Can accommodate changes with minimal impact.

Scalability Can handle growth in data, users, or complexity.

Robustness Performs well under unexpected conditions.

Efficiency Optimizes resources like CPU and memory.

Security Protects against unauthorized access and data breaches.

🧠 Tips for Achieving Good Design Quality

 Use design patterns and best practices.

 Apply SOLID principles and modular design.
 Perform regular design reviews and refactoring.
 Document designs clearly with diagrams and descriptions.
5.7 Software Architecture

Software Architecture is the high-level structure of a software system — it defines how software
components are organized and how they interact.

It serves as a blueprint for both development and system evolution. It captures decisions about the
system’s components, their relationships, and guidelines for design and implementation.

🔑 Key points
 A software architecture is a description of how a software system is organized.

 Architectural design decisions include decisions on the type of application, the distribution of
the system, the architectural styles to be used.

 Architectures may be documented from several different perspectives or views such as a

conceptual view, a logical view, a process view, and a development view.

 Architectural patterns are a means of reusing knowledge about generic system architectures.
They describe the architecture, explain when it may be used and describe its advantages and
disadvantages.

Key Elements of Software Architecture

 Components – Individual pieces (modules, services, classes) of the system.

 Connectors – How components interact (APIs, messages, calls).
 Configurations – The overall structure formed by components and connectors.
 Design decisions – Guidelines, constraints, and trade-offs made during architecture planning.
The architecture of a packing robot control system
📚 Types of Software Architecture

Below are the most commonly used architectural styles:

[Link] (Tiered) Architecture

 Structure: Divides software into layers (e.g., Presentation → Business Logic → Data
Access).
 Use Case: Enterprise applications, websites.
 Pros: Separation of concerns, easy to test and maintain.
 Cons: Can become tightly coupled if not properly managed.
 The architecture of the LIBSYS system

2. Client-Server Architecture

 The application is modelled as a set of services that are provided by servers and a set of clients
that use these services.
 Clients know of servers but servers need not know of clients.
 Clients and servers are logical processes
 The mapping of processors to processes is not necessarily 1 : 1.
A client-server system

c2 c3 c4 c12
c11
Server process

c1 s1 s4

c10
c5
Client process
s2 s3 c9

c6
c7 c8
A client-server ATM system

ATM

ATM
Account server

Tele- Customer
processing account
monitor database

ATM

ATM

1. Three-tier architectures

 In a three-tier architecture, each of the application architecture layers may

execute on a separate processor.
 Allows for better performance than a thin-client approach and is simpler to
manage than a fat-client approach.
 A more scalable architecture - as demands increase, extra servers can be
added.

A 3-tier C/S architecture

Presentation
Server Server

Client Application Data

processing management
An internet banking system

Client HTTP interaction

Web server Database server

Client
SQL query
Account service Customer
SQL account
provision
database
Client

Client

2. Distributed object architectures

 There is no distinction in a distributed object architectures between clients

and servers.
 Each distributable entity is an object that provides services to other objects
and receives services from other objects.
 Object communication is through a middleware system called an object
request broker.
 However, distributed object architectures are more complex to design than
C/S systems.

Advantages of distributed object architecture

 It allows the system designer to delay decisions on where and how services
should be provided.
 It is a very open system architecture that allows new resources to be added
to it as required.
 The system is flexible and scaleable.
 It is possible to reconfigure the system dynamically with objects migrating
across the network as required.
3. Peer-to-Peer (P2P) Architecture

 Peer to peer (p2p) systems are decentralised systems where computations

may be carried out by any node in the network.
 The overall system is designed to take advantage of the computational
power and storage of a large number of networked computers.
 Most p2p systems have been personal systems but there is increasing
business use of this technology.

P2p architectural models

 The logical network architecture

 Decentralised architectures;
 Semi-centralised architectures.

Decentralised p2p architecture

n4 n6
n8 n13

n7 n12
n2 n3
n13
n9 n10 n11

n1 n5
Semi-centralised p2p architecture

Discovery
server

n4
n1

n3
n6

n5
n2