MODULE 3 Software Design

MODULE 3
SOFTWARE DESIGN
Ch 3: Software Design

During the software design phase, the design document is produced based on the customer
requirements specified in the Software Requirements Specification (SRS) document. The
design phase transforms the SRS into a form that is directly implementable in the coding phase.

The overall design process is shown schematically in Figure 5.1, where the process starts from
the SRS document and ends with the production of the design document. The design document
is expected to provide sufficient detail for direct implementation using a programming
language.

Overview of the Design Process

The design process involves converting the SRS into a design document through a series of
well-defined steps. The key elements designed and documented during this process include:

1. Different Modules Required

The software is decomposed into multiple modules, where:

• Each module contains functions and shared data.

• Every module should have a clear, specific responsibility.
• Modules should be named according to their purpose (e.g., in an academic automation
software, a module for student registration would be named “Handle Student
Registration”).

2. Control Relationships among Modules

The design document must define the control relationships between modules, which typically
arise from function calls across modules.

3. Interfaces among Modules

The interfaces specify the exact data items exchanged between two modules when one module
invokes a function from another.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 1

MODULE 3 Software Design

4. Data Structures of Modules

Each module may store and manage its own data. Appropriate data structures are designed to
handle this shared data.

5. Algorithms for Module Implementation

Each function within a module performs specific processing tasks. The design phase specifies
the algorithms for these tasks, considering accuracy, time complexity, and space
complexity.

The design process is iterative: starting from the SRS (Figure 5.1), the design documents are
refined through multiple reviews to ensure they meet the specified requirements.

Classification of Design Activities

The design process is not a single-step procedure but an iterative one. It is classified into two
main stages:

1. Preliminary (High-Level) Design

• Objective: Decompose the problem into modules, identify control relationships, and
define interfaces.
• Outcome: The program structure or software architecture.
• Representation:
o Structure Charts (for procedural designs).
o UML diagrams (for object-oriented designs).
• At this stage, the design must ensure:
o High cohesion within modules.
o Low coupling among modules.
o Clear hierarchical structure.

2. Detailed Design

• Objective: Analyse each module to design its data structures and algorithms.
• Outcome: Module Specification (MSPEC) document.
o This includes detailed information that programmers can directly use for
implementation.

For example, once the high-level design is complete, the MSPEC allows programmers to
understand each module’s behaviour and proceed with coding.

Classification of Design Methodologies

Design methodologies vary depending on the design approach:

1. Procedural Design Methodologies

o Focus on functions and control flow.
o Examples: Structure charts.
2. Object-Oriented Design Methodologies
o Focus on objects, classes, and their interactions.
o Examples: UML diagrams.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 2

MODULE 3 Software Design

Although several other design techniques exist (e.g., Jackson diagram [1975], Warnier-Orr
diagram [1977, 1981]), the primary focus in this context is on structure charts and UML
diagrams.

Do Design Techniques Result in Unique Solutions?

Even when the same methodology is applied, different designers may arrive at different
solutions. This happens because:

• Design requires many subjective decisions.

• Designers must balance contradictory objectives.
• Even the same designer may create multiple valid designs for the same problem.

A good design is selected by comparing alternative solutions and identifying the one that meets
quality criteria like simplicity, efficiency, and maintainability.

Analysis vs Design

Analysis and design differ significantly in their goals and scope:

Aspect Analysis Design

Understand and model customer Transform analysis into an
Goal
requirements. implementable solution.
Generic representation of the Platform-specific and implementation-
Focus
problem. focused solution.
For function-oriented design: Structure
For function-oriented design:
Charts.
Data Flow Diagrams (DFDs).
Representation For object-oriented design: UML
For object-oriented design: UML
diagrams (with implementation-level
diagrams.
details).
Avoids implementation Includes implementation and platform-
Decisions
decisions. related details.

• Example: The analysis model of a library management system might only show data
flow (e.g., "issue book" or "return book"), while the design model specifies module
structure, algorithms, and data structures needed to implement these functions.

Thus, the design model is a transformation of the analysis model into a concrete solution that
is ready for coding.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 3

MODULE 3 Software Design

How to Characterise a Good Software Design

Defining a “good” software design is challenging because the criteria depend heavily on the
problem domain and the application type. For instance, in embedded systems, where
memory and power are limited, memory usage is often the most important factor. In such
cases, design comprehensibility may be sacrificed to achieve code compactness.

In contrast, for general-purpose business software, factors such as understandability and

maintainability take precedence because these systems evolve over time and require frequent
modifications.

Therefore, while criteria vary across application domains, there is broad agreement among
software engineers on a few universal characteristics that a good software design should
possess:

Characteristics of a Good Software Design

1. Correctness
o The design must accurately implement all the functionalities specified in the
SRS document.
o Any deviation results in defects during implementation or later phases.
2. Understandability
o A design must be simple and easy to understand.
o Complex designs are error-prone and increase development and maintenance
costs.
o Understandable designs reduce cognitive load and make debugging and testing
easier.
3. Efficiency
o A good design should optimize resource usage such as time, memory, and cost.
o For example, in real-time systems, design efficiency is as critical as
correctness.
4. Maintainability
o A design should be easy to modify, as most software products evolve after
deployment.
o Since about 60% of the total software life-cycle effort is spent on
maintenance, designs that are difficult to modify can lead to very high costs.

Understandability of a Design: A Major Concern

After correctness, understandability is the most important criterion for choosing the best
design from multiple correct alternatives.

A good design should overcome human cognitive limitations, especially the constraints of
short-term memory (as discussed in Chapter 1). A poor design overwhelms developers,
increases errors, and pushes up development costs.

If a design is difficult to understand:

• Implementation, testing, debugging, and maintenance become extremely challenging.

• Development cost and effort grow significantly.
• The resulting system may be unreliable and full of defects.

On the other hand, a simple and understandable design:

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 4

MODULE 3 Software Design

• Is easier to implement and maintain.

• Leads to reduced life-cycle costs.
• Produces a more reliable system.

As discussed earlier, understandability can be enhanced by applying abstraction and

decomposition principles effectively.

Characteristics of an Understandable Design

An understandable design generally has the following properties:

• Consistent and meaningful names for modules and components.

• Effective application of abstraction and decomposition.
• Modular structure with low interaction among modules.
• Clear layering of modules.

In other words, a design must be modular and layered to be understandable.

Modularity

A modular design is one in which the software is broken down into a set of modules with
minimal interactions. Each module:

• Represents a specific function or task.

• Interacts with other modules through well-defined interfaces.

Benefits of Modularity:

• Divide and Conquer: Each module can be understood independently, which reduces
complexity.
• Improved Debugging: Errors can be isolated within individual modules.
• Parallel Development: Teams can work on separate modules concurrently.

As illustrated in Figure 5.2, two design alternatives are compared:

• Figure 5.2(a): Low interaction among modules → Easier to understand and maintain.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 5

MODULE 3 Software Design

• Figure 5.2(b): High inter-module interaction → Increases complexity and decreases

modularity.

Quantifying Modularity:
Although modularity cannot be measured directly, it can be characterized in terms of:

• Cohesion: How strongly related the functions within a module are.

• Coupling: The degree of interdependence between modules.

A good design has high cohesion and low coupling, leading to effective problem
decomposition.

Layered Design

A layered design organizes modules in a hierarchical structure (tree-like diagram):

• Higher-level modules control and invoke lower-level modules.

• Each module only interacts with the layer immediately below it.
• This approach implements control abstraction, as lower modules are unaware of the
details of higher modules.

Benefits of Layered Design:

• Improved Understandability: To understand one module, you only need to examine

the modules directly below it.
• Simplified Debugging: When an error occurs in a module, debugging can be focused
on that module and its lower-level modules.
• Clear Separation of Responsibility: Higher-level modules focus on coordination,
while lower-level modules perform specific tasks.

For example:

• A user interface module at the top layer may call a business logic module, which in
turn calls a data access module.

This hierarchy reduces complexity and improves design maintainability.

Key Takeaways

• A good software design must be correct, understandable, efficient, and

maintainable.
• Among these, understandability is the most critical factor after correctness.
• Modularity (high cohesion, low coupling) and layered structure are the primary
techniques to improve design understandability.
• Figure references:
o Figure 5.2: Comparison of modular and non-modular designs.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 6

MODULE 3 Software Design

Cohesion and Coupling

In software design, effective problem decomposition is a key characteristic of a good design.

A design is considered effective when it produces functionally independent modules—
modules that are self-contained, focused on a single task, and require minimal interaction with
other modules. This is measured primarily using two attributes: cohesion and coupling.

• Cohesion represents how strongly related and focused the elements within a single
module are.
• Coupling represents the level of interdependence between different modules.

The goal of good software design is to maximize cohesion and minimize coupling, thereby
producing modular, maintainable, and reusable software.

1. Cohesion

Cohesion is a measure of the functional strength of a module. A module is cohesive if:

• All the functions and data within it are directed toward accomplishing a single well-
defined task.
• There is minimal or no inclusion of unrelated responsibilities.

For example, if a module named StudentRegistration handles all functionalities related to

student registration (e.g., form validation, database insertion, and confirmation), it is cohesive.
But if the same module also handles unrelated tasks like fee payment or report generation,
the cohesion is poor.

An analogy for cohesion is a speech by a good speaker:

• If every sentence in the speech supports one central theme, the speech is cohesive.
• If the sentences are disjointed and unrelated, the speech lacks cohesion.

2. Coupling

Coupling measures the degree of interaction between two modules.

Two modules are highly coupled if:

• They share large amounts of data or depend heavily on each other.

• They interact through global variables or shared data structures.

Two modules are loosely coupled if:

• They only interact minimally, usually through well-defined interfaces.

• They pass only a small number of primitive data items.

Loose coupling is desirable because it ensures that changes in one module do not heavily affect
other modules, reducing the risk of ripple effects throughout the system.

3. Functional Independence

When a module has high cohesion and low coupling, it is said to be functionally independent.
Functional independence is one of the most critical objectives in software design because it
leads to several key advantages:

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 7

MODULE 3 Software Design

a) Error Isolation

• Errors within a functionally independent module remain localized.

• If a bug occurs, it can be easily traced to the module where it originated, rather than
spreading across multiple interconnected modules.
• For example, if a PaymentProcessing module is functionally independent, an error in
payment calculation will not affect unrelated modules such as StudentRegistration.

b) Reusability

• Functionally independent modules are easier to reuse in other software systems.

• Since they have simple and limited interfaces with other modules, they can be
extracted and integrated into new applications with minimal changes.
• For example, a ReportGeneration module with low coupling and high cohesion can be
reused in different projects without modification.

c) Understandability

• Functionally independent modules reduce design complexity.

• Developers can focus on understanding one module at a time without worrying about
unnecessary inter-module dependencies.
• This simplifies development, testing, and maintenance, improving overall software
quality.

As discussed in earlier, modularity plays a crucial role in enhancing design understandability.

Cohesion and coupling directly influence this modularity.

4. Summary of Cohesion and Coupling

Aspect High Cohesion Low Coupling

Purpose Each module does one specific task Modules work independently
Advantages Easier to understand and maintain Less ripple effect from changes
Impact on Design Promotes functional independence Encourages reuse and error isolation

By combining high cohesion with low coupling, we achieve a functionally independent

design, which is the foundation of good software engineering practice.

Classification of Cohesiveness

Cohesiveness of a module indicates the extent to which the functions within the module
cooperate to accomplish a single well-defined objective. Modules in a software design can
vary significantly in their degree of cohesiveness. Figure 5.3 illustrates the classification of
cohesiveness, ranging from the weakest form (coincidental cohesion) to the strongest and most
desirable form (functional cohesion).

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 8

MODULE 3 Software Design

As we move from coincidental to functional cohesion, the quality of the design improves,
making the software more understandable, maintainable, and reusable.

1. Coincidental Cohesion

• Definition: A module is said to have coincidental cohesion if it performs a set of tasks

that are unrelated or only loosely related.
• Characteristics:
o Functions are grouped arbitrarily without meaningful relationships.
o Such designs are often created by inexperienced programmers.
• Example: A library module containing functions for issuing books, creating library
member records, and handling librarian leave requests. These tasks have no logical
relationship.
• Reference: Figure 5.4(a) shows an example of a module with coincidental cohesion
where unrelated functionalities are placed together, making the module unnecessarily
complex and hard to maintain.
• Impact: This is the worst type of cohesion and should be avoided in good software
design.

2. Logical Cohesion

• Definition: A module has logical cohesion if its functions perform similar operations
but are logically categorized rather than being functionally connected.
• Example: A module containing multiple print functions such as printGradeSheet(),
printSalarySlip(), and printAnnualReport().
• Drawback: While functions are similar in nature, they are not aimed at achieving a
single well-defined task.
• Impact: This improves over coincidental cohesion but still lacks strong modularity.

3. Temporal Cohesion

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 9

MODULE 3 Software Design

• Definition: Temporal cohesion occurs when a module’s functions are related because
they are executed during the same time frame or phase.
• Example:
o A system start-up module that initializes memory, configures devices, and loads
the operating system.
o Similarly, shutdown or initialization modules in other applications.
• Observation: These functions are grouped due to their timing rather than their
functional relationship.
• Impact: Temporal cohesion is better than logical cohesion but still does not promote
functional independence.

4. Procedural Cohesion

• Definition: A module has procedural cohesion if its functions are executed sequentially
in a predefined order but perform unrelated operations.
• Example: In an order-processing module of a trading system:
o Functions include login(), placeOrder(), checkOrder(), printBill(),
placeOrderOnVendor(), updateInventory(), and logout().
o While these are executed one after the other, each function performs a different
task.
• Impact: Though execution order gives a sense of structure, it does not improve
functional integration among the module’s functions.

5. Communicational Cohesion

• Definition: A module has communicational cohesion if all its functions access or

manipulate the same data structure.
• Example: A student module that contains functions like admitStudent(), enterMarks(),
and printGradeSheet() that all operate on studentRecords[].
• Impact: Communicational cohesion provides better modularity because the functions
are linked by a shared data structure, but they still might not work toward a single task.

6. Sequential Cohesion

• Definition: A module exhibits sequential cohesion when its functions execute in

sequence, and the output of one function becomes the input for the next.
• Example: In an online store:
o createOrder() → generates an order.
o checkItemAvailability() → verifies stock.
o placeOrderOnVendor() → places the order if stock is unavailable.
• Observation: This relationship forms a clear functional chain, making the module
stronger than communicational cohesion.

7. Functional Cohesion (Best Type)

• Definition: A module has functional cohesion if all its functions work together to
perform one single task.
• Example: A payroll module containing functions such as:
o computeOvertime()
o computeWorkHours()
o computeDeductions()
Together, these functions generate employee pay slips.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 10

MODULE 3 Software Design

• Reference: Figure 5.4(b) illustrates a module with functional cohesion, such as a

library management module containing issueBook(), returnBook(), queryBook(), and
findBorrower(), all cooperating to manage book-lending activities.
• Impact:
o The module can be described in one sentence, e.g., “This module manages the
book-lending process of the library.”
o This is the highest form of cohesion, leading to clear, maintainable, and reusable
modules.

Determining Cohesion

A simple way to determine the cohesiveness of a module is to analyze its purpose:

• If a compound sentence is required to describe the module, it is likely sequential or

communicational cohesion.
• If terms like “first, next, after” are needed, it indicates sequential cohesion.
• If terms like “initialize, setup, shutdown” are used, it points to temporal cohesion.
• If the module can be described in one simple sentence, it has functional cohesion.

Conclusion

A highly cohesive module has tightly related functions that interact heavily to achieve a single
goal. If one function is moved out, coupling would increase because the function would now
need to communicate across module boundaries. Thus, striving for functional cohesion is
essential for creating a robust, modular, and maintainable software design.

Classification of Coupling

Coupling represents the degree of interdependence between two modules in a software

design. Strong coupling means that modules rely heavily on each other, while weak coupling
indicates minimal interaction and high independence. A low degree of coupling is desirable
because it improves modularity, maintainability, and testability of the software.

The degree of coupling between two modules mainly depends on their interface complexity,
which is determined by:

• The number of parameters passed between modules.

• The complexity of the parameters exchanged (elementary vs. structured).

Figure 5.5 illustrates the different types of coupling, arranged from the lowest (best) form of
coupling (data coupling) to the highest (worst) form (content coupling).

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 11

MODULE 3 Software Design

1. Data Coupling (Best Form)

• Definition: Two modules are data coupled if they communicate only through
elementary data items passed as parameters, such as integers, floats, or characters.
• Key Points:
o The data exchanged is related to the problem domain.
o No control information (e.g., flags) should be passed.
• Example:
int calculateSquare (int number);

Here, the calculateSquare() function receives a single integer parameter.

• Impact:
• This is the most desirable form of coupling because the modules remain highly
independent.
• Such modules are easier to understand, maintain, and test.

2. Stamp Coupling

• Definition: Stamp coupling occurs when two modules share a composite data
structure (e.g., records in Pascal or structures in C).
• Key Points:
The entire structure is passed even if only a part of it is needed.
• Example:
struct Student {
char name[50];
int marks;
int rollNo;
};
void printStudentDetails(struct Student s);

Here, the printStudentDetails() function might only need the student's name, but the
entire structure is passed.

• Impact:
o Reduces modularity since unnecessary data is exposed.
o Changes in the structure can affect multiple modules, leading to high
maintenance costs.

3. Control Coupling

• Definition: Control coupling exists when one module controls the execution flow of
another by passing control information (e.g., flags or codes).
• Key Points:
o The called module's behavior changes based on control parameters.

Example:
void processData(int flag) {
if(flag == 1)
// process for case 1
else

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 12

MODULE 3 Software Design

// process for case 2

}

• Here, the flag variable determines the behavior of processData().

• Impact:
o Reduces module independence.
o Makes testing and debugging difficult since control logic spreads across
multiple modules.

4. Common Coupling

• Definition: Common coupling occurs when multiple modules share global data.
• Key Points:
o Modules can read and modify the same global variable, which can lead to
unwanted side effects.

Example:
int globalCounter;
void incrementCounter() { globalCounter++; }
void resetCounter() { globalCounter = 0; }

• Both functions access the same global variable.

• Impact:
o Debugging becomes harder since changes in one module may unexpectedly
affect others.
o Violates information hiding and modularity principles.

5. Content Coupling (Worst Form)

• Definition: Content coupling happens when one module directly accesses or modifies
the code or data of another module.
• Key Points:
o This is the tightest and most dangerous form of coupling.
o Modern programming languages (like C and Java) typically prevent such direct
jumps into another module’s code.
• Example:
o If a module modifies another module's local variables or jumps into the middle
of its code.
• Impact:
o Extremely error-prone and makes maintenance very difficult.
o Breaks modularity completely and prevents independent development of
modules.

Summary of Coupling Levels (Figure 5.5)

Coupling Type Description Desirability
Data Coupling Primitive data passed as parameters Best
Stamp Coupling Composite data structures passed Good
Control Coupling Passing control flags Moderate

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 13

MODULE 3 Software Design

Coupling Type Description Desirability

Common Coupling Shared global data Poor
Content Coupling Accessing another module’s code Worst

Conclusion
High coupling among modules significantly increases software complexity and cost.
Therefore, a good design must focus on minimizing coupling while promoting high
cohesion. The ideal design strives for data coupling and avoids content or common
coupling, enabling modules to be developed, tested, and maintained independently.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 14

MODULE 3 Software Design

Patterns in Software Design

Introduction
The concept of patterns originated in architecture, where standard solutions were created
for building designs. This concept has now been adapted to object-oriented analysis and
design (OOAD) to support design reuse. Patterns help in solving recurring design
problems systematically by applying proven solutions rather than reinventing them for
every project.

Design Patterns and Their Role in OOAD

In software design, experienced designers often reuse solutions they have successfully
implemented before. Patterns formalize this reuse, making it accessible to all developers.

• Definition:

A design pattern is a commonly accepted solution to a recurring design problem across

different applications.

• Benefits:

o Reduces the number of design iterations.

o Improves the quality of the final design.

o Enhances maintainability and flexibility.

When designers recognize a recurring problem, they can apply the corresponding pattern
instead of starting from scratch.

Basic Pattern Concepts

Every complex software problem consists of multiple subproblems. Some of these
subproblems are common across many applications.

• Core Idea of Patterns:

By mastering a few important patterns, developers can spot these subproblems in new
projects and reuse the documented solutions effectively.

• Patterns are not revolutionary techniques but are built on common sense and proven
design principles.

• Without patterns, developers may create unnecessarily complex or inefficient designs.

Patterns act as guides for good design and increase productivity.

Pattern Documentation Structure

Each documented pattern typically includes:

1. Problem: The recurring issue that needs a solution.

2. Context: The situation where the problem occurs.

3. Solution: The general reusable design structure.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 15

MODULE 3 Software Design

4. Applicability: When the solution works and when it should not be used.

Patterns also serve as a common vocabulary among developers, improving

communication and knowledge sharing.

Types of Patterns
Patterns exist at different levels of abstraction:

1. Architectural Patterns
• Definition: High-level strategies that deal with the overall structure of large software
systems.

• Purpose:

o Define subsystems and their responsibilities.

o Establish rules for organizing their relationships.

• Characteristics:

o Cannot be directly translated to code.

o Provide a foundation for detailed designs.

• Usage: Suitable for very large systems (e.g., Client-Server, Layered Architecture).

2. Design Patterns
• Definition: Solutions to recurring design problems at the class and object level.

• Purpose:

o Specify class structures, their roles, and their collaborations.

o Improve flexibility and reusability.

• Example Patterns: Observer, Facade, MVC, Proxy.

• Usage: Helps in medium-scale designs by defining interactions between classes and

objects.

3. Idioms
• Definition: Low-level, language-specific patterns that describe how to implement a
solution using a specific programming language’s features.

• Analogy: Similar to idioms in natural languages (e.g., "raining cats and dogs"), which
provide concise, widely understood meanings.

• Example: In C++, using RAII (Resource Acquisition Is Initialization) to manage

memory.

• Usage: Helps improve code readability and reduce development time.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 16

MODULE 3 Software Design

Comparison of Patterns

Pattern Type Abstraction Level Scope Example

Architectural High-level Overall system Layered Architecture

Design Medium-level Subsystems/classes Observer, Facade

Idioms Low-level Language-specific RAII (C++ idiom)

Architectural patterns define the global structure, design patterns focus on class
interactions, and idioms deal with implementation details.

Patterns vs. Algorithms

Although both aim to provide reusable solutions, they differ fundamentally:

• Algorithms: Focus on solving specific problems efficiently in terms of time and space
complexity.

• Patterns: Focus on maintainability, flexibility, and ease of development, not

necessarily efficiency.

Patterns are design blueprints, while algorithms are computational procedures.

Pros and Cons of Design Patterns

Advantages

• Provide a common vocabulary for developers.

• Help capture and transfer expert knowledge.

• Improve flexibility and maintainability of designs.

• Guide developers to make better design decisions.

• Reduce design iterations and improve productivity.

Disadvantages

• Do not directly result in code reuse (they are conceptual, not code-specific).

• No universal methodology to select the right pattern for every design scenario.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 17

MODULE 3 Software Design

Antipatterns
If a pattern represents a best practice, an antipattern represents a bad design practice
that should be avoided.

Two categories of antipatterns:

1. Bad Solutions: Describe incorrect solutions that lead to poor results.

2. Avoidance Guidelines: Explain how to prevent poor design practices.

Examples of Antipatterns:

• Input Kludge: No proper mechanism for handling invalid inputs.

• Magic Pushbutton: Business logic coded directly inside the UI instead of separate
classes.

• Race Hazard: Ignoring the consequences of event orderings in concurrent systems.

Antipatterns are valuable because they help designers recognize and avoid bad design
choices early.

Conclusion:
Patterns act as reusable blueprints for software design, helping to improve
maintainability, reduce complexity, and guide designers towards robust solutions. By
mastering patterns, designers can develop efficient, scalable, and maintainable software
while avoiding common pitfalls through awareness of antipatterns.

Some Common Design Patterns

Familiarity with design patterns is essential for software designers. Once you understand
key patterns, you can identify them during problem-solving and reuse proven solutions
effectively. Design patterns also provide a common vocabulary that improves
communication among developers.

Although patterns represent generic solutions, they often require adaptation for specific
problem contexts. The most widely used patterns are those documented by Larman and
the Gang of Four (GoF): Erich Gamma, Richard Helm, Ralph Johnson, and John
Vlissides.

1. Facade Pattern
Problem: How should services be requested from a package by client classes?

Context:

• A package is a cohesive set of classes with related responsibilities.

• For example, an RDBMS interface package might contain multiple classes for database
operations.

Solution:

• Create a Facade class (e.g., DBFacade) that provides a unified interface for accessing
services within the package.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 18

MODULE 3 Software Design

Explanation:

• Without a facade, clients need to know all the internal classes and their methods.

• When parameters or methods change, multiple client classes must be modified.

• By using a facade, only the facade class changes, while client classes remain unaffected.

• The facade simplifies service invocation by providing a single entry point.

Benefits:

• Reduces complexity for clients.

• Hides internal details of the package.

• Minimizes the impact of changes in the package.

(Figure 8.2 illustrates how facade reduces dependency between clients and the package.)

3. Observer Pattern
Problem: When a model object is accessed by multiple view objects, how should
interactions between them be structured?

Solution:

• Observers register with the model.

• The model maintains a list of registered observers.

• When the model changes, it notifies all observers. Each observer can then query the
model for specific details.

Explanation:

• Achieves loose coupling between the model and observers.

• Observers do not need to know about each other.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 19

MODULE 3 Software Design

• Both push and pull communication modes are supported.

Limitations:

• The model must maintain observer lists and handle updates, creating overhead.

• Notification may be inefficient if different observers are interested in different events.

(Figure 8.3 shows the interaction diagram for the observer pattern.)

3. Model-View-Controller (MVC) Pattern

Problem: How should GUI objects interact with model objects?

Solution:

• Split GUI into View and Controller:

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 20

MODULE 3 Software Design

o Controller: Collects user input and passes it to the model.

o Model: Updates state and notifies dependent views and controllers.

o View: Displays updated data.

Explanation:

• Loose coupling is maintained between model and view.

• Controller logic is separated from display logic.

• Multiple views of the same model are supported.

Benefits:

• Separation of concerns (input, processing, output).

• Supports multiple views (e.g., line chart, bar chart, pie chart) of the same data.

• Handles asynchronous updates efficiently.

(Figures 8.4 and 8.5 illustrate MVC class and collaboration diagrams.)

4. Publish-Subscribe Pattern

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 21

MODULE 3 Software Design

Problem: When a model object has many dependent views, and its state changes
asynchronously, how should updates be handled efficiently?

Solution:

• Implement an Event Manager:

o Publishers (model objects) notify the event manager of events.

o Subscribers register their interest in specific events with the event manager.

o The event manager notifies only the relevant subscribers.

Explanation:

• Reduces overhead compared to the observer pattern by filtering notifications.

• The event manager can be centralized or distributed.

• Modern languages (e.g., Java) support event-based mechanisms like EventListener.

Benefits:

• Publishers are not burdened with maintaining subscribers.

• Efficient notification to only interested subscribers.

(Figures 8.6 and 8.7 illustrate event flow in the publish-subscribe pattern.)

5. Intermediary (Proxy) Pattern

Problem: How should a client invoke services from a remote server object across a
network?

Context:

• Clients are service consumers, and servers are service providers.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 22

MODULE 3 Software Design

• Network communication details should be hidden from the client.

Solution:

• Create a Proxy object at the client side.

• The proxy forwards requests to the server, receives responses, and returns them to the
client.

Explanation:

• The proxy behaves like the server from the client's perspective.

• It manages network details such as:

o Locating the server.

o Transmitting requests.

o Encrypting/compressing data if necessary.

Benefits:

• Hides network complexity.

• Supports additional features such as caching, logging, and security.

• Provides a uniform interface to clients.

Adapter Pattern
Problem: How can incompatible interfaces between two classes be resolved so that they
can work together?

Context:
In many software systems, we encounter situations where an existing class offers the
desired functionality but has an interface that does not match the one required by the client.
Modifying the existing class might not be feasible because it may be part of a library or
reused in other systems.

Solution:
The Adapter pattern introduces an intermediate class, called the adapter, that translates the
interface of the existing class (adaptee) into the interface expected by the client. The client
interacts only with the adapter, which internally delegates requests to the adaptee using the
appropriate conversions.

Explanation:
The Adapter acts like a bridge between the client and the incompatible class. This allows
integration without changing the existing class implementation. For example, if a drawing
application expects an interface Shape, but we have an existing LegacyRectangle class with
a different method signature, an adapter can be created to implement Shape while internally
using LegacyRectangle methods.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 23

MODULE 3 Software Design

Benefits:

• Promotes reuse of existing classes without modification.

• Provides a clean separation between client code and legacy or third-party code.

• Simplifies integration of components with mismatched interfaces.

Command Pattern
Problem: How can requests be encapsulated so that they can be queued, logged, undone,
or executed later?

Context:
In many systems, it is useful to treat requests or operations as first-class objects so they can
be passed around, stored, or executed at different times. For instance, in a text editor,
operations like "copy," "paste," or "undo" need to be executed flexibly while maintaining
a record for undo/redo functionality.

Solution:
The Command pattern encapsulates each request into a separate command object. Each
command object implements a common interface, typically containing an execute()
method. The client creates a command object and passes it to an invoker, which executes
the command without knowing its implementation details. The command internally calls
the appropriate method of the receiver object.

Explanation:
This pattern decouples the sender (invoker) from the receiver. It also allows operations such
as undo/redo by maintaining a history of executed command objects. For example, a "Save"
operation in a text editor can be implemented as a command object that knows how to call
the saveDocument() method on the receiver.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 24

MODULE 3 Software Design

Benefits:

• Decouples request senders from request receivers.

• Supports undo and redo operations easily.

• Simplifies logging and queuing of operations.

• Improves code extensibility by allowing new commands to be added without changing

existing code.

Strategy Pattern
Problem: How can different algorithms or behaviors be selected dynamically at runtime
without changing the context class?

Context:
Many applications require multiple algorithms to perform a specific task. For example, a
payment system may support different payment methods like credit card, UPI, or PayPal.
Without the Strategy pattern, the context class might contain multiple conditional
statements to handle each algorithm, making the code hard to maintain.

Solution:
The Strategy pattern defines a family of algorithms, encapsulates each one in a separate
class, and makes them interchangeable. The context class maintains a reference to a strategy
interface and delegates the algorithm execution to the strategy object currently set.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 25

MODULE 3 Software Design

Explanation:
By encapsulating algorithms, the Strategy pattern eliminates the need for complex
conditional logic within the context. For example, a PaymentProcessor context can use a
PaymentStrategy interface. Specific strategies such as CreditCardPayment, UPIPayment,
or PayPalPayment implement this interface. At runtime, the desired strategy is injected into
the context, allowing the payment method to be changed dynamically.

Benefits:

• Promotes flexibility and maintainability by isolating algorithms.

• Allows adding new strategies without modifying existing context classes.

• Eliminates long conditional statements in the context.

• Supports dynamic selection or swapping of algorithms at runtime.

Architectural Styles in Software Design

1. Layered Architecture

Description
Layered architecture organizes the system into hierarchical layers where each layer
performs a specific role and only interacts with the layer directly above or below it.
Typically, systems have layers such as Presentation, Business Logic, and Data Access.
Each layer has clearly defined interfaces and responsibilities, making it easier to manage
complexity and evolve the system over time.

Real-time Example
In a university management system, the presentation layer manages user interactions (like
student portals), the business logic layer processes rules (like course registrations or fee
calculations), and the data layer handles storage and retrieval (like student records in a
database).

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 26

MODULE 3 Software Design

Benefits

• Promotes separation of concerns

• Easy to test and maintain individual layers

• Supports scalability and changes in technology at one layer without impacting others

Limitations

• Can lead to performance overhead due to multiple layer traversal

• Requires strict adherence to layer dependencies

• May become inflexible if layers are tightly coupled

2. Client-Server Architecture
Description
In this style, the system is divided into two main components: clients that request services
and servers that provide them. Clients are typically user-facing applications (e.g.,
browsers), while servers handle processing, data, or services (e.g., web servers or
databases). This architecture is foundational to internet and networked applications.

Real-time Example
In a banking application, the mobile app (client) sends transaction requests to a central
banking server (server), which processes the request, interacts with databases, and returns
the response to the app.

Benefits

• Centralized control over data and resources

• Easy to scale server independently from clients

• Clients can run on lightweight hardware

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 27

MODULE 3 Software Design

Limitations

• Server becomes a potential bottleneck

• If the server fails, the entire system may become unavailable

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 28

MODULE 3 Software Design

• Requires robust network communication

3. Tiered Architecture (Multi-tier)

Description
Tiered architecture, also known as N-tier architecture, extends client-server by splitting the
system into more than two layers or tiers, typically including: Presentation Tier, Business
Tier, and Data Tier. Each tier runs on separate infrastructure and handles different concerns,
promoting modularity.

Real-time Example
An e-commerce website uses a web browser (presentation tier), an application server
handling shopping cart logic (business tier), and a database server storing
product/catalogue information (data tier).

Benefits

• High scalability and reusability

• Separation of deployment concerns (UI, logic, data)

• Supports integration with third-party services easily

Limitations

• Increased complexity in configuration and deployment

• Communication between tiers can add latency

• Debugging across tiers can be challenging

4. Pipe and Filter Architecture

Description
In this style, the system is viewed as a series of processing components (filters) connected

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 29

MODULE 3 Software Design

by data streams (pipes). Each filter performs a transformation on the input and passes the
output to the next filter. This promotes the building of systems from small, reusable units.

Real-time Example
A compiler works in phases: lexical analysis → syntax analysis → semantic analysis →
code generation. Each phase acts as a filter that processes input and forwards output to the
next.

Benefits

• Supports reuse of filters

• Easy to add new filters or reorder steps

• Clear separation of tasks

Limitations

• Not suitable for interactive applications

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 30

MODULE 3 Software Design

• Difficult to manage global states or shared context

• Error handling across filters can be complex

UI Design in Software Engineering

What is UI Design?
User Interface (UI) Design is a crucial aspect of software development that focuses on
designing the visual and interactive elements of an application with which users engage
directly. It includes the layout of screens, buttons, forms, icons, menus, text fields, images,
and all other visual touchpoints. The primary objective of UI design is to make the
interaction between users and the software intuitive, efficient, and enjoyable.

UI design goes beyond just aesthetics—it ensures that the system is usable, accessible, and
responsive to user actions. A well-designed UI should minimize the cognitive load of users
and make navigation seamless by using consistent and familiar patterns. It also ensures that
the software is visually aligned with its purpose, audience, and platform (web, mobile,
desktop, etc.).

Real-Time Example

Consider a food delivery app like Swiggy or Zomato. The user interface must allow
customers to quickly browse through restaurants, apply filters, select dishes, place orders,
and track delivery. A clean layout, readable fonts, intuitive icons (like a magnifying glass
for search or a cart icon for orders), and responsive feedback (like progress bars or success
messages) all contribute to a good UI experience. Even subtle animations and color choices
influence user behavior and satisfaction.

Benefits of Good UI Design

1. Enhanced User Experience

A thoughtfully crafted UI simplifies interactions and makes it easier for users to
achieve their goals. This improves overall satisfaction and engagement with the
product.

2. Increased Productivity
In business or enterprise applications, efficient UI design allows users to perform
tasks more quickly, reducing time and effort.

3. Reduced Training and Support Costs

A self-explanatory interface reduces the need for manuals or training, saving time and
resources for organizations.

4. Improved Accessibility
Good UI considers diverse users, including those with disabilities, by supporting
screen readers, keyboard navigation, or high-contrast themes.

5. Competitive Advantage
In a crowded market, applications with superior UI often stand out and attract more
users simply by being more usable and visually appealing.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 31

MODULE 3 Software Design

Limitations of UI Design

1. Subjectivity and User Diversity

What is intuitive for one user might be confusing to another. Designing for a wide
range of users, cultures, or devices is challenging.

2. Time and Cost Intensive

High-quality UI design requires collaboration between designers, developers, and
users. It often involves iterations, testing, and refinements which can extend
development time and cost.

3. Technology Constraints
A well-designed UI might not always be technically feasible due to platform
limitations, performance issues, or hardware constraints (especially in embedded or
low-spec environments).

4. Overemphasis on Aesthetics
Sometimes teams focus too much on visual appeal and neglect usability or
accessibility, which defeats the purpose of UI design.

5. Constant Evolution
UI standards and user expectations evolve rapidly. Designers need to keep updating
the UI based on feedback, trends, and new device form factors.

Conclusion

User Interface Design is a critical component of software engineering that bridges human
psychology, technology, and creativity. While it's sometimes undervalued compared to
backend logic or system architecture, UI is often the deciding factor in user satisfaction
and product success. A good UI anticipates user needs, responds gracefully to errors, and
provides clear guidance throughout the user’s journey—making software not just
functional, but delightful to use.

Prof. Rajendra M. Jotawar MAC, AIT, Bangalore 32