3. Modeling
• We create models to gain a better understanding of the
actual entity to be built. we can build a model that is
identical in form and shape but smaller in scale.
• In software engineering work, two classes of models can
be created: requirements models and design models.
Requirements models (also called analysis models)
• Represent customer requirements by depicting the
software in three different domains: the information
domain, the functional domain, and the behavioral
domain.
Design models represent characteristics of the software
that help practitioners to construct it effectively: the
architecture, the user interface, and component-level
detail.
5. What is software Design?
• Design is pivotal to successful software
engineering. Software Design allows you to model
the system or product that is to be built.
• A system is a set of interrelated elements
• Formal Definition from text book
– Software Design creates a representation or model of
the software,ie.the design model provides detail about
software architecture, data structures, interfaces, and
components that are necessary to implement the
system.
6. General View of Software System
Example:
Banking System
ATM Client
Banking
Service
ATM
Customer
Cash
Dispenser
Card Reader
Receipt
Printer
ATM Operator
7. Advantages of design modelling
• A group of people can look at these simple diagrams
and quickly get the general idea behind a system.
• It improves the productivity of the development team.
• It improves the understandability of the system .
• It reduces the number of defects in the final code
• It increases the decomposition and modularization of
the system
8. Types of Design Model
• Data/Class Design
• Architectural Design
• Interface Design
• Component-level Design
9. Translating the requirements model into the design model
• Each of the elements of the requirements model provides
information that is necessary to create the four design models
required for a complete specification of design.
10. Types of Design Models
1. The data/class design transforms class models into
design class realizations and the requisite data
structures required to implement the software.
2. The architecture design elements provides us overall
view of the system. This involves breaking the system
down into its major functional pieces and describing
each in a diagrammatic fashion. Ex: OSI Model for
network.
11. Types of Design Models
3. The interface design elements for software represents
the information flow within it and out of the system. It
describes what is user interface, external interface to the
other system, internal interface between various
components. Ex: Messaging System.
– Sources: Therefore, use-case diagram and behavioral models
provide much of the information required for interface design.
4. The component-level design transforms structural
elements of the software architecture into a procedural
description of software components.
– The component level design for the software completely
describes the internal details of the each software component.
– Sources: Information obtained from the class-based models, flow
models, and behavioral models serve as the basis for component
design.
Network Layer
IP AddressNetwork Layer
IP Address
Ipv4
Ipv6
13. How to do Software Design?
• Software design encompasses the set of principles,
concepts, and practices that lead to the development of a
high-quality system or product.
1. Design principles establish an overriding
philosophy(Guidelines) that direct you in the design
work you must perform.
2. Design concepts must be understood before the
mechanics of design practice are applied.
3. Design practice itself leads to the creation of various
representations of the software that serve as a guide
for the construction activity that follows. Using UML
can implement design practice.
14. Software Design /Design Modelling
• Software Design is the process to transform the
user requirements into some suitable form,
which helps the programmer in software coding
and implementation.
• During the software design phase, the design
document is produced, based on the customer
requirements as documented in the SRS
document. Hence the aim of this phase is to
transform the SRS document into the design
document.
15. Major Components of SDS Document
• The following items are designed and
documented during the design phase:
– Different modules required.
– Control relationships among modules.
– Interface among different modules.
– Data structure among the different modules.
– Algorithms required to implement among the
individual modules.
19. Design Principles / Guidelines
A design should exhibit good architectural structure.
The design must implement all of the explicit requirements contained in the
requirements model, and it must accommodate all of the implicit requirements
desired by stakeholders.
A design should be modular, that is, the software should be logically
partitioned into elements or subsystems.
The design document must be a readable, understandable guide for those who
generate code and for those who test and subsequently support the software.
A design should contain distinct representations of data, architecture,
interfaces, and components (modules) .
The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation
perspective.
27. Design Concepts
“The Beginning of wisdom for a [software engineer] is
to recognize the difference between getting a program
to work, and getting it right.”
M. A. Jackson
29. ABSTRACTION
• Abstraction is the act of representing essential features
without including the background details or explanations.
• It is used to reduce complexity and allow efficient design
and implementation of complex software systems.
• Grady Booch has defined abstraction as follows −
– “An abstraction denotes the essential characteristics
of an object that distinguish it from all other kinds of
objects and thus provide crisply defined conceptual
boundaries, relative to the perspective of the viewer.”
• This provide highest level solution is stated in broad
terms using language terms of problem environment;
• At lower level a more detailed description is provided;
31. Modularity
• Monolithic software cannot be easily understand by
a software engineer. It takes more time to solve
more difficult problem.
• Modularization is a software design concept to
divide the software into modules, it follow “divide
an conquer” strategy.
• Advantage:
– it’s easier to solve complex problem when you break it
into manageable pieces.
– Reduce the overall complexity of the project.
• Definition given by Booch is “An important design
objective of modularization is maximize the module
cohesion and minimize coupling”
33. Benefits of Modularization
• Managerial (productivity)
– development time should be shortened because several groups
work on different modules with limited need for
communication
• Product flexibility (reusability, maintainability)
– it should be possible to make changes to one module without
the need to change others
• Comprehensibility (reducing complexity)
– it should be possible to study the system one module at a time
34. Modularization
• Modularizations include all the design decisions which must be
made before the work on independent modules can begin
• Question: What are the criteria to be used in dividing the system
into modules?
• In dividing a system into modules we need some guiding
principles.
– What is good for a module?
– What is bad for a module?
• There are two notions which characterize good things and bad
things about modules nicely
– Cohesion
• We want highly cohesive modules
– Coupling
• We want low coupling between modules
35. MODULARIZATION APPROACHES
• The goals of modularization are to reduce the complexity of the
software, and to improve maintainability, reusability and
productivity.
• A module is a responsibility assignment rather than a subprogram.
• Good modularization: highly cohesive modules and low coupling
between modules
• One modularization approach:
– Functional decomposition/Refinement: Draw a flowchart showing the steps
of the computation and convert steps of the computation to modules.
• Better modularization approach:
– Information hiding/Encapsulation: Isolate the changeable parts, make each
changeable part a secret for a module. Module interface should not reveal
module’s secrets.
36. Information hiding /Encapsulation
• Builds up on modularity concept.
• Modules should be specified and designed so that
information (algorithms and data) contained within a
module is inaccessible to other modules that have no
need for such information;
• Hiding defines and enforces access constraints to
procedural details and local data structures used
within a module.
• Advantage:
– Hiding prevents error propagation outside of a module.
– Security of data,algorithm
38. Functional independence
• Each module should address a specific sub function of
requirements and have a simple interface.
• Functional independent modules are easier to
develop, maintain, and test;
• Error propagation is reduced and reusable modules
are possible;
• Assessed using two qualitative criteria:
o cohesion;
o coupling.
39. Cohesion & Coupling
• Cohesion:
– It is a measure that defines the degree of intra-dependability within
elements of module. The greater the cohesion, better is the program design.
– A cohesive module performs a limited task and it requires a small interaction
with the other components/module in a program.
– Cohesion is an intra-module dependency. During design have to increase
intra-module dependency.
• Coupling
– Coupling is an indication of interconnection/interdependency between
modules in a structure of software.
– Coupling is an inter-Module dependency. During design have to decrease
inter-module dependency.
– Example
• If two modules are strongly coupled are strongly dependent on each other.
• On the other hand, two modules that are loosely coupled are not dependent on
each other.
41. Refinement
• It is a process of elaboration; It is a top-down design strategy.
• Stepwise Refinement is a way of working on big or complicated
problems by splitting them into smaller, more manageable pieces
• A hierarchy is established by decomposing a statement
of function in a stepwise manner till the programming language
statement are reached.
• Stepwise refinement is the idea that software is developed by
moving through the levels of abstraction, beginning at higher
levels and, incrementally refining the software through each level
of abstraction, providing more detail at each increment. At
higher levels, the software is merely its design models; at lower
levels there will be some code; at the lowest level the software
has been completely developed.
42. Abstraction vs refinement
• Abstraction and refinement are
complementary features:
o Abstraction is concerned with hiding
lower levels of detail; it moves from lower
to higher levels.
o Refinement is the movement from higher
levels of detail to lower levels
44. Refactoring
•“Refactoring is the process of changing
a software system in such a way that it does not alter the
external behavior of the code, yet improves its internal
structure.
•Refactoring is making changes to a body of code in order
to improve its internal structure, without changing its
external behavior.
•Use:
• Refactoring Improves the Design of Software
• Refactoring Makes Software Easier to Understand
• Refactoring Helps Finding Bugs
• Refactoring Helps Programming Faster
45. Refactoring
• When to refactor?
– On adding new functionality.
– On fixing errors
– On Review Code
46. Architecture
• The complete structure of the software is known as
software architecture.
• Structure provides conceptual integrity for a system
in a number of ways.
• The architecture is the structure of program
modules where they interact with each other in a
specialized way.
• The components use the structure of data.
• The aim of the software design is to obtain a good
architectural framework of a system.
• Goal – derive architectural rendering of system,
that serves as a framework from which more
detailed design activities are conducted.
47. Types of Architecture
Architectural design models:
• Data centered architectures
• Data- flow architectures
• Call and Return architectures
• Object Oriented architecture
• Layered architecture
48. Patterns
• A standardized way/method/template to address/solving a recurring problems in
software engineering.
• Software Engineering =>Giving Solution to Problem
• Definition: Design Pattern is a general reusable solution to a commonly occurring
problems within a given context in software design.
• Advantage:
– Developers are using the design patterns as a common platform to solve the software
engineering problem we are using software patterns.
– They provide best solutions to certain problems faced during software development.
Learning these patterns helps unexperienced developers to learn software design in
an easy and faster way.
• Example
– Prototype
• It uses the clone method to duplicate existing instances to be used as a prototype for new instances
public abstract class Shape implements Cloneable
{
//Functon definition
}
– Adapter
• works as a bridge between two independent interfaces
– Abstract Factory
• The Factory Method defines an interface for object creation
• 23 design patterns are there in Java to design system.
49. Characteristics of well formed Software design
• Complete and sufficient
• Clear & Understandable
• High cohesion
• Low coupling
50. RECAP
• Which of these describes refinement?
a) It is a data-flow representation.
b) It is a top-down stepwise elaboration.
c) A design notation is a symbolic representational system.
d) It follows Structure chart.
• CASE Tool stands for______________
a) Computer Aided Software Engineering
b) Component Aided Software Engineering
c) Computer Analysis Software Engineering
d) Constructive Aided Software Engineering
• What is / are the characteristics of a well-formed design class?
a) High Cohesion
b) Low Coupling
c) Understandable
d) All of the above
51. RECAP
• Independence of module is assessed using two qualitative criteria. What are
those criteria?
a) Module and modularity
b) Cyclomatic complexity and modularity
c) Cohesion and coupling
d) None of the above
• Independent modules are easier to maintain and test because of ______
a) Code modification is limited,
b) Error propagation is reduced
c) Reusable modules are possible.
d) All of the above
• ________ is an indication of the relative interdependence among modules.
a) Cohesion
b) Coupling
c) Modularity
d) Cohesion and coupling.
53. What is software architecture and how it is related to
software design?
• Definition:
– The software architecture of a system is the set of structures
needed to reason about the system, which comprise software
elements, relations among them and properties of both.
54. What software architecture contains? Or
Elements of Software Architecture with an Example
• Software components
• Details: Data structure
and Algorithm
• Relationship among
components
• Dependency, data flow,
control flow
58. • What is software architecture?
– The software architecture of a program or computing system is a depiction of
the system that aids in understanding how the system will behave.
– Divide the system into a set of modules.
– Decide the interfaces of the modules.
– Figure out the interactions among different modules
• Why to use software Architecture?
– Software architecture serves as the blueprint for both the system and the
project developing it, understanding the work assignments that must be
carried out by design and implementation teams.
– Architecture is an artifact for early analysis to make sure that a design
approach will yield an acceptable system.
– By building an effective architecture, you can identify design risks and
mitigate them early in the development process.
– Time scheduling for design and implementation
• Impact of designing Worst Architecture
– A good architecture is important, otherwise it becomes slower and more
Why to use Software Architecture?
60. Role of Software Architecture
• “Software architecture” as a framework made up of the
system structures that comprise the software components,
their properties, and the relationships among these
components.
• The goal of the architectural model is to allow the software
engineer to view and evaluate the system as a complete
before moving to component design.
• A series of architecture decisions and trade-offs impact
quality, performance, maintainability, and overall success of
the system.
61. Importance of software architecture
1. The representation of software architecture
allows the communication between all
stakeholder and the developer.
2. The architecture focuses on the early design
decisions that impact on all software
engineering work and it is the ultimate
success of the system.
3. The software architecture composes a small
and intellectually graspable model.
4. This model helps the system for integrating
the components using which the components
are work together.
62. Role of Software Architect
• A Software Architect provides a solution that the technical team can create and
design for the entire application. A software architect should have expertise in
the following areas:
• Technology Expertise
– Expert on available and current technologies that helps in the implementation of the system.
– Coordinate the selection of programming language, framework, platforms, databases, etc.
• Methodological Expertise
– Expert on software development methodologies that may be adopted during SDLC (Software
Development Life Cycle).
– Choose the appropriate approaches for development that helps the entire team.
• Design Expertise
– Expert in software design, including diverse methods and approaches such as object-oriented
design, data design, etc.
– Lead the development team and coordinate the development efforts for the integrity of the
design.
– Should be able to review design proposals and tradeoff among themselves.
• Domain Expertise
– Expert on the system being developed and plan for software evolution.
– Assist in the requirement investigation process, assuring completeness and consistency.
– Coordinate the definition of domain model for the system being developed.
63. Deliverables of the Software Architect
• A clear, complete, consistent, and achievable set of functional
goals.
• A concept for the system.
• A design in the form of the system architecture, with at least two
layers of decomposition.
• A notion of the timing, operator attributes, and the
implementation and operation plans.
• A document or process (SDS) which ensures functional
decomposition is followed, and the form of interfaces is
controlled.
64. Examples of Modules in System Architecture
• Web module for HTTP requests ( The WebApp)
• Repository and Data access Layer modules. (DAL code)
• Models module containing all the business entities.
• WebService modules for integrating with other apps.
• Infrastructure/Utility modules for utility like
functionalities and application configuration.
• Business logic modules.
• Transaction gateway module.
Tools to Draw Architecture
• Visual Paradigm
• Edraw
• visio
65. Software Architecture Patterns
• The purpose of Architectural Patterns is to understand
how the major parts of the system fit together and how
messages and data flow through the system.
• Architectural Pattern is a general and reusable solution
to an occurring problem in a particular context. It is a
recurring solution to a recurring problem.
• Types of Software Architecture Patterns:
– 3-Tier Architecture
– 2-Tier Architecture
– 1-Tier Architecture
66. Software Architecture Patterns
• 3-Tier Architecture
1. Presentation Layer
– End user interacts with a system
through presentation layer.
2. Application Layer
– Business logic and functions done by
server.
3. Data Layer
It is a collection of information in an
organized way so that it can be easily
accessed, managed and updated.
• 3-Tier Architecture
• Some of the popular sites who have
applied this architecture are:
– MakeMyTrip.com
– Sales Force enterprise application
– Indian Railways – IRCTC
– Amazon.com, etc.
69. 2-Tier Architecture & 1-Tier Architecture
• 2-Tier Architecture:
– It is like Client-Server architecture,
where communication takes place
between client and server.
– In this type of software
architecture, the presentation layer
or user interface layer runs on the
client side while dataset layer gets
executed and stored on server side.
– There is no Business logic layer or
immediate layer in between client
and server.
• 1-Tier Architecture:
– It is the simplest one as it is
equivalent to running the
application on the personal
computer. All of the required
components for an application
to run are on a single
application or server.
– Presentation layer, Business
logic layer, and data layer are all
located on a single machine.
70. RECAP
• Which of the following are correct statements?
a) An architecture may or may not defines components.
b) An architecture is not dependable on requirements
c) An architecture is foremost an abstraction of a system that suppresses
details of the components that do not affect how they are used
d) All of the mentioned
• The architectural representation can be an enable for
communication among project stakeholders
a) True
b) False
• Which of the following is true?
a) The input of architectural design process is SDS
b) The output of architectural design process is SRS
c) The input of architectural design process is SRS
d) None of the mentioned
71. RECAP
• Architecture of a software is based on ________________.
a) Requirements
b) Design
c) All of the mentioned
d) None of the mentioned
• Software architecture means _________________.
a) It comprises of software components
b) It is the structure or structure of systems
c) Relationship among components
d) All of the above
72. Software Architectural style
• The architectural style is a very specific solution to a particular software which
focuses on how to organize the code efficiently created for the software.
• It’s the highest level of granularity and it specifies layers, high-level modules of
the application and how those modules and layers interact with each other, the
relations between them.
• A topological layout of the components indicating their runtime
interrelationships.
• Each style describes a system category that encompasses:
• (1) a set of components (e.g., a database, computational modules) that
perform a function required by a system
• (2) a set of connectors that enable “communication, coordination and
cooperation” among components
• (3) constraints that define how components can be integrated to form the
system,
73. Software Architectural style
• There are 5 types in architectural style
– Data-centered Architecture
– Data- flow architectures
– Call and Return architectures
– Object Oriented architecture
– Layered architecture
• An Architectural Style is the application design at the highest level of
abstraction;
• An Architectural Pattern is a way to implement an Architectural Style;
74. 1.Data centered architectures/Repository architecture
• A data store will reside at the center of this architecture
and is accessed frequently by the other components that
update, add, delete or modify the data present within the
store.
• The client software access a central repository. This data-
centered architecture will promote integrability, scalability.
• This means that the existing components can be changed
and new client components can be added to the
architecture without the permission or concern of other
clients.
• Example:
– Inventory Management
– Student Management
75. Model of Data centered architectures/Repository
architecture
76. Ex of Data centered architectures/Repository architecture
77. 2.Data- flow architectures/Pipe-and-Filter
Architecture
• Data enters the system and then flows through the components one at a time until they are
assigned to output or a data store.
• Pipe and Filter is a simple architectural style that connects a number of components that
process a stream of data, each connected to the next component in the processing pipeline
via a Pipe.
• The Pipe and Filter architecture is inspired by the Unix technique of connecting the output
of an application/component to the input of another component via
pipes/communication link.
• The pipe and filter architecture consists of one or more data sources. The data source is
connected to data filters via pipes.
• The filters incrementally transform the data (entering and exiting via streams).The pipes are
stateless and simply exist to move data between filters.
• Filters process the data they receive, passing them to other filters in the pipeline. The final
data is received at a Data Sink.
79. Ex of Data flow architectures
Give
Assignment
Submit
Assignment
Grade
Assignment
Update
Gradebook
Calculate
Internal
Generate
Report
80. Ex of Data flow architectures
• Explains how the MM executes a program
81. 3.Call and Return architectures
• It is used to create a program that is easy to scale and
modify. Many sub-styles exist within this category.
• Popular example of Call and Return architectures is :
1. Main program or Subprogram architectures:
• Decomposes a program hierarchically into small
pieces (i.e., modules)
• Typically has a single thread of control that travels
through various components in the hierarchy
82. Main program or Subprogram architectures
Ex:Main program or Subprogram architectures
85. 4.Object Oriented architecture
• In object-oriented architectural style, components of a
system encapsulate data and functions.
• In this style, components are represented as objects
and they interact with each other through methods
(connectors).
• This architectural style has two Styles:
– Conceptual Design
– Detailed Design
86. Two stages of object-oriented design
•Conceptual model
recognizes all the classes
required to build the
system.
In conceptual design,
individual responsibilities
are allocated to each class.
In high-level design, class
diagram is used to analyze
the relationships between
classes and interaction
diagram is used for
showing the flow of
events.
1.Conceptual
Design
In detailed design, the
attributes and operations
are allocated to each class
based on their interaction
diagram.
•The state machine
diagram is developed to
explain the next details of
design is called as low level
design.
•This represents object
states of a system,
modeling
reactive(dynamic) system,
identifying events which
are responsible for state
changes.
2.Detailed
Design
88. Advantages of Object Oriented architecture
• Some of the advantages associated with the
object-oriented architecture are listed below.
–It allows designers to decompose a problem
into a collection of independent objects.
– The implementation detail of objects is
hidden from each other and hence, they can
be changed without affecting other objects.
89. 5.Layered architecture
• A number of different layers are defined with
each layer performing a well-defined set of
operations.
• Each layer will do some operations that becomes
closer to machine instruction set progressively.
• At the outer layer, components will receive the
user interface operations and at the inner layers,
components will perform the operating system
interfacing(communication and coordination
with OS) Intermediate layers to utility services
and application software functions
92. RECAP
• Name the type of software architecture patterns.
• Name the types of software architectural styles.
• What is a drawback of data centred architecture?
• What are the components of software architecture?
93. Levels of Software Design[OR]Types of Software Design
• Data Design
– Entity-Relationship Diagram
• Class Design
– Class Diagram in UML
• Architectural Design
• Interface Design
– Data flow Diagram/Interface Diagram
• Component Diagram
– Component Diagram in UML
95. Data Design/Data Modelling
• Data design is the first design activity of the four design activities
in software engineering, which results in less complex, modular
and efficient program structure.
• The information domain model developed during analysis phase
is transformed into data structures needed for implementing the
software.
• The data design element produced a model of data that represent
a high level of abstraction.
• The data objects, attributes, and relationships depicted in entity
relationship diagrams(E-R Model) and data dictionary provide a
base for data design activity.
• During the data design process, data types are specified along
with the integrity rules required for the data.
97. Interface Design/Functional Modelling
• This can be design using Data-flow diagram(DFD) and
interface diagram.
• A Data Flow Diagram (DFD) is a visual representation of
the information flows within a system. A neat and clear
DFD can depict the right amount of the system
requirement graphically.
• DFD is often called as a data flow graph.
• The objective of a DFD is to show the scope and
boundaries of a system as a whole. It may be used as a
communication tool between a system analyst and
stakeholder. The DFD is also called as a data flow graph.
100. System Design Process
• Systems design is the process of defining elements of a system like
modules, architecture, components and their interfaces and data
for a system based on the specified requirements.
• It is the process of defining, developing and designing systems
which satisfies the specific needs and requirements of a business or
organization.
• A systemic approach is required for a coherent and well-running
system. Bottom-Up or Top-Down approach is required to take into
account all related variables of the system.
• A designer uses the modelling languages to express the information
and knowledge in a structure of system that is defined by a
consistent set of rules and definitions.
• The designs can be defined in graphical and textual modelling
languages.
101. System Design Process
• Some of the examples of graphical modelling
languages are:
– Unified Modelling Language (UML): To describe software both
structurally and behaviourally with graphical notation.
– Flowchart : A schematic or stepwise representation of an
algorithm.
– Business Process Modelling Notation (BPMN): Used for Process
Modelling language.
– Systems Modelling Language (SysML): Used for systems
engineering.
102. System Design Process
• Design methods:
– 1) Architectural design
• To describes the views, models, behaviour, and structure of
the system.
– 2) Logical design
• To represent the data flow, inputs and outputs of the system.
Example: ER Diagrams (Entity Relationship Diagrams).
– 3) Physical design
• Defined as a) How users add information to the system and
how the system represents information back to the user. b)
How the data is modelled and stored within the system. c)
How data moves through the system, how data is validated,
secured and/or transformed as it flows through and out of
the system.
104. Transform Mapping
• Transform mapping is a technique in which
Data Flow Diagrams (DFD's) are mapped to a
specific software architecture.
• It is a data flow-oriented mapping technique
that uses DFDs to map real life scenarios to a
software architecture. These real life scenarios
are converted to what we call DFDs which can
be applied to a software architecture.
• This process of converting a real-life situation
(termed as system in software engineering)
with flow of data to a architecture diagram is
called transform mapping.
109. Output of Transform Mapping
Refer:https://www.1000sourcecodes.com/2012/05/software-engineering-
transform-mapping.html?m=1
110. Transaction Mapping
• Similar to ‘transform mapping’, transaction analysis
makes use of DFDs diagrams to establish the various
transactions involved and producing a structure chart
as a result.
• In transaction mapping a single data item triggers
one of a number of information flows that affect a
function implied by the triggering data item. The
data item implies a transaction.
111. Design Patterns
• Design patterns are reusable solutions for software
development. They serve as templates that programmers can
use when creating applications. They are not specific to
individual programming languages, but instead are best
practices or heuristics that can be applied in different
programming environments.
• The idea is to speed up the development process by providing
well tested, proven development/design paradigm.
• Design patterns are programming language independent
strategies for solving a common problem.
• That means a design pattern represents an idea, not a particular
implementation. By using the design patterns you can make your
code more flexible, reusable and maintainable.
• Whenever there is a need, you have to implement a suitable
pattern to avoid such problems in the future.
113. Design Patterns
• Major types of design patterns:
– Creational
• These design patterns are all about class instantiation or
object creation.
• Use case of creational design pattern:
• Suppose a developer wants to create a simple DBConnection class to connect
to a database and wants to access the database at multiple locations from
code, generally what developer will do is create an instance of DBConnection
class and use it for doing database operations wherever required. Which
results in creating multiple connections from the database as each instance
of DBConnection class will have a separate connection to the database. In
order to deal with it, we create DBConnection class as a singleton class, so
that only one instance of DBConnection is created and a single connection is
established. Because we can manage DB Connection via one instance so we
can control load balance, unnecessary connections, etc.
• Creational design patterns are singleton,factory
114. Design Patterns
• Major types of design patterns:
– Structural
• These design patterns are about organizing different classes and
objects to form larger structures and provide new functionality.
• Structural design patterns are Adapter, Bridge, Composite,
Decorator, Facade, Flyweight, Private Class Data, and Proxy.
• Usecase of structural design pattern
– When 2 interfaces are not compatible with each other and
want to make establish a relationship between them through
an adapter its called adapter design pattern.
115. Design Patterns
• Major types of design patterns:
– Behavioral
• Behavioral patterns are about identifying common communication
patterns between objects and realize these patterns.
• Behavioral patterns are Chain of responsibility, Command,
Interpreter, Iterator, Mediator, Memento, Null Object, Observer,
State, Strategy, Template method, Visitor
• Usecase of behavioral design pattern
– When 2 interfaces are not compatible with each other and
want to make establish a relationship between them through
an adapter its called adapter design pattern.