UNIT III SOFTWARE DESIGN

Software design – Design process – Design concepts – Coupling – Cohesion – Functional

independence – Design patterns – Model-view-controller – Publish-subscribe – Adapter
– Command – Strategy – Observer – Proxy – Facade – Architectural styles – Layered -
Client Server - Tiered - Pipe and filter- User interface design-Case Study

OVERVIEW OF DESIGN PROCESS

Software design in software engineering
Once the SRS document is completed then based on it the software design activity starts.
During design phase, design document is prepared. So it can be said that the design process
activities involve transforming the SRS document into the design document.

The design document created during the software design in software engineering should be
implementable using a programming language during subsequent coding phase. Software
designer has to keep this in mind while creating the design document.
We will talk about coding phase in later part of this tutorial. Lets move ahead and
cover software design in software engineering for now.

The high level diagram of design process in software engineering is shown below:

The characteristics of good software design are:

• Understandability
• Correctness
• Maintainability
• Efficiency
qualities of good software design
The characteristics of good software design is listed below:

Correctness of software design

Ensuring the correctness of the software design being prepared is very important. By
correctness we mean it should accurately implement all the functionality that software
product needs to exhibit.

A software design which is not correct will never help you to develop good software product.
Suppose if the software designer wrongly captures the relationship between different modules
or wrongly interprets the data flow between two modules then in the next phase software
coders will develop the software product based on the design. And the end software product
is going to have anomaly in it as it would never behave as captured in SRS document during
software requirement and specification phase. This would result in re-work and thus add
unnecessary cost to the software development.

Thus a software designer should be very cautious while designing the layout for the project
and make sure to ensure correctness.

Software design should be understandable

A software design should be prepared to be easily understandable. Easy understandability
will ensure its comprehensibility when the different stakeholders like architects, project
manager or coders will refer it.

If software design understandability or comprehensibility is compromised then it will be

difficult to implement it using programming language. So its duty of the software designer to
make sure the software design is easily understandable in nature.

An understandable design should be modular and layered in nature.

Software design should be efficient in nature

A good software design should capture efficiently all aspects of the product. It should be able
to provide an idea and estimate of the resource needed to complete the modules, time
required for each module and cost as well. It should also capture any optimization issues or
technical hindrance that may show up in future and possibility to handle it.

Software design should be easy to maintain

It is a well known fact that the requirements may change in future based on clients need. So a
good software design should be easily modifiable in nature to accomodate the change
requests at any point of time.

The software design process can be divided into the following three levels or phases of
design:

➢ Interface Design
➢ Architectural Design
➢ Detailed Design

Interface design is the specification of the interaction between a system and its
environment. This phase proceeds at a high level of abstraction with respect to the inner
workings of the system i.e, during interface design, the internal of the systems are
completely ignored, and the system is treated as a black box. Attention is focused on the
dialogue between the target system and the users, devices, and other systems with which it
interacts. The design problem statement produced during the problem analysis step should
identify the people, other systems, and devices which are collectively called agents.
Interface design should include the following details:
1. Precise description of events in the environment, or messages from agents to
which the system must respond.
2. Precise description of the events or messages that the system must produce.
3. Specification of the data, and the formats of the data coming into and going out
of the system.
4. Specification of the ordering and timing relationships between incoming events
or messages, and outgoing events or outputs.

Architectural Design
Architectural design is the specification of the major components of a system, their
responsibilities, properties, interfaces, and the relationships and interactions
between them. In architectural design, the overall structure of the system is chosen,
but the internal details of major components are ignored. Issues in architectural
design includes:
1. Gross decomposition of the systems into major components.
2. Allocation of functional responsibilities to components.
3. Component Interfaces.
4. Component scaling and performance properties, resource consumption
properties, reliability properties, and so forth.
5. Communication and interaction between components.
The architectural design adds important details ignored during the interface design. Design
of the internals of the major components is ignored until the last phase of the design.
Detailed Design
Design is the specification of the internal elements of all major system components, their
properties, relationships, processing, and often their algorithms and the data structures. The
detailed design may include:
1. Decomposition of major system components into program units.
2. Allocation of functional responsibilities to units.
3. User interfaces.
4. Unit states and state changes.
5. Data and control interaction between units.
6. Data packaging and implementation, including issues of scope and visibility of
program elements.
7. Algorithms and data structures.
Design process

Elements of a System
1. Architecture: This is the conceptual model that defines the structure, behavior,
and views of a system. We can use flowcharts to represent and illustrate the
architecture.
2. Modules: These are components that handle one specific task in a system. A
combination of the modules makes up the system.
3. Components: This provides a particular function or group of related functions.
They are made up of modules.
4. Interfaces: This is the shared boundary across which the components of a system
exchange information and relate.
5. Data: This is the management of the information and data flow.
OUTCOME OF DESIGN PHASE
Listed below are the outcome of design phase:
• Various modules required: Software that is going to be developed can be broken down
into different modules. Software design should be able to identify these modules
clearly. Each module will take care of certain important functionality out of all the
activities that the end software product exhibits. For example, if we consider a simple
calculator software then it can be identified to have modules such as addition,
subtraction, division, etc. Each of these can be written as a function with name as
perform Addition, perform Subtraction, etc. Naming your module properly gives clear
indication about the purpose of the module.
• Relationships among modules: The relationship between data flow and function call
between two or different module should be well established during design phase. This
becomes important because one module will call other module with some parameter
and requirement. For example, in calculator software, the main module will call
different modules like perform Addition, perform Division, etc. Now it is necessary to
identify the nature of call like what data will be required during call, what will be
returned as result, etc.
• Interfaces among modules: Interface between modules helps to identify the proper
and exact data which is going to be exchanged between them when one module
invokes other modules functionality.
• Data structure of each modules: Each module of the software design will play around
with data. These data needs to be properly managed with them help of suitable data
structure for smooth functioning of the software product. Thus identifying and
choosing suitable data structure become mandate which needs to be documented as
well in design document.
• Algorithm for each module: Each module will perform some task. These task requires
proper algorithm for their implementation so that space and time complexities issue
doesn't impact the final result and the end software product.

Software Design Concepts

Design activity is carried out in two stages:
1. Preliminary design or high level design
2. Detailed design
The activity carried out in the above two stages may vary depending on the design
methodology adopted.

Concepts are defined as a principal idea or invention that comes into our mind or in thought
to understand something. The software design concept simply means the idea or principle
behind the design. It describes how you plan to solve the problem of designing software,
and the logic, or thinking behind how you will design software. It allows the software
engineer to create the model of the system software or product that is to be developed or
built. The software design concept provides a supporting and essential structure or model
for developing the right software. There are many concepts of software design and some of
them are given below:
1. Abstractions
2. Architecture
3. Patterns
4. Modularity
5. Information Hiding
6. Functional Independence
7. Refinement
8. Re-factoring
9. Design Classes

ABSTRACTION:
Many levels of abstraction.
Highest level of abstraction: Solution is slated in broad terms using the language of the
problem environment
Lower levels of abstraction: More detailed description of the solution is provided
• Procedural abstraction-- Refers to a sequence of instructions that a specific and limited
function
• Data abstraction-- Named collection of data that describe a data object
DESIGN CONCEPTS ARCHITECTURE--Structure organization of program components
(modules) and their interconnection Architecture Models
(a) Structural Models-- An organized collection of program components
(b) Framework Models-- Represents the design in more abstract way
(c) Dynamic Models-- Represents the behavioural aspects indicating changes as a function of
external events
(d). Process Models-- Focus on the design of the business or technical process.

PATTERNS Provides a description to enables a designer to determine the followings:

(a). whether the pattern is applicable to the current work
(b). Whether the pattern can be reused
(c). Whether the pattern can serve as a guide for developing a similar but functionally or
structurally different pattern.
MODULARITY:
 Divides software into separately named and addressable components, sometimes called
modules. Modules are integrated to satisfy problem requirements. Consider two problems p1
and p2. If the complexity of p1 iscp1 and of p2 is cp2 then effort to solve p1=cp1 and effort
to solve p2=cp2 If cp1>cp2 then ep1>ep2
The complexity of two problems when they are combined is often greater than the sum of the
perceived complexity when each is taken separately. • Based on Divide and Conquer strategy
: it is easier to solve a complex problem when broken into sub-modules .
INFORMATION HIDING
Information contained within a module is inaccessible to other modules who do not need
such information. Achieved by defining a set of Independent modules that communicate with
one another only that information necessary to achieve S/W function. Provides the greatest
benefits when modifications are required during testing and later. Errors introduced during
modification are less likely to propagate to other location within the S/W.
FUNCTIONAL INDEPENDENCE
A direct outgrowth of Modularity. abstraction and information hiding. Achieved by
developing a module with single minded function and an aversion to excessive interaction
with other modules. Easier to develop and have simple interface. Easier to maintain because
secondary effects caused b design or code modification are limited, error propagation is
reduced and reusable modules are possible. Independence is assessed by two quantitative
criteria:
(1) Cohesion
(2) Coupling Cohesion -- Performs a single task requiring little interaction with other
components Coupling--Measure of interconnection among modules. Coupling should be low
and cohesion should be high for good design.
REFINEMENT & REFACTORING
REFINEMENT -- Process of elaboration from high level abstraction to the lowest level
abstraction. High level abstraction begins with a statement of functions. Refinement causes
the designer to elaborate providing more and more details at successive level of abstractions
Abstraction and refinement are complementary concepts.
Refactoring -- Organization technique that simplifies the design of a component without
changing its function or behaviour. Examines for redundancy, unused design elements and
inefficient or unnecessary algorithms.
DESIGN CLASSES Class represents a different layer of design architecture. Five types of
Design Classes
1. User interface class -- Defines all abstractions that are necessary for human computer
interaction
2. Business domain class -- Refinement of the analysis classes that identity attributes and
services to implement some of business domain
3. Process class -- implements lower level business abstractions required to fully manage the
business domain classes
4. Persistent class -- Represent data stores that will persist beyond the execution of the
software
5. System class -- Implements management and control function.

Points to be Considered While Designing Software

1. Abstraction (Hide Irrelevant data): Abstraction simply means to hide the details
to reduce complexity and increase efficiency or quality. Different levels of
Abstraction are necessary and must be applied at each stage of the design
process so that any error that is present can be removed to increase the
efficiency of the software solution and to refine the software solution. The
solution should be described in broad ways that cover a wide range of different
things at a higher level of abstraction and a more detailed description of a
solution of software should be given at the lower level of abstraction.
2. Modularity (subdivide the system): Modularity simply means dividing the
system or project into smaller parts to reduce the complexity of the system or
project. In the same way, modularity in design means subdividing a system into
smaller parts so that these parts can be created independently and then use these
parts in different systems to perform different functions. It is necessary to divide
the software into components known as modules because nowadays, there are
different software available like Monolithic software that is hard to grasp for
software engineers. So, modularity in design has now become a trend and is also
important. If the system contains fewer components then it would mean the
system is complex which requires a lot of effort (cost) but if we can divide the
system into components then the cost would be small.
3. Architecture (design a structure of something): Architecture simply means a
technique to design a structure of something. Architecture in designing software
is a concept that focuses on various elements and the data of the structure. These
components interact with each other and use the data of the structure in
architecture.
4. Refinement (removes impurities): Refinement simply means to refine something
to remove any impurities if present and increase the quality. The refinement
concept of software design is a process of developing or presenting the software
or system in a detailed manner which means elaborating a system or software.
Refinement is very necessary to find out any error if present and then to reduce
it.
5. Pattern (a Repeated form): A pattern simply means a repeated form or design in
which the same shape is repeated several times to form a pattern. The pattern in
the design process means the repetition of a solution to a common recurring
problem within a certain context.
6. Information Hiding (Hide the Information): Information hiding simply means to
hide the information so that it cannot be accessed by an unwanted party. In
software design, information hiding is achieved by designing the modules in a
manner that the information gathered or contained in one module is hidden and
can’t be accessed by any other modules.
 7. Refactoring (Reconstruct something): Refactoring simply means reconstructing
something in such a way that it does not affect the behavior of any other
features. Refactoring in software design means reconstructing the design to
reduce complexity and simplify it without impacting the behavior or its
functions. Fowler has defined refactoring as “the process of changing a software
system in a way that it won’t impact the behavior of the design and improves the
internal structure”.

Coupling and Cohesion – Software Engineering

• ••
Introduction: The purpose of the Design phase in the Software Development Life Cycle is to
produce a solution to a problem given in the SRS(Software Requirement Specification)
document. The output of the design phase is a Software Design Document (SDD).
Coupling and Cohesion are two key concepts in software engineering that are used to
measure the quality of a software system’s design.
Coupling refers to the degree of interdependence between software modules. High coupling
means that modules are closely connected and changes in one module may affect other
modules. Low coupling means that modules are independent and changes in one module have
little impact on other modules.
Cohesion refers to the degree to which elements within a module work together to fulfill a
single, well-defined purpose. High cohesion means that elements are closely related and
focused on a single purpose, while low cohesion means that elements are loosely related and
serve multiple purposes.
Both coupling and cohesion are important factors in determining the maintainability,
scalability, and reliability of a software system. High coupling and low cohesion can make a
system difficult to change and test, while low coupling and high cohesion make a system
easier to maintain and improve.

Basically, design is a two-part iterative process. The first part is Conceptual Design which
tells the customer what the system will do. Second is Technical Design which allows the
system builders to understand the actual hardware and software needed to solve a customer’s
problem.
Conceptual design of the system:
• Written in simple language i.e. customer understandable language.
• Detailed explanation about system characteristics.
• Describes the functionality of the system.
• It is independent of implementation.
• Linked with requirement document.
Technical Design of the System:
• Hardware component and design.
• Functionality and hierarchy of software components.
• Software architecture
• Network architecture
• Data structure and flow of data.
• I/O component of the system.
• Shows interface.
Modularization: Modularization is the process of dividing a software system into multiple
independent modules where each module works independently. There are many advantages
of Modularization in software engineering. Some of these are given below:
• Easy to understand the system.
• System maintenance is easy.
• A module can be used many times as their requirements. No need to write it again
and again.
Coupling: Coupling is the measure of the degree of interdependence between the modules. A
good software will have low coupling.
Types of Coupling:
• Data Coupling: If the dependency between the modules is based on the fact that
they communicate by passing only data, then the modules are said to be data
coupled. In data coupling, the components are independent of each other and
communicate through data. Module communications don’t contain tramp data.
Example-customer billing system.
• Stamp Coupling In stamp coupling, the complete data structure is passed from one
module to another module. Therefore, it involves tramp data. It may be necessary
due to efficiency factors- this choice was made by the insightful designer, not a
lazy programmer.
• Control Coupling: If the modules communicate by passing control information,
then they are said to be control coupled. It can be bad if parameters indicate
completely different behavior and good if parameters allow factoring and reuse of
functionality. Example- sort function that takes comparison function as an
argument.
• External Coupling: In external coupling, the modules depend on other modules,
external to the software being developed or to a particular type of hardware. Ex-
protocol, external file, device format, etc.
• Common Coupling: The modules have shared data such as global data structures.
The changes in global data mean tracing back to all modules which access that
data to evaluate the effect of the change. So it has got disadvantages like difficulty
in reusing modules, reduced ability to control data accesses, and reduced
maintainability.
• Content Coupling: In a content coupling, one module can modify the data of
another module, or control flow is passed from one module to the other module.
This is the worst form of coupling and should be avoided.
• Temporal Coupling: Temporal coupling occurs when two modules depend on the
timing or order of events, such as one module needing to execute before another.
This type of coupling can result in design issues and difficulties in testing and
maintenance.
 • Sequential Coupling: Sequential coupling occurs when the output of one module
is used as the input of another module, creating a chain or sequence of
dependencies. This type of coupling can be difficult to maintain and modify.
• Communicational Coupling: Communicational coupling occurs when two or more
modules share a common communication mechanism, such as a shared message
queue or database. This type of coupling can lead to performance issues and
difficulty in debugging.
• Functional Coupling: Functional coupling occurs when two modules depend on
each other’s functionality, such as one module calling a function from another
module. This type of coupling can result in tightly-coupled code that is difficult to
modify and maintain.
• Data-Structured Coupling: Data-structured coupling occurs when two or more
modules share a common data structure, such as a database table or data file. This
type of coupling can lead to difficulty in maintaining the integrity of the data
structure and can result in performance issues.
• Interaction Coupling: Interaction coupling occurs due to the methods of a class
invoking methods of other classes. Like with functions, the worst form of
coupling here is if methods directly access internal parts of other methods.
Coupling is lowest if methods communicate directly through parameters.
• Component Coupling: Component coupling refers to the interaction between two
classes where a class has variables of the other class. Three clear situations exist
as to how this can happen. A class C can be component coupled with another class
C1, if C has an instance variable of type C1, or C has a method whose parameter
is of type C1,or if C has a method which has a local variable of type C1. It should
be clear that whenever there is component coupling, there is likely to be
interaction coupling.
Cohesion: Cohesion is a measure of the degree to which the elements of the module are
functionally related. It is the degree to which all elements directed towards performing a
single task are contained in the component. Basically, cohesion is the internal glue that keeps
the module together. A good software design will have high cohesion.

Types of Cohesion:
• Functional Cohesion: Every essential element for a single computation is
contained in the component. A functional cohesion performs the task and
functions. It is an ideal situation.
• Sequential Cohesion: An element outputs some data that becomes the input for
other element, i.e., data flow between the parts. It occurs naturally in functional
programming languages.
• Communicational Cohesion: Two elements operate on the same input data or
contribute towards the same output data. Example- update record in the database
and send it to the printer.
• Procedural Cohesion: Elements of procedural cohesion ensure the order of
execution. Actions are still weakly connected and unlikely to be reusable. Ex-
calculate student GPA, print student record, calculate cumulative GPA, print
cumulative GPA.
• Temporal Cohesion: The elements are related by their timing involved. A module
connected with temporal cohesion all the tasks must be executed in the same time
span. This cohesion contains the code for initializing all the parts of the system.
Lots of different activities occur, all at unit time.
• Logical Cohesion: The elements are logically related and not functionally. Ex- A
component reads inputs from tape, disk, and network. All the code for these
functions is in the same component. Operations are related, but the functions are
significantly different.
• Coincidental Cohesion: The elements are not related(unrelated). The elements
have no conceptual relationship other than location in source code. It is accidental
and the worst form of cohesion. Ex- print next line and reverse the characters of a
string in a single component.
• Procedural Cohesion: This type of cohesion occurs when elements or tasks are
grouped together in a module based on their sequence of execution, such as a
module that performs a set of related procedures in a specific order. Procedural
cohesion can be found in structured programming languages.
• Communicational Cohesion: Communicational cohesion occurs when elements or
tasks are grouped together in a module based on their interactions with each other,
such as a module that handles all interactions with a specific external system or
module. This type of cohesion can be found in object-oriented programming
languages.
• Temporal Cohesion: Temporal cohesion occurs when elements or tasks are
grouped together in a module based on their timing or frequency of execution,
such as a module that handles all periodic or scheduled tasks in a system.
Temporal cohesion is commonly used in real-time and embedded systems.
• Informational Cohesion: Informational cohesion occurs when elements or tasks
are grouped together in a module based on their relationship to a specific data
structure or object, such as a module that operates on a specific data type or
object. Informational cohesion is commonly used in object-oriented programming.
• Functional Cohesion: This type of cohesion occurs when all elements or tasks in a
module contribute to a single well-defined function or purpose, and there is little
or no coupling between the elements. Functional cohesion is considered the most
desirable type of cohesion as it leads to more maintainable and reusable code.
• Layer Cohesion: Layer cohesion occurs when elements or tasks in a module are
grouped together based on their level of abstraction or responsibility, such as a
module that handles only low-level hardware interactions or a module that handles
 only high-level business logic. Layer cohesion is commonly used in large-scale
software systems to organize code into manageable layers.
Advantages of low coupling:
• Improved maintainability: Low coupling reduces the impact of changes in one
module on other modules, making it easier to modify or replace individual
components without affecting the entire system.
• Enhanced modularity: Low coupling allows modules to be developed and tested in
isolation, improving the modularity and reusability of code.
• Better scalability: Low coupling facilitates the addition of new modules and the
removal of existing ones, making it easier to scale the system as needed.
Advantages of high cohesion:
• Improved readability and understandability: High cohesion results in clear,
focused modules with a single, well-defined purpose, making it easier for
developers to understand the code and make changes.
• Better error isolation: High cohesion reduces the likelihood that a change in one
part of a module will affect other parts, making it easier to
• Improved reliability: High cohesion leads to modules that are less prone to errors
and that function more consistently,
• leading to an overall improvement in the reliability of the system.
Disadvantages of high coupling:
• Increased complexity: High coupling increases the interdependence between
modules, making the system more complex and difficult to understand.
• Reduced flexibility: High coupling makes it more difficult to modify or replace
individual components without affecting the entire system.
• Decreased modularity: High coupling makes it more difficult to develop and test
modules in isolation, reducing the modularity and reusability of code.
Disadvantages of low cohesion:
• Increased code duplication: Low cohesion can lead to the duplication of code, as
elements that belong together are split into separate modules.
• Reduced functionality: Low cohesion can result in modules that lack a clear
purpose and contain elements that don’t belong together, reducing their
functionality and making them harder to maintain.
• Difficulty in understanding the module: Low cohesion can make it harder for
developers to understand the purpose and behavior of a module, leading to errors
and a lack of clarity.

WHAT IS FUNCTIONAL INDEPENDENCE IN SOFTWARE ENGINEERING?

Functional independence in software engineering means that when a module focuses on a
single task, it should be able to accomplish it with very little interaction with other modules.

In software engineering, if a module is functionally independent of other module then

it means it has high cohesion and low coupling.

Functional independence is essential for good software design.

Example of functional independence

We will take an example of simple college level project to explain concept of functional
independence.
Suppose you and your friends are asked to work on a calculator project as a team. Here we
need to develop each calculator functionality in form of modules taking two user inputs.

So our modules are addition Module, subtraction Module, division Module, multiplication
Module. Each one of you pick up one module for development purpose.

Before you enter into development phase, you and your team needs to make sure to design
the project in such a way that each of the module that you develop individually should be
able to perform its assigned task without requiring much or no interaction with your friends
module. What I intend to say is, if you are working on addition Module then your module
should be able to independently perform addition operation on receiving user input. It should
not require to make any interaction with other modules like subtraction Module,
multiplication Module or etc.

This is actually the concept of having module as functional independence of other modules.
There is advantages of functional independence in software engineering which we are going
to discuss next.

Advantage of functional independence

Advantages of functional independence are given below:
Error isolation
When a module is functionally independent then it performs most of its task independently
without interacting with other modules much. This reduces the chances of error getting
propagated to other modules. This helps in easily isolating and tracing the error.

Module reusability
A functionally independent module performs some well defined and specific task. So it
becomes easy to reuse such modules in different program requiring same functionality.

Understandability
A functionally independent module is less complex so easy to understand. Since such
modules are less interaction with other modules so can be understood in isolation.

Add Your Comment

Design patterns

Gang of Four (GOF) Design Patterns

•
The••Gang of Four (GoF) Design Patterns, introduced in the book “Design Patterns: Elements
of Reusable Object-Oriented Software,” authored by Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides, provide a catalog of proven solutions to common design
problems in software development. The GoF Design Patterns encourage best practices, code
reusability, and the separation of concerns, aiding in the development of robust and scalable
applications.
What are Gang of Four (GOF) Design Patterns?
The Gang of Four Design Patterns is a set of solutions to common problems we encounter in
software design and development. They were first introduced in the book Design Patterns:
Elements of Reusable Object-Oriented Software, published in 1994. The book was written by
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, who are collectively
known as Gang of Four.
Why they’re called Gang of Four?
The Gang of Four are four smart people who wrote a book about clever ways to solve
common problems in computer programming, and they’re called the Gang of Four because
there were four of them who wrote the book together. Their book has been a big help to many
programmers around the world.
Types of Gang of Four Design Patterns
The Gang of Four (GOF) patterns are set of 23 common software design patterns introduced
in the book Design Patterns: Elements of Reusable Object-Oriented Software.
These patterns categorize into three main groups:
1. Creational Patterns
2. Structural Patterns
3. Behavioral Patterns
These patterns provide solutions to common design problems and help make software
systems more modular, flexible and maintainable.
Creational Design Patterns
Imagine you’re in a pizza restaurant, and you’re craving a delicious pizza. The Chef has to
make it, right? But here’s the thing – the Chef doesn’t just randomly throw ingredients
together. There’s a method to it, a recipe. In the world of software, we often need to create
things too, just like Pizzas. That’s where Creational Design Patterns come in.
Think of Creational Design Patterns as those secret Pizza recipes that Chef use. These
patterns help us create objects in a smart and organized way, just like how a Chef makes a
perfect Pizza every time.
Creational Design Patterns focus on the process of object creation in software development.
These patterns make sure that we create things in a way that’s not only easy but also flexible,
so we can change them later if we need too. They hide the complicated details of how we put
pieces together.
Types of Creational Design Patterns
1. Factory Method Pattern: Think of it as a way to make objects with flexibility. It’s
like having a blueprint for creating things. You define an interface for creating
objects, but the actual creation is left to subclasses. This means different
subclasses can create objects of different types using the same method.
2. Abstract Factory Pattern: Imagine you’re in charge of a fancy dinner party, and
you need matching tableware, cutlery and decorations. The abstract factory is like
one-stop for all these related items. It provides a way to create families of objects,
ensuring that everything you create fits together seamlessly.
3. Singleton Pattern: This one’s all about exclusivity. It ensures that a class has just
one instance, like having a VIP pass to a club. You can access that instance from
anywhere, making it handy for situations where you want a single point of control
or coordination in your application.
4. Prototype Pattern: Instead of creating something from scratch, you make a copy of
an existing one, saving time and resources. This is great when you have an object
that’s similar to what you need, and you want to tweak it a bit.
5. Builder Pattern: The Builder Pattern is like a set of instructions for making
something complex. It helps you create that complex thing step by step, one piece
at a time, without worrying too much about the details.
 6. Object Pool Pattern: Think of it as a resource manager for reusable items. Imagine
a library that lends out books. Instead of buying a new book each time, you check
one out and return it when you’re done. The object pool keeps a collection of
objects, like database connections or threads, and hands them out when needed.
This saves time and resources compared to createing and destroying objects
frequently.
Structural Design Patterns
A Structural Design pattern is like a recipe for putting together different objects and classes
to build a bigger structure. It’s a bit like following a blueprint to construct a house. These
patterns teach us how to combine the unique parts of a system in a way that’s easy to change
or expand without affecting the entire system.
Types of Structural Design Patterns
1. Adapter Pattern: The Adapter Pattern allows one class to work with another class
that has a different interface. It acts as a bridge between two incompatible
interfaces.
2. Bridge Pattern: The Bridge Pattern separates on object’s abstraction (how it
behaves) from it’s implementation (how it’s done). This helps to change both
independently.
3. Composite Pattern: The Composite Pattern lets you the creation of hierarchical
structures with various complexities while maintaining the ability to treat each
element, whether simple or complex, as an individual entity.
4. Decorator Pattern: The Decorator Pattern allows you to add new behaviors or
responsibilities to objects without altering their existing code. It’s like adding
layers of wrapping to a gift.
5. Facade Pattern: The Facade Pattern provides a simplified interface to a complex
system, making it easier to use.
6. Flyweight Pattern: The Flyweight Patterns lets us save memory and resources by
using the same kind of objects again and again. Instead of making lots of copies, it
checks if we already have one, and if not, it creates a new one. This way, we don’t
waste space on objects that are the same.
7. Proxy Pattern: The Proxy Pattern provides a placeholder of another object to
control access to it. It’s like having a remote control for a TV; you interact with
the remote instead of directly with the TV.
Behavioral Design Patterns
Imagine you’re building a puzzle. In software development, we build complex programs like
puzzles made up of many pieces (objects or classes). Behavioral design patterns are like
special instructions for how these puzzle pieces should talk to each other and work together.
These patterns help solve common problems in how pieces of code share tasks, hide whay
they do, and stay organized. When developers use these patterns, it’s like building a puzzle
where the pieces fit together easily, making the software more organized, easy to change, and
less likely to break when we need to add or change things. So it’s like having a guide to make
sure all the parts of your software work together smoothly.
Types of Behavioral Design Patterns:
1. Chain of Responsibility Pattern: The Chain of Responsibility Pattern is a desing
pattern in software development. It lets you pass a request through a series of
objects, each having its own logic to handle the request or pass it along the chain.
This pattern helps in making code more modular and flexibly, as it seprates the
sender of a request from the receiver, allowing multiple objects to participate in
handling requests.
 2. Command Pattern: The Command Pattern is a behavioral design pattern that
transforms a request into an independent object called a command. This pattern
encapsulate all the necessary information for an action, bundling the action and its
associated parameters into a single object. It’s primary purpose is to decouple the
object triggering the operation from the object performing the operation.
3. Iterator Pattern: The Iterator Pattern offers a mechanism for sequentially accessing
elements within a collection without revealing the internal structure of the
collection.
4. Mediator Pattern: The Mediator Pattern creates a middleman object that manages
communication between group of objects, making them less dependent on each
other.
5. Memento Pattern: The Memento Pattern is like taking a snapshot of an object’s
current condition and saving it in a way that you can use it to bring the object back
to that exact state in the future. It’s like saving a game so you can continue from
where you left off.
6. Observer Pattern: The Observer Pattern establishes a relationship where one thing
(called the subject) is watched by several other things (knows as observers).
7. State Pattern: The State Pattern enables an object to modify how it behaves as its
internal state changes.
8. Strategy Pattern: The Strategy Pattern involves defining a group of different
algorithm and making it possible to choose and switch between them as needed
while a program is running.
9. Template Method Pattern: The Template Method is like providing a recipe with
some fixed steps (skeleton), but allowing different cooks (subclasses) to add their
unique ingredients or flavors (override specific parts) without changing the basic
cooking instructions (overall structure).
Conclusion
Design patterns are like smart and efficient recipes for coding in the world of software
development. They help us solve common problems and build software that works well, is
easy to update, and can handle changes without breaking. The Gang of Four Design Patterns,
introduced by a group of four experts in their famous book, Design Patterns: Elements of
Reusable Object-Oriented Software. They are divided into three categories: Creational,
Structural and Behavioral patterns, each serving a different purpose.

Model-View-Controller (MVC):

Technical Explanation: The Model contains the application's data and business logic. The
View is responsible for rendering the user interface based on the Model's data. The Controller
handles user input, updates the Model, and triggers the necessary changes in the View.

Example: In a Java application, the Model could be a set of JavaBeans, the View could be
implemented using Swing components, and the Controller could use event listeners to capture
user interactions.
Publish-Subscribe (Observer) Pattern:

Technical Explanation: The Observer pattern involves a subject (publisher) and multiple
observers (subscribers). The subject maintains a list of observers and notifies them of any
state changes. Observers implement an interface with an update method to respond to
notifications.
Example: In Java, the java.util.Observable class and java.util.Observer interface can be used.
Subjects extend Observable, and observers implement the update method.
Adapter Pattern:

Technical Explanation: The Adapter pattern allows the integration of incompatible interfaces.
An adapter class wraps an existing class and provides a compatible interface, translating calls
between the new and old systems.
Example: In Java, adapting an existing class to a new interface can be achieved by creating
an adapter class that implements the new interface and delegates calls to the methods of the
existing class.

Command Pattern:

Technical Explanation: The Command pattern encapsulates a request as an object, allowing

for parameterization of clients with different requests. It involves command objects, an
invoker, and objects that perform the actual work.
Example: In Java, command objects can be implemented as classes with an execute method.
An invoker can maintain a list of commands, and clients can pass different command objects
to achieve varying behavior.

Strategy Pattern:

Technical Explanation: The Strategy pattern defines a family of algorithms, encapsulates each
algorithm, and makes them interchangeable. Clients can switch between strategies at runtime.
Example: In Java, strategies can be implemented as a set of classes or interfaces, each
representing a different algorithm. The context class maintains a reference to the current
strategy and delegates the algorithm's execution to it.

Observer Pattern:

Technical Explanation: The Observer pattern involves a subject and multiple observers.
Observers register with the subject, and when the subject's state changes, it notifies all
registered observers.
Example: In Java, the observer pattern can be implemented using interfaces like Observer and
Observable or by creating custom implementations. Observers register with subjects, and the
subjects notify observers of changes.

Proxy Pattern:

Technical Explanation: The Proxy pattern provides a surrogate or placeholder for another
object to control access. This can involve controlling access, lazy loading, or adding
additional functionality.
Example: In Java, a proxy class can be created that implements the same interface as the real
object. The proxy intercepts method calls, performs additional actions (e.g., lazy loading),
and delegates the actual work to the real object.

Facade Pattern:

Technical Explanation: The Facade pattern provides a simplified interface to a set of

interfaces in a subsystem, making it easier to use. It involves a facade class that delegates
client requests to the appropriate subsystem components.
Example: In Java, a facade class can be created to simplify interactions with a complex
subsystem. The facade class hides the complexity of subsystem components and provides a
high-level interface for clients.

ARCHITECTURAL STYLES
Describes a system category that encompasses:
(1) a set of components
(2) a set of connectors that enables “communication and coordination
(3) Constraints that define how components can be integrated to form the system
(4) Semantic models to understand the overall properties of a system Data-flow architectures
Shows the flow of input data, its computational components and output data. Structure is also
called pipe and Filter. Pipe provides path for flow of data. Filters manipulate data and work
independent of its neighbouring filter. If data flow degenerates into a single line of transform,
it is termed as batch sequential. Call and return architectures Achieves a structure that is easy
to modify and scale .Two sub styles (1) Main program/sub program architecture -- Classic
program structure.

Data-flow architectures Shows the flow of input data, its computational components and
output data. Structure is also called pipe and Filter. Pipe provides path for flow of data. Filters
manipulate data and work independent of its neighbouring filter. If data flow degenerates into
a single line of transform, it is termed as batch sequential. Call and return architectures
Achieves a structure that is easy to modify and scale .Two sub styles
(1) Main program/sub program architecture
---Classic program structure
----Main program invokes a number of components, which in turn invoke still
other components

Remote procedure call architecture -- Components of main

program/subprogram are distributed across computers over network .

Object-oriented architectures The components of a system encapsulate data

and the operations. Communication and coordination between components is
done via message .

Layered architectures
A number of different layers are defined Inner Layer( interface with OS) •
Intermediate Layer Utility services and application function) Outer Layer
(User interface)
ARCHITECTURAL PATTERNS :
A template that specifies approach for some behavioural characteristics of the
system Patterns are imposed on the architectural styles Pattern Domains
1.Concurrency --Handles multiple tasks that simulate parallelism. --
Approaches (Patterns)

(a) Operating system process management pattern

(b) A task scheduler pattern
2.Persistence --Data survives past the execution of the process --Approaches
(Patterns) (a) Data base management system pattern
(b) Application Level persistence Pattern( word processing software)

3. Distribution -- Addresses the communication of system in a distributed

environment --Approaches (Patterns)
(a) Broker Pattern -- Acts as middleman between client and server.

Client-Server Architecture:

Definition: This architecture involves dividing the system into two major
components - the client, which makes requests, and the server, which
processes those requests and provides responses.
Key Characteristics: Separation of concerns, scalability, and easier
maintenance.

Tiered Architecture:

Definition: Also known as multi-tier architecture, this design involves

organizing the components of a system into multiple layers or tiers, each
responsible for specific functionality.
Typical Tiers: Presentation tier (user interface), application/business logic tier,
and data storage tier.

Pipe and Filter Architecture:

Definition: In this design, the system is divided into a series of processing

steps (filters) that are connected by pipes. Each filter performs a specific task
on the data and passes it to the next filter through a pipe.
Advantages: Modularity, reusability, and flexibility.

User Interface Design:

Definition: The process of designing the visual and interactive aspects of a

software application or system to ensure a user-friendly experience.
Considerations: User personas, usability, accessibility, and aesthetics.
Case Study:

Purpose: A case study is an in-depth analysis of a particular situation, typically

involving a real-world problem or scenario, to derive insights and lessons.
Components: Introduction, background, problem statement, solution,
implementation details, results, and conclusions.