Unit 4 - Oose

Department of
Computer Science and Engineering
UNIT 4- Design
Sem : Summer Semester 2022-2023

Slot : S3 & S4
Unit : IV / Design
Faculty Name : Mrs.Suganya V.
School of Computing
Vel Tech Rangarajan Dr. Sagunthala R&D Institute of
Science and Technology
Unit-4::Syllabus
UNIT- IV DESIGN
Design Concepts & Principles - Design Process -
Design Concepts - Modular Design - Design
Effective Modularity - Introduction to Software
Architecture - Data Design - Transform Mapping -
Transaction Mapping - Object Oriented Design -
System design process- Object design process -
Design Patterns.
10/31/2022 Suganya V. Department of Computer Science and Engineering 2

DESIGN
❑What is it? A meaningful engineering
representation of something that is to be built.
❑Who does it? Software engineers with a variety of
skills, ranging from human ergonomics to computer
architecture
❑Why is it important? A house would never be built
without a blueprint. Why should software? Without
design the system may fail with small changes, is
difficult to test and cannot be assessed for quality
❑What is the work product? A design specification
DESIGN

DESIGN CONCEPTS & PRINCIPLES
❑Design
A plan or drawing.
❑Basic of Software Design
➢Software design is a phase in software engineering,
in which a blueprint is developed to serve as a base
for constructing the software system.
➢IEEE defines software design as ‘both a process of
defining, the architecture, components, interfaces,
and other characteristics of a system or component
and the result of that process.’
❑Software design
➢Software design is an iterative process through
which requirements are translated into a
“blueprint” for constructing the software.
➢Initially, the blueprint depicts a holistic view of
software


➢Design Principles:
✓Avoid ‘tunnel vision’
✓Be traceable back to analysis
✓Not reinvent the wheel
✓“Minimize the intellectual distance” between the
problem and the solution
✓Exhibit uniformity and integration (look like the
work of a single designer)
✓Accommodate change
✓Recognize that design is not coding, coding is not
design
❑Quality Attributes of Good Design

Good software design should exhibit:
➢ Firmness: A program should not have any bugs
that inhibit its function.
➢Commodity: A program should be suitable for the
purposes for which it was intended
➢Delight: The experience of using the program
should be pleasurable one

DESIGN PROCESS

DESIGN PROCESS
➢During the design process the software
specifications are transformed into design models.
➢ Models describe the details of the data structures,
system architecture, interface, and components.
➢Each design product is reviewed for quality before
moving to the next phase of software development.
➢ At the end of the design process a design model and
specification document is produced.
➢ This document is composed of the design models
that describe the data, architecture, interfaces and
components.
DESIGN PROCESS

DESIGN PROCESS
➢Design Specification Models
✓Data design – created by transforming the analysis
information model (data dictionary and ERD) into
data structures required to implement the
software.
✓Part of the data design may occur in conjunction
with the design of software architecture. More
detailed data design occurs as each software
component is designed.

DESIGN PROCESS
➢Architectural design
✓Defines the relationships among the major
structural elements of the software, the “design
patterns” than can be used to achieve the
requirements that have been defined for the
system, and the constraints that affect the way in
which the architectural patterns can be applied.
✓It is derived from the system specification, the
analysis model, and the subsystem interactions
defined in the analysis model (DFD).
DESIGN PROCESS
➢Interface design
✓ Describes how the software elements
communicate with each other, with other systems,
and with human users.
✓The data flow and control flow diagrams provide
much of the necessary information required.

DESIGN PROCESS
➢Procedural / Component-level design
✓Created by transforming the structural elements
defined by the software architecture into
procedural descriptions of software components
using information obtained from the process
specification (PSPEC), control specification
(CSPEC), and state transition diagram (STD)

DESIGN CONCEPTS
➢ Abstraction
➢Architecture
➢Patterns
➢Modularity
➢Information hiding
➢ Functional independence
➢Refinement
➢ Refactoring

DESIGN CONCEPTS
➢ Abstraction
✓“Abstraction permits one to concentrate on a
problem at some level of generalization without
regard to irrelevant low level details..”
✓Software Engineering is a process of refining
abstractions
✓Modern programming languages allow for
abstraction, e.g. abstract data types
✓Types:
oData Abstraction
o Procedural Abstraction
DESIGN CONCEPTS
o Data Abstraction
A named collection of data that describes a data
object

DESIGN CONCEPTS
o Procedural Abstraction
A named sequence of instructions with a specific
and limited function

DESIGN CONCEPTS
➢ Architecture Design
✓The overall structure of the software and the
ways in which that structure provides conceptual
integrity for a system.
✓Design can be represented as
Design
Dynamic model
Structural Framework Functional
& process
Models Models Models
Models

DESIGN CONCEPTS
✓Structural Models
Defines the components of a system (e.g.,
modules, objects, filters) and How the components
are packaged and interact with one another.
✓Framework Models
Increase level of abstraction
✓ Dynamic Models and Process Models
Predicts behavioral and reliability aspects
✓Functional Models
Depicts functional Hierarchy.
DESIGN CONCEPTS
➢ Patterns
▪ A pattern is “a common solution to a common
problem in a given context.”
▪ While architectural styles can be viewed as patterns
describing the high-level organization of software
(their macroarchitecture), other design patterns can
be used to describe details at a lower, more local
level (their microarchitecture).

DESIGN CONCEPTS
➢ Design Pattern
Design Pattern enables a designer to determine
whether the pattern :
✓ is applicable to the current work
✓ can be reused
✓ can serve as a guide for developing a similar, but
functionally or structurally different pattern.

DESIGN CONCEPTS
Types of Design Patterns

DESIGN CONCEPTS
✓Creational Patterns
To create objects of the right class for a problem,
generally when instances of several different classes
are available.
✓Structural Patterns
To form larger structures from individual parts,
generally of different class.
✓Behavioral Patterns
To describe interactions between objects. They focus
on how objects communicate with each other.

DESIGN CONCEPTS
✓Creational patterns
Example: builder, factory, prototype, and
singleton
✓Structural patterns
Example: adapter, bridge, composite, decorator,
façade, flyweight, and proxy
✓ Behavioral patterns
Example: command, interpreter, iterator,
mediator, memento, observer, state, strategy, template,
visitor
DESIGN CONCEPTS
➢Modularity
A Module is “a lexically contiguous sequence of
program statements, bounded by boundary elements,
having an aggregate identifier” [Yourdon and
Constantine 1979]
✓Modular Design
▪ Easier to change
▪ Easier to build
▪ Easier to maintain

DESIGN CONCEPTS

DESIGN CONCEPTS
➢Information Hiding
✓Principle of information hiding says that a good split
of modules is when modules communicate with one
another with only the information necessary to
achieve the s/w function.
✓ So information hiding enforces access constraints to
both
o procedural detail with a module, and local data
structure used by that module.
✓ Data hiding is a CRITERION for modular design.
✓How to know what modules to create.
DESIGN CONCEPTS

DESIGN CONCEPTS
➢Functional independence
✓The functional independence is the concept of
separation and related to the concept of
modularity, abstraction and information hiding.
✓The functional independence is accessed using
two criteria i.e Cohesion and coupling.

DESIGN CONCEPTS
➢Functional independence

DESIGN CONCEPTS
➢Refinement
✓ Refinement is a process of elaboration
✓ It is a top-down design strategy
✓ A program is developed by successfully refining
levels of procedural details

DESIGN CONCEPTS
▪ Stepwise for refinement

DESIGN CONCEPTS
➢Refactoring
✓It is a reorganization technique which simplifies
the design of components without changing its
function behaviour.
✓Refactoring is the process of changing the
software system in a way that it does not change
the external behaviour of the code still improves
its internal structure.

MODULAR DESIGN
➢Modularization
✓Modularization is a technique to divide a software
system into multiple discrete and independent
modules, which are expected to be capable of
carrying out task(s) independently.
✓These modules may work as basic constructs for the
entire software.
✓Designers tend to design modules such that they can
be executed and/or compiled separately and
independently.
MODULAR DESIGN
✓Modular design unintentionally follows the rules of
‘divide and conquer’ problem-solving strategy this
is because there are many other benefits attached
with the modular design of a software.

MODULAR DESIGN
➢Advantage of modularization:
• Smaller components are easier to maintain
• Program can be divided based on functional aspects
• Desired level of abstraction can be brought in the
program
• Components with high cohesion can be re-used
again
• Concurrent execution can be made possible
• Desired from security aspect
Design Effective Modularity
✓Software should be split into separately named and
addressable components
✓Procedures, functions and objects are all modules


➢Benefits of Modularity
• “Modularity is the single attribute of software that
allows a program to be intellectually manageable”
• Don’t overdo it. Too many modules makes
integration complicated
• Sometimes the code must be monolithic (e.g. real-
time and embedded software) but the design still
shouldn’t be
• Effective modular design is achieved by developing
“single minded” (highly cohesive) modules with an
“aversion” to excessive interaction (low coupling)
➢Modularity:Trade-offs

➢Modularity Support
✓ A design method supports effective modularity if
it evidences:
o Decomposability - a systematic mechanism for
decomposing the problem
o Composability - able to reuse modules in a new
system
o Understandability - the module can be
understood as a standalone unit
o Continuity - minimizes change-induced side
effects
o Protection - minimizes error-induced side effects
➢Cohesion & Coupling
Cohesion
Relative functional strength of a module
• Coupling
Relative interdependence among modules

➢Cohesion
✓ The degree of interaction within a module
✓A measure of functional strength; strive for high
cohesion.(intra-dependability)
✓Terminology:
o Action = the behaviour of a module (e.g.
compute square root)
o Logic = how the module performs its action (e.g.
using Newton’s method)
o Context = specific usage of the module (e.g. find
square root of a double precision integer)
➢Types of Cohesion

6. Coincidental Cohesion
✓ Performs multiple unrelated actions
✓ Can happen if an organization enforces rigid rules
on module size - modules are hacked apart and
glued together
✓ Worse than no modularity at all
5. Logical Cohesion
✓ Module tasks related logically
✓ Example: an object that performs all input and
output
✓ Interface can be difficult to understand (e.g. printf)
and code for several actions may be intertwined
4. Temporal Cohesion
✓ Tasks executed within the same span of time
✓ Example: initialization of data structures
3. Procedural
✓Actions are related and must be executed in a
certain order
2. Communication
✓Actions are performed in series and on the same
data
✓Example: CalculateTrajectoryAndPrint
✓Damages Reusability
1. Functional or informational cohesion
✓ Performs exactly one action OR
✓ Performs a number of actions, with separate
entry points, all performed on the same data
structure
✓ Equivalent to a well-designed abstract data type
or object

➢Coupling
✓The degree of interaction between modules
✓A measure of relative interdependence; strive for
low coupling since this reduces the “ripple effect”
✓Types of Coupling (Worst to Best):

➢Types of Coupling
5.Content Coupling(worst)
✓ One module directly references the internals of
another
✓ Example: module p branches to a local label of
module q
✓ Almost any change in one requires a change in
the other

4.Common Coupling
✓Both modules have access to the same global data
area
✓ Example: module p and q have read and write access
to the same database element
✓Suffers from all the disadvantages of global variables
3.Control Coupling
✓ Element of control is transferred between modules
✓ Example: Module q not only passes information but
also informs module p as to what action to take
✓ These kinds of modules often have logical cohesion
2.Stamp Coupling
✓Whole data structures (records, arrays, object)
transferred
✓BUT the called module only operates on part of the
data structure
✓Security Risk: allows uncontrolled data access
1.Data Coupling
✓Every argument is either a simple type or a data
structure
✓AND all elements are used by the called module
✓Maintenance is easier because regression faults less
likely
Introduction to Software Architecture
❖ Software Architecture
❖ Data Design
❖ Architectural Style
❖ Analyzing Alternative Architectural
Designs
❖ Mapping Requirements into a Software
Architecture
❖ Transform Mapping, and Transaction
Mapping
❖ Refining the Architectural Design
❑ Architecture
✓ Architecture represents the significance design
decisions that shape the system
✓ The architecture of a system describes its major
components, their relationships (structures), and
how they interact with each other. Software
architecture and design includes several
contributory factors such as Business strategy,
quality attributes, human dynamics, design, and IT
environment.

✓ Architecture serves as a blueprint for a system. It
provides an abstraction to manage the system
complexity and establish a communication and
coordination mechanism among components.
✓ It defines a structured solution to meet all the

technical and operational requirements, while
optimizing the common quality attributes like
performance and security.


➢ Why Architecture is important?
✓ Handling complexity
✓ Communication among stakeholders
✓ Early Design Decisions
✓ SA is a transferable, reusable model

➢ Software architecture
It is a representation that enables a software
engineer to
✓ Analyze the effectiveness of the design in
meeting stated requirements
✓ Consider architectural alternatives
✓ Reduce the risk associated with the

construction of the software
✓ Examine the system as a whole

✓Software Architecture and Design into two distinct
phases:
o Software Architecture
o Software Design.
✓In Architecture, nonfunctional decisions are cast
and separated by the functional requirements.
✓ In Design, functional requirements are
accomplished

➢Types of Architecture
There are four types of architecture from the
viewpoint of an enterprise and collectively, these
architectures are referred to as enterprise architecture.
✓Business architecture - Defines the strategy of

business, governance, organization, and key
business processes within an enterprise and focuses
on the analysis and design of business processes

• Application (software) architecture − Serves as
the blueprint for individual application systems,
their interactions, and their relationships to the
business processes of the organization.
• Information architecture − Defines the logical
and physical data assets and data management
resources.
• Information technology (IT) architecture −
Defines the hardware and software building blocks
that make up the overall information system of the
organization.

Software design
✓Provides a design plan that describes the elements of
a system, how they fit, and work together to fulfill the
requirement of the system.
✓The objectives of having a design plan are as follows
o To negotiate system requirements, and to set
expectations with customers, marketing, and
management personnel.
o Act as a blueprint during the development process.
o Guide the implementation tasks, including detailed
design, coding, integration, and testing
➢Architectural Styles
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,
(4) semantic models that enable a designer to

understand the overall properties of a system by
analyzing the known properties of its constituent
parts.

➢Taxonomy of Architectural Styles

✓Data-centered architectures
✓Data flow architectures
✓Call and return architectures
✓Object-oriented architectures
✓Layered architectures

o 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.
o This data-centered architecture will promote
integrability. 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.


✓Data flow architectures.

o This kind of architecture is used when input data
to be transformed into output data through a series
of computational manipulative components.
o It uses both pipe and filter and it has a set of
components called filters connected by pipes.
o Pipes are used to transmit data from one
component to the next.

o Each filter will work independently and is
designed to take data input of a certain form and
produces data output to the next filter of a
specified form. The filters don’t require any
knowledge of the working of neighboring filters.
o If the data flow degenerates into a single line of
transforms, then it is termed as batch sequential.
This structure accepts the batch of data and then
applies a series of sequential components to
transform it.

✓Call and Return architectures
o it is used to create a program that is easy to scale
and modify.
o Many sub-styles exist within this category.
o Two of them are explained below.
1.Remote procedure call architecture: This

components is used to present in a main program or
sub program architecture distributed among multiple
computers on a network.

2.Main program or Subprogram architectures: The
main program structure decomposes into number of
subprograms or function into a control hierarchy.
Main program contains number of subprograms that
can invoke other components.

✓ Call and return - program structure decomposes
function into control hierarchy with main
program invokes several subprograms

✓ Object Oriented architecture:

o The components of a system encapsulate data and
the operations that must be applied to manipulate
the data.
o The coordination and communication between the
components are established via the message
passing.

✓ Layered architecture:

✓ Layered architecture:
o 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.
o 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)
o Intermediate layers to utility services and
application software functions
✓ Architectural Complexity:
o Sharing dependencies
-represent dependence relationships among
consumers who use the same resource or producers
who produce for the same consumers
o Flow dependencies
-represent dependence relationships between
producers and consumers of resources
o Constrained dependencies
-represent constraints on the relative flow among a
set of components
❑ Data Design
✓ Data Design at Application Level
✓ Data Design at Business Level
✓ Data Modeling, Data Structure, Database, and the
Data Warehouse
o Subject oriented
o Integration
o Time Variance
o NonVolatility

➢ Data Design principles
✓ Systematic analysis principles applied to function
and behavior should also be applied to data.
o All data structures and the operations to be
performed on each should be identified.
o Data dictionary should be established and
used to define both data and program design.
o Low level design processes should be
deferred until late in the design process.

➢ Data Design principles
o Representations of data structure should be
known only to those modules that must make

direct use of the data contained within in the data
structure.
o A library of useful data structures and operations
should be developed.
o A software design and its implementation
language should support the specification and
realization of abstract data types.
➢ Architectural Design
✓ The software must be placed into context.
o The design should define the external entities
(other systems, devices, people) that the
software interacts with and the nature of the
interaction
✓ A set of architectural archetypes should be
identified
o An archetype is an abstraction (similar to a
class) that represents one element of system
behavior
✓ The designer specifies the structure of the system

by defining and refining software components that
implement each archetype.
✓ Structured design, considered as a tool that
converts data flow diagrams (DFDs) to software
architecture can be described as a data-flow-
oriented design method.’
✓ There are two types of information flow in DFDs:
o Transform flow
o Transaction flow
✓ Establish type of information flow

o transform flow - overall data flow is
sequential and flows along a small number
of straight line paths
o transaction flow - a single data item triggers
information flow along one of many paths

Deriving Program Architecture

Partitioning the Architecture
“horizontal” and “vertical” partitioning are
required

Horizontal Partitioning
✓ Define separate branches of the module hierarchy
for each major function
✓ Use control modules to coordinate communication
between functions

Vertical Partitioning :Factoring
✓ Design so that decision making and work are
stratified
✓ Decision making modules should reside at the top
of the architecture

Structured Design
✓ objective:
To derive a program architecture that is
partitioned
✓ approach:
A DFD is mapped into a program architecture
the PSPEC and STD are used to indicate the content of
each module
✓ notation:
structure chart

Flow Characteristics

Transform & Transaction mapping

General mapping approach
✓ isolate incoming and outgoing flow boundaries; for
transaction flows, isolate the transaction center
✓ working from the boundary outward, map DFD

transforms into corresponding modules
✓ add control modules as required
✓ refine the resultant program structure using

effective modularity concepts
✓ Isolate the transform center by specifying incoming
and outgoing flow boundaries
✓ Perform "first-level factoring.”
•The program architecture derived using this mapping
results in a top-down distribution of control.
•Factoring leads to a program structure in which top-
level components perform decision-making and low-
level components perform most input, computation,
and output work.
•Middle-level components perform some control and
do moderate amounts of work.
✓ Perform "second-level factoring."
Transform Mapping
✓ Review fundamental system model
✓ Review & refine data flow diagrams for the software
✓ Determine whether the DFD has transform or
transaction characteristics
✓ Isolate the transform center by specifying incoming
and outgoing flow boundaries

✓ Perform first level factoring
✓ Perform second level factoring
✓ Refine the first iteration architecture using

design heuristics for improved software quality
Transform Mapping

Transform Mapping
-Factoring

Transform Mapping
-First Level Factoring

Transform Mapping
-Second Level Factoring

Example for Transform Mapping
SafeHome security function

Step:1- Context-level DFD

Step:2- Level 1 DFD

Step:2- Level 2 DFD

Step:2- Level 3 DFD

Step:3- Determine whether the DFD has transform

or transaction flow characteristics
• Evaluating the DFD
• data entering the software along one
incoming path and
• exiting along three outgoing paths.
• overall transform characteristic will be
assumed for information flow.

Step:4- Isolate the transform center by specifying

incoming and outgoing flow boundaries.
• Incoming data flows along a path in which
information is converted from external to
internal form; outgoing flow converts
internalized data to external form.
• Incoming and outgoing flow boundaries are
open to interpretation

Step:5-Perform “first-level factoring

Step:6-Perform “Second-level factoring

Steps for Transaction Mapping
• Review the fundamental system model
• Review and refine DFD for the SW
• Assess the DFD in order to decide the usage of
transform or transaction flow.
• Identify the transaction center and the flow
characteristics along each action path
• Find transaction center
• Identify incoming path and isolate action paths

Cont..(Steps for Transaction Mapping)
• Evaluate each action path for transform vs.
transaction characteristics
• Map the DFD in a program structure agreeable to
transaction processing
• Carry out the ‘factoring’ process

Transaction Flow

Transaction Mapping Principles
✓ Isolate the incoming flow path
✓ Define each of the action paths by looking for the
"spokes of the wheel"
✓ Assess the flow on each action path
✓ Define the dispatch and control structure map
each action path flow individually

Transaction Mapping

Isolate Flow Paths

Transaction Flow Example

Object Oriented Design(OOD)&Process
Designing systems using self-contained objects and
object classes.
✓Object Oriented is a popular design approach for
analyzing and designing an application.
✓Object-oriented concepts are used in the design
methods such as classes, objects, polymorphism,
encapsulation, inheritance, dynamic binding,
information hiding, interface, constructor, destructor

Characteristics of OOD
✓Objects are abstractions of real-world or system
entities and manage themselves
✓Objects are independent and encapsulate state and
representation information.
✓System functionality is expressed in terms of object
services
✓Objects communicate by message passing
✓Objects may be distributed and may execute
sequentially or in parallel
Design classes:
A set of design classes refined the analysis class by
providing design details.
Design
Class
User Business Process Persistence System

Interface Domain

There are five different types of design classes
1. User interface classes: These classes are designed
for Human Computer Interaction(HCI).
These interface classes define all abstraction which is
required for Human Computer Interaction(HCI).
2. Business domain classes: These classes are
commonly refinements of the analysis classes.
✓These classes are recognized as attributes and
methods which are required to implement the
elements of the business domain
3.Process classes
It implement the lower level business abstraction
which is needed to completely manage the business
domain class.
4.Persisten ceclasses
It shows data stores that will persist behind the
execution of the software.
5.System Classes
System classes implement software management and
control functions that allow to operate and
communicate in computing environment and outside
world
10/31/2022 Suganya V. Department of Computer Science and Engineering
121
Design class characteristic
1.Completeandsufficient
✓A design class must be the total encapsulation of all
attributes and methods which are required to exist
for the class.
2. Primitiveness
✓The method in the design class should fulfil one
service for the class.
✓If service is implemented with a method then the
class should not provide another way to fulfil same
10/31/2022 Suganya V. Department of Computer Science and Engineering
122
thing.
3. High cohesion
✓ A cohesion design class has a small and focused
set of responsibilities.
✓For implementing the set of responsibilities the
design classes are applied single-mindedly to the
methods and attribute.

4. Low-coupling
✓ All the design classes should collaborate with each
other in a design model.
✓The minimum acceptable of collaboration must be
kept in this model.
✓If a design model is highly coupled then the system
is difficult to implement, to test and to maintain
over time.

Design Elements
1. Data design elements
✓The data design element produced a model of data
that represent a high level of abstraction.
✓This model is then more refined into more
implementation specific representation which is
processed by the computer based system.
✓The structure of data is the most important part of
the software design.

2. Architectural design elements
• The architecture design elements provides us
overall view of the system.
• It is generally represented as a set of interconnected
subsystem that are derived from analysis packages
in the requirement model.
. Interface design elements
• The interface design elements for software
represents the information flow within it and out of
the system.
• They communicate
10/31/2022 Suganya V. Department between
of Computer Science andthe
Engineeringcomponents
126
3.Interface design elements
• The interface design elements for software
represents the information flow within it and out of
the system.
• They communicate between the components
defined as part of architecture.

4. Component level diagram elements
✓The component level design for software is similar
to the set of detailed specification of each room in a
house.
✓It completely describes the internal details of the
each software component.
✓The processing of data structure occurs in a
component and an interface which allows all the
component operations.

5.Deployment level design elements
• The deployment level design element shows the
software functionality and subsystem that allocated
in the physical computing environment which
support the software.

Concepts of Object Oriented Design
✓Objects - All entities involved in the solution
design are known as objects.
✓Encapsulation - In OOD, the attributes (data
variables) and methods (operation on the data) are
bundled together is called encapsulation.

✓Inheritance - OOD allows similar classes to stack
up in hierarchical manner where the lower or sub-
classes can import, implement and re-use allowed
variables and methods from their immediate super
classes.
✓Polymorphism - OOD languages provide a
mechanism where methods performing similar
tasks but vary in arguments, can be assigned same
name.

➢Design Process
Software design process can be perceived as series
of well-defined steps. Though it varies according to
design approach (function oriented or object oriented,
yet It may have the following steps involved:
✓ A solution design is created from requirement or previous
used system and/or system sequence diagram.
✓ Objects are identified and grouped into classes on behalf of
similarity in attribute characteristics.
✓ Class hierarchy and relation among them is defined.
✓ Application framework is defined.
➢Design Process
Software design process can be perceived as series
of well-defined steps. Though it varies according to
design approach (function oriented or object oriented,
yet It may have the following steps involved:
✓ A solution design is created from requirement or previous
used system and/or system sequence diagram.
✓ Objects are identified and grouped into classes on behalf of
similarity in attribute characteristics.
✓ Class hierarchy and relation among them is defined.
✓ Application framework is defined.
Design Pattern
✓Design patterns are used to represent some of the
best practices adapted by experienced object-
oriented software developers.
✓ A design pattern systematically names, motivates,
and explains a general design that addresses a
recurring design problem in object-oriented
systems.
✓A "pattern" has been defined as "an idea that has
been useful in one practical context and will
probably be useful in others.“

Design Pattern
➢Why Design Patterns?
✓ Apply well known and proven solutions
o many problems are not new → no need to
invent wheels
o code structure easier to understand →
easier maintainance
o great help for beginners to learn good
practice
o patterns are not static, guide to individual
solutions
Design Pattern
➢Design patterns help to translate “OOD rules”

✓Dependency management
✓Components
✓ Code reuse
✓Ease of planned (and unplanned) changes
✓ Maintainance
✓ Code quality

Design Pattern
✓"Design Patterns are general, repeatable solutions to
common recurring problems in software
development."
✓There are 23 design patterns, also known as Gang
of Four (GoF) design patterns.
✓These 23 patterns are grouped into three main
categories:

Design Pattern

Design Pattern
Pattern Classification

Design Pattern
1.Creational Design Patterns
✓These design patterns provide a way to create
objects while hiding the creation logic, rather than
instantiating objects directly using new operator.
✓This gives program more flexibility in deciding
which objects need to be created for a given use
case.

Design Pattern
2.Structural Design Patterns
These design patterns concern class and object
composition. Concept of inheritance is used to
compose interfaces and define ways to compose
objects to obtain new functionalities.
3.Behavioral Design Patterns

These design patterns are specifically concerned with
communication between objects.

Design Pattern
Structured pattern description
✓Pattern name
one or twoword descriptive title
✓ Intent
what happens? Why? Design issue or problem?
✓ Motivation
example pattern application scenario
✓Applicability
when to use? What problems solved?

Design Pattern
✓Structure
UML graphical description
✓Participants and Collaborations
classes, objects, their roles and collaborations
✓Consequences and Implementation
results and tradeoffs, implementation tricks
✓ Examples
code, projects
✓ Related patterns
relation to other patterns, combined uses
Design Pattern
➢Creational Patterns
✓Organise object creation
✓ Class creational patterns
o Factory Method
odefer (part of) object creation to subclasses
✓ Object creational patterns
o Abstract Factory
o Singleton
odefer (part of) object creation to other objects

Design Pattern
✓Singleton:
Makes sure a class only has one instance,
and thence provides a global point of access to it.

Design Pattern
Methods in Creational Pattern
✓ Abstract Factory:
This provides an interface for creating families of
dependent objects without specifying their concrete
classes.
✓Prototype:
Specifies the objects for creating a prototypical
instance, and also to create new objects by copying
this prototype.
✓Singleton:
Makes sure a class only has one instance,
and thence provides
10/31/2022
a global point of access to it.
Suganya V. Department of Computer Science and Engineering
146
Design Pattern
(Abstract) Factory Method

Design Pattern
Prototype

Design Pattern
Singleton

Design Pattern
Structural Pattern
✓ Compose complex structures from small ones
✓ Class structural patterns
o Compose interfaces or implementations using
class inheritance
o Adapter
✓ Object structural patterns
o Compose objects to get new functionality, possibly
at runtime
o Adapter, Composite, Decorator, Proxy
Design Pattern
Methods in Structural Pattern
Adapter:
✓ An adapter allows classes to work together which
could not otherwise because of incompatible
interfaces.
Bridge:
✓ Seprates or decouples an abstraction from its
implementation allowing them to vary
independently.

Design Pattern
Composite:
✓ Composite divides objects into tree
structures in order to represent part-whole
hierarchies.
Decorator:
✓ Adds additional responsibilities for an
dynamically while keeping the same interface.

Design Pattern
Facade:
✓ Facade specifies a high-level interface that makes
the subsystem easier to use.
Flyweight:
✓ Sharing is used to support large numbers
of similar objects efficiently and effectively.
Proxy:
✓ Provides a placeholder for a different object in
order to control access to it.

Design Pattern
Adapter

Design Pattern
Composite

Design Pattern
Decorator

Design Pattern
Proxy

Design Pattern
Behavioral Patterns
✓ Implement algorithms
✓ Class behavioral patterns
o use inheritance to separate algorithm invariants
from algorithm variants
o Template Method
✓ Object behavioral patterns
o use object composition to distribute algorithm
parts (invariants, variants)
o Chain of Responsibility, Iterator, State, Observer,
Strategy

Design Pattern
Methods in Behavioral Patterns
✓Template method:
Skeleton of an algorithm is defined in an operation
✓Chain of responsibility:
Avoids coupling the sender of a request to its
receiver by giving more than one object a chance to
handle the request.
✓Iterator:
Provides a solution to access the elements of an
object sequentially, without exposing its
underlying representation.
Design Pattern
✓State:
Allowing the objects to alter their behavior
simultaneosly when its internal state changes.
✓Mediator:
Sets an object that encapsulates and describes how a
set of objects interact.
✓Observer:
Defines a one-to-many dependency between objects,
where a state change in one of the object results in all
its dependent objects being notified and updated
automatically.
Design Pattern
✓ Strategy:
Sets a family of algorithms, encapsulate each
one, and makes them interchangeable.

Design Pattern
✓ Template method

Design Pattern
✓ Chain of responsibility

Design Pattern
✓ Chain of responsibility

Design Pattern
✓ Iterator

Design Pattern
✓ State

Design Pattern
✓ State

Design Pattern
✓ Observer

Design Pattern
✓ Observer

Design Pattern
✓ Mediator

Design Pattern
✓ Mediator

Design Pattern
✓ Mediator

Scenario
Thank You
Department of Computer Science and Engineering 173

Unit 4 - Oose

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 4 - Oose

Uploaded by

Copyright:

Available Formats

Department of

Computer Science and Engineering

Sem : Summer Semester 2022-2023

10/31/2022 Suganya V. Department of Computer Science and Engineering 2

10/31/2022 Suganya V. Department of Computer Science and Engineering 4

10/31/2022 Suganya V. Department of Computer Science and Engineering 6

10/31/2022 Suganya V. Department of Computer Science and Engineering 7

❑Quality Attributes of Good Design

10/31/2022 Suganya V. Department of Computer Science and Engineering 10

10/31/2022 Suganya V. Department of Computer Science and Engineering 11

10/31/2022 Suganya V. Department of Computer Science and Engineering 13

10/31/2022 Suganya V. Department of Computer Science and Engineering 14

10/31/2022 Suganya V. Department of Computer Science and Engineering 16

10/31/2022 Suganya V. Department of Computer Science and Engineering 17

10/31/2022 Suganya V. Department of Computer Science and Engineering 18

10/31/2022 Suganya V. Department of Computer Science and Engineering 20

10/31/2022 Suganya V. Department of Computer Science and Engineering 21

10/31/2022 Suganya V. Department of Computer Science and Engineering 22

10/31/2022 Suganya V. Department of Computer Science and Engineering 24

10/31/2022 Suganya V. Department of Computer Science and Engineering 25

10/31/2022 Suganya V. Department of Computer Science and Engineering 26

10/31/2022 Suganya V. Department of Computer Science and Engineering 27

10/31/2022 Suganya V. Department of Computer Science and Engineering 29

10/31/2022 Suganya V. Department of Computer Science and Engineering 30

10/31/2022 Suganya V. Department of Computer Science and Engineering 32

10/31/2022 Suganya V. Department of Computer Science and Engineering 33

10/31/2022 Suganya V. Department of Computer Science and Engineering 34

10/31/2022 Suganya V. Department of Computer Science and Engineering 35

10/31/2022 Suganya V. Department of Computer Science and Engineering 36

10/31/2022 Suganya V. Department of Computer Science and Engineering 37

10/31/2022 Suganya V. Department of Computer Science and Engineering 39

10/31/2022 Suganya V. Department of Computer Science and Engineering 41

10/31/2022 Suganya V. Department of Computer Science and Engineering 42

10/31/2022 Suganya V. Department of Computer Science and Engineering 44

10/31/2022 Suganya V. Department of Computer Science and Engineering 46

10/31/2022 Suganya V. Department of Computer Science and Engineering 48

10/31/2022 Suganya V. Department of Computer Science and Engineering 51

10/31/2022 Suganya V. Department of Computer Science and Engineering 52

10/31/2022 Suganya V. Department of Computer Science and Engineering 53

10/31/2022 Suganya V. Department of Computer Science and Engineering 57

✓ It defines a structured solution to meet all the

10/31/2022 Suganya V. Department of Computer Science and Engineering 58

10/31/2022 Suganya V. Department of Computer Science and Engineering 59

➢ Why Architecture is important?

✓ Communication among stakeholders

✓ Early Design Decisions

✓ SA is a transferable, reusable model

10/31/2022 Suganya V. Department of Computer Science and Engineering 60

✓ Reduce the risk associated with the

10/31/2022 Suganya V. Department of Computer Science and Engineering 61

10/31/2022 Suganya V. Department of Computer Science and Engineering 62

✓Business architecture - Defines the strategy of

10/31/2022 Suganya V. Department of Computer Science and Engineering 63

10/31/2022 Suganya V. Department of Computer Science and Engineering 65

10/31/2022 Suganya V. Department of Computer Science and Engineering 67

(3) constraints that define how components can be

(4) semantic models that enable a designer to

10/31/2022 Suganya V. Department of Computer Science and Engineering 68

➢Taxonomy of Architectural Styles

10/31/2022 Suganya V. Department of Computer Science and Engineering 69

10/31/2022 Suganya V. Department of Computer Science and Engineering 70

10/31/2022 Suganya V. Department of Computer Science and Engineering 71

✓Data flow architectures.