Spiral Model

The spiral model, initially proposed by Boehm, is an evolutionary software process model that
couples the iterative feature of prototyping with the controlled and systematic aspects of the
linear sequential model. It implements the potential for rapid development of new versions of the
software. Using the spiral model, the software is developed in a series of incremental releases.
During the early iterations, the additional release may be a paper model or prototype. During
later iterations, more and more complete versions of the engineered system are produced.

Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification of purpose for that cycle,
the various alternatives that are possible for achieving the targets, and the constraints that exists.
Risk Assessment and reduction: The next phase in the cycle is to calculate these various
alternatives based on the goals and constraints. The focus of evaluation in this stage is located on
the risk perception for the project.

Development and validation: The next phase is to develop strategies that resolve uncertainties
and risks. This process may include activities such as benchmarking, simulation, and
prototyping.

Planning: Finally, the next step is planned. The project is reviewed, and a choice made whether
to continue with a further period of the spiral. If it is determined to keep, plans are drawn up for
the next step of the project.

The development phase depends on the remaining risks. For example, if performance or user-
interface risks are treated more essential than the program development risks, the next phase may
be an evolutionary development that includes developing a more detailed prototype for solving
the risks.

The risk-driven feature of the spiral model allows it to accommodate any mixture of a
specification-oriented, prototype-oriented, simulation-oriented, or another type of approach. An
essential element of the model is that each period of the spiral is completed by a review that
includes all the products developed during that cycle, including plans for the next cycle. The
spiral model works for development as well as enhancement projects.

When to use Spiral Model?

o When deliverance is required to be frequent.
o When the project is large
o When requirements are unclear and complex
o When changes may require at any time
o Large and high budget projects

Advantages
o High amount of risk analysis
o Useful for large and mission-critical projects.

Disadvantages
o Can be a costly model to use.
o Risk analysis needed highly particular expertise
o Doesn't work well for smaller projects.
Waterfall model
Winston Royce introduced the Waterfall Model in 1970.This model has five phases:
Requirements analysis and specification, design, implementation, and unit testing, integration
and system testing, and operation and maintenance. The steps always follow in this order and do
not overlap. The developer must complete every phase before the next phase begins. This model
is named "Waterfall Model", because its diagrammatic representation resembles a cascade of
waterfalls.

1. Requirements analysis and specification phase: The aim of this phase is to understand the
exact requirements of the customer and to document them properly. Both the customer and the
software developer work together so as to document all the functions, performance, and
interfacing requirement of the software. It describes the "what" of the system to be produced and
not "how."In this phase, a large document called Software Requirement Specification
(SRS) document is created which contained a detailed description of what the system will do in
the common language.

2. Design Phase: This phase aims to transform the requirements gathered in the SRS into a
suitable form which permits further coding in a programming language. It defines the overall
software architecture together with high level and detailed design. All this work is documented
as a Software Design Document (SDD).
3. Implementation and unit testing: During this phase, design is implemented. If the SDD is
complete, the implementation or coding phase proceeds smoothly, because all the information
needed by software developers is contained in the SDD.

During testing, the code is thoroughly examined and modified. Small modules are tested in
isolation initially. After that these modules are tested by writing some overhead code to check
the interaction between these modules and the flow of intermediate output.

4. Integration and System Testing: This phase is highly crucial as the quality of the end
product is determined by the effectiveness of the testing carried out. The better output will lead
to satisfied customers, lower maintenance costs, and accurate results. Unit testing determines the
efficiency of individual modules. However, in this phase, the modules are tested for their
interactions with each other and with the system.

5. Operation and maintenance phase: Maintenance is the task performed by every user once
the software has been delivered to the customer, installed, and operational.

When to use SDLC Waterfall Model?

Some Circumstances where the use of the Waterfall model is most suited are:

o When the requirements are constant and not changed regularly.

o A project is short
o The situation is calm
o Where the tools and technology used is consistent and is not changing
o When resources are well prepared and are available to use.

Advantages of Waterfall model

o This model is simple to implement also the number of resources that are required for it is
minimal.
o The requirements are simple and explicitly declared; they remain unchanged during the
entire project development.
o The start and end points for each phase is fixed, which makes it easy to cover progress.
o The release date for the complete product, as well as its final cost, can be determined
before development.
o It gives easy to control and clarity for the customer due to a strict reporting system.
Disadvantages of Waterfall model
o In this model, the risk factor is higher, so this model is not suitable for more significant
and complex projects.
o This model cannot accept the changes in requirements during development.
o It becomes tough to go back to the phase. For example, if the application has now shifted
to the coding phase, and there is a change in requirement, It becomes tough to go back
and change it.
o Since the testing done at a later stage, it does not allow identifying the challenges and
risks in the earlier phase, so the risk reduction strategy is difficult to prepare.

Waterfall Model Vs Spiral Model

Both the models, Waterfall model and Spiral model are used in software development.
Waterfall model is also known as classical or linear model because it follows sequential stages
while the spiral model does not follow the sequential stages it follows the evolutionary way.
The amount of risk in waterfall model is more as compared to spiral model because the errors
or risks are identified and refined after the completion of each stages. There are some
difference between these two models waterfall and spiral model which are given below:

S.
No. Waterfall Model Spiral Model

1. The Waterfall model is simple and easy. The spiral model is a lot more complex.

The waterfall model works in a sequential While the spiral model works in the
2. method. evolutionary method.

In the waterfall model errors or risks are

identified and rectified after the completion In the spiral model errors or risks are
3. of stages. identified and rectified earlier.

While the spiral model is adopted by

4. The waterfall model is adopted by customers. developers.

The waterfall model is applicable for small While the Spiral model is used for large
5. projects. projects.
S.
No. Waterfall Model Spiral Model

While in spiral model requirements and

In waterfall model requirements and early early stage planning is necessary if
6. stage planning is necessary. required.

Flexibility to change in waterfall model is Flexibility to change in spiral model is

7. Difficult. not Difficult.

8. There is high amount risk in waterfall model. There is low amount risk in spiral model.

Waterfall model is comparatively While cost of spiral model is very

9. inexpensive. expensive.

Customer involvement is minimum in In the Spiral Model Customer

10. Waterfall Model involvement is high.

11. It requires least maintenance. It requires typical maintenance.

It is based on linear and iterative

12. It is based on linear framework type. framework type.

Testing is done after the coding phase in the Testing is done after the engineering
13. development life cycle. phase in the development cycle.

To a certain extent, reusability is

14. Reusability is extremely unlikely. possible.

Customers have control over the

Customer control over the administrator is administrator as compared to waterfall
15. very limited. model.
Defining the Object model
Object Model refers to a visual representation of software or systems’ objects, attributes, actions,
and relationships. The basic factors of an object model are classes and objects.

Object
An object is a physical component in the object-oriented domain. An object may be tangible such
as a person, car, or intangible such as a project.

Class
A class is a representation of objects. It represents a group of objects that have similar properties
and exhibit an expected behavior.

Below is an example of a class and a few objects.

Class (Car Brand) = Objects (Toyota, Subaru, Hyundai, Audi, Volkswagen)

An object model uses various diagrams to show how objects behave and perform real-world
tasks. The diagrams used include use-case diagram and sequence diagram.

The object model describes objects in object-oriented programming, object-oriented analysis,

and object-oriented design.

Understanding OOP, OOD, and OOA

Object-Oriented Programming (OOP)
OOP is a programming paradigm with a view of objects and classes. OOP incorporates
properties/attributes and functions/methods into an element called an object. These objects are
grouped into classes.

This programming style exists in programming languages such as C++, Java, JavaScript, Python,
etc. These languages help structure and organize systems and software programs quickly.

Developers use Object-Oriented Languages when creating large, complex, and actively updated
programs.

OOP is based on four principles, i.e., Encapsulation, Abstraction, Inheritance, and

Polymorphism.

1. Encapsulation: It’s the bundling of data and methods to control access into the object. It’s
also known as information/data hiding. In other words, the data is not available to the
outside world. Therefore, only those methods that are within the class can access it.
2. Abstraction: It hides implementation details while presenting the attributes to the outer
world. It reduces code complexity, hides the facts, and expose the essential parts.
For example:

A database system details how a database is created while hiding how data is stored and
maintained. The user only sees the database results on the screen.

3. Inheritance: It’s a technique of creating a new class from an existing one. A sub-class
derives features from the parent class(base class).

There are various types of inheritance in OOP:

 Single Inheritance

 Multiple Inheritance

 Hierarchical Inheritance

 Multilevel Inheritance

 Hybrid Inheritance

4. Polymorphism: The term polymorphism refers to the occurrence of something in many

forms. Objects can be represented in many forms. In other words, it means an object can
perform many functions and work differently.

For example:

A person in this scenario is the object, performing different functions, and behaving in distinct
ways. While in church, the person behaves like a follower. While in the market, a person behaves
like a customer. While in a rented house, the person behaves like a tenant. While heading an
organization, the person behaves like a boss.

Object-Oriented Analysis (OOA)

Object-Oriented Analysis assesses the system requirements. It recognizes the classes and objects
and determines the relationship between them.

The primary purpose of OOA is identifying the application domain and gathering the
requirements of the system. It mainly focuses on what the system will do rather than how it
performs the task.

There are three OOA components: Object Modeling, Dynamic Modeling, and Functional
Modeling.
 1. Object Modeling: Objects are occurrences in a class.

Object Modeling develops the constant formation of the system concerning the object.

It recognizes the objects and the relationship between them. It identifies the attributes and
functions of each class.

2. Dynamic Modeling: It explains how objects respond to events.

3. Functional Modeling indicates the processes executed in an object and how data changes
when it moves to objects.

Object-Oriented Design (OOD)

In OOD, a system is a group of objects. It involves designing the objects, classes, and
relationships between classes.

Terms in Object-Oriented Design:

 Instance Variables: Data attributes that are specific to an object.

 Instance method: Operations that are specific to an object.
 Class Variables: Data attributes that are not specific to an object.
 Class Method: Operations that are not specific to an object.
 Constructors: A unique method that creates and initializes the objects for a class to
perform some operations.

Elements of the Object model

Here are the significant features of the object model.

Abstraction
Abstraction reduces complexity. It comes from the recognizing similarities between objects.
Abstraction takes place when the system stress details those that are important to the user. It
focuses mostly on the outside view of the object. Data is abstracted when protected by a set of
methods, and only those methods can access data in the object.

Encapsulation
Encapsulation is achieved through information hiding or data hiding to used to reduce
complexity and increase reusability. The user cannot see the inside of an object or a class, but the
object can be accessed by calling the object’s methods.

Encapsulation and Abstraction are complementary concepts. In Abstraction, the system focuses
on object behavior and functionality. Encapsulation focuses on implementation that gives rise to
action.
Hierarchy
The hierarchy shows the order in which objects in a system are put together. It also explains the
relationship between different parts of a system. Different properties and functions form a class
of the hierarchy.

A hierarchy class is composed of a base class (parent class) and derived classes (subclass). A
derived class inherits the properties of a parent class.

Through hierarchy, a class can be composed of inter-related sub-classes, that can have their sub-
classes until the smallest level of components is reached.

Here is an example of a class of hierarchy:

Image Source

In the scenario above, the vehicle is the base class. The objects car, boat, and aircraft inherit
properties of the base class (vehicle). Objects like truck and van inherit properties from the car.
Sailboat and yacht inherit from the class boat, and helicopter and blimp inherit properties from
class aircraft.

Modularity
Modularity refers to dividing a program into components or modules to reduce the problem’s
complexity. Modularity takes place on broad and powerful applications with multiple classes.

The modules help to manage complexity. Modularity focuses on implementation. Making

modularity and Encapsulation related.

Modularity can be viewed as a way of matching encapsulated abstraction into basic components.
This takes place after the partitioning of a system into modules.
Object Oriented Analysis Vs Structured Analysis.
Analysis simple means to study or examine the structure of something, elements, and system
requirements in detail, and methodical way. Structured analysis and Object-oriented analysis
both are important for software development and are analysis techniques used in software
engineering. But both are different from each other.
Structured Analysis and Object-Oriented Analysis (OOA) are two software development
methodologies that are used to design and develop software systems. While they have some
similarities, they differ in a number of key ways.

Structured Analysis:

1. Focus on processes: Structured Analysis focuses on the processes involved in a software

system, modeling them as a series of connected steps.
2. Top-down approach: Structured Analysis follows a top-down approach, breaking down
complex systems into smaller, simpler parts that can be more easily understood.
3. Data-centered: Structured Analysis focuses on the data that a software system manipulates,
modeling it as data flows between processes.
4. Emphasis on functional decomposition: Structured Analysis emphasizes the functional
decomposition of a software system into smaller, independent functions.

Object-Oriented Analysis (OOA):

1. Focus on objects: OOA focuses on the objects involved in a software system, modeling
them as instances of classes that encapsulate both data and behavior.
2. Bottom-up approach: OOA follows a bottom-up approach, building complex systems from
smaller, simpler objects that can be more easily understood.
3. Object-centered: OOA focuses on the objects that make up a software system, modeling
their relationships and interactions.
4. Emphasis on object-oriented design patterns: OOA emphasizes the reuse of objects and
object-oriented design patterns, reducing the amount of code that needs to be written and
improving the quality and consistency of the software.
In conclusion, Structured Analysis and OOA are both valuable software development
methodologies, each with its own strengths and weaknesses. The choice of which to use
depends on the particular requirements and constraints of a software project.
1. Structured Analysis :
Structured analysis is a method of development that allows and gives permission to the analyst
to understand and know about the system and all of its activities in a logical way. It is simply a
graphic that is used to specify the presentation of the application.
Example –
2. Object-Oriented Analysis :
Object-Oriented Analysis (OOA) is a technical approach generally used for analyzing and
application designing, system designing, or even business designing just by applying object-
oriented programming even with the use of visual modeling throughout the process of
development to just simply guide the stakeholder communication and quality of the product. it
is actually a process of discovery where a team of developers understands and models all the
requirements of the system.
Example –
Difference Between Structured and Object-oriented analysis :

Structured Analysis Object-Oriented Analysis

The main focus is on the process and The main focus is on data structure and real-
procedures of the system. world objects that are important.

It uses System Development Life Cycle

(SDLC) methodology for different purposes
like planning, analyzing, designing,
implementing, and supporting an It uses Incremental or Iterative methodology to
information system. refine and extend our design.

It is suitable for well-defined projects with It is suitable for large projects with changing
stable user requirements. user requirements.

Risk while using this analysis technique is Risk while using this analysis technique is low
high and reusability is also low. and reusability is also high.
 Structuring requirements include DFDs Requirement engineering includes the Use case
(Data Flow Diagram), Structured Analysis, model (find Use cases, Flow of events, Activity
ER (Entity Relationship) diagram, CFD Diagram), the Object model (find Classes and
(Control Flow Diagram), Data Dictionary, class relations, Object interaction, Object to ER
Decision table/tree, and the State transition mapping), Statechart Diagram, and deployment
diagram. diagram.

This technique is old and is not preferred

usually. This technique is new and is mostly preferred.

Advantages of Structured Analysis:

1. Clear and straightforward: Structured Analysis is a clear and straightforward methodology
that is easy to understand and implement.
2. Top-down approach: The top-down approach of Structured Analysis makes it easy to
identify the high-level functions and processes involved in a software system, and to break
them down into smaller, more manageable components.
3. Emphasis on data: Structured Analysis places a strong emphasis on the data that a software
system manipulates, making it easier to understand the relationships between data and
processes.
4. Well-suited for small to medium-sized systems: Structured Analysis is well-suited for small
to medium-sized systems, where the focus is on breaking down complex systems into
simpler, more manageable components.

Disadvantages of Structured Analysis:

1. Limited scalability: Structured Analysis is limited in its scalability, and may become
cumbersome when dealing with complex, large-scale systems.
2. Lack of object orientation: Structured Analysis does not provide the object orientation and
encapsulation benefits of OOA, making it more difficult to manage and maintain large
systems over time.
3. Limited ability to model complex relationships: Structured Analysis has a limited ability to
model complex relationships between objects, making it less suitable for modeling large,
complex systems.
Advantages of Object-Oriented Analysis (OOA):

1. Reusable code: OOA enables the creation of reusable objects and design patterns, reducing
the amount of code that needs to be written and improving the quality and consistency of
the software.
2. Scalability: OOA is more scalable than Structured Analysis, making it better suited for
large, complex systems.
3. Object orientation: OOA provides the benefits of object orientation, including
encapsulation, inheritance, and polymorphism, making it easier to manage and maintain
large systems over time.
4. Better modeling of complex relationships: OOA enables better modeling of complex
relationships between objects, making it better suited for modeling large, complex systems.

Disadvantages of Object-Oriented Analysis (OOA):

1. Steep learning curve: OOA can be more difficult to understand and implement than
Structured Analysis, especially for those who are not familiar with object-oriented
programming.
2. Bottom-up approach: The bottom-up approach of OOA can make it difficult to understand
the high-level functions and processes involved in a software system, and to break them
down into smaller, more manageable components.
3. Emphasis on objects: OOA places a strong emphasis on objects, making it more difficult to
understand the relationships between data and processes.
What is UML?
Unified Modelling Language (UML) is the set of notations,models and diagrams used when
developing object-oriented (OO) systems. UML is the industry standard OO visual modelling
language. The latest version is UML 1.4 and was formed from the coming together of three
leading software methodologists; Booch, Jacobson and Rumbaugh. UML allows the analyst
ways of describing structure, behaviour of significant parts of system and their relationships.

Unified Modeling Language (UML) is a standardized general-purpose modeling language in

the field of software engineering. The standard is managed, and was created by, the Object
Management Group. UML includes a set of graphic notation techniques to create visual models
of software-intensive systems.

The Unified Modeling Language is commonly used to visualize and construct systems which are
software intensive. Because software has become much more complex in recent years,
developers are finding it more challenging to build complex applications within short time
periods. Even when they do, these software applications are often filled with bugs, and it can
take programmers weeks to find and fix them. This is time that has been wasted, since an
approach could have been used which would have reduced the number of bugs before the
application was completed. However, it should be emphasized that UML is not limited simply
modeling software. It can also be used to build models for system engineering, business
processes, and organization structures. A special language called Systems Modeling Language
was designed to handle systems which were defined within UML 2.0. The Unified Modeling
Language is important for a number of reasons. First, it has been used as a catalyst for the
advancement of technologies which are model driven, and some of these include Model Driven
Development and Model Driven Architecture. Because an emphasis has been placed on the
importance of graphics notation, UML is proficient in meeting this demand, and it can be used to
represent behaviors, classes, and aggregation. While software developers were forced to deal
with more rudimentary issues in the past, languages like UML have now allowed them to focus
on the structure and design of their software programs. It should also be noted that UML models
can be transformed into various other representations, often without a great deal of effort. One
example of this is the ability to transform UML models into Java representations.
This transformation can be accomplished through a transformation language that is similar to
QVT. Many of these languages may be supported by OMG. The Unified Modeling Language has
a number of features and characteristics which separate it from other languages within the same
category. Many of these attributes have allowed it to be useful for developers. In this article, I
intend to show you many of these attributes, and you will then understand why the Unified
Modeling Language is one of the most powerful languages in existence today.
Unified Process
The Unified Software Development Process or Unified Process is a popular iterative and
incremental software development process framework. The best-known and extensively
documented refinement of the Unified Process is the Rational Unified Process (RUP).

Various Models in UML

It is very important to distinguish between the UML model. Different diagrams are used for
different types of UML modeling. There are three important types of UML modeling.
Structural Modeling
Structural modeling captures the static features of a system. They consist of the following −

 Classes diagrams
 Objects diagrams
 Deployment diagrams
 Package diagrams
 Composite structure diagram
 Component diagram
Structural model represents the framework for the system and this framework is the place where
all other components exist. Hence, the class diagram, component diagram and deployment
diagrams are part of structural modeling. They all represent the elements and the mechanism to
assemble them.
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 blueprint of the
entire system. Package diagram comes under architectural modeling.
OOAD: Process of object oriented software development
We know that the Object-Oriented Modelling (OOM) technique visualizes things in an
application by using models organized around objects. Any software development approach goes
through the following stages −

 Analysis,
 Design, and
 Implementation.
In object-oriented software engineering, the software developer identifies and organizes the
application in terms of object-oriented concepts, prior to their final representation in any specific
programming language or software tools.
Phases in Object-Oriented Software Development
The major phases of software development using object–oriented methodology are object-
oriented analysis, object-oriented design, and object-oriented implementation.
Object–Oriented Analysis
In this stage, the problem is formulated, user requirements are identified, and then a model is
built based upon real–world objects. The analysis produces models on how the desired system
should function and how it must be developed. The models do not include any implementation
details so that it can be understood and examined by any non–technical application expert.
Object–Oriented Design
Object-oriented design includes two main stages, namely, system design and object design.
System Design
In this stage, the complete architecture of the desired system is designed. The system is
conceived as a set of interacting subsystems that in turn is composed of a hierarchy of interacting
objects, grouped into classes. System design is done according to both the system analysis model
and the proposed system architecture. Here, the emphasis is on the objects comprising the system
rather than the processes in the system.
Object Design
In this phase, a design model is developed based on both the models developed in the system
analysis phase and the architecture designed in the system design phase. All the classes required
are identified. The designer decides whether −

 new classes are to be created from scratch,

 any existing classes can be used in their original form, or
 new classes should be inherited from the existing classes.
The associations between the identified classes are established and the hierarchies of classes are
identified. Besides, the developer designs the internal details of the classes and their associations,
i.e., the data structure for each attribute and the algorithms for the operations.
Object–Oriented Implementation and Testing
In this stage, the design model developed in the object design is translated into code in an
appropriate programming language or software tool. The databases are created and the specific
hardware requirements are ascertained. Once the code is in shape, it is tested using specialized
techniques to identify and remove the errors in the code.

What is a Pattern?
A pattern is a commonly occurring reusable piece in software system
that provides a certain set of functionality. The identification of a
pattern is also based on the context in which it is used. So, using
patterns in modeling of systems helps in keeping design standardized
and more importantly, minimizes the reinventing of the wheel in the
system design. This article is all about patterns; especially design
patterns.

How do Patterns Relate to UML?

The patterns that we encounter need to be captured and documented in a sufficiently descriptive
manner so that they can be referred for future use. UML provides the perfect tools to do just this.
The class diagram in UML can be used to capture the patterns identified in a system. In addition,
UML has a sufficiently extensive and expressive vocabulary to capture the details of patterns.

Over the previous articles in this series, we explored the different UML diagrams and learned
how to model each of the diagrams in a case study application. Building on this background we
will see how to leverage the usefulness of well-known patterns to make application designing a
lot easier.

To sum up, a pattern should have the following characteristics

 Useful solution
 Reusable
 Contextual
Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides first popularized the concept of
patterns with their book on design patterns. These authors came to be known as the “Gang Of
Four” or GOF. The name stuck ever since and the patterns catalog that they documented is
known as the GOF patterns catalog.
Design Patterns

Since a system is made up of static as well as dynamic elements, you will find patterns that can
be used for either of these types. For static elements of a system especially the architecture and
design of a system, there are design patterns – the focus of this article. The dynamic aspects of a
system are abstracted and captured as process patterns. But patterns are not limited to this.
Patterns can be abstracted for the implementation aspects of a system as well.

Based on how they are to be used, patterns are primarily categorized as:

 Creational
 Structural
 Behavioral
Creational

Creational patterns define mechanisms for instantiating objects. The implementation of the
creational pattern is responsible for managing the lifecycle of the instantiated object. A few
examples of Creational design patterns are listed below.

Factory

One of the easily recognized and frequently used design patterns is the Factory pattern. If you
have designed any object that is responsible for creating and maintaining the lifecycle of another
object, you have used the Factory pattern. Obtaining a database connection in your application
using a connection manager or connection factory object is a good example of the Factory
pattern.

Singleton

A singleton is another example of a factory pattern. What makes the Singleton pattern unique is
that one and only one instance of the object can exist irrespective of the number of times the
object is instantiated. The most common use of a Singleton pattern is for server applications like
a Java based Remote Method Invocation (RMI) server application.

Structural

The composition of objects and their organization to obtain new and varied functionality is the
underlying basis of Structural patterns. A few examples of Structural design patterns are listed
below.
Adapter

In the Adapter pattern, an object provides an implementation of an interface used by other

objects in a consistent way. The adapter object wraps different disparate implementations of the
interface and presents a unified interface for other objects to access. A good example of this is a
database driver like an ODBC (Open Database Connectivity) or JDBC (Java Database
Connectivity) driver that wraps the custom database accessing implementation for different
databases and yet, presents a consistent interface that is a published and standardized API.

Proxy

A Proxy pattern constitutes use of proxy objects during object interaction. A proxy object acts as
a substitute for the actual object. Use of proxy objects is prevalent in remote object interaction
protocols. As an example, when an object needs to interact with a remote object, say across a
network, the most preferred way of encapsulating and hiding the interaction mechanism is by
using a proxy object that mediates communication between the requesting object and the remote
object.

Behavioral

Interaction between different objects is specifically covered by Behavioral patterns. Some

examples of behavioral patterns are given below.

Command

The Command pattern is commonly used for gathering requests from client objects and
packaging them into a single object for processing. The Command pattern allows for having well
defined command interfaces that are implemented by the object that provides the processing for
the client requests packaged as commands.

Iterator

A simple mechanism to traverse and access a list of objects is defined by the Iterator pattern. The
Iterator pattern encapsulates the internal implementation of the list while providing a
standardized mechanism for list traversal.

UML Tools and Design Patterns

Quite a few UML tools in the market support design patterns. Many such tools have a pre-built
catalog of well-known design patterns. With this using Creational, Structural or Behavioral
design patterns in your system is a breeze! The design patterns can be easily pulled in into your
design as templates and then customized for your application design. Some examples of UML
tools that support design patterns are Rational Rose and Together ControlCenter.

Applying Design Patterns

Now let us take a look at the Courseware Management System and see if we can identify any
possible design patterns. Our class diagram of the Courseware Management System only
captured the primary entities in the system. If we go about refining and elaborating the class
diagram we will come across a few design patterns.

One of the simplest design patterns that we can identify is the Behavioral pattern. The methods
in the classes of the Courseware Management System that return multiple results, like the
viewCourses() method of the CourseAdministrator class, will use the Iterator pattern to iterate
through the list of courses in the system.

We can identify atleast a couple of examples of Structural patterns. For instance, one component
that is not shown in the class diagram is a database accessing element that will provide database
accessing services for all the classes in the class diagram that need to interact with a data store.
All database interactions to retrieve or update information required for their business
functionality can be routed through this database access element, which acts as a bridge between
the database and the application components. This is an example of the Bridge design pattern.

If we take things to the implementation level, we can define a common interface object that is
used to package data passed between the different classes. This would help to keep the interface
between interacting classes the same while allowing for flexibility in implementation. Such a
common interface object is a good example of the ValueObject pattern that falls under the
category of Structural design pattern.