SlideShare una empresa de Scribd logo
1 de 115
SOFTWARE DESIGN
TOPICS
Design Principles
 Design Concepts
Modular Design
 Design Effective Modularity (Cohesion & Coupling)
 Introduction to Software Architecture
Data Design
Interface Design/Functional Modelling
System Design
Transform Mapping
 Transaction Mapping
Design Patterns
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.
Design Model
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.
General View of Software System
Example:
Banking System
ATM Client
Banking
Service
ATM
Customer
Cash
Dispenser
Card Reader
Receipt
Printer
ATM Operator
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
Types of Design Model
• Data/Class Design
• Architectural Design
• Interface Design
• Component-level Design
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.
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.
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
Design Modelling
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.
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.
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.
Example of Software Design &
Architecture
Student Education Portal
Student Education Portal
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.
Example of Class/Data Design-ATM System
Example of Class/Data Design-BookMyShow.com
https://cnx.org/contents/QQMFd2tj@1/StarUML-
Tutorial
Example of Architecture Design
Example of Interface Design
Example of Component Design
Example of Component Design
Software Design Concepts
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
Software Design Concepts
1.Abstraction 2.Modularity 3.Encapsulation
4.Functional
Independence
5.Refinement 6.Refactoring
7.Architecture 8.Patterns
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;
Abstraction
OOSE
Unit 1
Topic 1
Topic 2
Unit 2
Unit 3
Unit 4
Unit 5 Topics
Topic 1
Topic 1
Highest level of
Abstraction
LowerlevelofAbstraction
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”
Modularity
Module 1 Module 2 Module 3 Module 4 Module 5 Module 6
Integrate to make Complete Software
Software Requirement
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
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
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.
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
Information hiding /Encapsulation
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.
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.
Cohesion vs Coupling
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.
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
Refinement
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
Refactoring
• When to refactor?
– On adding new functionality.
– On fixing errors
– On Review Code
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.
Types of Architecture
Architectural design models:
• Data centered architectures
• Data- flow architectures
• Call and Return architectures
• Object Oriented architecture
• Layered architecture
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.
Characteristics of well formed Software design
• Complete and sufficient
• Clear & Understandable
• High cohesion
• Low coupling
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
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.
SOFTWARE ARCHITECTURE
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.
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
Example of Facebook
Example of Facebook
Example of Facebook
• 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?
Role of Software Architecture
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.
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.
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.
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.
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
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
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.
3-Tier Architecture
Example of 3-Tier System Architecture
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.
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
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
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,
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;
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
Model of Data centered architectures/Repository
architecture
Ex of Data centered architectures/Repository architecture
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.
Model of Data flow architectures
Ex of Data flow architectures
Give
Assignment
Submit
Assignment
Grade
Assignment
Update
Gradebook
Calculate
Internal
Generate
Report
Ex of Data flow architectures
• Explains how the MM executes a program
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
Main program or Subprogram architectures
Ex:Main program or Subprogram architectures
Main program or Subprogram architectures
Main program or Subprogram architectures
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
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
Object Oriented architecture
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.
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
5.Layered architecture
5.Layered architecture
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?
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
Data Design
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.
E-R Diagram(Entity-Relationship Diagram)
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.
Data-flow diagram
Example of DFD
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.
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.
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.
Transform Mapping
&
Transaction Mapping
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.
Transform Mapping
data flow model
"Transform" mapping
a
b
c
d e f
g h
i
j
x1
x2 x3 x4
b c
a
d e f g i
h j
Input of Transform Mapping
Ex:SafeHome security system
Detail DFD(Input of Transform Mapping)
Transform Mapping
Output of Transform Mapping
Refer:https://www.1000sourcecodes.com/2012/05/software-engineering-
transform-mapping.html?m=1
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.
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.
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
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.
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.

Más contenido relacionado

La actualidad más candente

Software architecture design ppt
Software architecture design pptSoftware architecture design ppt
Software architecture design pptfarazimlak
 
User Interface Analysis and Design
User Interface Analysis and DesignUser Interface Analysis and Design
User Interface Analysis and Design Saqib Raza
 
REQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGSaqib Raza
 
Software Engineering 2 lecture slide
Software Engineering 2 lecture slideSoftware Engineering 2 lecture slide
Software Engineering 2 lecture slideAdil Mehmoood
 
Unit 5- Architectural Design in software engineering
Unit 5- Architectural Design in software engineering Unit 5- Architectural Design in software engineering
Unit 5- Architectural Design in software engineering arvind pandey
 
Software requirements specification
Software requirements specificationSoftware requirements specification
Software requirements specificationlavanya marichamy
 
Quality and productivity factors
Quality and productivity factorsQuality and productivity factors
Quality and productivity factorsNancyBeaulah_R
 
Agile development, software engineering
Agile development, software engineeringAgile development, software engineering
Agile development, software engineeringRupesh Vaishnav
 
Pressman ch-11-component-level-design
Pressman ch-11-component-level-designPressman ch-11-component-level-design
Pressman ch-11-component-level-designOliver Cheng
 
Design Pattern in Software Engineering
Design Pattern in Software EngineeringDesign Pattern in Software Engineering
Design Pattern in Software EngineeringManish Kumar
 
Software requirement specification
Software requirement specificationSoftware requirement specification
Software requirement specificationshiprashakya2
 
Modules and modularization criteria
Modules and modularization criteriaModules and modularization criteria
Modules and modularization criteriaUmaselvi_R
 
Design concept -Software Engineering
Design concept -Software EngineeringDesign concept -Software Engineering
Design concept -Software EngineeringVarsha Ajith
 
Fundamental design concepts
Fundamental design conceptsFundamental design concepts
Fundamental design conceptssrijavel
 
Software Cost Estimation Techniques
Software Cost Estimation TechniquesSoftware Cost Estimation Techniques
Software Cost Estimation TechniquesSanthi thi
 
Chapter 1 2 - some size factors
Chapter 1   2 - some size factorsChapter 1   2 - some size factors
Chapter 1 2 - some size factorsNancyBeaulah_R
 

La actualidad más candente (20)

Software architecture design ppt
Software architecture design pptSoftware architecture design ppt
Software architecture design ppt
 
User Interface Analysis and Design
User Interface Analysis and DesignUser Interface Analysis and Design
User Interface Analysis and Design
 
REQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERING
 
Software Engineering 2 lecture slide
Software Engineering 2 lecture slideSoftware Engineering 2 lecture slide
Software Engineering 2 lecture slide
 
Component level design
Component   level designComponent   level design
Component level design
 
Unit 5- Architectural Design in software engineering
Unit 5- Architectural Design in software engineering Unit 5- Architectural Design in software engineering
Unit 5- Architectural Design in software engineering
 
Software requirements specification
Software requirements specificationSoftware requirements specification
Software requirements specification
 
Quality and productivity factors
Quality and productivity factorsQuality and productivity factors
Quality and productivity factors
 
Agile development, software engineering
Agile development, software engineeringAgile development, software engineering
Agile development, software engineering
 
Pressman ch-11-component-level-design
Pressman ch-11-component-level-designPressman ch-11-component-level-design
Pressman ch-11-component-level-design
 
Design Pattern in Software Engineering
Design Pattern in Software EngineeringDesign Pattern in Software Engineering
Design Pattern in Software Engineering
 
Software requirement specification
Software requirement specificationSoftware requirement specification
Software requirement specification
 
unit testing and debugging
unit testing and debuggingunit testing and debugging
unit testing and debugging
 
Modules and modularization criteria
Modules and modularization criteriaModules and modularization criteria
Modules and modularization criteria
 
Design concept -Software Engineering
Design concept -Software EngineeringDesign concept -Software Engineering
Design concept -Software Engineering
 
SQE Lecture 1.pptx
SQE Lecture 1.pptxSQE Lecture 1.pptx
SQE Lecture 1.pptx
 
Fundamental design concepts
Fundamental design conceptsFundamental design concepts
Fundamental design concepts
 
Software Quality Metrics
Software Quality MetricsSoftware Quality Metrics
Software Quality Metrics
 
Software Cost Estimation Techniques
Software Cost Estimation TechniquesSoftware Cost Estimation Techniques
Software Cost Estimation Techniques
 
Chapter 1 2 - some size factors
Chapter 1   2 - some size factorsChapter 1   2 - some size factors
Chapter 1 2 - some size factors
 

Similar a Software design

Design Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxDesign Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxKarthigaiSelviS3
 
Function Oriented and Object Oriented Design,Modularization techniques
Function Oriented and Object Oriented Design,Modularization techniquesFunction Oriented and Object Oriented Design,Modularization techniques
Function Oriented and Object Oriented Design,Modularization techniquesnimmik4u
 
CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3SIMONTHOMAS S
 
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvfUNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvfputtipavan23022023
 
Design Engineering and Design concepts
Design Engineering and Design conceptsDesign Engineering and Design concepts
Design Engineering and Design conceptsJigyasaAgrawal7
 
Chapter 1 - Software Design - Introduction.pptx
Chapter 1 - Software Design - Introduction.pptxChapter 1 - Software Design - Introduction.pptx
Chapter 1 - Software Design - Introduction.pptxHaifaMohd3
 
Pressman_ch_9_design_engineering.ppt
Pressman_ch_9_design_engineering.pptPressman_ch_9_design_engineering.ppt
Pressman_ch_9_design_engineering.pptMotherTheresa2
 
Software architecture and software design
Software architecture and software designSoftware architecture and software design
Software architecture and software designMr. Swapnil G. Thaware
 
Object oriented sad-5 part i
Object oriented sad-5 part iObject oriented sad-5 part i
Object oriented sad-5 part iBisrat Girma
 
Software Design and Modularity
Software Design and ModularitySoftware Design and Modularity
Software Design and ModularityDanyal Ahmad
 

Similar a Software design (20)

Design Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxDesign Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptx
 
Function Oriented and Object Oriented Design,Modularization techniques
Function Oriented and Object Oriented Design,Modularization techniquesFunction Oriented and Object Oriented Design,Modularization techniques
Function Oriented and Object Oriented Design,Modularization techniques
 
CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3CS8494 SOFTWARE ENGINEERING Unit-3
CS8494 SOFTWARE ENGINEERING Unit-3
 
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvfUNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
 
software Design.ppt
software Design.pptsoftware Design.ppt
software Design.ppt
 
unit 3 Design 1
unit 3 Design 1unit 3 Design 1
unit 3 Design 1
 
Design Engineering and Design concepts
Design Engineering and Design conceptsDesign Engineering and Design concepts
Design Engineering and Design concepts
 
Software Design Concepts
Software Design ConceptsSoftware Design Concepts
Software Design Concepts
 
Software design
Software designSoftware design
Software design
 
Design final
Design finalDesign final
Design final
 
DESIGN CONCEPTS
DESIGN CONCEPTSDESIGN CONCEPTS
DESIGN CONCEPTS
 
Software engg unit 3
Software engg unit 3 Software engg unit 3
Software engg unit 3
 
rEFUP.pdf
rEFUP.pdfrEFUP.pdf
rEFUP.pdf
 
Chapter 1 - Software Design - Introduction.pptx
Chapter 1 - Software Design - Introduction.pptxChapter 1 - Software Design - Introduction.pptx
Chapter 1 - Software Design - Introduction.pptx
 
Pressman_ch_9_design_engineering.ppt
Pressman_ch_9_design_engineering.pptPressman_ch_9_design_engineering.ppt
Pressman_ch_9_design_engineering.ppt
 
CHAPTER12.ppt
CHAPTER12.pptCHAPTER12.ppt
CHAPTER12.ppt
 
Software architecture and software design
Software architecture and software designSoftware architecture and software design
Software architecture and software design
 
Object oriented sad-5 part i
Object oriented sad-5 part iObject oriented sad-5 part i
Object oriented sad-5 part i
 
Software Design and Modularity
Software Design and ModularitySoftware Design and Modularity
Software Design and Modularity
 
06 fse design
06 fse design06 fse design
06 fse design
 

Más de Benazir Fathima

Simple example program for inheritance in c++
Simple example program for inheritance in c++Simple example program for inheritance in c++
Simple example program for inheritance in c++Benazir Fathima
 
Analysis modeling & scenario based modeling
Analysis modeling &  scenario based modeling Analysis modeling &  scenario based modeling
Analysis modeling & scenario based modeling Benazir Fathima
 

Más de Benazir Fathima (6)

Simple example program for inheritance in c++
Simple example program for inheritance in c++Simple example program for inheritance in c++
Simple example program for inheritance in c++
 
Requirement engineering
Requirement engineeringRequirement engineering
Requirement engineering
 
Behavioural modelling
Behavioural modellingBehavioural modelling
Behavioural modelling
 
Data modeling
Data modeling Data modeling
Data modeling
 
Analysis modeling & scenario based modeling
Analysis modeling &  scenario based modeling Analysis modeling &  scenario based modeling
Analysis modeling & scenario based modeling
 
Complete unit ii notes
Complete unit ii notesComplete unit ii notes
Complete unit ii notes
 

Último

A Study of Urban Area Plan for Pabna Municipality
A Study of Urban Area Plan for Pabna MunicipalityA Study of Urban Area Plan for Pabna Municipality
A Study of Urban Area Plan for Pabna MunicipalityMorshed Ahmed Rahath
 
A CASE STUDY ON CERAMIC INDUSTRY OF BANGLADESH.pptx
A CASE STUDY ON CERAMIC INDUSTRY OF BANGLADESH.pptxA CASE STUDY ON CERAMIC INDUSTRY OF BANGLADESH.pptx
A CASE STUDY ON CERAMIC INDUSTRY OF BANGLADESH.pptxmaisarahman1
 
Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...
Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...
Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...Call Girls Mumbai
 
Thermal Engineering-R & A / C - unit - V
Thermal Engineering-R & A / C - unit - VThermal Engineering-R & A / C - unit - V
Thermal Engineering-R & A / C - unit - VDineshKumar4165
 
Minimum and Maximum Modes of microprocessor 8086
Minimum and Maximum Modes of microprocessor 8086Minimum and Maximum Modes of microprocessor 8086
Minimum and Maximum Modes of microprocessor 8086anil_gaur
 
School management system project Report.pdf
School management system project Report.pdfSchool management system project Report.pdf
School management system project Report.pdfKamal Acharya
 
Work-Permit-Receiver-in-Saudi-Aramco.pptx
Work-Permit-Receiver-in-Saudi-Aramco.pptxWork-Permit-Receiver-in-Saudi-Aramco.pptx
Work-Permit-Receiver-in-Saudi-Aramco.pptxJuliansyahHarahap1
 
notes on Evolution Of Analytic Scalability.ppt
notes on Evolution Of Analytic Scalability.pptnotes on Evolution Of Analytic Scalability.ppt
notes on Evolution Of Analytic Scalability.pptMsecMca
 
Block diagram reduction techniques in control systems.ppt
Block diagram reduction techniques in control systems.pptBlock diagram reduction techniques in control systems.ppt
Block diagram reduction techniques in control systems.pptNANDHAKUMARA10
 
Engineering Drawing focus on projection of planes
Engineering Drawing focus on projection of planesEngineering Drawing focus on projection of planes
Engineering Drawing focus on projection of planesRAJNEESHKUMAR341697
 
2016EF22_0 solar project report rooftop projects
2016EF22_0 solar project report rooftop projects2016EF22_0 solar project report rooftop projects
2016EF22_0 solar project report rooftop projectssmsksolar
 
Learn the concepts of Thermodynamics on Magic Marks
Learn the concepts of Thermodynamics on Magic MarksLearn the concepts of Thermodynamics on Magic Marks
Learn the concepts of Thermodynamics on Magic MarksMagic Marks
 
Thermal Engineering -unit - III & IV.ppt
Thermal Engineering -unit - III & IV.pptThermal Engineering -unit - III & IV.ppt
Thermal Engineering -unit - III & IV.pptDineshKumar4165
 
Introduction to Serverless with AWS Lambda
Introduction to Serverless with AWS LambdaIntroduction to Serverless with AWS Lambda
Introduction to Serverless with AWS LambdaOmar Fathy
 
DC MACHINE-Motoring and generation, Armature circuit equation
DC MACHINE-Motoring and generation, Armature circuit equationDC MACHINE-Motoring and generation, Armature circuit equation
DC MACHINE-Motoring and generation, Armature circuit equationBhangaleSonal
 
Bridge Jacking Design Sample Calculation.pptx
Bridge Jacking Design Sample Calculation.pptxBridge Jacking Design Sample Calculation.pptx
Bridge Jacking Design Sample Calculation.pptxnuruddin69
 
Unleashing the Power of the SORA AI lastest leap
Unleashing the Power of the SORA AI lastest leapUnleashing the Power of the SORA AI lastest leap
Unleashing the Power of the SORA AI lastest leapRishantSharmaFr
 
Employee leave management system project.
Employee leave management system project.Employee leave management system project.
Employee leave management system project.Kamal Acharya
 
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...soginsider
 

Último (20)

A Study of Urban Area Plan for Pabna Municipality
A Study of Urban Area Plan for Pabna MunicipalityA Study of Urban Area Plan for Pabna Municipality
A Study of Urban Area Plan for Pabna Municipality
 
A CASE STUDY ON CERAMIC INDUSTRY OF BANGLADESH.pptx
A CASE STUDY ON CERAMIC INDUSTRY OF BANGLADESH.pptxA CASE STUDY ON CERAMIC INDUSTRY OF BANGLADESH.pptx
A CASE STUDY ON CERAMIC INDUSTRY OF BANGLADESH.pptx
 
Call Girls in South Ex (delhi) call me [🔝9953056974🔝] escort service 24X7
Call Girls in South Ex (delhi) call me [🔝9953056974🔝] escort service 24X7Call Girls in South Ex (delhi) call me [🔝9953056974🔝] escort service 24X7
Call Girls in South Ex (delhi) call me [🔝9953056974🔝] escort service 24X7
 
Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...
Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...
Bhubaneswar🌹Call Girls Bhubaneswar ❤Komal 9777949614 💟 Full Trusted CALL GIRL...
 
Thermal Engineering-R & A / C - unit - V
Thermal Engineering-R & A / C - unit - VThermal Engineering-R & A / C - unit - V
Thermal Engineering-R & A / C - unit - V
 
Minimum and Maximum Modes of microprocessor 8086
Minimum and Maximum Modes of microprocessor 8086Minimum and Maximum Modes of microprocessor 8086
Minimum and Maximum Modes of microprocessor 8086
 
School management system project Report.pdf
School management system project Report.pdfSchool management system project Report.pdf
School management system project Report.pdf
 
Work-Permit-Receiver-in-Saudi-Aramco.pptx
Work-Permit-Receiver-in-Saudi-Aramco.pptxWork-Permit-Receiver-in-Saudi-Aramco.pptx
Work-Permit-Receiver-in-Saudi-Aramco.pptx
 
notes on Evolution Of Analytic Scalability.ppt
notes on Evolution Of Analytic Scalability.pptnotes on Evolution Of Analytic Scalability.ppt
notes on Evolution Of Analytic Scalability.ppt
 
Block diagram reduction techniques in control systems.ppt
Block diagram reduction techniques in control systems.pptBlock diagram reduction techniques in control systems.ppt
Block diagram reduction techniques in control systems.ppt
 
Engineering Drawing focus on projection of planes
Engineering Drawing focus on projection of planesEngineering Drawing focus on projection of planes
Engineering Drawing focus on projection of planes
 
2016EF22_0 solar project report rooftop projects
2016EF22_0 solar project report rooftop projects2016EF22_0 solar project report rooftop projects
2016EF22_0 solar project report rooftop projects
 
Learn the concepts of Thermodynamics on Magic Marks
Learn the concepts of Thermodynamics on Magic MarksLearn the concepts of Thermodynamics on Magic Marks
Learn the concepts of Thermodynamics on Magic Marks
 
Thermal Engineering -unit - III & IV.ppt
Thermal Engineering -unit - III & IV.pptThermal Engineering -unit - III & IV.ppt
Thermal Engineering -unit - III & IV.ppt
 
Introduction to Serverless with AWS Lambda
Introduction to Serverless with AWS LambdaIntroduction to Serverless with AWS Lambda
Introduction to Serverless with AWS Lambda
 
DC MACHINE-Motoring and generation, Armature circuit equation
DC MACHINE-Motoring and generation, Armature circuit equationDC MACHINE-Motoring and generation, Armature circuit equation
DC MACHINE-Motoring and generation, Armature circuit equation
 
Bridge Jacking Design Sample Calculation.pptx
Bridge Jacking Design Sample Calculation.pptxBridge Jacking Design Sample Calculation.pptx
Bridge Jacking Design Sample Calculation.pptx
 
Unleashing the Power of the SORA AI lastest leap
Unleashing the Power of the SORA AI lastest leapUnleashing the Power of the SORA AI lastest leap
Unleashing the Power of the SORA AI lastest leap
 
Employee leave management system project.
Employee leave management system project.Employee leave management system project.
Employee leave management system project.
 
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
 

Software design

  • 2. TOPICS Design Principles  Design Concepts Modular Design  Design Effective Modularity (Cohesion & Coupling)  Introduction to Software Architecture Data Design Interface Design/Functional Modelling System Design Transform Mapping  Transaction Mapping Design Patterns
  • 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.
  • 16. Example of Software Design & Architecture
  • 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.
  • 20. Example of Class/Data Design-ATM System
  • 21. Example of Class/Data Design-BookMyShow.com https://cnx.org/contents/QQMFd2tj@1/StarUML- Tutorial
  • 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
  • 28. Software Design Concepts 1.Abstraction 2.Modularity 3.Encapsulation 4.Functional Independence 5.Refinement 6.Refactoring 7.Architecture 8.Patterns
  • 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;
  • 30. Abstraction OOSE Unit 1 Topic 1 Topic 2 Unit 2 Unit 3 Unit 4 Unit 5 Topics Topic 1 Topic 1 Highest level of Abstraction LowerlevelofAbstraction
  • 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”
  • 32. Modularity Module 1 Module 2 Module 3 Module 4 Module 5 Module 6 Integrate to make Complete Software Software Requirement
  • 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?
  • 59. Role of 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.
  • 68. Example of 3-Tier System Architecture
  • 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.
  • 78. Model of Data flow architectures
  • 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
  • 83. Main program or Subprogram architectures
  • 84. 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.
  • 105. Transform Mapping data flow model "Transform" mapping a b c d e f g h i j x1 x2 x3 x4 b c a d e f g i h j
  • 106. Input of Transform Mapping Ex:SafeHome security system
  • 107. Detail DFD(Input of 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.
  • 112.
  • 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.