Please read this disclaimer before

proceeding:
This document is confidential and intended solely for the educational purpose of RMK
Group of Educational Institutions. If you have received this document through email in
error, please notify the system manager. This document contains proprietary
information and is intended only to the respective group / learning community as
intended. If you are not the addressee you should not disseminate, distribute or copy
through e-mail. Please notify the sender immediately by e-mail if you have received this
document by mistake and delete this document from your system. If you are not the
intended recipient you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this information is strictly prohibited.
21CS933-OBJECT ORIENTED ANALYSIS AND
DESIGN
Department: Computer Science & Engineering

Batch/Year:2021-2025/III Year
Created by: Dr.M.Vedaraj & Mr.Shanker
January 2024
1. CONTENTS

S. No. Contents

1 Contents

2 Course Objectives

3 Pre Requisites

4 Syllabus

5 Course outcomes

6 CO- PO/PSO Mapping

7 Lecture Plan

8 Activity based learning

9 Lecture Notes

10 Assignments

11 Part A Questions & Answers

12 Part B Questions

13 Supportive online Certification courses

14 Real time Applications

15 Contents beyond the Syllabus

16 Assessment Schedule

17 Prescribed Text Books & Reference Books

18 Mini Project Suggestions

2. Course Objectives
1. To learn the basics of OOAD and various UML diagrams.
2. To understand how to create design patterns.
3. To understand the various stages of the design process using a case
study.
4. To learn how to apply design patterns using various UML diagrams.
5. To know how to map design to code and learn different testing
techniques.
3. Pre Requisites
Course Name: Object Oriented Analysis and Design

Course Code: 21CS933

Pre Requisites

1. Understand object-oriented Programming concepts and methodology

2. Experience of Programming Projects would help; but is not mandatory
3. General understanding of programming, preferably using the Java
programming language
4. Understand the fundamentals of the systems development process
4. Syllabus
21CS933 OBJECT ORIENTED ANALYSIS AND LTPC
DESIGN
3003
OBJECTIVES:
 To learn the basics of OOAD and various UML diagrams.
 To understand how to create design patterns.
 To understand the various stages of the design process using a case study.
 To learn how to apply design patterns using various UML diagrams.
 To know how to map design to code and learn different testing techniques.

UNIT I UML DIAGRAMS 6+6

Introduction to OOAD with OO Basics - Unified Process – UML diagrams – Use Case
– Class Diagrams– Interaction Diagrams – State Diagrams – Activity Diagrams
– Package, component, and Deployment Diagrams.

UNIT II DESIGN PATTERNS 6+6

GRASP: Designing objects with responsibilities – Creator – Information expert – Low

Coupling –High Cohesion – Controller Design Patterns – creational – factory method–
structural – Bridge – Adapter – behavioural – Strategy – observer.

UNIT III CASE STUDY 6+6

Case study – the Next Gen POS system, Inception -Use case Modelling - Relating Use
cases – include, extend and generalization - Elaboration - Domain Models - Finding
conceptual classes and description classes – Associations – Attributes – Domain model
refinement – Finding conceptual class Hierarchies - Aggregation and Composition.
UNIT IV APPLYING DESIGN PATTERNS 6+6
System sequence diagrams - Relationship between sequence diagrams and use cases
Logical architecture and UML package diagram – Logical architecture refinement - UML
class diagrams - UML interaction diagrams - Applying GoF design patterns.

UNIT V CODING AND TESTING, METRICS 6+6

Mapping design to code – Testing: Issues in OO Testing – Class Testing – OO Integration

Testing – GUI Testing – OO System Testing-Metrics for Object Oriented Design-
ClassOriented Metrics
TOTAL: 60 PERIODS
TEXT BOOKS:

1. Craig Larman, ―Applying UML and Patterns: An Introduction to Object-Oriented

Analysis and Design and Iterative Development‖, Third Edition, Pearson Education,
2005.

REFERENCES:

1.Roger.S.Pressman and Bruce R. Maxim, “Software Engineering: A Practitioner's

Approach” , Eighth Edition, Mc-Graw Hill Education, 2015.

2.Simon Bennett, Steve Mc Robb and Ray Farmer, “Object Oriented Systems
Analysis and Design Using UML”, Fourth Edition, Mc-Graw Hill Education, 2010.

3.Erich Gamma, and Richard Helm, Ralph Johnson, John Vlissides, “Design
patterns: Elements of Reusable Object-Oriented Software”, Addison-Wesley,
1995.

4.Martin Fowler, “UML Distilled: A Brief Guide to the Standard Object Modeling
Language”, Third edition, Addison Wesley, 2003.

5.Paul C. Jorgensen, “Software Testing:- A Craftsman‟s Approach”, Third Edition,

Auerbach Publications, Taylor and Francis Group, 2008.
5. Course outcomes
At the end of this course, the students will be able to:
CO1: To learn the basics of OOAD and various UML diagrams.
CO2: To understand how to create design patterns.
CO3:To understand the various stages of the design process using a case study.
CO4:To learn how to apply design patterns using various UML diagrams.
CO5:To know how to map design to code and learn different testing techniques.
 6. CO - PO / PSO MAPPING

PROGRAM OUTCOMES PSO

K3,
CO HKL K3 K4 K5 K5K A3 A2 A3 A3 A3 A3 A2

PSO3
PSO2
PSO1
4,K
5
PO- PO- PO- PO- PO- PO- PO- PO- PO- PO- PO- PO-
1 2 3 4 5 6 7 8 9 10 11 12

CO1 K3 2 1 1 - - - - - - - - - 2 2 2

CO2
K3 3 3 3 - - - - - - - - - 2 2 2

CO3
K3 3 3 3 - - - - - - - - - 2 2 2

CO4
K3 3 3 3 - - - - - - - - - 2 2 2

CO5
K3 3 3 3 - - - - - - - - - 2 2 2

Correlation Level:
1. Slight (Low)
2. Moderate (Medium)
3. Substantial (High)
If there is no correlation, put
“-“.
 7. LECTURE PLAN

Number Propose Actual Taxono Mode of

Sl.
Topic of d Lecture CO my Delivery
No.
Periods Date Date Level
GRASP:
Designing Chalk &
1 objects with 1 CO1 K1 talk
responsibilities
– Creator –
Information
expert
Low Coupling – Chalk &
2 High Cohesion 1 CO1 K2 talk
Controller Chalk &
3 1 CO1 K2 talk
Creational -
factory method PPT/
4 1 CO1 K2
Demo

Structural – PPT/
5 Bridge 1 CO1 K2
Demo
Adapter -
PPT/
6 behavioural 1 CO1 K3
– Strategy – Demo
observer
8. Activity based learning(Factory Method)

Sourse code Link:

https://www.javatpoint.com/factory-method-
design-pattern Execution:
9. Links to Videos, e-book reference, PPTs
Links to Videos
https://fccdl.in/9DFiMFQULX

E-book reference
1. Clean Code: A Handbook of Agile Software Craftsmanship
2. The Clean Coder: A Code of Conduct for Professional Programmers
3. Agile Software Development, Principles, Patterns, and Practices
4. UML for Java Programmers
5. Design Patterns: Elements of Reusable Object-Oriented Software
6. Object-Oriented Analysis and Design with Applications (3rd Edition)
7. Test Driven Development: By Example (Kent Beck)
8. Refactoring: Improving the Design of Existing Code: Martin Fowler also have a
Ruby version
9. Applying UML and Patterns: Craig Larman
 UNIT II DESIGN PATTERNS

GRASP: Designing objects with responsibilities – Creator – Information

expert – Low Coupling – High Cohesion – Controller Design Patterns –
creational – factory method – structural – Bridge – Adapter – behavioural
– Strategy

General Responsibility Assignment Software Patterns (or Principles),

abbreviated GRASP, consists of guidelines for assigning responsibility to classes and
objects in object-oriented design.

The different patterns and principles used in GRASP are: Information Expert,
Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication,
Indirection, Protected Variations. All these patterns answer some software problem,
and in almost every case these problems are common to almost every software
development project. These techniques have not been invented to create new ways
of working but to better document and standardize old, tried-and-testedprogramming
principles in object oriented design.

The GRASP principles or patterns are a learning aid to understand essential

object design and apply design reasoning in a methodical, rational, explainable way.
This approach to understanding and using design principles is based on patterns of
assigning responsibilities
 UNIT II DESIGN PATTERNS

Responsibilities and Responsibility-Driven Design

A popular way of thinking about the design of software objects and also larger-
scale components is in terms of responsibilities, roles , and collaborations . Thisis
part of a larger approach called responsibility-driven design or RDD

The UML defines a responsibility as "a contract or obligation of a classifier"

Responsibilities are related to the obligations or behavior of an object interms
of its role. Basically, these responsibilities are of the following twotypes: doing
and knowing.

Doing responsibilities of an object include:

doing something itself, such as creating an object or doing a calculation

initiating action in other objects

controlling and coordinating activities in other objects Knowingresponsibilities

of an object include:

• knowing about private encapsulated data

• knowing about related objects

• knowing about things it can derive or calculate

Responsibilities are assigned to classes of objects during object design. For
example, I may declare that "a Sale is responsible for creating SalesLineItems "
(a doing), or "a Sale is responsible for knowing its total" (a knowing).
 UNIT II DESIGN PATTERNS

RDD also includes the idea of collaboration. Responsibilities are implemented by

means of methods that either act alone or collaborate with other methods and
objects. For example, the Sale class might define one or more methods to know its
total; say, a method named getTotal. To fulfill that responsibility, the Sale may
collaborate with other objects, such as sending a getSubtotal message to each
SalesLineItem object asking for its subtotal

Patterns
In OO design, a pattern is a named description of a problem and solution that can
be applied to new contexts; Many patterns, given a specific category of problem,
guide the assignment of responsibilities to objects. For example, here is a sample
pattern

Pattern Name: Information Expert

Problem : What is a basic principle by which to
assignresponsibilities to objects?

Solution :Assign a responsibility to the class that has the

information needed to fulfill it

Creator Pattern

Creator:

The creation of objects is one of the most common activities in an object- oriented
system. Consequently, it is useful to have a general principle for assignment of
creation responsibilities. Assigned well, the design can support low coupling
increased clarity, encapsulation, and reusability.
 UNIT II DESIGN PATTERNS

Problem:
Who should be responsible for creating a new instance of some class ?
Solution:
Assign class B the responsibility to create an instance of class A if one ormore of the
following is true :
 B aggregates A objects .
 B contains A objects.
 B records instances of A objects.
 B closely uses A objects.
 B has the initializing data that will be passed to A when it is created
 B is a creator of A objects.

Example: NextGen POS Example

Problem :Who should create a SalesLineItem

 UNIT II DESIGN PATTERNS

Solution:
Since a Sate contains (in fact, aggregates) many SalesLineltem objects, the
Creator pattern suggests that Sale is a good candidate to have the responsibility
of creating SalesLineltem instances.

Creation of objects is one of the most common activities in an object-oriented

system. Which class is responsible for creating objects is a fundamentalproperty
of the relationship between objects of particular classes. In general, a class B
should be responsible for creating instances of class A if one, or preferably more,
of the following apply:

a) Instances of B contains or compositely aggregates instances of A

b) Instances of B record instances of A

c) Instances of B closely use instances of A

d) Instances of B have the initializing information for instances of A and pass it

on creation.

Discussion of Creator pattern

 Responsibilities for object creation are common

 Connect an object to its creator when:

 Aggregator aggregates Part Container contains Content Recorder

records Initializing data passed in during creation
 UNIT II DESIGN PATTERNS

Related Patterns

 Low coupling

 Concrete Factory & Abstract Factory

Information Expert

Information Expert

By Information expert we should look for the class of objects that has the
information needed to determine the total.

Information Expert is a principle used to determine where to delegate

responsibilities. These responsibilities include methods, computed fields and so
on. Using the

principle of Information Expert a general approach to assigning responsibilities

is to look at a given responsibility, determine the information needed to fulfill
it, and then determine where that information is stored. Information Expert will
lead to placing the responsibility on the class with the most information required
to fulfill it.
 UNIT II DESIGN PATTERNS

Problem: What is a general principle of assigning responsibilities to

objects?
Solution: Assign a responsibility to the information expert – a class that
has the information necessary to fulfill the responsibility.

Example:
Problem: Who should be responsible for knowing the total price for a
sale?
Solution : Let Sale do it because it knows all of its SaleLineItems. For
example, to get the sale total, Sale gets subtotals from SaleLineItem
which get prices from Product Description.

We see that Sale already has the SalesLineItem objects needed to calculate
the total
 UNIT II DESIGN PATTERNS

But to get the price of a SalesLineItem, we also need the ProductDescription's

price attribute. SalesLineItem has the needed information
 UNIT II DESIGN PATTERNS

To fulfill the responsibility to know its subtotal, the SalesLineItem needs to

collaborate with Product Description
 UNIT II DESIGN PATTERNS

Expert benefits
Information encapsulation is maintained since obj. use their own info to fulfill
tasks. This usually supports low coupling, which leads to more robust and
maintainable systems.

Behavior is distributed across the classes that have the required info, thus
encouraging more cohesive ―lightweight‖ class definitions that are easier to
understand and maintain.

Related Patterns

Low coupling

High cohesion

Low Coupling.
Coupling is a measure of how strongly one element is connected to, has knowledge
of, or relies on other element. If there is coupling or dependency, then when the
depended-upon element changes, the dependent may be affected.

Problem: How to support a low dependency, low change impact ,and increased
reuse?

Solution:

 Assign a responsibility so that coupling remains low.

 Evaluate design alternatives

 Choose option that minimizes coupling

 Simple chain of command

 UNIT II DESIGNPATTERNS

Example: NextGen POS Example

Problem: Who should create a Payment and associate it with a Sale?

Solution :
 By Expert, let Register create Payment info, then associate it with the
Sale Register & Sale now coupled to Payment

 By Low Coupling, Register delegates Payment creation to Sale Only Sale

coupled to Payment

Design:1
On the one hand, we might give Register the responsibility to create the
Payment:

Design :2
On the other hand, we might give Sale the responsibility to create the Payment:

Which is better? It is unavoidable that Sale is coupled to Payment. But the

first design creates an unnecessary coupling of Sale to Register. All else being equal,
we prefer the second.
 UNIT II DESIGN PATTERNS

Low Coupling benefits

Not affected by changes in other components
Simple to understand in isolation
Convenient to reuse
Classes are

More independent Easier to reuse Easier to

understand Easier to maintain

Related Patterns

Protected Variation
High Cohesion
Cohesion measures how functionality related the operations of a software
elements are, and also measures how much work a software element is
doing.

Problem : How to keep objects focused, understandable, manageable,

maintainable and a side effect?. How to support low coupling?

Solution :
 Assign responsibilities so that
cohesion remains high and object„s
responsibilities are closely related

Evaluate alternatives to optimize cohesion

Don„t spread yourself too thin„

Teamwork„
 UNIT IIDESIGNPATTERNS

Example:
For the POS system, when we design for the makePayment() system operation:

We already saw that this creates an unnecessary coupling between Register and
Payment. But it also reduces the cohesion of Register.
By delegating Payment creation to Sale, we not only decrease coupling, but we also
increase the cohesion of Register.

Since Register has fewer responsibilities, it is more cohesive.

 UNIT II DESIGN PATTERNS

High Cohesion benefits

Clarity and ease of comprehension of the design is increased

Maintenance and enhancements are simplified

Low coupling is often supported

Reuse of fine-grained, highly related functionality is increased because a

cohesive class can be used for a very specific purpose.

Controller

Controller is the first obj. (class) beyond the UI layer that is responsible for receiving
or handling a system operation message.

The Controller pattern assigns the responsibility of dealing with system events
to a non-UI class that represent the overall system or a use case scenario. A
Controller object is a non-user interface object responsible for receiving or handling
a system event.

A use case controller should be used to deal with all system events of a use case,
and may be used for more than one use case (for instance, for use cases Create
User and Delete User, one can have one User Controller, instead of two separate
use case controllers).

It is defined as the first object beyond the UI layer that receives and coordinates
("controls") a system operation. The controller should delegate to other objects the
work that needs to be done; it coordinates or controls the activity. It should not do
much work itself.
 UNIT II DESIGN PATTERNS

The GRASP Controller can be thought of as being a part of the Application/Service

layer (assuming that the application has made an explicit distinction between the
App/Service layer and the Domain layer) in an object- oriented system with
common layers.

Problem:
The UI & domain layers should be loosely coupled. What is the 1st object should
receive and coordinate messages (system operation) between the UI layer and
other domain objects?

Solution :

Assign responsibility to an object representing one of these choice:

 The overall ‗system„ or a ‗root„ object (Store, Bank)

A device that the SW is running within (BankATM)

A major subsystem (AccountingSystem)

A major use case scenario (GameHandler)

 Single channel of communication between layers„

Example:NextGen POS Example

Problem :Which object in the domain layer should be responsible for the system
operations?
Solution:
 Select the ‗root„ object in the POS domain model (Store)

 Select an object that represents a key device (Register)

 Create an object that handles the use case (SaleHandler)

 UNIT II DESIGN PATTERNS

Example: for the enterItem operation, we have a situation like this:

Some possible design alternatives:

 UNIT II DESIGN PATTERNS

Combining with the other system operations, we can see the

consequences of each design alternative:
 UNIT II DESIGN PATTE RNS

Some tips about controllers:

The controller should be seen as a facade into the domain layer.

Use the same controller for all system events involved in a use case.
Controllers will often be stateful, maintaining information about the current
progress of the use case.
For purposes of cohesion, controllers should primarily delegate, (forward
responsibility to other objects) wherever possible.
In Java EE, controllers will oftentimes be stateful session Enterprise Java Beans.
The controller may delegate directly to domain layer objects, or if it is in a
separate application logic layer, it may make requests to other controllers in the
pure domain layer.

Some controller antipatterns:

A single controller with \too many" system events.

No delegation.

Duplication of information found elsewhere in the domain layer.M

Don't allow direct manipulation of domain objects in the UI layer

 UNIT II DESIGN PATTERNS

Example (good design)

 UNIT II DESIGN PATTERNS

Example (bad design):

 UNIT II DESIGN PATTERNS

Controller benefits

Increased potential for reuse and pluggable interfaces

Opportunity to reason about the state of the UC

Related Patterns

Command: In a msg handling sys., each msg may be represented and handled by
a spate Command obj
Façade
Layers (POSA pattern) placing domain logic in the domain layer.
Pure Fabrication

Gang of Four Design Patterns (GOF)

The Gang of Four are the four authors of the book, "Design Patterns: Elements of
Reusable Object-Oriented Software".

Design Patterns
Design patterns provide solutions to common software design problems. In the case
of object-oriented programming, design patterns are generally aimed at solving the
problems of object generation and interaction, rather than the larger scale problems
of overall software architecture. They give generalised solutions in the form of
templates that may be applied to real-world problems.

Who are the Gang of Four?

The Gang of Four are the authors of the book, “Design patterns Elements of Reusable
Object-Oriented Software. This important book describes various development
techniques and pitfalls in addition to providing twenty-three object- oriented
programming design patterns. The four authors were Erich Gamma, Richard
Helm,Ralph Johnson and John Vlissides.
 UNIT II DESIGN PATTERNS

Gang of Four Design Patterns

The following gives a high-level description of the twenty-three design
patterns described by the Gang of Four. It cab be divided into three categories

 Creational Patterns

 Structural Patterns

 Behavioural Patterns

Purpose Design Scop

Patterns e
Creational Abstract Factory Object
Builder Object
Factory Method Class
Prototype Object
Singleton Object
Structural Adapter Class
Bridge Object
Composite Object
Decorator Object
Facade Object
Flyweight Object
Proxy Object
Behaviora Chain of Object
Responsibilit y

Command Object
Interpreter Class
Iterator Object
Mediator Object
Memento Object
Observer Object
State Object
Strategy Object
Template Class
Method
Visitor Object
 UNIT II DESIGN PATTERNS

Creational Patterns
The first type of design pattern is the creational pattern. Creational patterns
provide ways to instantiate single objects or groups of related objects. There
are five such patterns:

Abstract Factory: The abstract factory pattern is used to provide a client with
a set of related or dependant objects. The "family" of objects created by the
factory are determined at run-time.

Builder : The builder pattern is used to create complex objects with constituent
parts that must be created in the same order or using a specific algorithm. An
external class controls the construction algorithm.

Factory Method: The factory pattern is used to replace class constructors,

abstracting the process of object generation so that the type of the object
instantiated can be determined at run-time.

Prototype :The prototype pattern is used to instantiate a new object by copying

all of the properties of an existing object, creating an independent clone. This
practise is particularly useful when the construction of a new object is inefficient.

Singleton The singleton pattern ensures that only one object of a particular
class is ever created. All further references to objects of the singleton class refer
to the same underlying instance.
 UNIT II DESIGN PATTERNS

Creational Patterns Abstract Factory

Intent

Provide an interface for creating families of related or dependent objects

without
specifying their concrete classes.
A hierarchy that encapsulates: many possible "platforms", and the
construction of a suite of "products".

The new operator considered harmful. Problem

If an application is to be portable, it needs to encapsulate platform dependencies.

These "platforms" might include: windowing system, operating system,
database, etc. Too often, this encapsulation is not engineered inadvance, and
lots of #ifdef case statements with options for all currently supported platforms
begin to procreate like rabbits throughout the code.

Discussion
Provide a level of indirection that abstracts the creation of families of related or
dependent objects without directly specifying their concrete classes. The
"factory" object has the responsibility for providing creation services for the entire
platform family. Clients never create platform objects directly, they ask the
factory to do that for them.

This mechanism makes exchanging product families easy because the specific
class of the factory object appears only once in the application - where it is
instantiated. The application can wholesale replace the entire family of products
simply by instantiating a different concrete instance of the abstract factory.
UNIT II DESIGN PATTERNS

Because the service provided by the factory object is so pervasive, it is routinely

implemented as a Singleton Structure
The Abstract Factory defines a Factory Method per product. Each Factory Method
encapsulates the new operator and the concrete, platform-specific, product
classes. Each "platform" is then modeled with a Factory derived class.
 UNIT II DESIGN PATTERNS

Example
The purpose of the Abstract Factory is to provide an interface for creating families of
related objects, without specifying concrete classes. This pattern is found in the sheet
metal stamping equipment used in the manufacture of Japanese automobiles. The
stamping equipment is an Abstract Factory which creates auto body parts. The same
machinery is used to stamp right hand doors, left hand doors, right front fenders, left
front fenders, hoods, etc. for different models of cars. Through the use of rollers to
change the stamping dies, the concrete classes produced by the machinery can be
changed within three minutes.

Factory
This is also called Simple Factory or Concrete Factory. This pattern is not a GoF
design pattern,

but extremely widespread. It is also a simplification of the GoF Abstract Factory pattern
and often described as a variation of Abstract Factory, although that's not strictly
accurate.

separation of concerns . modularize or separate distinct concerns into different areas,

so that each has a cohesive purpose. Fundamentally, it is an application of the GRASP
High Cohesion principle. For example, the domain layer of software objects emphasizes
relatively pure application logic responsibilities, whereas a different group of objects is
responsible for the concern of connectivity to external systems. Name:FactoryProblem:
Who should be responsible for creating objects when there are special considerations,
such as complex creation logic, a desire to separate the creation responsibilities for
better cohesion, and so forth?

Solution: (advice) Create a Pure Fabrication object called a Factory that handles the
creation.
UNIT II DESIGN PATTERNS
 UNIT II DESIGN PATTERNS

In the ServicesFactory , the logic to decide which class to create is resolved by

reading in the class name from an external source (for example, via a system
property if Java is used) and then dynamically loading the class. This is an
example of a partial data-driven design . This design achieves Protected
Variations with respect to changes in the implementation class of the adapter.

Without changing the source code in this factory class, can create instances of
new adapter classes by changing the property value and ensuring that the new
class is visible in the Java class path for loading.

Structural Patterns
The second type of design pattern is the structural pattern. Structural patterns
provide a manner to define relationships between classes or objects.

 Adapter. The adapter pattern is used to provide a link between two otherwise
incompatible types by wrapping the "adaptee" with a class that supports the
interface required by the client.

 Bridge .The bridge pattern is used to separate the abstract elements of a class
from the implementation details, providing the means to replace the implementation
details without modifying the abstraction.
 UNIT II DESIGN PATTERNS

Composite The composite pattern is used to create hierarchical, recursive tree

structures of related objects where any element of the structure may be accessed
and utilised in a standard manner.

Decorator The decorator pattern is used to extend or alter the functionality

of objects at run-time by wrapping them in an object of a decorator class. This
provides a flexible alternative to using inheritance to modify behaviour.

Facade The facade pattern is used to define a simplified interface to a more

complex subsystem.

Adapter (GoF)

Name: Adapter

Problem: How to resolve incompatible interfaces, or provide a

stable interface to similar

components with different interfaces?

Solution: Convert the original interface of a component into another interface,
through intermediate adapter object.

Example:
The NextGen POS system needs to support several kinds of external third- party
services, including tax calculators, credit authorization services, inventory
systems, and accounting systems, among others. Each has a different API, which
can't be changed.

A solution is to add a level of indirection with objects that adapt the

varying external interfaces to a consistent interface used within the application.
UNIT II DESIGN PATTERNS

The Adapter pattern

 UNIT II DESIGN PATTERNS

Bridge
Name : Bridge
Problem : How to decouple an abstraction from its implemention so
that the two can vary independently.

Solution : The bridge uses

encapsulation,aggregation, and can use
inheritance to separate responsibilities into different classes.
 UNIT II DESIGN PATTERNS

Intent
Decouple an abstraction from its implementation so that the two can vary
independently.

Publish interface in an inheritance hierarchy, and bury implementation in its own

inheritance hierarchy.

Beyond encapsulation, to insulation Problem

"Hardening of the software arteries" has occurred by using subclassing of an abstract

base class to provide alternative implementations. This locks in compile- time binding
between interface and implementation. The abstraction and implementation cannot be
independently extended or composed.

Discussion
Decompose the component's interface and implementation into orthogonal class
hierarchies. The interface class contains a pointer to the abstract implementation class.
This pointer is initialized with an instance of a concrete implementation class, but all
subsequent interaction from the interface class to the implementation class is limited
to the abstraction maintained in the implementation base class. The client interacts
with the interface class, and it in turn "delegates" all requests to the implementation
class.

The interface object is the "handle" known and used by the client; while the
implementation object, or "body", is safely encapsulated to ensure that it may continue
to evolve, or be entirely replaced (or shared at run-time.

Use the Bridge pattern when:

 UNIT II DESIGN PATTERNS

Use Bridge Pattern when

you want run-time binding of the implementation,

you have a proliferation of classes resulting from a coupled interface and numerous
implementations,

you want to share an implementation among multiple objects,

you need to map orthogonal class hierarchies.

Consequences include:

decoupling the object's interface,

improved extensibility (you can extend (i.e. subclass) the abstraction and
implementation hierarchies independently),

hiding details from clients.

Example

• The Bridge pattern decouples an abstraction from its implementation, so that the
two can vary independently. A household switch controlling lights, ceiling fans, etc.
is an example of the Bridge. The purpose of the switch is to turn a device on or off.
The actual switch can be implemented as a pull chain, simple two position switch,
or a variety of dimmer switches.
UNITIVDESIGNPATTERNS
 UNIT II DESIGN PATTERNS

Behavioral patterns

In software engineering, behavioral design patterns are design patterns that

identify common communication patterns between objects and realize these
patterns. By doing so, these patterns increase flexibility in carrying out this
communication.

Strategy (GoF)

Name: Strategy

Problem: How to design for varying, but related, algorithms or policies?

How to design for ability to change these algorithms or policies?

Solution: (advice) Define each algorithm/policy/strategy in a separate class,

with a common interface.
The design problem to be resolved is to provide more complex pricing logic,
such as a store-
wide discount for the day, senior citizen discounts, and so forth.
The pricing strategy (which may also be called a rule, policy, or algorithm) for
a sale can vary. During one period it may be 10% off all sales, later it may be
$10 off if the sale total is greater than $200,and myriad other variations. The
strategy pattern provide design for these varying pricing algorithms Since the
behavior of pricing varies by the strategy (or algorithm), create multiple
SalePricingStrategy classes, each with a polymorphic getTotal method
UNIT II DESIGN PATTERNS

Each getTotal method takes the Sale object as a parameter, so that the pricing
strategy object can find the pre-discount price from the Sale , and then apply the
discounting rule. The implementation of each getTotal method will be
different: PercentDiscountPricingStrategy will discount by a percentage, and so on.

Pricing Strategy classes

 UNIT II DESIGN PATTERNS

A strategy object is attached to a context object the object to which it applies the
algorithm. In this example, the context object is a Sale . When a getTotal
message is sent to a Sale, it delegates some of the work to its strategy object. It
is not required that the message to the context object and the strategy object have
the same name, as in this example (for example,getTotal and getTotal ), but it
is common. However, it is common indeed, usually required that the context object
pass a reference to itself (this ) on to the strategy object, so that the strategy has
parameter visibility to the context object, for

further collaboration.
 UNIT II DESIGN PATTERNS

Creating a Strategy with a Factory

There are different pricing algorithms or strategies, and they change
over time. Who should create the strategy? A straightforward approach
is to apply the Factory pattern again:
A Pricing StrategyFactory can be responsible for creating all strategies
(all the pluggable or changing algorithms or policies) needed by the
application.
As with the ServicesFactory , it can read the name of the
implementation class of the pricing strategy from a system property (or
some external data source), and then make an instance of it.
With this partial data-driven design (or reflective design) one can
dynamically change at any time while the NextGen POS application is
running the pricing
policy, by specifying a different class of Strategy to create.
Observe that a new factory was used for the strategies; that is,
different than the ServicesFactory .
This supports the goal of High Cohesion each factory is cohesively
focused on
creating a related family of objects.
 UNIT II DESIGN PATTERNS

When a Sale instance is created, it can ask the factory for its pricing strategy

Observer/Publish-Subscribe/Delegation Event Model (GoF)

Name: Observer (Publish-Subscribe)

Problem: Different kinds of subscriber objects are interested in the state changes or
events of a publisher object, and want to react in their own unique way when the
publisher generates an event. Moreover, the publisher wants to maintain low coupling
to the subscribers. What to do?

Solution: Define a "subscriber" or "listener" interface. Subscribers implement this

interface. The publisher can dynamically register subscribers who are interested in an
event and notify them when an event occurs.
UNIT II DESIGN PATTERNS
UNIT II DESIGN PATTERNS

The major ideas and steps in this example:

1. An interface is defined; in this case, Property Listener with the operation
on Property Event .

2. Define the window to implement the interface. SaleFrame1 will

implement the method on Property Event .

3. When the SaleFrame1 window is initialized, pass it the Sale instance from which
it is displaying the total.

4. The SaleFrame1 window registers or subscribes to the Sale instance for

notification of "property events," via the add Property Listener message. That is,
when a property (such as total) changes, the window wants to be notified.

5. Note that the Sale does not know about SaleFrame1 objects; rather, it only knows
about objects that implement the Property Listener interface. This lowers the
coupling of the Sale to the window the coupling is only to an interface, not to a
GUI class.

6. The Sale instance is thus a publisher of "property events." When the total
changes, it iterates across all subscribing Property Listeners

, notifying each.
The SaleFrame1 object is the observer/subscriber/listener. it subscribes to interest
in property events of the Sale , which is a publisher of property events. The Sale
adds the object to its list of Property Listener subscribers. Note that the Sale does
not know about the SaleFrame1 as a SaleFrame1 object, but only as a Property
Listener object; this lowers the coupling from the model up to the view layer.
 UNIT II DESIGN PATTERNS

As illustrated when the Sale total changes, it iterates across all its registered
subscribers, and "publishes an event" by sending the onPropertyEvent message to
each.
 UNIT II DESIGN PATTERNS

The onPropertyEvent message is polymorphic; the specific cases of

polymorphic implementation will be shown in the following
diagrams

SaleFrame1 , which implements the PropertyListener interface, thus implements

an onPropertyEvent method. When the SaleFrame1 receives the message, it sends a
message to its JTextField GUI widget object to refresh with the new sale total.
 UNIT II DESIGN PATTERNS

Mapping design to code:

 Process: Write source code for

• Class and interface definitions

• Method definitions

Design Class Diagrams:

 DCDs contain class or interface names, classes, method and simple attributes.

 These are sufficient for basic class definitions.

 Elaborate from associations to add reference attributes.

 Creating Class definitions from DCDs

 UNIT II DESIGN PATTERNS

Creating Methods from Interaction Diagrams

 UNIT II DESIGN PATTERNS

Reference Attributes:

An attribute that refers to another complex objects.

 Reference Attributes are suggested by associations and

navigability in a class diagram.

 Example: A product specification reference on a Sales Line Item.

So here we can use product spec as a complex reference attribute
to sales line item class.

Role Names:

Each end of an association is a role. Reference Attributes are often suggested by

role names. (use role names as the names of reference attributes)
UNIT II DESIGN PATTERNS
UNIT II DESIGN PATTERNS
UNIT II DESIGNPATTERNS
 UNIT II DESIGN PATTERNS

Order of implementation
 UNIT II DESIGNPATTERNS

Next Gen POS System Program Solution

Next Gen POS System Program Solution
 UNIT II DESIGN PATTERNS

Class Register
UNIT II DESIGN PATTERNS
UNIT II DESIGN PATTERNS
10. Assignments ( For higher level learning and
Evaluation - Examples: Case study, Comprehensive
design, etc.,)

Category I:
Consider the scenario where a Funds Transfer operation must be supported
by an ATM, over Net Banking application, as well as in-person by a Cashier
from a Bank branch location. Which GRASP principle can best guide the
assignment of this responsibility? Explain in detail. (C02,K4)

Category II:
Design a class diagram for a university course management system. Apply
the Information Expert pattern to determine which class should be
responsible for calculating the GPA of a student. (C02,K4)

Category III:
Develop a class diagram for a traffic monitoring system. Apply the
Controller pattern to identify the class responsible for coordinating the
traffic data and generating reports. (C02,K4)

Category IV:
Create a class diagram for a library management system. Apply the Expert
pattern to determine which class should be responsible for checking if a
book is available for checkout. (C02,K4)

Category V:
Apply the Controller pattern to a banking system. Identify an alternative
scenario where a different class would be responsible for coordinating the
transfer of funds between accounts. (C02,K4)
 11. Part AQ& A(with Klevel andCO)
S.N Questions
K Level CO
o
Level

1 K2 C02
Define patterns.
A pattern is a named problem/solution pair that can be applied in
new context, with advice on how to apply it in novel situations and

discussion of its trade-offs.

2 K2 C02
How to Apply the GRASP Patterns?
The following sections present the first five GRASP patterns:
Information Expert

Creator
High Cohesion
Low Coupling

Controller
3 K2 C02
Define Responsibilities and Methods.
The UML defines a responsibility as “a contract or obligation of a
classifier” [OMG01]. Responsibilities are related to the obligations of
an object in terms of its behavior.

Basically, these responsibilities are of the following two types:

• Knowing

• Doing

4 List out some scenarios that illustrate varying degrees of functional K1 C02
cohesion.

• Very low cohesion

• Low cohesion
• High cohesion
• Moderate cohesion
6 K2 C02
What are the advantages of Factory objects?
• Separate the responsibility of complex creation into cohesive helper
objects.

• Hide potentially complex creator logic

• Allow introduction of performance-enhancing memory
management strategies, such as object caching or recycling.

7 K2 C02
What is meant by Abstract Class Abstract Factory?
A common variation on Abstract Factory is to create an abstract class
factory that is accessed using the Singleton pattern, reads from a
system property to decide which of its subclass factories to create,
and then returns the appropriate subclass instance.. Toolkit class,
which is an abstract class abstract factory for creating families of GUI
widgets for different operating system and GUI subsystems.

8 K2 C02
Differentiate coupling and cohesion.
Coupling deals with interactions between objects or software
components while cohesion deals with the interactions within a single
object or software component. Highly cohesive components can lower
coupling because only a minimum of essential information need to b
passed between components.

9 K2 C02
What is meant by Low Coupling?
Coupling is a measure of how strongly one element is connected to,
has knowledge of, or relies on other elements. An element with low
(or weak) coupling is not dependent on too many other elements;
"too many" is context-dependent, but will be examined. These
elements include classes, subsystems, systems, and so on.

10 K2 C02
What is meant by High cohesion?
Cohesion (or more specifically, functional cohesion) is a measure of
how strongly related and focused the responsibilities of an element
are. An element with highly related responsibilities, and which does
not do a tremendous amount of work, has high cohesion. These
elements include classes, subsystems, and so on.
11 K2 C04
What is meant by Pure Fabrication?
This is another GRASP pattern. A Pure Fabrication is an arbitrary
creation of the designer, not a software class whose name is inspired
by the Domain Model. A use-case controller is a kind of Pure
Fabrication.

12 K2 C04
How to create an instance?
Any message can be used to create an instance, but there is a convention
in the UML to use a message named create for this purpose. If anothe
(perhaps less obvious) message name is used, the message may be
annotated with a special feature called a UML stereotype, like so
«create». The create message may include parameters, indicating the
passing of initial values. This indicates, for example, a constructor cal
with parameters in Java.

13
Define Controller. K2 C04
Assign the responsibility for receiving or handling a system event
message to a class representing one of the following choices: -
Represents the overall system, device, or subsystem (facade
controller). - Represents a use case scenario within which the system
event occurs, often named Handler, Coordinator, or Session (use-case
or session controller). - Use the same controller class for all system
events in the same use case scenario.

14 What is GRASP and Designing Objects with Responsibilities? The K2 C04

following sections present the first five GRASP patterns:

• Information Expert
• Creator

• High Cohesion
• Low Coupling
• Controller

15 K2 C04
What do you mean by design patterns?
Design patterns are devices that allow systems to share knowledge
about their design, by describing commonly recurring structures of
communicating components that solve a general design problem
within a particular context.
12. Part BQs(with Klevel andCO)
S.No Questions
K Level CO Level

1 Explain the GoF Patterns

K3 CO2

2 Discuss about Low Coupling and High Cohesion with

K3 CO2
example.

3 Explain about Creator and information Expert with

K3 CO2
example.

4 Explain about the Creational Patterns

K3 CO2

5 Explain about the Behavioral Patterns

K3 CO2

6 Explain about the Structural Patters

K3 CO2

7 What is Controller? Explain the concepts of Façade,

K3 CO2
session and bloated controller.

8 Explain in detail about the Factory Pattern and mention

K3 CO2
the Limitations and applications of Factory pattern.

9 Explain in detail about the GRASP pattern and also

K3 CO2
explain in designing objects with Responsibilities.

10 Write short notes on adapter, factory method,

K2 CO2
behavioral and observer pattern.

11 What is coupling? Explain the types of Coupling in

K2 CO2
detail.

12 Explain in detail about the different categories of Design

K3 CO2
patterns.
13.Supportive online Certification
courses(NPTEL, Swayam, Coursera,
Udemy, etc.,)
Online Repository:
1. Google Drive 2. GitHub 3. Code Guru

2 NPTEL Swayam
https://onlinecourses.nptel.ac.in/noc16_cs19
http://engineeringvideolectures.com/video/1237

www.uml-diagrams.org/uml-object-oriented-concepts.html
14. Real time Applications in day to
daylife and to Industry
To create a Plan abstract class and concrete classes that extends the Plan
abstract class. A factory class GetPlanFactory is defined as a next step.
GenerateBill class will use GetPlanFactory to get a Plan object. It will pass
information (DOMESTICPLAN / COMMERCIALPLAN /
INSTITUTIONALPLAN) to GetPalnFactory to get the type of object it needs.

Factory Method
15. Contents beyond the Syllabus ( COE related Value
added courses)

S.No. Name of the Topic

1. Forward & Reverse Engineering of all UML diagrams

16. Assessment Schedule ( Proposed Date & Actual
Date)

S.No Assessment Proposed Actual

Date Date

10.02.24
1 Internal Assessment to
Test I
16.02.24

01.04.24
2 Internal Assessment
To
Test II
06.04.24

20.04.24
3 Model Examination To
30.04.24
 17. Prescribed Text Books & Reference Books

TEXT BOOKS:

1. Craig Larman, ―Applying UML and Patterns: An Introduction to Object-Oriented

Analysis and Design and Iterative Development‖, Third Edition, Pearson Education,
2005.

REFERENCES:

1. Roger.S.Pressman and Bruce R. Maxim, “Software Engineering: A Practitioner's

Approach” , Eighth Edition, Mc-Graw Hill Education, 2015.
2. Simon Bennett, Steve Mc Robb and Ray Farmer, “Object Oriented Systems Analysis
And Design Using UML”, Fourth Edition, Mc-Graw Hill Education, 2010.
3. Erich Gamma, and Richard Helm, Ralph Johnson, John Vlissides, “Design patterns:
Elements of Reusable Object-Oriented Software”, Addison-Wesley, 1995.
4. Martin Fowler, “UML Distilled: A Brief Guide to the Standard Object Modeling
Language”, Third edition, Addison Wesley, 2003.
5. Paul C. Jorgensen, “Software Testing:- A Craftsman‟s Approach”, Third Edition,
Auerbach Publications, Taylor and Francis Group, 2008.
2. Mini Project suggestions

1. Passport automation system.

2. Book bank
3. Exam Registration
4. Stock maintenance system.
5. Online course reservation system
6. E-ticketing
7. Software personnel management system
8. Credit card processing
9. e-book management system
10. Recruitment system
11. Foreign trading system
12. Conference Management System
13. BPO Management System
 Thankyou

Disclaimer:

This document is confidential and intended solely for the educational purpose of RMK Group
of Educational Institutions. If you have received this document through email in error, please
notify the system manager. This document contains proprietary information and is intended
only to the respective group / learning community as intended. If you are not the addressee
you should not disseminate, distribute or copy through e-mail. Please notify the sender
immediately by e-mail if you have received this document by mistake and delete this document
from your system. If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents of this information is
strictly prohibited.