VISHNU INSTITUTE OF TECHNOLOGY

(Approved by AICTE, Accredited by NBA & NAAC, Permanently Affiliated to JNTUK)

VISHNUPUR, BHIMAVARAM-534202
TEL: 08816-251333, FAX: 08816-250344

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

LABORATORY MANUAL
IV B.Tech. – I Semester

SOFTWARE ARCHITECTURE AND DESIGN PATTERNS LAB

ESTABLISHED BY
SRI VISHNU EDUCATIONAL SOCIETY
153, SITA NILAYAM, DWARAKAPURI COLONY, PUNJAGUTTA
HYDERABAD-500082
 VISHNU INSTITUTE OF TECHNOLOGY

VISION
To ignite the minds of the students through academic excellence so as to bring about social
transformation and prosperity.
MISSION
 To expand the frontiers of knowledge through Quality Education.
 To provide value added Research and Development.
 To embody a spirit of excellence in Teaching, Creativity, Scholarship and Outreach.
 To provide a platform for synergy of Academy, Industry and Community.
 To inculcate high standards of Ethical and Professional Behavior.

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

VISION
To build a strong teaching-learning base with a flair for innovation and research that responds to
the dynamic needs of the software industry and the society.

MISSION
 To provide strong foundation both in theory and applications of Computer Science &
Engineering, so as to solve real-world problems
 To empower students with state-of-art knowledge and up to date technological skills,
making them globally competent
 To promote research, innovation and entrepreneurship with focus on industry and social
outreach
 To foster civic minded leadership with ethics and values among students

i
 COURSE STRUCTURE

IV Year - I Semester

S. No. Subjects L T P Credits

1 Cryptography and Network Security 4 -- -- 3
2 Software Architecture & Design Patterns 4 -- -- 3
3 Web Technologies 4 -- -- 3
Managerial Economics and Financial
4- HS Analysis 4 -- -- 3
Elective-I
i. Big Data Analytics
5 4 -- -- 3
ii. Information Retrieval Systems
iii. Mobile Computing
Elective-II
i. Cloud Computing
6 4 -- -- 3
ii. Software Project Management
iii. Scripting Languages
Software Architecture& Design Patterns
7 Lab -- -- 3 2
8 Web Technologies Lab -- -- 3 2
Total
Credits 22

ii
 PROGRAM EDUCATIONAL OBJECTIVES
 Graduates will have knowledge of mathematics, science, engineering fundamentals, and
in-depth studies in Computer Science Engineering, and will be able to apply them for
formulating, analyzing and solving real world problems.
 Graduates will succeed in earning coveted entry level positions in leading Computer
Software and Hardware Firms in India and abroad.
 Graduates will succeed in the pursuit of advanced degrees and research in engineering or
other fields and will have skills for continued, independent, lifelong learning and
professional development throughout life.
 Graduates will have good communication skills, leadership qualities, ethical values and
will be able to work in teams with due attention to their social responsibilities.

PROGRAM OUTCOMES
 An ability to apply knowledge of computing, mathematics, science and engineering
fundamentals to the solution of complex engineering problems.
 An ability to formulate and analyze a problem, and define the computing requirements
appropriate to its solution using basic principles of mathematics, science and computer
engineering.
 An ability to design, implement, and evaluate a computer based system, process,
component, or software to meet the desired needs.
 An ability to design and conduct research based experiments, perform analysis and
interpretation of data and provide valid conclusions.
 An ability to use current techniques, skills, and tools necessary for computing practice.
 An understanding of legal, health, security, cultural and social issues, and thereby ones
responsibility in their application in Professional Engineering practice.
 An understanding of the impact of professional engineering solutions on environmental
context and the need for sustainable development.
 An understanding and commitment towards the professional and ethical responsibilities
of an engineer.
 An ability to function effectively as an individual, and as a team member/leader in
accomplishing a common goal.
 An ability to communicate effectively, make effective presentations and write and
comprehend technical reports and publications.
 An ability to learn and adopt new technologies, and use them effectively towards
continued professional development throughout the life.
 An understanding of engineering and management principles and their application to
manage projects in the software industry.

iii
Regd.No: ____________________________________

SUMMARY OF WORK-DONE
Marks
Exercise
Date Lab Record Signature
No. Viva Total(15)
(5) (5)
1

10

11

12

13

14

15

Total Marks Awarded: __________

Signature of the Teacher Signature of HOD

iv
 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS LAB

Course Objectives:
 Construct UML diagrams for static view and dynamic view of the system.
 Generate creational patterns by applicable patterns for given context.
 Create refined model for given Scenario using structural patterns.
 Construct behavioral patterns for given applications.
Course Outcomes:
At the end of this lab session, the student will

 CO1) Understand the Case studies and design the Model..

 CO2) Understand how design patterns solve design problems.

 CO3) Develop design solutions using creational patterns.

 CO4) Construct design solutions by using structural and behavioural

patterns

Learning Resources
Text Books
 Grady Booch , James Rumbaugh , Ivar Jacobson : The Unified Modeling
Language User Guide, Pearson Education
 Design Patterns By Erich Gamma, Pearson Education
 Meta Patterns designed by Wolf gang , Pearson.
References
1. Design Patterns Explained By Alan Shalloway, Pearson Education..
2. Head First Design Patterns By Eric Freeman - Oreilly-spd.
3. JAVA Enterprise Design Patterns Vol-III By Mark Grand , Wiley Dreamtech.
4. Pattern‟s in JAVA Vol-I By Mark Grand ,Wiley Dreamtech.
4. Pattern‟s in JAVA Vol-II By Mark Grand ,Wiley Dreamtech.

v
 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS LAB
SYLLABUS
Software Architecture Lab
The course project is divided in 6 small components that will be
performed during the different lab sessions; there are, in principle, 7 lab
sessions. The project consists of the design and implementation of the software
architecture of a Weather Mapping System (WMS). Implementation will take
place both in Java and C++ (combination of both languages). Each lab
assignment consists of a theoretical part and a practical part, which are
defined in specific lab assignment statements that are posted at least one or
two weeks before the session. Report and demo (if applicable) for each
assignment is due for the following session.
Report and demo (if applicable) for each assignment is due for the following
session.
1. Tool Presentation

This session is an introductory session; there is no lab assignment for

this session. Introduction to working with an industrial strength software

development environment, namely Rational Rose: how to write and maintain a

UML specification; configuration management; architecture design; CORBA-

IDL document generation; Java code generation from a UML model etc.

Presentation of the Project: Weather Mapping System.

2. Use Case View
Design of the Use Case View. Risk Analysis.
3. Logical View
Design of the Logical View of the Weather Mapping System (WMS).
4. Integrating Patterns in the Architecture
Integration of selected architectural and design patterns in the logical
view obtained previously.
5. Implementation, Process, and Deployment Views
Design of the implementation, process, and deployment views for the
Weather Mapping System.
6. Component and Interprocess Communication Design

Generation from the previous architecture design of CORBA Interfaces and

Components Definitions
7. Implementation of WMS
Implementation of the Weather Mapping System (Java & C++), with a
particular emphasis on the Interprocess communication mechanism and the
software components identified.

vi
Lab Reports:
Lab reports should include:
• The answers to the questions included in the assignment statement. The
answers should motivate briefly your design choices.
• The printout of the diagrams and related documents (e.g. class, use cases,
operations descriptions etc.) produced using Rational Rose.

Reference: http://www.ece.uvic.ca/~itraore/seng422-06/eng422-06.html
Design Patterns Lab
S. No Programs
1. Use case Diagram for Librarian Scenario
2. Using UML design Abstract factory design pattern
3. Using UML design Adapter-class Design pattern
4. Using UML design Adapter-object Design pattern
5. Using UML design Strategy Design pattern
6. Using UML design Builder Design pattern
7. Using UML design Bridge Design pattern
8. Using UML design Decorator Design pattern
9. User gives a print command from a word document. Design to
represent
this chain of responsibility Design pattern
10. Design a Flyweight Design pattern
11. Using UML design Facade Design pattern.
12. Using UML design Iterator Design pattern
13. Using UML design Mediator Design pattern
14. Using UML design Proxy Design pattern
15. Using UML design Visitor Design pattern

vii
 Software Architecture and Design Patterns Lab 2019-2020

Introduction to UML

What is UML?
"The Unified Modeling Language (UML) is a language for specifying, visualizing,
constructing, and documenting the artifacts of software systems, as well as for business
modeling and other non software systems".— OMG UML Specification
"UML is a graphical notation for modeling various aspects of software systems."
Why use UML?
Two questions, really:
1) Why use a graphical notation of any sort?
Facilitates construction of models that in turn can be used to:
 Reason about system behavior.
 Present proposed designs to others.
 Document key elements of design for future understanding.
2) Which graphical notation should be used?
 UML has become the de-facto standard for modeling object oriented systems.
 UML is extensible and method-independent.
 UML is not perfect, but it's good enough.
UML Diagram Types
There are several types of UML diagrams:
 Use-case Diagram
Shows actors, use-cases, and the relationships between them.
 Class Diagram
Shows relationships between classes and pertinent information about classes
themselves.
 Object Diagram
Shows a configuration of objects at an instant in time.
 Interaction Diagrams
Show an interaction between a group of collaborating objects.
Two types: Collaboration diagram and sequence diagram
 Package Diagram
Shows system structure at the library/package level.
 State Diagram
Describes behavior of instances of a class in terms of states, stimuli, and transitions.
 Activity Diagram
Very similar to a flowchart—shows actions and decision points, but with the ability to
accommodate
concurrency.
 Deployment Diagram
Shows configuration of hardware and software in a distributed system.

8 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

UML Modeling Types

It is very important to distinguish between the UML models. Different diagrams are used
for different type of UML modeling. There are three important type of UML modeling:
Structural modeling:
Structural modeling captures the static features of a system. They
consist of the followings:
Classes diagrams
Objects diagrams
Deployment diagrams
Package diagrams
Component diagrams
Structural model represents the framework for the system and this framework is the
place where all other components exist. So the class diagram, component diagram and
deployment diagrams are the part of structural modeling. They all represent the elements
and the mechanism to assemble them.
But the structural model never describes the dynamic behavior of the system. Class
diagram is the most widely used structural diagram.
Behavioral Modeling
Behavioral model describes the interaction in the system. It represents the interaction
among the
structural diagrams. Behavioral modeling shows the dynamic nature of the system. They
consist of the following:
Activity diagrams
Interaction diagrams
Use case diagrams
All the above show the dynamic sequence of flow in a system.
Architectural Modeling
Architectural model represents the overall framework of the system. It contains both
structural and behavioral elements of the system. Architectural model can be defined as
the blue print of the entire system. Package diagram comes under architectural
modeling.
UML Basic Notations
UML is popular for its diagrammatic notations. We all know that UML is for visualizing,
specifying, constructing and documenting the components of software and non software
systems. Here the Visualization is the most important part which needs to be
understood and remembered by heart. UML notations are the most important elements
in modeling. Efficient and appropriate use of notations is very important for making a
complete and meaningful model. The model is useless its purpose is depicted properly.

So learning notations should be emphasized from the very beginning. Different notations
are available for things and relationships. And the UML diagrams are made using the

9 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

notations of things and relationships. Extensibility is another important feature which

makes UML more powerful and flexible.

10 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

PART-1
Software Architecture Lab
The course project is divided in 6 small components that will be performed
during the different lab sessions; there are, in principle, 7 lab sessions. The project
consists of the design and implementation of the software architecture of a Weather
Mapping System (WMS). Implementation will take place both in Java and C++
(combination of both languages). Each lab assignment consists of a theoretical part and
a practical part, which are defined in specific lab assignment statements that are posted
at least one or two weeks before the session. Report and demo (if applicable) for each
assignment is due for the following session.
Report and demo (if applicable) for each assignment is due for the following session.
1. Tool Presentation
This session is an introductory session; there is no lab assignment for this
session. Introduction to working with an industrial strength software development
environment, namely Rational Rose: how to write and maintain a UML specification;
configuration management; architecture design; CORBA-IDL document generation; Java
code generation from a UML model etc.
Theory:
• Software design and implementation is the stage in the software engineering
process at which an executable software system is developed.
• Software design and implementation activities are invariably inter-leaved.

– Software design is a creative activity in which you identify software components

and their relationships, based on a customer’s requirements.

– Implementation is the process of realizing the design as a program.

An object-oriented design process

• Structured object-oriented design processes involve developing a number of

different system models.

• They require a lot of effort for development and maintenance of these models
and, for small systems, this may not be cost-effective.

• However, for large systems developed by different groups design models

are an important communication mechanism.
Process stages
• There are a variety of different object-oriented design processes that depend on the
organization using the process.
• Common activities in these processes include:
– Define the context and modes of use of the system;

11 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

– Design the system architecture;

– Identify the principal system objects;
– Develop design models;
– Specify object interfaces.
• Process illustrated here using a design for a wilderness weather
station.
System context and interactions
 Understanding the relationships between the software that is being designed and its
external environment is essential for deciding how to provide the required system
functionality and how to structure the system to communicate with its
environment.
 Understanding of the context also lets you establish the boundaries of the
system. Setting the system boundaries helps you decide what features are
implemented in the system being designed and what features are in other
associated systems.
Context and interaction models
• A system context model is a structural model that demonstrates the other
systems in the environment of the system being developed.
• An interaction model is a dynamic model that shows how the system interacts
with its environment as it is used.
System context for the weather Mapping system

12 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

Presentation of the Project: Weather Mapping System.

2. Use Case View

Architectural design
 Once interactions between the system and its environment have been understood,
you use this information for designing the system architecture.
 You identify the major components that make up the system and their
interactions, and then may organize the components using an architectural
pattern such as a layered or client-server model.
 The weather station is composed of independent subsystems that communicate by
broadcasting messages on a common infrastructure.

Architecture of data collection system

13 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

Object class identification

• Identifying object classes is too often a difficult part of object
oriented design.
• There is no 'magic formula' for object identification. It relies on the skill,
experience and domain knowledge of system designers.
• Object identification is an iterative process. You are unlikely to get it right
first time.
Approaches to identification
 Use a grammatical approach based on a natural language description of the
system (used in Hood OOD method).
 Base the identification on tangible things in the application domain.
 Use a behavioral approach and identify objects based on what participates in
what behavior.
 Use a scenario-based analysis. The objects, attributes and methods in each
scenario are identified.
Weather station description
A weather station is a package of software controlled instruments which collects
data, performs some data processing and transmits this data for further processing. The
instruments include air and ground thermometers, an anemometer, a wind vane, a
barometer and a rain gauge. Data is collected periodically.

When a command is issued to transmit the weather data, the weather station
processes and summarizes the collected data. The summarized data is transmitted
to the mapping computer when a request is received.
Weather station object classes
• Object class identification in the weather station system may
be based on the tangible hardware and data in
the system:
– Ground thermometer, Anemometer, Barometer
• Application domain objects that are ‘hardware’ objects related to
the instruments in the system.
– Weather station

14 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

• The basic interface of the weather station to its environment. It therefore

reflects the interactions identified in the use-case model.
– Weather data
• Encapsulates the summarized data from the instruments

Weather station object classes

Design models
• Design models show the objects and object classes and relationships between
these entities.
• Static models describe the static structure of the system in terms of object
classes and relationships.
• Dynamic models describe the dynamic interactions between
objects
Examples of design models
• Subsystem models that show logical groupings of objects into coherent
subsystems.
• Sequence models that show the sequence of object interactions.
• State machine models that show how individual objects change their
state in response to events.
• Other models include use-case models, aggregation models, generalisation
models, etc.
Subsystem models
• Shows how the design is organised into logically related groups of
objects.
• In the UML, these are shown using packages - an encapsulation construct. This is
a logical model. The actual organisation of objects in the system may be different

15 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

Sequence models
• Sequence models show the sequence of object interactions that take
place
o Objects are arranged horizontally across the top;
o Time is represented vertically so models are read top to bottom;
o Interactions are represented by labelled arrows, Different styles of arrow
represent different types of interaction;
o A thin rectangle in an object lifeline represents the time when the object is
the controlling object in the system.
Sequence diagram describing data Collection

State diagrams
 State diagrams are used to show how objects
 respond to different service requests and the state transitions triggered
by these requests.
 State diagrams are useful high-level models of a system or an object’s
run-time behavior.
 You don’t usually need a state diagram for all of the objects in the
system. Many of the objects in a system are relatively simple and a
state model adds unnecessary detail to the design.

16 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

Weather station state diagram

Interface specification

• Object interfaces have to be specified so that the objects and other components
can be designed in parallel.

• Designers should avoid designing the interface representation but should hide this
in the object itself.

• Objects may have several interfaces which are viewpoints on the methods
provided.

• The UML uses class diagrams for interface specification but Java may also be
used.
• Weather station interfaces

17 Dept. Of CSE Vishnu Institute Of Technology

Software Architecture and Design Patterns Lab 2019-2020

PART-II
DESIGN PATTERN INTRODUCTION

Design patterns represent the best practices used by experienced object-

oriented software developers. Design patterns are solutions to general problems
that software developers faced during software development. These solutions were
obtained by trial and error by numerous software developers over quite a
substantial period of time.
Gang of Four (GOF)
In 1994, four authors Erich Gamma, Richard Helm; Ralph Johnson und John
Vlissides published a book titled Design Patterns - Elements of Reusable Object-
Oriented Software which initiated the concept of Design Pattern in Software
development. These authors are collectively known as Gang of Four (GOF).
According to these authors design patterns are primarily based on the following
principles of object orientated design.
Program to an interface not an implementation
Favor object composition over inheritance
Usage of Design Pattern
Design Patterns have two main usages in software development.
Design patterns provide a standard terminology and are specific to particular
scenario. For example, a singleton design pattern signifies use of single object so
all developers familiar with single design pattern will make use of single object
and they can tell each other that program is following a singleton pattern. Design
patterns have been evolved over a long period of time and they provide best
solutions to certain problems faced during software development. Learning these
patterns helps inexperienced developers to learn software design in an easy and
faster way.
Types of Design Pattern
As per the design pattern reference book Design Patterns - Elements of Reusable
Object Oriented Software, there are 23 design patterns. These patterns can be
classified in three categories: Creational, Structural and behavioral patterns. We'll
also discuss another category of design patterns: J2EE design patterns.

18 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

AIM1: Use case Diagram for Librarian Scenario

Theory:
Use cases represents typical set of scenarios that help to structure, relate
and understand the essential requirement .A use case diagram is diagram that help
system analyst to discover the requirement of target system from the user’s
perspective. Use case diagram can be used to describe the functionality of system in
horizontal way.
Use case diagram are used to represent functionality of the system from a top down
perspective.
Actors of the system are:
1. Librarian: Librarian can check availability of book, verify member issue
book, calculate fine and return book.
2. Member: Member can check availability of book, issue book and return
book to system

19 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

AIM2. Using UML design Abstract factory design pattern

Abstract Factory is creational software design pattern. This pattern provides interfaces for
creating families of related or dependent objects without specifying their concrete classes.
Client software creates a concrete implementation of the abstract factory and then uses the
generic interfaces to create the concrete objects that are part of the family of objects. The
client does not know or care which concrete objects it gets from each of these concrete
factories since it uses only the generic interfaces of their products.
Use of this pattern makes it possible to interchange families of concrete classes without
changing the code that uses them. It separates details of implementation of a set of objects
from their usage.

UML class diagram example for the Abstract Factory Design Pattern.

20 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

AIM3: Using UML design Adapter-class Design pattern

The adapter pattern is adapting between classes and objects. Like any
adapter in the real world it is used to be an interface, a bridge between two objects.
In real world we have adapters for power supplies, adapters for camera memory
cards, and so on. Probably everyone has seen some adapters for memory cards. If you
cannot plug in the camera memory in your laptop you can use and adapter. You plug
the camera memory in the adapter and the adapter in to laptop slot. That's it, it's
really simple.
A real life example could be a case of card reader which acts as an adapter between
memory card and a laptop. You plugins the memory card into card reader and card
reader into the laptop so that memory card can be read via laptop. We are
demonstrating use of Adapter pattern via following example in which an audio player
device can play mp3 files only and wants to use an advanced audio player capable of
playing vlc and mp4 files.

Intent

1. Convert the interface of a class into another interface clients expect.

2. Adapter lets classes work together, that could not otherwise because of
incompatible interfaces

The figure below shows a UML class diagram for the Adapter Pattern:

The classes/objects participating in adapter pattern:

 Target - defines the domain-specific interface that Client uses.

 Adapter - adapts the interface Adaptee to the Target interface.
 Adaptee - defines an existing interface that needs adapting.
 Client - collaborates with objects conforming to the Target interface

21 Dept. Of CSE Vishnu Institute Of Technology

Software Architecture and Design Patterns Lab 2019-2020

AIM4: Using UML design Adapter-object Design pattern

The general idea of an adapter in software development is identical to the one
in the physical world. If you have been to different countries, you probably
recognized that a lot of them are using differently shaped power sockets. Quite
often, they are shaped in a way that the plug of your electrical device doesn’t
fit. So, how do you connect the charger of your mobile phone or laptop to these
power sockets?

The answer is simple. You get an adapter which you can put into the power
socket and then you put your plug into the other end of the adapter. The
adapter changes the form of your plug so that you can use it with the power
socket. In that example and in most other situations, the adapter doesn’t
provide any additional functionality. It just enables you to connect your plug to
the power socket.

The Adapter Pattern applies the same idea to object-oriented programming by

introducing an additional adapter class between an interface and an existing
class.
Class Diagram:

The adapter class implements the expected interface and keeps a reference to
an object of the class you want to reuse. The methods defined by the interface
call one or more methods on the referenced object and return a value of the
expected type. By doing that, the adapter class fulfills the expected contract by
implementing the interface and enables you to reuse existing, incompatible
implementation.

22 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

AIM5: Using UML design Strategy Design pattern

There are common situations when classes differ only in their behavior. For
this cases is a good idea to isolate the algorithms in separate classes in order to have
the ability to select different algorithms at runtime.
Intent
Define a family of algorithms, encapsulate each one, and make them
interchangeable. Strategy lets the algorithm vary independently from clients that use
it.

Implementation

Strategy - defines an interface common to all supported algorithms. Context

uses this interface to call the algorithm defined by a ConcreteStrategy.
ConcreteStrategy - each concrete strategy implements an algorithm.
Context
contains a reference to a strategy object.
may define an interface that lets strategy accessing its data.
The Context objects contains a reference to the ConcreteStrategy that should be
used. When an operation is required then the algorithm is run from the strategy
object. The Context is not aware of the strategy implementation. If necessary,
addition objects can be defined to pass data from context object to strategy.

The context object receives requests from the client and delegates them to the
strategy object. Usually the ConcreteStartegy is created by the client and passed to
the context. From this point the clients interacts only with the context.

23 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

AIM6: Using UML design Builder Design pattern

The more complex an application is the complexity of classes and objects used
increases. Complex objects are made of parts produced by other objects that need
special care when being built. An application might need a mechanism for building
complex objects that is independent from the ones that make up the object. If this is
the problem you are being confronted with, you might want to try using the Builder
(or Adaptive Builder) design pattern.

This pattern allows a client object to construct a complex object by specifying only its
type and content, being shielded from the details related to the objects
representation. This way the construction process can be used to create different
representations. The logic of this process is isolated from the actual steps used in
creating the complex object, so the process can be used again to create a different
object form the same set of simple objects as the first one.

Intent

1. Defines an instance for creating an object but letting subclasses decide which

class to instantiate
2. Refers to the newly created object through a common interface.

The Builder design pattern uses the Factory Builder pattern to decide which concrete
class to initiate in order to build the desired type of object, as we will see below in the
UML diagram:

The participants classes in this pattern are:

 The Builder class specifies an abstract interface for creating parts of a Product
object.

24 Dept. Of CSE Vishnu Institute Of Technology

Software Architecture and Design Patterns Lab 2019-2020

 The Concrete Builder constructs and puts together parts of the product by
implementing the Builder interface. It defines and keeps track of the
representation it creates and provides an interface for saving the product.
 The Director class constructs the complex object using the Builder interface.
 The Product represents the complex object that is being built.

25 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

AIM7: Using UML design Bridge Design pattern

Sometimes an abstraction should have different implementations; consider
an object that handles persistence of objects over different platforms using either
relational databases or file system structures (files and folders). A simple
implementation might choose to extend the object itself to implement the
functionality for both file system and RDBMS. However this implementation would
create a problem; Inheritance binds an implementation to the abstraction and thus it
would be difficult to modify, extend, and reuse abstraction and implementation
independently.
Intent
The intent of this pattern is to decouple abstraction from implementation so that the
two can vary independently.
Implementation

The figure below shows a UML class diagram for the Bridge Pattern:

Bridge Pattern Implementation - UML Class Diagram

26 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

8 AIM: Using UML design Decorator Design pattern

Decorator pattern allows adding new functionality an existing object without

altering its structure. This type of design pattern comes under structural pattern as
this pattern acts as a wrapper to existing class. This pattern creates a decorator class
which wraps the original class and provides additional functionality keeping class
methods signature intact.

We are demonstrating use of Decorator pattern via following example in which we'll
decorate a shape with some color without alter shape class.
Intent
Attach additional responsibilities to an object dynamically. Decorators provide
a flexible alternative to sub classing for extending functionality.
Also Known As
Wrapper
Applicability
Use Decorator 
1. To add responsibilities to individual objects dynamically and transparently,
that is, without affecting other objects.
2. for responsibilities that can be withdrawn.
3. when extension by sub classing is impractical. Sometimes a large number of
independent extensions are possible and would produce an explosion of
subclasses to support every combination. Or a class definition may be hidden
or otherwise unavailable for sub classing.
Implementation
We're going to create a Shape interface and concrete classes implementing the
Shape interface.We then create a abstract decorator class ShapeDecorator
implementing the Shape interface and havingShape object as its instance variable.
RedShapeDecorator is concrete class implementing ShapeDecorator.

DecoratorPatternDemo, our demo class will use RedShapeDecorator to decorate

Shape objects.

27 Dept. Of CSE Vishnu Institute Of Technology

Software Architecture and Design Patterns Lab 2019-2020

Class Diagram

28 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

AIM9: User gives a print command from a word document. Design to

represent this chain of responsibility Design pattern
As the name suggests, the chain of responsibility pattern creates a chain of
receiver objects for a request. This pattern decouples sender and receiver of a request
based on type of request. This pattern comes under behavioral patterns.
In this pattern, normally each receiver contains reference to another receiver.
If one object cannot handle the request then it passes the same to the next receiver
and so on.
Implementation
We have created an abstract class AbstractLogger with a level of logging. Then we
have created three types of loggers extending the AbstractLogger. Each logger checks
the level of message to its level and print accordingly otherwise does not print and
pass the message to its next logger.
Class Diagram:

29 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

AIM10: Design a Flyweight Design pattern

Some programs require a large number of objects that have some shared state among
them. Consider for example a game of war, were there is a large number of soldier
objects; a soldier object maintain the graphical representation of a soldier, soldier
behavior such as motion, and firing weapons, in addition soldiers health and location
on the war terrain. Creating a large number of soldier objects is a necessity however
it would incur a huge memory cost. Note that although the representation and
behavior of a soldier is the same their health and location can vary greatly
Intent
The intent of this pattern is to use sharing to support a large number of objects that
have part of their internal state in common where the other part of state can vary.
Implementation
The figure below shows a UML class diagram for the Flyweight Pattern:
Class Diagram:

Flyweight - Declares an interface through which flyweights can receive and act on
extrinsic state.
Concrete Flyweight - Implements the Flyweight interface and stores intrinsic state.
A Concrete Flyweight object must be sharable. The Concrete flyweight object must
maintain state that it is intrinsic to it, and must be able to manipulate state that is
extrinsic. In the war game example graphical representation is an intrinsic state,
where location and health states are extrinsic. Soldier moves, the motion behavior
manipulates the external state (location) to create a new location.
Flyweight Factory - The factory creates and manages flyweight objects. In addition
the factory ensures sharing of the flyweight objects. The factory maintains a pool of
different flyweight objects and returns an object from the pool if it is already created,
adds one to the pool and returns it in case it is new.
In the war example a Soldier Flyweight factory can create two types of flyweights : a
Soldier flyweight, as well as a Colonel Flyweight. When the Client asks the Factory for
a soldier, the factory checks to see if there is a soldier in the pool, if there is, it is
returned to the client, if there is no soldier in pool, a soldier is created, added to pool,
30 Dept. Of CSE Vishnu Institute Of Technology
 Software Architecture and Design Patterns Lab 2019-2020

and returned to the client, the next time a client asks for a soldier, the soldier created
previously is returned, no new soldier is created.
Client - A client maintains references to flyweights in addition to computing and
maintaining extrinsic state
A client needs a flyweight object; it calls the factory to get the flyweight object. The
factory checks a pool of flyweights to determine if a flyweight object of the requested
type is in the pool, if there is, the reference to that object is returned. If there is no
object of the required type, the factory creates a flyweight of the requested type, adds
it to the pool, and returns a reference to the flyweight. The flyweight maintains
intrinsic state (state that is shared among the large number of objects that we have
created the flyweight for) and provides methods to manipulate external state (State
that vary from object to object and is not common among the objects we have created
the flyweight for).

31 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

AIM11: Using UML design Facade Design pattern.

Facade pattern hides the complexities of the system and provides an
interface to the client using which the client can access the system. This type of
design pattern comes under structural pattern as this pattern adds an interface to
existing system to hide its complexities.
This pattern involves a single class which provides simplified methods required by
client and delegates calls to methods of existing system classes.
Implementation
We are going to create a Shape interface and concrete classes implementing the
Shape interface. A facade class ShapeMaker is defined as a next step.
Shape Maker class uses the concrete classes to delegate user calls to these classes.
FacadePatternDemo, our demo class, will use ShapeMaker class to show the results.
Class Diagram:

32 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

AIM12: Using UML design Iterator Design pattern

Theory:
Iterator pattern is very commonly used design pattern in Java and .Net
programming environment. This pattern is used to get a way to access the elements
of a collection object in sequential manner without any need to know its underlying
representation.
Iterator pattern falls under behavioral pattern category.
Intent
Provide a way to access the elements of an aggregate object sequentially without
exposing its underlying representation.
Also Known As
Cursor
Applicability
Use the Iterator pattern:
to access an aggregate object's contents without exposing its internal
representation.
to support multiple traversals of aggregate objects.
to provide a uniform interface for traversing different aggregate structures
(that is, to support polymorphic iteration).
Class Diagram:

33 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

AIM13: Using UML design Mediator Design pattern

Theory:
Decorator pattern allows a user to add new functionality to an existing object without
altering its structure. This type of design pattern comes under structural pattern as
this pattern acts as a wrapper to existing class. This pattern creates a decorator class
which wraps the original class and provides additional functionality keeping class
methods signature intact.
Intent
Attach additional responsibilities to an object dynamically. Decorators provide a
flexible alternative to sub classing for extending functionality.
Also Known As
Wrapper
Applicability
Use Decorator
To add responsibilities to individual objects dynamically and transparently,
that is, without affecting other objects.
for responsibilities that can be withdrawn.
when extension by sub classing is impractical. Sometimes a large number of
independent extensions are possible and would produce an explosion of
subclasses to support every combination. Or a class definition may be hidden
or otherwise unavailable for sub classing.
Class Diagram:

34 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

AIM14: Using UML design Proxy Design pattern

Theory:
• In Proxy pattern, a class represents functionality of another class. This type of
design pattern comes under structural pattern.
• In Proxy pattern, we create object having original object to interface its functionality
to outer world
Intent
• Provide a surrogate or placeholder for another object to control access to it.
Also Known As
• Surrogate
Applicability:
1. A remote proxy provides a local representative for an object in a different
address space. NEXTSTEP [Add94] uses the class NXProxy for this purpose.
2. virtual proxy creates expensive objects on demand. The ImageProxy
described in the Motivation is an example of such a proxy.
CLASS DIAGRAM:

35 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

AIM15: Using UML design Visitor Design pattern

Theory:
In Visitor pattern, we use a visitor class which changes the executing algorithm of an
element class. By this way, execution algorithm of element can vary as and when
visitor varies. This pattern comes under behavior pattern category. As per the
pattern, element object has to accept the visitor object so that visitor object handles
the operation on the element object.
Intent
Represent an operation to be performed on the elements of an object structure.
Visitor lets you define a new operation without changing the classes of the elements
on which it operates.
Applicability
Use the Visitor pattern when
an object structure contains many classes of objects with differing interfaces,
and you want to perform operations on these objects that depend
on their concrete classes.
many distinct and unrelated operations need to be performed on objects in
an object structure, and you want to avoid "polluting" their classes with these
operations. Visitor lets you keep related operations together by defining them in one
class. When the object structure is shared by many applications, use Visitor to put
operations in just those applications that need them.
the classes defining the object structure rarely change, but you often want
to define new operations over the structure. Changing the object structure classes
requires redefining the interface to all visitors, which is potentially costly. If the object
structure classes change often, then it's probably better to define the operations in
those classes.

36 Dept. Of CSE Vishnu Institute Of Technology

 Software Architecture and Design Patterns Lab 2019-2020

Class Diagram:

37 Dept. Of CSE Vishnu Institute Of Technology