UML & DESIGN PATTERNS

(BR20)
UNIT-I
1.1 What is Analysis and Design?

Analysis emphasizes an investigation of the problem and requirements, rather than a solution.
For example, if a new online trading system is desired, how will it be used? What are its functions?

Design emphasizes a conceptual solution (in software and hardware) that fulfills the requirements,
rather than its implementation.

For example, a description of a database schema and software objects.

1.2 What is Object-Oriented Analysis and Design?

Definition: OOAD is a technical method of analyzing and designing an application based on

that system’s object models (the logical components of the system that interact with one another).

During object-oriented analysis there is an emphasis on finding and describing the objects — or
concepts—in the problem domain. For example, in the case of the flight information system, some
of the concepts include Plane, Flight, and Pilot.

During object-oriented design there is an emphasis on defining software objects and how they
collaborate to fulfill the requirements.

For example, a Plane software object may have a tailNumber attribute and
a getFlightHistory method (see below fig.)

Fig. Object-orientation emphasizes representation of objects.

Finally, during implementation or object-oriented programming, design objects are implemented,

such as a Plane class in Java.

Advantages

1
UML & DESIGN PATTERNS
(BR20)
 Encourages Encapsulation:
 Easy to Understand

Disadvantages
 Not suited to Procedural Applications
 Too Complex for Simple Applications

An Example of Object – Oriented Analysis and Design: “A Dice Game”

The dice game is very simple problem, presented in order to focus on some of the steps and
artifacts in object – oriented analysis and design rather than on the problem domain.

A "dice game" in which a player rolls two dice. If the total is seven, they win; otherwise, they
lose.

Most essential and commonly used steps in OOAD:

1. Define Use Cases

Requirements analysis may include stories or scenarios of how people use the application; these
can be written as use cases. They are a popular tool in requirements analysis.
For example, here is a brief version of the Play a Dice Game use case:

Play a Dice Game: Player requests to roll the dice. System presents results: If the dice face value
totals seven, player wins; otherwise, player loses.

Use case diagram

2. Define a Domain Model

A decomposition of the problem domain involves an identification of

 Concepts
 Attributes
 Associations in the domain that are considered important.

A domain model is a visualization of the concepts of a real-world domain. Thus, it has also been
called a conceptual object model.
2
UML & DESIGN PATTERNS
(BR20)
The result can be expressed in a conceptual model, which is illustrated in a set of diagrams that
depict concepts (objects).

For example, a partial domain model is shown in fig.

Fig. Partial domain model of the dice game.

This model illustrates the concepts Player, Die, and DiceGame, with their associations and
attributes.

3. Assign Object Responsibilities and Draw Interaction Diagrams

Object - oriented design is concerned with defining logical software specifications that fulfill the
functional requirements based on decomposition by classes of objects.

An essential step in this phase is the allocation of responsibilities to objects and illustration how
they interact via messages, expressed in collaboration diagrams.

Collaboration diagrams show the flow of messages between instances and the invocation of
methods

For example, the sequence diagram which shows the flow of messages between software objects
in Fig. illustrates an OO software design, by sending messages to instances ofthe
DiceGame and Die classes. Note this illustrates a common real-world way the UML is applied: by
sketching on a whiteboard.

Fig. Sequence diagram illustrating messages between software objects.

3
UML & DESIGN PATTERNS
(BR20)
The collaboration diagram in Figure illustrates the essential step of playing by sending messages
to instances of the Player and die classes.

Fig. Collaboration diagram illustrating messages between software objects.

4. Define Design Class Diagrams

“These illustrate class definitions that are to be implemented in software”

In order to define a class, several questions must be answered

 How do objects connect to other objects?

 What are the methods of a class?

To answer these questions,For example, in the dice game, an inspection of the sequence diagram
leads to the partial design class diagram shown in Fig. Since a play message is sent to a DiceGame
object, the DiceGame class requires a play method, while class Dierequires roll and getFaceValue
method.

Fig. Partial design class diagram.

1.3 Iterative and Evolutionary Development

In this approach, development is organized into a series of short, fixed-length (for example, four
week) mini-projects called iterations. The outcome of each is a tested, integrated, and executable
system. Each iteration includes its own requirements analysis, design, implementation, and testing
activities.

The iterative lifecycle is based on the successive enlargement and refinement of a systemthrough
multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable
system.

4
UML & DESIGN PATTERNS
(BR20)
The system grows incrementally over time, iteration by iteration, and thus this approach is also
known as iterative and incremental development. See below Fig.

Benefits of iterative development include:

 Early rather than late mitigation of high risks (technical, requirements, objectives,
usability, and so forth)
 Early visible progress
 Early feedback, user engagement, and adaptation, leading to a refined system that more
closely meets the real needs of the stakeholders
 Managed complexity; the team is not overwhelmed by "analysis paralysis" or very long
and complex steps
 The learning within an iteration can be methodically used to improve the development
process itself, iteration by iteration.

1.4 The UML (Unified Modeling Language)

― The UML is language for
 visualizing,
 specifying,
 constructing, and
 documenting
the artifacts of a software-intensive system‖.

The UML offers a standard way to write a systems blueprint, including conceptual things such as
business processes and system functions as well as concrete things such as programming language
statements, database schemas, and reusable software components. (UML Specification)
 Visualizing –
o To communicate conceptual models to others is error prone unless everyone
speaks the same language. Many projects develop in their own language.

5
UML & DESIGN PATTERNS
(BR20) o There are some things that are easier to explain using models.
o The originating thoughts must be documented. They are valuable.
 Specifying – Building models that are precise, unambiguous, and complete.
 Constructing – While it is not a programming language, code can be generated from it.
 Documenting – UML helps document all parts of the software life cycle.

Three ways to apply UML

 UML as sketch: Informal and Incomplete diagrams created to explore difficult parts of
the problem or solution space
 UML as blueprint: Detailed design diagrams used either for:
o forward engineering (code generation)
o reverse engineering to visualize and better understanding existing code in UML
diagrams.
 UML as programming language: Complete executable specification of a softwaresystem
in UML. Executable code will be automatically but works only in the UML programming
language.
Three perspectives to apply UML
The UML describes diagram types, such as class diagrams and interaction diagrams. For example,
the same UML class diagram notation can be used to draw pictures of concepts in the real world
or software classes in Java. The same notation may be used for three perspectives and types of
models.
 Conceptual perspective: The diagrams are interpreted as describing things in a situation of
the real world or domain of interest.
 Specification perspective: The diagrams describe software abstractions or comp-onents with
specifications and interfaces, but no commitment to a particular implementation
 Implementation perspective: The diagrams describe software implementations in a
particular technology (such Java) .

Meaning of class in different perspectives

 Conceptual class: real-world concept or thing. The UP Domain Model contains conceptual
classes.
 Software class: a class representing a specification or implementation perspective of software
component, regardless of the process or method.
 Implementation class: a class implemented in a specific OO language such Java

1.5 The Unified Process

The Unified Process (UP), or Unified Software Development Process, is an iterative and
incremental software development framework from which a customized process can be defined.

The key characteristics of the Unified Process are:

6
UML & DESIGN PATTERNS
(BR20)
 It is an iterative and incremental development framework
 It is architecture-centric with major work being done to define and validate an
architectural design for most coding is done
 It is risk-focused and emphasizes that highest-risk factors be addressed in the earliest
deliverables possible
 It is use-case and UML driven with nearly all requirements being documented in one of
those forms. 

The Unified Process is a design framework which guides the tasks, people and products of the
design process. It is a framework because it provides the inputs and outputs of each activity, but
does not restrict how each activity must be performed.

It is comprised of a number of different hierarchical elements (See below Fig.).

 The Unified Process actually comprises low-level activities (such as finding classes).
 Activities are combined together into disciplines (formerly known as workflows) which
describe how one activity feeds into another.
 These disciplines are organized into iterations. Each iteration identifies some aspect of
the system to be considered.
 Iterations themselves are organized into phases. Phases focus on different aspects of the
design process, for example requirements, analysis, design and implementation.
 In turn phases can be grouped into cycles. Cycles focus on the generation of successive
releases of a system (for example, version 1.0, version 1.1 etc.).

Characteristics of UP
There are four key characteristics behind the Unified Process. They are:
 iterative and incremental
 use case-driven
 architecture-centric
 acknowledge risks

Iterative and Incremental

An iterative approach advocates an increasing understanding of the problem through successive
refinements and an incremental growth of an effective solution over multiple cycles. Built into the
iterative approach is the flexibility to accommodate new requirements or tactical changes in
7
UML & DESIGN PATTERNS
(BR20)
business objectives. It also allows the project to identify and resolve risks sooner rather than
later.

Use case-driven
The Unified Process is also use case-driven. The use cases help to identify who uses the system
and what they need to do with the system (i.e. the top-level functionality). Thus, use cases help
identify the primary requirements of the system. In the Unified Process use cases are used to ensure
that the evolving design is always relevant to what the user required

Architecture-Centric
One problem with having an iterative and incremental approach is that while one group may be
working on part of the implementation another group may be working on part of the design. To
ensure that all the various parts fit together there needs to be something.

Life Cycle Phases

The Unified Process is composed of four distinct phases. These four phases focus on different
aspects of the design process. The four phases are:

1. Inception
2. Elaboration
3. Construction and
4. Transition.

Inception Phase
The Inception Phase is the part of the framework. This phase defines:

 Scope of the project

 Defining the business case
 Establishes the feasibility of the system to be built. 
 Creating a vision document with core requirements, features, and constraints
 Creating an initial risk assessment
 Creating early use cases (10-20% complete, mostly use-case models) 
 Creating initial project plan and creation of one or more prototypes (especially
architectural prototypes) 

Elaboration Phase
This phase captures the functional requirements of the system. It should also specify any
non-functional requirements to ensure that they are taken into account. The other primary task for
this phase is the creation of the base line architecture to be used throughout the remainder of the
Unified Process.

Construction Phase

8
UML & DESIGN PATTERNS
(BR20)
This phase concentrates on completing the analysis of the system, performing the majority of the
design and the implementation of the system. That is, it essentially builds the product.
The specific activities of this phase include:

 The software is built, integrated, and tested

 The user manuals have been created (or updated)
 The details of the software developed are documented and ready to be provided to end
users or support staff (including changes, etc.)

Transition Phase
The transition phase moves the system into the user’s environment. This involves activities such
as deploying the system and maintaining it.
The specific activities of this phase include:
 ―beta testing‖ or ―user acceptance testing‖ by end users to validate the new software
against user expectations
 Users and maintainers of the software are fully trained. 
 The software is fully rolled-out.

Milestones
Each phase has a set of major milestones that are used to judge the progress of the overall
Unified Process. A milestone is the conclusion of a phase and comprises a set of artifacts which
are the product of the disciplines in that phase.The primary milestones (or products) of the four
phases are illustrated in Figure.

 Inception. The output of this phase is the vision for the system. This includes a very
simplified use case model and a very tentative architecture, and the most significant risks
are identified and the elaboration phase is planned.

 Elaboration. The primary output of this phase is the architecture, along with a detailed
use case model and a set of plans for the construction phase.

 Construction. The end result of this phase is the implemented product which includes the
9
UML & DESIGN PATTERNS
(BR20)software as well as the design and associated models. The product may not be without
defects, as some further work has yet to be completed in the transition phase.

 Transition. The transition phase is the last phase of a cycle. The major milestone met by
this phase is the final production-quality release of the system.

The UP Disciplines/Workflows
Each Workflow is a set of activities that various project workers perform.

Business Modeling
The Business Modeling discipline focuses on efforts to understand the organization, its
processes, and the problem domain. The discipline focuses on understanding the following
factors and how they may impact or relate to the software being considered.

 Enterprise business rules

 Enterprise business process model
 Enterprise domain model
 Enterprise mission statement
 Enterprise vision
 Organization model

Requirements
The requirements discipline in UP is like the requirements discipline in every other software
process. The main difference is that UP requirements are highly focused in the form of UML
models and Use Cases (both diagrams and descriptions).

Analysis and Design

The requirements are analyzed from a solution design perspective, rather than a requirements
analysis perspective. Specific activities that are part of this discipline include:
 Understanding and analyzing the requirements for the system
 Defining a candidate architecture for a system
 Constructing a proof-of-concept or prototype to validate a candidate architecture
 Design of components, services, and/or modules
 Design of interfaces (network, user, and databases)

Implementation
The Implementation discipline consists of coding, unit testing, and integration of the software.

Testing
The Testing discipline is focused on quality assurance of the software being released in that
cycle or iteration. It includes such activities as:
 Planning test efforts
 Creating test cases
 Running tests
 Reporting defects

10
UML & DESIGN PATTERNS
(BR20)
Deployment
The Deployment discipline is focused on planning the deployment of, and actually deploying,
the software that is being completed that cycle, phase or iteration. It includes such activities as:
 Planning the deployment
 Developing support and operations materials
 Planning alpha, beta, and pilot testing efforts
 Deploying the software
 Training end users
 Managing acceptance testing efforts

Configuration and Change Management

The Configuration and Change Management discipline is focused on track the changes and
identify the current versions of the system. This includes such activities as:
 Managing change requests
 Setting up the Change Management process and environment
 Planning configuration control
 Monitoring and reporting the configuration status
 Managing baselines and releases

Project Management
The Project Management discipline is focused on standard project management activities such
as:
 Managing project staff
 Stakeholder coordination and management
 Managing project risks
 Project estimating, planning, and scheduling
 Iteration planning

Environment
The Environment discipline is focused on supporting the overall project and development efforts
through managing environmental factors such as:
 Processes
 Standards
 Tools (hardware, software, etc.)

11
UML & DESIGN PATTERNS
(BR20)
1.6 Design Patterns
In software engineering, a design pattern is a general repeatable solution to a commonly
occurring problem in software design. A design pattern isn't a finished design that can be
transformed directly into code. It is a description or template for how to solve a problem that can
be used in many different situations.

In 1994, Four authors Erich Gamma, Richard Helm, Ralph Johnson and 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

Types of Design Patterns

There are 23 design patterns which can be classified in three categories: Creational, Structural
and Behavioral patterns.

1. Creational Patterns: These design patterns are all about class instantiation.
2. Structural Patterns: These design patterns concern class and object composition. Concept
of inheritance is used to compose interfaces and define ways to compose objects to obtain
new functionalities.
3. Behavioral Patterns: These design patterns are specifically concerned with
communication between objects.
4. J2EE Patterns: These design patterns are specifically concerned with the presentation tier.
These patterns are identified by Sun Java Center.

Creational Patterns Structural Patterns Behavioral Patterns

1. Abstract Factory 1. Adapter 1. Chain of responsibility
2. Builder 2. Bridge 2. Command

12
UML & DESIGN PATTERNS
(BR20)
3. Factory Method 3. Composite 3. Interpreter
4. Prototype 4. Decorator 4. Iterator
5. Singleton 5. Façade 5. Mediator
6. Flyweight 6. Memento
7. Proxy 7. Observer
8. State
9. Strategy
10. Template method
11. Visitor

Creational Patterns
1. Abstract Factory: Creates an instance of several families of classes
2. Builder: Separates object construction from its representation
3. Factory Method: Creates an instance of several derived classes
4. Prototype: A fully initialized instance to be copied or cloned
5. Singleton: A class of which only a single instance can exist

Structural Patterns
1. Adapter: Match interfaces of different classes
2. Bridge: Separates an object’s interface from its implementation
3. Composite: A tree structure of simple and composite objects
4. Decorator: Add responsibilities to objects dynamically
5. Façade: A single class that represents an entire subsystem
6. Flyweight: A fine-grained instance used for efficient sharing
7. Proxy: An object representing another object

Behavioral Patterns
1. Chain of responsibility: A way of passing a request between a chain of objects
2. Command: Encapsulate a command request as an object
3. Interpreter: A way to include language elements in a program
4. Iterator: Sequentially access the elements of a collection
5. Mediator: Defines simplified communication between classes
6. Memento: Capture and restore an object's internal state
7. Observer: A way of notifying change to a number of classes
8. State: Alter an object's behavior when its state changes
9. Strategy: Encapsulates an algorithm inside a class
10. Template method: Defer the exact steps of an algorithm to a subclass
11. Visitor: Defines a new operation to a class without change

Goals of Design Patterns

 To support reuse, of
o Successful designs
o Existing code !though less important"
 To facilitate software evolution
o Add new features easily, without breaking existing ones
 Design for change
 Reduce implementation dependencies between elements of software system.

13
UML & DESIGN PATTERNS
(BR20)
1.7 MVC Architecture
MVC is popularly called, is a software design pattern for developing web applications. A Model
-View-Controller pattern is made up of the following three parts:

 Model - The lowest level of the pattern which is responsible for maintaining data.
 View - This is responsible for displaying all or a portion of the data to the user. View
represents the visualization of the data that model contains.

 Controller - Software Code that controls the interactions between the Model and View.
It keeps view and model separate.

Fig. MVC Architecture

The Model-View-Controller (MVC) object-oriented architecture originally came from Smalltalk-
80 as a methodology to separate user interface presentation from the underlying data. The purpose
of MVC is to decompose the whole system into three sub-systems (modules) that are Model, View,
and Controller. It is also called a component-based architectural style.

The MVC is triad of classes is used to build user interfaces in Smalltalk-80. MVC consists of
three kinds of objects.
 The Model is the application object;
 The View is its screen presentation, and
 The Controller defines the way the user interface reacts to user input.

MVC decouples views and models by establishing a subscribe/notify protocol between them.
A view must ensure that its appearance reflects the state of the model. Whenever the model's data
changes, the model notifies views that depend on it. In response, each view gets anopportunity to
update itself. This approach lets you attach multiple views to a model to provide different
presentations.

The following diagram shows a model and three views. The model contains some data values,
and the views defining a spreadsheet, histogram, and pie chart display these data in
14
UML & DESIGN PATTERNS
(BR20)ways. The model communicates with its views when its values change, and the views
various
communicate with the model to access these values.

A Simple MVC Example in Java

The following example illustrates a simple implementation of MVC architecture in Java where
there is only one Java class in each of the three modules in the MVC architecture.

 The MyBean JavaBean class plays the role of model

 MyServlet Servlet class plays the role of controller and
 The fromServlet JSP plays a role of view in the MVC architecture.

Below fig. shows the architecture diagram of this Web application.

Fig. A simple example of MVC architecture

This example emphasizes the MVC so we omit the user input interfaces. The myServlet Servlet set
a username and stores this name in a JavaBean named myBean, then transfers the control to a JSP
page named fromServlet.jsp which retrieves the username from the myBean and displays ona Web
page.

15