www.rejinpaul.

com
www.rejinpaul.com

CS6502 OBJECT ORIENTED ANALYSIS AND DESIGN LTPC

3003
UNIT I UML DIAGRAMS 9
Introduction to OOAD – Unified Process - UML diagrams – Use Case – Class Diagrams–
Interaction Diagrams – State Diagrams – Activity Diagrams – Package, component and
Deployment Diagrams.

UNIT II DESIGN PATTERNS 9

GRASP: Designing objects with responsibilities – Creator – Information expert – Low Coupling
– High Cohesion – Controller - Design Patterns – creational - factory method - structural –
Bridge – Adapter - behavioral – Strategy – observer.

UNIT III CASE STUDY 9

Case study – the Next Gen POS system, Inception -Use case Modeling - Relating Use cases –
include, extend and generalization - Elaboration - Domain Models - Finding conceptual classes
and description classes – Associations – Attributes – Domain model refinement – Finding
conceptual class Hierarchies - Aggregation and Composition.

UNIT IV APPLYING DESIGN PATTERNS 9

System sequence diagrams - Relationship between sequence diagrams and use cases Logical
architecture and UML package diagram – Logical architecture refinement - UML class diagrams
– UML interaction diagrams - Applying GoF design patterns.

UNIT V CODING AND TESTING 9

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

TEXT BOOK:
1. Craig Larman, "Applying UML and Patterns: An Introduction to Object-Oriented Analysis
and Design and Iterative Development”, Third Edition, Pearson Education, 2005.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

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

Introduction to OOAD

Object
An object is a real-world element in an object–oriented environment that may have a physical or
a conceptual existence. Each object has:
 Identity that distinguishes it from other objects in the system.
 State that determines the characteristic properties of an object as well as the values of the
properties that the object holds.
 Behavior that represents externally visible activities performed by an object in terms of
changes in its state.
Objects can be modelled according to the needs of the application. An object may have a
physical existence, like a customer, a car, etc.; or an intangible conceptual existence, like a
project, a process, etc.

Class
A class represents a collection of objects having same characteristic properties that exhibit
common behavior. It gives the blueprint or description of the objects that can be created from it.
Creation of an object as a member of a class is called instantiation. Thus, object is an instance of
a class.
The constituents of a class are:
 A set of attributes for the objects that are to be instantiated from the class. Generally,
different objects of a class have some difference in the values of the attributes.
Attributes are often referred as class data.
 A set of operations that portray the behavior of the objects of the class. Operations are
also referred as functions or methods.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Example
Let us consider a simple class, Circle, that represents the geometrical figure circle in a two–
dimensional space. The attributes of this class can be identified as follows:
 x–coord, to denote x–coordinate of the center
 y–coord, to denote y–coordinate of the center
 a, to denote the radius of the circle
Some of its operations can be defined as follows:
 findArea(), method to calculate area
 findCircumference(), method to calculate circumference
 scale(), method to increase or decrease the radius
During instantiation, values are assigned for at least some of the attributes. If we create an object
my_circle, we can assign values like x-coord : 2, y-coord : 3, and a : 4 to depict its state. Now, if
the operation scale() is performed on my_circle with a scaling factor of 2, the value of the
variable a will become 8. This operation brings a change in the state of my_circle, i.e., the object
has exhibited certain behavior.

Encapsulation
Encapsulation is the process of binding both attributes and methods together within a class.
Through encapsulation, the internal details of a class can be hidden from outside. It permits the
elements of the class to be accessed from outside only through the interface provided by the
class.

Data Hiding
Typically, a class is designed such that its data (attributes) can be accessed only by its class
methods and insulated from direct outside access. This process of insulating an object’s data is
called data hiding or information hiding.

Example
In the class Circle, data hiding can be incorporated by making attributes invisible from outside
the class and adding two more methods to the class for accessing class data, namely:
 setValues(), method to assign values to x-coord, y-coord, and a

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

 getValues(), method to retrieve values of x-coord, y-coord, and a

Here the private data of the object my_circle cannot be accessed directly by any method that is
not encapsulated within the class Circle. It should instead be accessed through the methods
setValues() and getValues().

Message Passing
Any application requires a number of objects interacting in a harmonious manner. Objects in a
system may communicate with each other using message passing. Suppose a system has two
objects: obj1 and obj2. The object obj1 sends a message to object obj2, if obj1 wants obj2 to
execute one of its methods.
The features of message passing are:
 Message passing between two objects is generally unidirectional.
 Message passing enables all interactions between objects.
 Message passing essentially involves invoking class methods.
 Objects in different processes can be involved in message passing.

Inheritance
Inheritance is the mechanism that permits new classes to be created out of existing classes by
extending and refining its capabilities. The existing classes are called the base classes/parent
classes/super-classes, and the new classes are called the derived classes/child classes/subclasses.
The subclass can inherit or derive the attributes and methods of the super-class(es) provided that
the super-class allows so. Besides, the subclass may add its own attributes and methods and
may modify any of the super-class methods. Inheritance defines an “is – a” relationship.

Example
From a class Mammal, a number of classes can be derived such as Human, Cat, Dog, Cow, etc.
Humans, cats, dogs, and cows all have the distinct characteristics of mammals. In addition, each
has its own particular characteristics. It can be said that a cow “is – a” mammal.
Types of Inheritance:
 Single Inheritance : A subclass derives from a single super-class.
 Multiple Inheritance : A subclass derives from more than one super-classes.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

 Multilevel Inheritance : A subclass derives from a super-class which in turn is derived

from another class and so on.
 Hierarchical Inheritance : A class has a number of subclasses each of which may have
subsequent subclasses, continuing for a number of levels, so as to form a tree structure.
 Hybrid Inheritance : A combination of multiple and multilevel inheritance so as to
form a lattice structure.
The following figure depicts the examples of different types of inheritance.

Polymorphism
Polymorphism is originally a Greek word that means the ability to take multiple forms. In
object-oriented paradigm, polymorphism implies using operations in different ways, depending
upon the instance they are operating upon. Polymorphism allows objects with different internal

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

structures to have a common external interface. Polymorphism is particularly effective while

implementing inheritance.
Example
Let us consider two classes, Circle and Square, each with a method findArea(). Though the
name and purpose of the methods in the classes are same, the internal implementation, i.e., the
procedure of calculating area is different for each class. When an object of class Circle invokes
its findArea() method, the operation finds the area of the circle without any conflict with the
findArea() method of the Square class.

Generalization and Specialization

Generalization and specialization represent a hierarchy of relationships between classes, where
subclasses inherit from super-classes.

Generalization
In the generalization process, the common characteristics of classes are combined to form a class
in a higher level of hierarchy, i.e., subclasses are combined to form a generalized super-class. It
represents an “is – a – kind – of” relationship. For example, “car is a kind of land vehicle”, or
“ship is a kind of water vehicle”.

Specialization
Specialization is the reverse process of generalization. Here, the distinguishing features of
groups of objects are used to form specialized classes from existing classes. It can be said that
the subclasses are the specialized versions of the super-class.
The following figure shows an example of generalization and specialization.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Links and Association

Link
A link represents a connection through which an object collaborates with other objects.
Rumbaugh has defined it as “a physical or conceptual connection between objects”. Through a
link, one object may invoke the methods or navigate through another object. A link depicts the
relationship between two or more objects.

Association
Association is a group of links having common structure and common behavior. Association
depicts the relationship between objects of one or more classes. A link can be defined as an
instance of an association.

Degree of an Association
Degree of an association denotes the number of classes involved in a connection. Degree may be
unary, binary, or ternary.
 A unary relationship connects objects of the same class.
 A binary relationship connects objects of two classes.
 A ternary relationship connects objects of three or more classes.

Cardinality Ratios of Associations

Cardinality of a binary association denotes the number of instances participating in an
association. There are three types of cardinality ratios, namely:
 One–to–One : A single object of class A is associated with a single object of class B.
 One–to–Many : A single object of class A is associated with many objects of class B.
 Many–to–Many : An object of class A may be associated with many objects of class B
and conversely an object of class B may be associated with many objects of class A.

Aggregation or Composition
Aggregation or composition is a relationship among classes by which a class can be made up of
any combination of objects of other classes. It allows objects to be placed directly within the

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

body of other classes. Aggregation is referred as a “part–of” or “has–a” relationship, with the
ability to navigate from the whole to its parts. An aggregate object is an object that is composed
of one or more other objects.
Example
In the relationship, “a car has–a motor”, car is the whole object or the aggregate, and the motor
is a “part–of” the car. Aggregation may denote:
 Physical containment : Example, a computer is composed of monitor, CPU, mouse,
keyboard, and so on.
 Conceptual containment : Example, shareholder has–a share.

Object Oriented Systems Development Life Cycle

Goals
 The software development process
 Building high-quality software
 Object-oriented systems development
 Use-case driven systems development
 Prototyping
 Rapid application development
 Component-based development
 Continuous testing and reusability

Software Process The essence of the software process is the transformation of

 Users‘ needs to
 The application domain into
 A software solution.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Traditional Waterfall Approach to Systems Development

Software Quality
 There are two basic approaches to systems testing.
 We can test a system according to how it has been built.
 Alternatively, we can test the system with respect to what it should do.

Quality Measures

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

 Systems can be evaluated in terms of four quality measures:

o Correspondence
o Correctness
o Verification
o Validation
 Correspondence measures how well the delivered system corresponds to the needs of the
operational environment.

It cannot be determined until the system is in place.

o Correctness measures the consistency of the product requirements with respect to the design
specification.

• Verification - "Am I building the product right?"

• Validation - "Am I building the right product?"

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

• Verification is to predict the correctness.

• Validation is to predict the correspondence.

Object-Oriented Systems Development Approach

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Object-Oriented Systems Development activities

o Object-oriented analysis.
o Object-oriented design.
o Prototyping.
o Component-based development.
o Incremental testing.

Use-case driven systems development

Use Case, is a name for a scenario to describe the user–computer system interaction.

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.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

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

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

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.

OOD activities include:

 Design and refine classes.
 Design and refine attributes.
 Design and refine methods.
 Design and refine structures.
 Design and refine associations.
 Design User Interface or View layer classes.

 Design data Access Layer classes.

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.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Prototyping
 A Prototype enables you to fully understand how easy or difficult it will be to implement
some of the features of the system.

 It can also give users a chance to comment on the usability and usefulness of the design.

Types of Prototypes
 A horizontal prototype is a simulation of the interface.

 A vertical prototype is a subset of the system features with complete functionality.

 An analysis prototype is an aid for exploring the problem domain.

 A domain prototype is an aid for the incremental development of the ultimate software
solution.

Component-based development (CBD)

o CBD is an industrialized approach to the software development process.

o Application development moves from custom development to assembly of pre-built, pre-

tested, reusable software components that operate with each other.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Rapid Application Development (RAD)

• RAD is a set of tools and techniques that can be used to build an application faster than
typically possible with traditional methods.

• RAD does not replace SDLC but complements it, since it focuses more on process description
and can be combined perfectly with the object-oriented approach.

Incremental Testing
• Software development and all of its activities including testing are an iterative process.
• If you wait until after development to test an application for bugs and performance, you could
be wasting thousands of dollars and hours of time.

Reusability A major benefit of object-oriented systems development is reusability, and this is the
most difficult promise to deliver on.

Reuse strategy
o Information hiding (encapsulation).

o Conformance to naming standards.

o Creation and administration of an object repository.
o Encouragement by strategic management of reuse as opposed to constant redevelopment.
o Establishing targets for a percentage of the objects in the project to be reused (i.e., 50
percent reuse of objects).

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

The essence of the software process is the transformation of users‘ needs into a software
solution. The O-O SDLC is an iterative process and is divided into analysis, design, prototyping/
implementation, and testing.

OBJECT ORIENTED METHODOLOGIES

Basic Definition
 A methodology is explained as the science of methods.

 A method is a set of procedures in which a specific goal is approached step by step.

 Many methodologies are available to choose from for system development.

 Here, we look at the methodologies developed by Rumbaugh et al., Booch, and Jacobson
which are the origins of the Unified Modeling Language (UML) and the bases of the UA

Strength of the Methods

 Rumbaug: Describing Object Model or the static structure of the system
 Jacobson: good for producing user-driven analysis models
 Booch: Detailed object-oriented design models

Rumbaugh Methodologies OMT (Object Modeling Technique) describes a method for the
analysis, design, and implementation of a system using an object-oriented technique. Class
attributes, method, inheritance, and association also can be expressed easily Phases of OMT
 Analysis

 System Design

 Object Design
 Implementation

OMT consists of four phases, which can be performed iteratively:

 Analysis. The results are objects and dynamic and functional models.
 System design. The result is a structure of the basic architecture of the system.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

 Object design. This phase produces a design document, consisting of detailed objects and
dynamic and functional models.
 Implementation. This activity produces reusable, extendible, and robust code.

OMT Modeling OMT separates modeling into three different parts:

 An object model, presented by the object model and the data dictionary.
 A dynamic model, presented by the state diagrams and event flow diagrams.
 A functional model, presented by data flow and constraints.

Object Modelling
Object modelling develops the static structure of the software system in terms of objects. It
identifies the objects, the classes into which the objects can be grouped into and the relationships
between the objects. It also identifies the main attributes and operations that characterize each
class.
The process of object modelling can be visualized in the following steps:

 Identify objects and group into classes

 Identify the relationships among classes
 Create user object model diagram
 Define user object attributes
 Define the operations that should be performed on the classes
 Review glossary

Dynamic Modelling
After the static behavior of the system is analyzed, its behavior with respect to time and external
changes needs to be examined. This is the purpose of dynamic modelling.
Dynamic Modelling can be defined as “a way of describing how an individual object responds
to events, either internal events triggered by other objects, or external events triggered by the
outside world”.
The process of dynamic modelling can be visualized in the following steps:

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

 Identify states of each object

 Identify events and analyze the applicability of actions
 Construct dynamic model diagram, comprising of state transition diagrams
 Express each state in terms of object attributes
 Validate the state–transition diagrams drawn

Functional Modelling
Functional Modelling is the final component of object-oriented analysis. The functional model
shows the processes that are performed within an object and how the data changes as it moves
between methods. It specifies the meaning of the operations of object modelling and the actions
of dynamic modelling. The functional model corresponds to the data flow diagram of traditional
structured analysis.
The process of functional modelling can be visualized in the following steps:

 Identify all the inputs and outputs

 Construct data flow diagrams showing functional dependencies
 State the purpose of each function
 Identify constraints
 Specify optimization criteria

Booch Methodology
 The Booch methodology covers the analysis and design phases of systems development.
 Booch sometimes is criticized for his large set of symbols.
 The Booch method consists of the following diagrams:
 Class diagrams o Object diagrams
 State transition diagrams
 Module diagrams
 Process diagrams
 Interaction diagrams

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

The Booch methodology prescribes

– A macro development process
– A micro development process.

The Macro Development Process It serves as a controlling framework for the micro process.
The primary concern is Technical Management of the System. The macro development process
consists of the following steps:
1. Conceptualization
2. Analysis and development of the model.
3. Design or create the system architecture.
4. Evolution or implementation.
5. Maintenance.

Conceptualization:
• Establish the core requirements of the system
• Establish a set of goals and develop prototype to prove the concept

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Analysis and development of the modal

o Using the class diagram to describe the roles and responsibilities objects are to carry out in
performing the desired behavior of the system
o Using the object diagram to describe the desired behavior of the system in terms of
scenarios or, alternatively
o Using the interaction diagram to describe behavior of the system in terms of scenarios

Design or create the system architecture

o Using the class diagram to decide what mechanisms are used to regulate how objects
collaborate
o Using the module diagram to map out were each class and object should be declared
o Using the process diagram to determine to which processor to allocate a process. Also,
determine the schedules for multiple processes on each relevant processor

Evolution or implementation
o Successively refine the system through many iterations
o Produce a stream of software implementations, each of which is refinement of the prior one

Maintenance
o Make localized changes to the system to add new requirements and eliminate bugs

The Micro Development Process

o The micro development process consists of the following steps:
o Identify classes and objects.
o Identify class and object semantics.
o Identify class and object relationships.
o Identify class and object interfaces and implementation.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Jacobson Methodologies The Jacobson et al. methodologies (e.g., OOBE, OOSE, and
Objectory) cover the entire life cycle and stress traceability between the different phases.

Object-Oriented Software Engineering: Objectory

o Object-oriented software engineering (OOSE), also called Objectory, is a method of object-
oriented development with the specific aim to fit the development of large, real-time
systems.
o Objectory is built around several different models:
o Use case model.
o Domain object model.
 Analysis object model. Implementation model.
o Test model

Object-Oriented Business Engineering (OOBE)

o Object-oriented business engineering (OOBE) is object modeling at the enterprise level.

o Use cases again are the central vehicle for modeling, providing traceability throughout the
software engineering processes.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

• OOBE consists of :
– Analysis phase
– Design
– Implementation phases and
– Testing phase.

Structured Analysis vs. Object Oriented Analysis

The Structured Analysis/Structured Design (SASD) approach is the traditional approach of
software development based upon the waterfall model. The phases of development of a system
using SASD are:

 Feasibility Study
 Requirement Analysis and Specification
 System Design
 Implementation
 Post-implementation Review

Advantages/Disadvantages of Object Oriented Analysis

Advantages Disadvantages

Focuses on data rather than the Functionality is restricted within objects.

procedures as in Structured Analysis. This may pose a problem for systems
which are intrinsically procedural or
computational in nature.

The principles of encapsulation and It cannot identify which objects would

data hiding help the developer to generate an optimal system design.
develop systems that cannot be
tampered by other parts of the system.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

The principles of encapsulation and The object-oriented models do not easily

data hiding help the developer to show the communications between the
develop systems that cannot be objects in the system.
tampered by other parts of the system.

It allows effective management of All the interfaces between the objects

software complexity by the virtue of cannot be represented in a single
modularity. diagram.

It can be upgraded from small to large

systems at a greater ease than in
systems following structured analysis.

Agile Methodology

Agile SDLC model is a combination of iterative and incremental process models with focus on
process adaptability and customer satisfaction by rapid delivery of working software product.

Agile Methods break the product into small incremental builds. These builds are provided in
iterations. Each iteration typically lasts from about one to three weeks. Every iteration involves
cross functional teams working simultaneously on various areas like planning, requirements
analysis, design, coding, unit testing, and acceptance testing.

Following are the Agile Manifesto principles

 Individuals and interactions - in agile development, self-organization and motivation

are important, as are interactions like co-location and pair programming.
 Working software - Demo working software is considered the best means of
communication with the customer to understand their requirement, instead of just
depending on documentation.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

 Customer collaboration - As the requirements cannot be gathered completely in the

beginning of the project due to various factors, continuous customer interaction is very
important to get proper product requirements.
 Responding to change - agile development is focused on quick responses to change and
continuous development.

Following table lists out the pros and cons of Agile Model:

Pros Cons
 Is a very realistic approach to software  Not suitable for handling complex
development dependencies.
 Promotes teamwork and cross training.  More risk of sustainability,
 Functionality can be developed rapidly maintainability and extensibility.
and demonstrated.  An overall plan, an agile leader and
 Resource requirements are minimum. agile PM practice is a must without
 Suitable for fixed or changing which it will not work.
requirements  Strict delivery management dictates the
 Delivers early partial working solutions. scope, functionality to be delivered, and
 Good model for environments that adjustments to meet the deadlines.
change steadily.  Depends heavily on customer
 Minimal rules, documentation easily interaction, so if customer is not clear,
employed. team can be driven in the wrong
 Enables concurrent development and direction.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

delivery within an overall planned  There is very high individual

context. dependency, since there is minimum
 Little or no planning required documentation generated.
 Easy to manage  Transfer of technology to new team
 Gives flexibility to developers members may be quite challenging due
to lack of documentation.

Agile Vs Traditional SDLC Models

Agile is based on the adaptive software development methods where as the traditional
SDLC models like waterfall model is based on predictive approach. Customer interaction is the
backbone of Agile methodology, and open communication with minimum documentation are the
typical features of Agile development environment. The agile teams work in close collaboration
with each other and are most often located in the same geographical location.

Unified Process

Unified Process is a popular iterative process for projects using object oriented analysis and
design. UP make use of best practices such as iterative life cycle and risk-driver development to
provide a well documents process description.
The Unified Process supports the following
1. Evolution of project plans, requirements and software architecture with well-
defined synchronization points
2. Risk management
3. Evolution of system capabilities through demonstrations of increasing
functionality
It emphasizes the difference between engineering and production.
• Engineering Stage
• Driven by less predictable but smaller teams, focusing on design and synthesis
activities
• Production Stage

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

• Driven by more predictable but larger teams, focusing on construction, test and
deployment activities

What is a workflow?
 A set of activities that is performed by the various roles in a project
 Describes a meaningful sequence of activities that produce a useful result (an artifact)
 Shows interaction between roles
 Three key elements of each workflows:
o Artifacts
o Roles
o Activities

Artifact: A work product in a uniform representation format (natural language, UML, Java,
binary code,…)

 A piece of information that:

o Is produced, modified, or used by a process
o Defines an area of responsibility
o Is subject to version control.
 An artifact can be a model, a model element, or a document. A document can enclose
other documents.
Roles
 Represent a role that an individual may play on the project
 Responsible for producing artifacts
 Distinct from actors

Activities
 Tasks performed by people representing particular roles in order to produce artifacts

Unified Process Characteristics

Iterative and incremental

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

The Unified Process is an iterative and incremental development process. The

Elaboration, Construction and Transition phases are divided into a series of timeboxed iterations.
(The Inception phase may also be divided into iterations for a large project.) Each iteration
results in an increment, which is a release of the system that contains added or improved
functionality compared with the previous release.

Architecture-centric

The Unified Process insists that architecture sit at the heart of the project team's efforts to
shape the system. Since no single model is sufficient to cover all aspects of a system, the Unified
Process supports multiple architectural models and views. One of the most important
deliverables of the process is the executable architecture baseline which is created during the
Elaboration phase. This partial implementation of the system serves to validate the architecture
and act as a foundation for remaining development.

Risk-focused

The Unified Process requires the project team to focus on addressing the most critical risks early
in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase,
must be selected in order to ensure that the greatest risks are addressed first.

Phases in the Unified Process

The two stages of the Unified Process are decomposed into four distinct phases

• Engineering stage

• Inception phase - Define the scope of project

• Elaboration phase - Plan project, specify features, baseline architecture

• Production phase

• Construction phase - Build the product

• Transition phase - Transition the product into end user community

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

States of a Software System in the UP

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Inception Phase

Inception Phase: Objectives

• Establish the project scope

• Identify the critical use cases and scenarios

• Define acceptance criteria

• Demonstrate at least one candidate software architecture

• Estimate the cost and schedule for the project

• Define and estimate potential risks.

Inception Phase: Activities

• Formulate the scope of the project

• Capture requirements

• Result: problem space and acceptance criteria are defined

• Design the software architecture

• Evaluate design trade-offs, investigate solution space

• Result: Feasibility of at least one candidate architecture is explored, initial set of

build vs. buy decisions

• Plan and prepare a business case

• Evaluate alternatives for risks, staffing problems, plans.

Inception Phase: Artifacts

► Vision: The project's core requirements, key features, and main constraints are
documented. Stakeholders …

► Glossary: defines important terms used by the project.

► Business Case: provides the necessary information from a business standpoint to

determine whether or not this project is worth investing in.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

► Software Development Plan: all information required to manage the project. (Risk, time
and durations, needed tools, changes, documentations)

► Use-case model: a model of the system's intended functions and its environment, and
serves as a contract between the customer and the developers.

Inception Phase: Evaluation Criteria

• Do all stakeholders concur on the scope definition and cost and schedule estimates?

• Are the requirements understood, are the critical use cases adequately modeled?

• Is the software architecture understood?

• Are cost, schedule estimates, priorities, risks and development processes credible?

• Is there a prototype that helps in evaluating the criteria?

Elaboration Phase

Elaboration Phase: Objectives

• Baseline the software architecture

• Establish a configuration management plan in which all changes are tracked and
maintained

• Baseline the problem statement

• Base line the software project management plan for the construction phase

• Demonstrate that the architecture supports the requirements at a reasonable cost in a

reasonable time

Question: Why does the Unified process not recommend the establishment of a configuration
management plan during the inception phase?

Elaboration Phase: Activities

• Elaborate the problem statement (“vision”) by working out the critical use cases that
drive technical and managerial decisions.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

• Elaborate the infrastructure.

• Tailor the software process for the construction stage, identify tools.

• Establish intermediate milestones and evaluation criteria for these milestones.

• Identify buy/build (“make/buy”) problems and make decisions.

• Identify lessons learned from the inception phase to redesign the software architecture if
necessary (“always necessary”:-)

Elaboration Phase: Artifacts

► Software Architecture Document: provides a comprehensive architectural overview of

the system, using a number of different architectural views to depict different aspects of
the system.

► Prototypes: One or more executable architectural prototypes have been created to

explore critical functionality and architecturally significant scenarios.

► Design model: an object model describing the realization of use cases, and serves as an
abstraction of the implementation model and its source code.

► Data model: a subset of the implementation model which describes the logical and
physical representation of persistent data in the system.

► Testing Mechanisms and refining previous Iteration’s artifacts.

Elaboration Phase: Evaluation Criteria

• Apply the following questions to the results of the inception phase:

• Is the problem statement stable?

• Is the architecture stable?

• Does the executable demonstration show that the major risk elements have been
addressed and credibly resolved?

• Is the construction plan credible? By what claims is it backed up?

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

• Do all stakeholders (project participants) agree that the vision expressed in the
problem can be met if the current plan is executed?

• Are actual resource expenditures versus planned expenditures so far acceptable?

Construction Phase

Construction Phase: Objectives

• Minimize development costs by optimizing resources

• Achieve adequate quality as rapidly as practical

• Achieve useful version (alpha, beta, and other test releases) as soon as possible

Construction Phase: Activities

• Resource management, control and process optimization

• Complete component development and testing against evaluation criteria

• Assessment of product releases against acceptance criteria

Construction Phase: Activities

► The System: The executable system itself, ready to begin "beta" testing.

► Training materials: the material that is used in training programs or courses to assist the
end-users with product use, operation and/or maintenance.

► Testing results and refining previous Iteration’s artifacts.

Construction Phase: Evaluation Criteria

• Apply the following questions to the results of the construction phase:

• Is the product baseline mature enough to be deployed in the user community?

• Existing faults are not obstacles to do the release

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

• Is the product baseline stable enough to be deployed in the user community?

• Pending changes are not obstacles to do the release

• Are the stakeholders ready for the transition of the software system to the user
community?

• Are actual resource expenditures versus planned expenditures so far acceptable?

Transition Phase

• The transition phase is entered when a baseline is mature

• A usable subset of the system has been built with acceptable quality levels and
user documents

• It can be deployed to the user community

• For some projects the transition phase means the starting point for another version of the
software system

• For other projects the transition phase means the complete delivery of the software
system to a third party responsible for operation, maintenance and enhancement.

Transition Phase: Objectives

• Achieve independence of user (users can support themselves)

• Deployment baseline is complete and consistent with the criteria in the project agreement

• The final baseline can be built as rapidly and cost-effectively as possible.

Transition Phase: Activities

• Synchronization and integration of concurrent development increments into one

consistent deployment baseline

• Commercial packaging and production

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

• Sales rollout kit development

• Field personnel training

• Test of deployment baseline against the acceptance criteria.

Transition Phase: Activities

► Product.

► Release Notes: identify changes and known bugs in a version of a build or deployment
unit that has been made available for use.

► Installation Artifacts: refer to the software and documented instructions required to

install the product.

► End-User Support Material: Materials that assist the end-user in learning, using,
operating and maintaining the product.

► Testing results and refining previous Iteration’s artifacts.

Transition Phase: Evaluation Criteria

• Is the user satisfied?

• Are actual resource expenditures versus planned expenditures so far acceptable?

Iterations in the Unified Process

• Each of the four phases introduced so far (inception, elaboration, construction, transition)
consists of one or more iterations

• An iteration represents a set of activities for which there is a milestone (“well-defined

intermediate event”)

• The scope and results of the iteration are captured via work products (called
artifacts in the UP).

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Phase vs. Iteration

• A phase creates a formal, stake-holder approved version of artifacts

• It leads to a “major milestone”

• Phase to phase transition:

• triggered by a significant business decision (not by the completion of a

software development activity)

• An iteration creates an informal, internally controlled version of artifacts

• It leads to a “minor milestone”

• Iteration to iteration transition:

• Triggered by a specific software development activity.

Artifact Sets in the Unified Process

• Artifact: A work product in a uniform representation format (natural language, UML,

Java, binary code,…)

• Artifact set:

• A set of artifacts developed and reviewed as a single entity

• The Unified Process distinguishes five artifact sets

• Management set

• Requirements set

• Design set

• Implementation set

• Deployment set

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Artifact Sets in the Unified Process

Life-cycle Focus on Artifact Sets

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Rational Unified Process(RUP)

Overview

Rational Unified Process

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

The Unified Approach

• The idea behind the UA is not to introduce yet another methodology.

• The main motivation here is to combine the best practices, processes, methodologies, and
guidelines along with UML notations and diagrams.

The Unified Approach (UA)

The unified approach to software development revolves around (but is not limited to) the
following processes and components.

The UA processes are:

 Use-case driven development.

 Object-oriented analysis.

 Object-oriented design.

 Incremental development and prototyping.

 Continuous testing.

UA Methods and Technology

 Unified modeling language (UML) used for modeling.
 Layered approach.
 Repository for object-oriented system development patterns and frameworks.
 Promoting Component-based development.

UA Object-Oriented Analysis: Use-Case Driven

 The use-case model captures the user requirements.

 The objects found during analysis lead us to model the classes.

 The interaction between objects provide a map for the design phase to model the
relationships and designing classes.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

UA Object-Oriented Design
 Booch provides the most comprehensive object-oriented design method.

 However, Booch methods can be somewhat imposing to learn and especially tricky to
figure out where to start.

 UA realizes this by combining Jacobson et al.'s analysis with Booch's design concept to
create a comprehensive design process.

Iterative Development and Continuous Testing

The UA encourages the integration of testing plans from day 1 of the project. Usage scenarios or
Use Cases can become test scenarios; therefore, use cases will drive the usability testing.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

The Layered Approach to Software Development Most systems developed with today's CASE
tools or client-server application development environments tend to lean toward what is known
as two-layered architecture: interface and data.

Two-Layer Architecture
In a two-layer system, user interface screens are tied directly to the data through routines that sit
directly behind the screens

Problem with the Two-Layer Architecture This approach results in objects that are very
specialized and cannot be reused easily in other projects.
Three-Layer Architecture Your objects are completely independent of how:
.

User Interface layer This layer is typically responsible for two major aspects of the applications:
Data Workstation Owner Name Title Address
• Responding to user interaction

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

• Displaying business objects.

Business Layer
 The responsibilities of the business layer are very straight- forward:
 model the objects of the business and how they interact to accomplish the business
processes.

Unified Modelling Language (UML)

Introduction to Modelling
 Describing a system at a high level of abstraction
o A model of the system
o Used for requirements and specifications
o Is it necessary to model software systems?

Object Oriented Modelling

Unified Modelling Language (UML)

 UML stands for “Unified Modeling Language”
 It is a industry-standard graphical language for specifying, visualizing, constructing, and
documenting the artifacts of software systems
 The UML uses mostly graphical notations to express the OO analysis and design of
software projects.
 Simplifies the complex process of software design

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Why UML for Modelling

 Use graphical notation to communicate more clearly than natural language (imprecise)
and code(too detailed).
 Help acquire an overall view of a system.
 UML is not dependent on any one language or technology.
 UML moves us from fragmentation to standardization.

History of UML

Types of UML Diagrams

UML Diagram
Types

Structural Diagrams Behavioral

Diagrams

Composite Structure Deployment Diagram State Diagram Use Case Diagram

Diagram
Activity Diagram Timing
Package Diagram Class Diagram Diagram
Interaction
Diagram Sequence Diagram
Object Diagram Component Diagram
Structural Diagrams
Communication
Profile Diagram Diagram

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

- Structure diagrams emphasize on the things that must be present in the system being modeled.
- Since structure diagrams represent the structure, they are used extensively in documenting the
software architecture of software systems.

Behavioural Diagrams
- Behavior diagrams emphasize on what must happen in the system being modeled.
- Since behavior diagrams illustrate the behavior of a system, they are used extensively to
describe the functionality of software systems.

USE CASE DIAGRAM

o A use case diagram describes how a system interacts with outside actors.
o It is a graphical representation of the interaction among the elements and system.
o Each use case representation a piece of functionality that a system provides to its user.
o Use case identifies the functionality of a system.
o A use case diagram contains four components.
 The boundary, which defines the system of interest in relation to the world around it.
 The actors, usually individuals involved with the system defined according to their
roles.
 The use cases, which the specific roles are played by the actors within and around the
system.
 The relationships between and among the actors and the use cases.

Purpose:
o The main purpose of the use case diagram is to capture the dynamic aspect of a system.
o Use case diagram shows, what software is suppose to do from user point of view.
o It describes the behavior of system from user’s point.
o It provides functional description of system and its major processes.
o Use case diagram defines the scope of the system you are building.

When to Use: Use Cases Diagrams

o Use cases are used in almost every project.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

o They are helpful in exposing requirements and planning the project.

o During the initial stage of a project most use cases should be defined.

Sample Use Case Diagram

CLASS DIAGRAM
Introduction
o The class diagram is a static diagram.
o A class model captures the static structure of a system by characterizing the objects in the
system, the relationship between the objects, and the attributes and operations for each class
of objects.
o The class diagram can be mapped directly with object oriented languages.
o The class model is the most important among the three models.
o Class diagram provide a graphical notation for modeling classes and their relationship.

Purpose
o Analysis and design of the static view of an application.
o Describe responsibilities of a system.
o Base for component and deployment diagrams.

When to use: Class Diagram

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

o Useful for Forward and Reverse engineering.

o Class diagrams are useful both for abstract modeling and for designing actual programs.
o Developer uses class diagram for implementation decision.

Sample Class Diagram

STATE CHART DIAGRAM

Introduction
 A state diagram is a graph in which nodes correspond to states and directed arcs correspond
to transitions labeled with event names.
 A state diagram combines states and events in the form of a network to model all possible
object states during its life cycle, helping to visualize how an object responds to different
stimuli.
o A state diagram is a graph whose nodes are states and whose directed arcs are transitions
between states.
o A state diagram specifies the state sequence caused by event sequence.

Purpose

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

o The state model describes those aspects of objects concerned with time and the sequencing
of operations events that mark changes, states that define the context for events, and the
organization of events and states.
o They are used to give an abstract description of the behavior of a system.
o It provides direction and guidance to the individual counties within the states.
o It specifies the possible states, what transitions are allowed between states.
o It describes the common behavior for the objects in a class and each object changes its
behavior from one state to another.

When to use: State Diagram

o They are perfectly useful to model behavior in real time system.
o Each state represents a named condition during the life of an object during which it satisfies
some condition or waits for some event.
o It determines how objects of that class react to events.
o For each object state, it determines what actions the object will perform when it receives an
event.

Sample State Diagram

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

INTERACTION DIAGRAM
This interactive behaviour is represented in UML by two diagrams known as
 Sequence Diagram
 Collaboration Diagram

SEQUENCE DIAGRAM (INTERACTION DIAGRAM)

Introduction
o Sequence diagrams model the dynamic aspects of a software system.
o The emphasis is on the “sequence” of messages rather than relationship between objects.
o A sequence diagram maps the flow of logic or flow of control within a usage scenario into a
visual diagram enabling the software architect to both document and validate the logic
during the analysis and design stages.
o Sequence diagrams provide more detail and show the message exchanged among a set of
objects over time.

Purpose
o The main purpose of this diagram is to represent how different business objects interact.
o A sequence diagram shows object interactions arranged in time sequence.
o It depicts the objects and classes involved in the scenario and the sequence of messages
exchanged between the objects needed to carry out the functionality of the scenario.

When to use: Sequence Diagram

o Sequence diagram can be a helpful modeling tool when the dynamic behavior of objects
needs to be observed in a particular use case or when there is a need for visualizing the “big
picture of message flow”.
o A company’s technical staff could utilize sequence diagrams in order to document the
behavior of a future system.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Sample Sequence Diagram

COLLABORATION DIAGRAM (INTERACTION DIAGRAM)

The second interaction diagram is collaboration diagram. It shows the object organization as
shown below. Here in collaboration diagram the method call sequence is indicated by some
numbering technique as shown below. The number indicates how the methods are called one
after another. We have taken the same order management system to describe the collaboration
diagram. The method calls are similar to that of a sequence diagram. But the difference is that
the sequence diagram does not describe the object organization where as the collaboration
diagram shows the object organization.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

ACTIVITY DIAGRAM
Introduction
o An activity diagram is a type of flow chart with additional support for parallel behavior.
o This diagram explains overall flow of control.
o Activity diagram is another important diagram in UML to describe dynamic aspects of the
system.
o Activity diagram is basically a flow chart to represent the flow from one activity to another
activity

Purpose
o Contrary to use case diagrams, in activity diagrams it is obvious whether actors can perform
business use cases together or independently from one another.
o Activity diagrams allow you to think functionally.

When to use : Activity Diagrams

o Activity diagrams are most useful when modeling the parallel behavior of a multithreaded
system or when documenting the logic of a business process.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

o Because it is possible to explicitly describe parallel events, the activity diagram is well suited
for the illustration of business processes, since business processes rarely occur in a linear
manner and often exhibit parallelisms.
o This diagram is useful to investigate business requirements at a later stage.

Sample Activity Diagram

DEPLOYMENT DIAGRAM

Deployment diagrams are used to visualize the topology of the physical components of a system
where the software components are deployed. So deployment diagrams are used to describe the
static deployment view of a system. Deployment diagrams consist of nodes and their
relationships.

Purpose:
The purpose of deployment diagrams can be described as:

 Visualize hardware topology of a system.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

 Describe the hardware components used to deploy software components.

 Describe runtime processing nodes.

How to draw Deployment Diagram?

Deployment diagram represents the deployment view of a system. It is related to the component
diagram. Because the components are deployed using the deployment diagrams. A deployment
diagram consists of nodes. Nodes are nothing but physical hardwares used to deploy the
application.

Deployment diagrams are useful for system engineers. An efficient deployment diagram is very
important because it controls the following parameters

 Performance

 Scalability

 Maintainability

 Portability

So before drawing a deployment diagram the following artifacts should be identified:

 Nodes

 Relationships among nodes

The following deployment diagram is a sample to give an idea of the deployment view of order
management system. Here we have shown nodes as:

 Monitor

 Modem

 Caching server

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

 Server

The application is assumed to be a web based application which is deployed in a clustered

environment using server 1, server 2 and server 3. The user is connecting to the application
using internet. The control is flowing from the caching server to the clustered environment.

So the following deployment diagram has been drawn considering all the points mentioned
above:

Where to use Deployment Diagrams?

Deployment diagrams are mainly used by system engineers. These diagrams are used to
describe the physical components (hardwares), their distribution and association.

So the usage of deployment diagrams can be described as follows:

 To model the hardware topology of a system.

 To model embedded system.

 To model hardware details for a client/server system.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

 To model hardware details of a distributed application.

 Forward and reverse engineering.

COMPONENT DIAGRAM

Component diagrams are different in terms of nature and behaviour. Component diagrams are
used to model physical aspects of a system.

Purpose:
Component diagram is a special kind of diagram in UML. The purpose is also different from all
other diagrams discussed so far. It does not describe the functionality of the system but it
describes the components used to make those functionalities.

So from that point component diagrams are used to visualize the physical components in a
system. These components are libraries, packages, files etc. Component diagrams can also be
described as a static implementation view of a system. Static implementation represents the
organization of the components at a particular moment.

A single component diagram cannot represent the entire system but a collection of diagrams are
used to represent the whole.

So the purpose of the component diagram can be summarized as:

 Visualize the components of a system.

 Construct executables by using forward and reverse engineering.

 Describe the organization and relationships of the components.

How to draw Component Diagram?

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Component diagrams are used to describe the physical artifacts of a system. This artifact
includes files, executables, libraries etc. So the purpose of this diagram is different, Component
diagrams are used during the implementation phase of an application.

So the following component diagram has been drawn considering all the points mentioned
above:

Where to use Component Diagrams?

Component diagrams are very important from implementation perspective. So the
implementation team of an application should have a proper knowledge of the component
details.

OBJECT DIAGRAM

Object diagrams are derived from class diagrams so object diagrams are dependent upon class
diagrams. Object diagrams represent an instance of a class diagram. The basic concepts are
similar for class diagrams and object diagrams. Object diagrams also represent the static view of
a system but this static view is a snapshot of the system at a particular moment. Object diagrams
are used to render a set of objects and their relationships as an instance.

Purpose:

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

The purpose of the object diagram can be summarized as:

 Forward and reverse engineering.

 Object relationships of a system

 Static view of an interaction.

 Understand object behaviour and their relationship from practical perspective

How to draw Object Diagram?

 First, analyze the system and decide which instances are having important data and
association.

 Second, consider only those instances which will cover the functionality.

 Third, make some optimization as the numbers of instances are unlimited.

The following diagram is an example of an object diagram. It represents theOrder management

system which we have discussed in Class Diagram. The following diagram is an instance of the
system at a particular time of purchase. It has the following objects

 Customer

 Order

 SpecialOrder

 NormalOrder

Now the customer object (C) is associated with three order objects (O1, O2 and O3). These
order objects are associated with special order and normal order objects (S1, S2 and N1). The
customer is having the following three orders with different numbers (12, 32 and 40) for the
particular time considered. Now the customer can increase number of orders in future and in
that scenario the object diagram will reflect that. If order, special order and normal order objects

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

are observed then you will find that they are having some values. For orders the values are 12,
32, and 40 which implies that the objects are having these values for the particular moment
(here the particular time when the purchase is made is considered as the moment) when the
instance is captured. The same is for special order and normal order objects which are having
number of orders as 20, 30 and 60. If a different time of purchase is considered then these
values will change accordingly. So the following object diagram has been drawn considering all
the points mentioned above:

Where to use Object Diagrams?

Object diagrams can be imagined as the snapshot of a running system at a particular moment.
Now to clarify it we can take an example of a running train.

Object diagrams are used for:

 Making the prototype of a system.

 Reverse engineering.

 Modeling complex data structures.

 Understanding the system from practical perspective.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

PACKAGE DIAGRAM

• A package is used to group elements, and provides a namespace for the grouped
elements. A package is a namespace for its members, and may contain other packages.

• Owned members of a package should all be package elements.

• Package can also be merge with other package, thus provide the hierarchical organization
of the package.

• The elements that can be referred to within a package using non-qualified names are:
Owned Element, Imported Element, and elements enclosing namespaces.

• Owned and imported elements may have a visibility that determines whether they are
available outside the package.

• Package Member are not shown inside the package.

• Package org.hibernate

• Package org.hibernate contains SessionFactory and Session.

• Package Member are shown inside the package.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

• Members of the package may be shown outside of the package by branching lines.

• Package org.hibernate contains interfaces Session and SessionFactory.

• Packages are useful for simplify this kind of diagrams

• Nested packages.

• Qualifier for Graphics class is Java::Utilities::Graphics

• Visibility of Owned and Import element.

• "+" for public and "-" for private or helper class.

• All elements of Library Domain package are public except for Account.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

• Packageable element is a named element that may be owned directly by a package.

• Owned member of the package should all be packageable elements.

• If a package is removed from the model, so are all the elements owned by the package.
Package by itself is packageable element, so any package could be also a member of the
other packages.

Relationships in Package Diagram

• Dependency

• Generalization

• Refinement

Dependency

• One Package depends on another package.

Fish depends on water.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Generalization

Fish is a kind of Animal

Refinement

• Refinement shows different kind of relationship between packages.

• One Package refines another package, if it contains same elements but offers more
details about those elements.

Package Import

• Private import of Presentation package and public import of Domain package.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Package Merge

• A package merge is a directed relationship between two packages.

• It indicates that content of one package is extended by the contents of another package.

• Package merge used when elements defined in different packages have the same name
and are intended to represent the same concept.

• Package merge is shown using a dashed line with an open arrowhead pointing from the
receiving package to the merged package.

Model

• Model is a package which captures a view of a system.

• View of the system defined by its purpose and abstraction level.

• Model is notated using the ordinary package symbol (a folder icon) with a small triangle
in the upper right corner of the large rectangle.

Business layer model:

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

• If contents of the model are shown within the large rectangle, the triangle may be drawn
to the right of the model name in the tab.

• Service Layer model contains service interfaces and message types.

Package Relationship

• A relationship between two packages is called a package dependency.

• Dependencies are not transitive.

• The dependency relationship between packages is consistent with the associative

relationship between classes.

• Ex. If changing the contents of a package, P2, affects the contents of another package,
P1, we can say that P1 has a Package Dependency on P2.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Examples of Package Diagram

Use Case Package Diagram

Class Package Diagram

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

When to Use Package Diagram

• A large complex project can hundred of classes. Without some way to organization
those classes. It becomes impossible to make sense of tem all.

• Packages create a structure for you classes or other Uml element by grouping related
elements.

Use of Package Diagram

• When you want to show high level view of the system.

• To keep track of dependencies.

• With the large system to show its major element and how they relate to one another.

• To divide a complex system into module

• Package diagrams can use packages that represent the different layers of a software
system to illustrate the layered architecture of a software system.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Use Case Notation

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Class Diagram Notation

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

State Diagram Notation

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Sequence Diagram Notation

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Activity Diagram Notation

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Unit – 2

GRASP INTRODUCTION

What is Pattern?

It is common that when experts works on particular problems, they need not reinvent the wheel
i.e. they need not find a complete new solution that is completely different from existing
solutions. Rather they remember the similar problem and it solution and reuse the core of it for
solving new problem. They think in terms of “Problem Solution” pairs. Abstracting from such
pairs and churning out the commonalities leads to patterns.

Each pattern is three-part rule which expresses a relation between a certain context, a problem
and a solution.

Patterns have names and they facilitate communication- common vocabulary and understanding-
easy to remember whole concept in a nutshell.

GRASP:
Craig Larman coined these terms for the first time.
stands for General Responsibility Assignment Software Patterns.
The mnemonic meaning could be “successful OOAD (Object Oriented Analysis & Design)
requires grasping (understanding)”.
General: = Abstract i.e. widely applicable for variety of situations
Responsibility: = Obligations, duties –information object performing duty of holding
information, computational object performing duty of computation
Assignment: = Giving a responsibility to a module- capability to carry out responsibility
structure and methods
Software: = Computer code
Patterns: = Regularities, templates, abstraction
Assigning responsibilities to objects is always is major task in designing the software’s.
Specifically it’s always a challenge to decide which object carry out what job (responsibilities)
and quality of software design largely depended upon such responsibilities assignment.
Poor choices about such responsibities leads to fragile systems and components which are hard
to maintain, understand, reuse or extend.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Let’s define responsibility:

Responsibility is defined as a contract or obligation of a type or class and is related to
behavior.
There are 2 types of responsibilities
1. Knowing - responsibilities of an object include
a. Knowing about private encapsulated data-member data
b. Knowing about related objects
c. Knowing about things it can derive or calculate
2. Doing - responsibility of an object include
a. Doing something itself-assign, calculate, create
b. Initiating action in other objects
c. Controlling and coordinating activities in other objects
The responsibilities would be translated into classes and their methods and it is largely
influenced by the granularity of the responsibility. Don’t confuse the responsibility as a method
in a class even though they are implemented using methods which either act alone or collaborate
with other methods and objects. Object-oriented principles are applied by experienced
developers/experts in deciding general assignment of responsibilities.
GRASP patterns describe fundamental principles of assigning responsibilities to objects and it
has following principles and patterns in the family

 Information Expert
 Creator
 Controller
 Low Coupling
 High Cohesion
 Polymorphism
 Pure Fabrication
 Indirection
 Protected Variations.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Information Expert
Objective
To understand about the GRASP pattern “Information Expert’.

Problem: Any real world application has hundreds of classes and thousand of actions. How do I
start assigning the responsibility?

Solution: Assign a responsibility to Information Expert, the class that has information necessary
to fulfil the responsibility.”
Generally, if domain model is ready then it is pretty straight forward to assign the responsibilities
and arrive at design model.

Approach
Step I: State the responsibility clearly.
Step II: Search for the classes who have the information needed to fulfil the responsibility.
Step III: Assign the responsibility

Description
Let’s take an example of POS (Point Of Sale) systems. This is what we come across malls where
there are many POS counters. In the domain model, following classes are identified. These
classes are shown in the left part of diagram (Fig. No.1). Let’s think about some responsibility.

Who should have the responsibility of calculating the Sales Total?

Sales Total =Sum of (Unit price X quantity of sale line item)
E.g. a person is buying 2 line items, toothpaste (2 no’s) and soap (2 no’s) are being bought
Sales total = (Price of toothpaste)* (quantity of toothpaste) + (Price of soap)* (quantity of soap)

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

In the above scenario, the classes Sale, “SaleLineItem” and “ProductSpecification” has the
information such as unit price for item/ product (“ProductSpecification”), sales quantity
(“SaleLineItem”) and no. of saleLineItems (“Sale”). So the responsibility of arriving at Sales
Total needs to be assigned to all these classes. Now in this case, If the class is encapsulating data
members then maintaining these data values is the responsibility of the class and it should
provide the get and set methods for accessing such data.
Class Data Values Encapsulated Responsibility and
method
ProductDescription UnitPrice Getting the unit price
getPrice()
SaleLineItem Quantity of items and hence the Getting the Subtotal
subtotal for particular item getSubTotal()
Quantity X Unit Price
Sale No. of Saleline Items, data and Get the Total of Sales
time getTotal()
Sum of (getSubTotal() x
SaleLine item )

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

It is demonstrated in right portion of above diagram (Fig. No.1).

Following diagram depicts the assignment of responsibilities and corresponding methods.

Benefits:

 Encapsulation is maintained as objects use their own data to fulfil the task.
 Support low coupling
 Behaviour (responsibility) is distributed across the classes that have the required
information thus encouraging the highly cohesive lightweight classes
Liabilities /Contradictions:

 Sometimes while assigning responsibilities, lower level responsibilities are uncovered e.g
what the profit or loss for a particular sale?
 Not all the times the application of this pattern is desirable. Consider the responsibility of
saving such Sale to database. By the principle for this pattern, it should be the class
“Sale” to carry out this responsibility but as experienced programmer we know it is
hardly the case. The DAL (Data Access Layer) carries out this responsibilities may be by
providing methods such as SaveSale() into some controller class.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Creator
Objective
To understand the GRASP pattern “Creator”.

Problem: Who creates the new instance of some class?

Solution:
Assign class A the responsibility to create an instance of class B if….
· A aggregates (whole-part relationship) B objects
· A contains B objects
· A records instances of B objects
· A closely uses B objects
· A has initializing data that is needed while creating B objects (thus A is an expert
with respect to creating B)

Approach:
Step I: Closely look at domain/ design model and ask: who should be creating these
classes?
Step II: Search for the classes who create, aggregate etc.
Step III: Assign the responsibility of creation

Description
Let’s extend an example of POS (Point Of Sale) systems explained in previous part. This is what
we come across malls where there are many POS counters. In the domain model, following
classes are identified. These classes are shown in the left part of diagram (Fig. No.1). A class
“Register” represents the sales register. This would have details of all sales done. As the
“Register” aggregates the “Sale”, it fulfils the first criteria of the solution. Similarly the “Sale”
contains the “SaleLineItem”. Hence “Register” should create the instance of “Sale” and “Sale”
should create instance of “SaleLineItem”.
Fig. No. 1

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Table No. 1
Class Relationship with other Responsibility and
classes method
Register Contains Class “Sale” Creating an instance
createSale()
Sale Composite aggregation with Creating an instance
SaleLineItem makeSaleLineItem()

Following diagram depicts the assignment of responsibilities and corresponding methods.

Fig No. 2

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Benefits:
· Support low coupling
· The responsibility is assigned to a class which fulfils the criteria thus separating the
logic for creation and actual execution.

Liabilities /Contradictions:
· Sometimes creation may require significant complexity. Many a times there would be
tight coupling among the creator and create class. Also the task of destroying the
objects is to be thought of. Recycling of such instances (pooling) becomes important for
the performance reasons.
· In many scenarios the creations is conditional and it may be from family of classes
making it very complex.
· For creation of family of classes or to tackle the creation and recycling, other patterns
are available which are factory, abstract factory etc.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Controller
Objective
To understand the GRASP pattern “Controller”
Problem: Who should be responsible for handling a system event?
Solution: Assign the responsibility for handling a system event message to a class representing
one of the following

 A class that represents the overall system, device, or sub-system(facade controller) e.g.
Jukebox.
 A class that represents a use case within which the system event occurs
(a session controller
 or use case controller)Example: makeSaleHandler, makeSaleCoordinator, etc.
 Represents the overall business (facade controller)
 Represents something in real world that is active (role controller)

These classes often don’t do the work themselves, but delegate it to others and in other terms it
coordinates or controls the activity. The decision to create the specific controller i.e. system
controllers vs. use case controllers are often driven and influenced by the dynamics of high
cohesion vs. low coupling scenario.

Approach:
Step I: Closely look at domain/ design model and when you have family of classes doing
work/job pertaining to some specific function and would need some facilitator
e.g. if one has requirement to connect to multiple databases and has the DAL, a
CommunicationManager class can be introduced to control and manage DAL and connection to
different database

Step II: Add a new class to take the responsibility of controller or manager and all client code
would access the functionality through this class

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Description
Let’s extend an example of POS (Point Of Sale) systems explained in previous part. In the
domain model, following classes are identified. These classes are shown in the left part of
diagram (Fig. No.1). There are many system operations such as closing a sale, make payment etc
which are related to business function “Sales”.
Controller pattern gives following choices

 represents overall system

 represents the overall business
 MakeSaleHandler- an artificial handler of all system operations

Following diagram depicts the Controller pattern. Compared to Creator pattern, it has additional
class called makeSaleHandler (in fact the “Register” class shown in the article for Creator pattern
can be called as controller) which controls and coordinates the sale.
Cashier - represents some role in real-world that is active in the task
UI Form- shows the UI layer for POS software system

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Class Relationship with other Responsibility and

classes method
MakeSaleHandler Controls the“Sale” Controls and coordinates
the sale through
makeSaleLineItem()
Sale Composite aggregation with Creating an instance
SaleLineItem makeSaleLineItem()

This is an example of a use case handler which would be used to deal with all system events of a
use case, and may be used for more than one use case (e.g. for use cases “Create User” and
“Delete User”, one can have one UserController, instead of two separate controllers). In this case
the use case is “Create SaleLineItem”
If you choose use case controller,, you might want to use the some controller class for all system
in a particular use case scenario. E.g. for POS system one can have POSController through
which all system events would be routed to domain (as well as business logic) layer. In some
scenarios, the only reason for not doing so is that the class can become too complex and it
becomes better to delegate the work.
Controller is defined as the first object beyond the UI layer that receives and coordinates
("controls") a system operation (triggered by user of the system). The controller should delegate
to other objects the work that needs to be done; it should not do much work itself. The GRASP
Controller can be thought of as being a part of the Application/Service layer (assuming that the
application has made an explicit distinction between the Application/Service layer and the
Domain layer) in object-oriented systems with layered pattern implemented.
What such controller does?

o It sees to it that the messages are sent to the correct expert in the model. (e.g.
“Sale” class)
o The reason to have a controller is to separate the business model called
domain objects from the visual logic called view objects

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Once the decision to have a controller is decided, the real question is choosing which concept is
to be the controller class

o This is relatively easy as the concept that processes the system events is the
logical choice
o In the above case, cashier is really an actor the runs the posting of sale. Hence
it can’t be a controller.

The classes which represent the overall system, sub-system or devices are called as Facade
controllers and it is suitable when there are few events.
When Use-case controllers are used, there will be one controller for each use-case.
Bloated Controller: There are the controllers which handle too many system events leading to
low cohesion. This would happen when only one class is receiving all system events. These
perform many of the tasks for handling events without delegating the work and also has
significant amount of information which should have distributed to other project. Sometimes it
duplicates information found somewhere else. Such controller better be avoided and they can be
avoided by addition of few more controllers.
Design the controller in such a way that it primarily delegates the fulfillment of each system
operation to other objects.
Related Patterns: This patterns needs to be studied from the angle of understanding and
applying principle. The patterns related to this are “Low Coupling” and “High Cohesion”.

Benefits:
· Supports Low Coupling
· Promotes Understandability, maintainability
Liabilities /Contradictions:
· Sometimes grouping of responsibilities or code into one class or component to
simplify maintenance occurs when controllers are designed. This should be avoided as it
would become bloated controllers as discussed above.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Low Coupling
Objective
To understand the GRASP pattern “Low Coupling”

The principle behind this pattern is “How to support low dependency and increased
reuse?” and “How to assign the responsibilities so that the coupling is low?”
Coupling refers to connectedness or linking. It is a measure of how strongly one class is
connected to or has knowledge (information or knowhow) of or relies/depends upon the other
classes. With experience, programmers would agree on something i.e. making changes is always
been the hardest task and given a chance all would like to work upon systems from ground up.
With increased complexity in the programming world and programming languages, designing is
becoming driver for system’s overall quality and usability. Designing for low connectedness is
an important activity which can help to have a system in such a way that the changes in one
element (sub-system, system, class, etc) will limit changes to other elements. Being at extreme,
is it possible to have no coupling at all? The answer to this question is “No” as without having
any connection; a system can’t be called a system.
High coupling (high dependency, linking and connectedness) leads to

 Cascade of changes – this forces changes in related classes

 Harder to reuse its use of highly coupled elements requires the additional presence of
the classes it is dependent on
 Harder to understand in isolation

Problem: How to reduce impact of changes and encourage reuse?

Solution: Assign a responsibility so that the coupling (linking classes) remains low

Approach:
Step I: Closely look for classes with many associations to other classes.
Step II: Look for the methods that rely on a lot of other methods (or methods in other
classes i.e. dependencies
Step III: Rework the design so as assign responsibilities to different classes in such a
way that they have lesser association and dependency.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Description
Let’s extend an example of POS (Point Of Sale) systems carried in series of articles. In the
domain model, following classes like Register, Payment and Sale are identified. These classes
are shown in the left part of diagram (Fig. No.1). There are many system operations such as
closing a sale, make payment etc which are related to business function “Sales”.
Fig No. 1

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Table No. 1
Class Relationship with other Responsibility and method Remarks
classes
“Register” Creator of the “Payment” Controls and coordinates the So if Sale or payment
of Design Controls the “Sale” sale through makePayment() changes its going to
I affect the Register.
This results in tight
coupling
“Register” Controller of “Sale” and Creating an instance This results in
and “Sale” being the creator “create” division of
“Sale” of of “Payment” Controlling the Sale through responsibilities and
Design II makePayment() hence low coupling
as “Register” need
not know about the
payment.

The common forms of coupling for A to B include

· A has a data member which refers to B instance
· A has a method which B is an argument
· A is direct or indirect subclass of B
· B is an interface and A implements B

Related Patterns: The pattern related to is “High Cohesion”.

Benefits
· Maintainability -Little or not affected by changes in other components
· Understandability- simple to understand in the isolation
· Reusability- convenient to reuse and easier to grab hold of classes

Liabilities / Contradictions:
· Coupling to stable elements (classes in library or well tested classes) doesn’t account
to be a problem.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

High Cohesion
Objective
To understand the GRASP pattern “High Cohesion”
The dictionary meaning of the word “cohesion” is “the state of cohering or sticking
together”. In botany world “the process of some parts (which are generally separate) of plant
growing together” and in physics world “it’s the intermolecular force that holds together the
molecules in solid or liquid”. So this meaning would give us good forethought as what would
“High Cohesion” would mean in the context of responsibilities? As we have proceeded through
this series, we have seen principles behind assigning the responsibilities. Once they are assigned
or being assigned, an important aspect is how they are related or focused? If they are related,
sticking together or focussed, the element carrying to those responsibilities would become
bloated and result into system quite complex and harder to maintain and reuse. The principle
behind this pattern is “How to keep complexity manageable?
Cohesion can be said to a measure of “relatedness” or “how related all the attributes
and behaviour in a class are”. High cohesion refers to how strongly related the responsibilities
are.
A class with low cohesion i.e. carrying out the unrelated responsibilities in turn does so
many unrelated things or end up doing too much of a work. Such classes culminates into

 Hard to comprehend or understand

 Harder to reuse as it is tough job to segregate and mark the reusable elements
 Harder to maintain and extend

Problem: How to keep classes focused and manageable?

Solution: Assign responsibility so that cohesion remains high

Approach:
Step I: Closely look for classes with probability of many responsibilities i.e. classes with
too-few or disconnected methods.
Step II: Look for the methods which do a lot (look for method names having words like
“AND”, “OR”)

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Step III: Assign a responsibility in such a way that all the responsibilities in a class are
related

Description
Let’s extend an example of POS (Point Of Sale) systems carried in series of articles. In the
domain model, following classes like Register, Payment and Sale are identified. In the upper part
of diagram (Fig. No.1) a class “Register” is displayed carrying out many unrelated
responsibilities. There are many system operations such as closing a sale, make payment etc
which are related to business function “Sales”.
Fig No. 1

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Class Relationship with other Responsibility and method Remarks

classes
“Register” Creator of the Carries out responsibilities These are absolutely
of Design “Payment”, for adding sale, payment unrelated
I “Sale” and and also the sale line item. responsibilities
“SaleLineItem” resulting in low
cohesion
“Register” Controller of “Sale” and Creating an instance This results in
and “Sale” being the creator “create” division of
“Sale” of of “Payment” Controlling the Sale through responsibilities
Design II makePayment() according to relations
among them and
reduces the
complexity hence
high cohesion

The common examples of Low cohesion are

 System level: ATM having functionality for getting “Teller Reports” i.e. for user this
is not required and related
 Class level: An “Employee” class with a method called “getDrivingRecords()”
 Method level: The methods with having “AND”,”OR” in their names which implies
that the method is going to execute multiple functions making it difficult to reuse.
 This also applies to subsystem (package), component level. E.g. a component for
exception handling also doing job of caching.

One of the fundamental goals of an effective design is to achieve high cohesion with low
coupling.

Larman has described degree of cohesion from low to high

· Very low cohesion:- Class responsible for many things in unrelated areas

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

· Low cohesion:-Class responsible for many things in related areas

· Moderate cohesion :- Class has few responsibilities in different areas which are related
to the class but not to each other
· High Cohesion- Class has few responsibilities in one area and collaborates with other
classes to fulfill tasks

Related Patterns: This pattern is related rather complementary to “Low Coupling” and little
contradictory to information expert.

Benefits

o Understandability :- Clarity and ease of understanding design is increased

o Maintainability :- Maintenance and enhancements are simplified
o Low coupling is often supported
o Reusability :Small size classes with highly related functionality increases
reuse

Liabilities / Contradictions:
· In scenarios of server objects, it would be desirable to have less cohesive server
objects due t o performance needs. Remote objects and remote communication are the
examples where performance matters than anything else. In this case, an interface
provided for many operations would be recommended than having highly cohesive but
different interfaces/ components.
· While grouping the responsibilities or code into one class or component motivated by
maintainability from view of one person is not desirable as it would end up in
maintainability for one person but not for all. This happens when the responsibilities
could be related to class but not to each other. This is a good trap for any developer who
can never imagine there would be somebody else working on it and he/she has preferred
to keep things at one place for better traceability.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Design Patterns in Java

A design patterns are well-proved solution for solving the specific problem/task.

Now, a question will be arising in your mind what kind of specific problem? Let me explain by
taking an example.

Problem Given:

Suppose you want to create a class for which only a single instance (or object) should be created
and that single object can be used by all other classes.

Solution:
Singleton design pattern is the best solution of above specific problem. So, every design pattern
has some specification or set of rules for solving the problems. What are those specifications,
you will see later in the types of design patterns.

Advantage of design pattern:

1. They are reusable in multiple projects.

2. They provide the solutions that help to define the system architecture.
3. They capture the software engineering experiences.
4. They provide transparency to the design of an application.
5. They are well-proved and testified solutions since they have been built upon the
knowledge and experience of expert software developers.
6. Design patterns don?t guarantee an absolute solution to a problem. They provide clarity
to the system architecture and the possibility of building a better system.

When should we use the design patterns?

We must use the design patterns during the analysis and requirement phase of
SDLC(Software Development Life Cycle).

Design patterns ease the analysis and requirement phase of SDLC by providing information
based on prior hands-on experiences.

Categorization of design patterns:

Basically, design patterns are categorized into two parts:

1. Core java (or JSE) Design Patterns.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

2. JEE Design Patterns.

Core Java Design Patterns

In core java, there are mainly three types of design patterns, which are further divided into their
sub-parts:

1. Creational Design Pattern

1. Factory Pattern
2. Factory Method Pattern
3. Abstract Factory Pattern
4. Singleton Pattern
5. Prototype Pattern
6. Builder Pattern.

2. Structural Design Pattern

1. Adapter Pattern
2. Bridge Pattern
3. Composite Pattern
4. Decorator Pattern
5. Facade Pattern
6. Flyweight Pattern
7. Proxy Pattern

3. Behavioral Design Pattern

1. Chain Of Responsibility Pattern

2. Command Pattern
3. Interpreter Pattern
4. Iterator Pattern

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

5. Mediator Pattern
6. Memento Pattern
7. Observer Pattern
8. State Pattern
9. Strategy Pattern
10. Template Pattern
11. Visitor Pattern

Creational Pattern
Factory Method
Factory Method
Intent

 Define an interface for creating an object, but let subclasses decide which class to
instantiate. Factory Method lets a class defer instantiation to subclasses.

 Defining a "virtual" constructor.

 The new operator considered harmful.

Problem
A framework needs to standardize the architectural model for a range of applications, but allow
for individual applications to define their own domain objects and provide for their instantiation.

Discussion
Factory Method is to creating objects as Template Method is to implementing an algorithm. A
superclass specifies all standard and generic behavior (using pure virtual "placeholders" for
creation steps), and then delegates the creation details to subclasses that are supplied by the
client.
Factory Method makes a design more customizable and only a little more complicated. Other
design patterns require new classes, whereas Factory Method only requires a new operation.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

People often use Factory Method as the standard way to create objects; but it isn't necessary if:
the class that's instantiated never changes, or instantiation takes place in an operation that
subclasses can easily override (such as an initialization operation).
Factory Method is similar to Abstract Factory but without the emphasis on families.
Factory Methods are routinely specified by an architectural framework, and then implemented by
the user of the framework.

Structure
The implementation of Factory Method discussed in the Gang of Four (below) largely overlaps
with that of Abstract Factory. For that reason, the presentation in this chapter focuses on the
approach that has become popular since.

An increasingly popular definition of factory method is: a static method of a class that returns an
object of that class' type. But unlike a constructor, the actual object it returns might be an
instance of a subclass. Unlike a constructor, an existing object might be reused, instead of a new
object created. Unlike a constructor, factory methods can have different and more descriptive
names (e.g.Color.make_RGB_color(float red, float green, float
blue) andColor.make_HSB_color(float hue, float saturation, float brightness)

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

The client is totally decoupled from the implementation details of derived classes. Polymorphic
creation is now possible.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Example
The Factory Method defines an interface for creating objects, but lets subclasses decide which
classes to instantiate. Injection molding presses demonstrate this pattern. Manufacturers of
plastic toys process plastic molding powder, and inject the plastic into molds of the desired
shapes. The class of toy (car, action figure, etc.) is determined by the mold.

Real World Java Example for Factory Method Pattern

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

o We are going to create a Plan abstract class and concrete classes that extends the Plan
abstract class. A factory class GetPlanFactory is defined as a next step.
o GenerateBill class will use GetPlanFactory to get a Plan object. It will pass information
(DOMESTICPLAN / COMMERCIALPLAN / INSTITUTIONALPLAN) to
GetPalnFactory to get the type of object it needs.

Calculate Electricity Bill: A Real World Example of Factory Method

Step 1: Create a Plan abstract class.

import java.io.*;
abstract class Plan{
protected double rate;
abstract void getRate();

public void calculateBill(int units){

System.out.println(units*rate);
}
}//end of Plan class.

Step 2: Create the concrete classes that extends Plan abstract class.
class DomesticPlan extends Plan{
//@override
public void getRate(){
rate=3.50;
}
}//end of DomesticPlan class.
class CommercialPlan extends Plan{
//@override
public void getRate(){
rate=7.50;
}
/end of CommercialPlan class.
class InstitutionalPlan extends Plan{
//@override
public void getRate(){
rate=5.50;
}
/end of InstitutionalPlan class.

Step 3: Create a GetPlanFactory to generate object of concrete classes based on given

information..
class GetPlanFactory{

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

//use getPlan method to get object of type Plan

public Plan getPlan(String planType){
if(planType == null){
return null;
}
if(planType.equalsIgnoreCase("DOMESTICPLAN")) {
return new DomesticPlan();
}
else if(planType.equalsIgnoreCase("COMMERCIALPLAN")){
return new CommercialPlan();
}
else if(planType.equalsIgnoreCase("INSTITUTIONALPLAN")) {
return new InstitutionalPlan();
}
return null;
}
}//end of GetPlanFactory class.

Step 4: Generate Bill by using the GetPlanFactory to get the object of concrete classes by
passing an information such as type of plan DOMESTICPLAN or COMMERCIALPLAN or
INSTITUTIONALPLAN.
import java.io.*;
class GenerateBill{
public static void main(String args[])throws IOException{
GetPlanFactory planFactory = new GetPlanFactory();

System.out.print("Enter the name of plan for which the bill will be generated: ");
BufferedReader br=new BufferedReader(new InputStreamReader(System.in));

String planName=br.readLine();
System.out.print("Enter the number of units for bill will be calculated: ");
int units=Integer.parseInt(br.readLine());

Plan p = planFactory.getPlan(planName);
//call getRate() method and calculateBill()method of DomesticPaln.

System.out.print("Bill amount for "+planName+" of "+units+" units is: ");

p.getRate();
p.calculateBill(units);
}
}//end of GenerateBill class.

Download Useful Materials from Rejinpaul.com

 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

Scanned by CamScanner
Download Useful Materials from Rejinpaul.com
 www.rejinpaul.com
www.rejinpaul.com

UNIT IV - APPLYING DESIGN PATTERNS

System sequence diagrams - Relationship between sequence diagrams and use cases Logical
architecture and UML package diagram – Logical architecture refinement - UML class
diagrams - UML interaction diagrams - Applying GoF design patterns.

1. System Sequence Diagram (SSD)

SSD versus Sequence Diagram

 A System Sequence Diagram is an artifact that illustrates input and output events
related to the system under discussion.
 System Sequence Diagrams are typically associated with use-case realization in the
logical view of system development.
 Sequence Diagrams (Not System Sequence Diagrams) display object interactions
arranged in time sequence.

Sequence Diagram
 Sequence Diagrams depict the objects and classes involved in the scenario and the
sequence of messages exchanged between the objects needed to carry out the
functionality of the system.
 Sequence diagrams can be used to drive out testable user interface requirements.

SSD - System Behaviour

 System behaves as “Black Box”.

 Interior objects are not shown, as they would be on a Sequence Diagram.

: System

System Sequence Diagrams are

 Use cases describe-

 How actors interact with system.

 www.rejinpaul.com
www.rejinpaul.com

 Typical course of events that external actors generate and

 The order of the events.

 For a particular scenario of use-case an SSD shows-

 The external actors that interact directly with the system.

 The System (as a black box).

 The system events that the actors generate.

 The operations of the system in response to the events generated.

 System Sequence Diagrams depict the temporal order of the events.

 System Sequence Diagrams should be done for the main success scenario of the use-
case, and frequent and alternative scenarios.

Notations

Object:

 Objects are instances of classes. Object is represented as a rectangle which contains

the name of the object underlined.
 Because the system is instantiated, it is shown as an object.

:Object1

Actor: An Actor is modeled using the ubiquitous symbol, the stick figure.

actor 1

Lifeline: The LifeLine identifies the existence of the object over time. The notation for a
Lifeline is a vertical dotted line extending from an object.
 www.rejinpaul.com
www.rejinpaul.com

Message: Messages, modeled as horizontal arrows between Activations, indicate the

communications between objects.

messageName(argument)

Examples of SSD

 Following example shows the success scenario of the Process Sale use case.

 Events generated by cashier (actor)-

makeNewSale, enterItem, endSale and makePayment.

SSD for Process Sale Scenario

 www.rejinpaul.com
www.rejinpaul.com

2. System Sequence Diagrams and Use Cases

1. System Sequence Diagram is generated from inspection of a use case.
2. Constructing a systems sequence diagram from a use case-
a. Draw a line representing the system as a black box.
b. Identify each actor that directly operates on the system. Draw a line for each such
actor.
3. From the use case, typical course of events text, identify the system (external) events
that each actor generates. They will correspond to an entry in the right hand side of the
typical use case. Illustrate them on the diagram.

4. Optionally, include the use case text to the left of the diagram.

SSDs are derived from Use Cases

System Events and System Boundary

Identifying the System events-

1. Determine the actors that directly interact with the system.

 www.rejinpaul.com
www.rejinpaul.com

2. In the process Sale example, the customer does not directly interact with the POS
system. Cashier interacts with the system directly. Therefore cashier is the generator
of the system events.

Defining the System Boundary

Naming System Event and System Operations

 System event

 External input event generated by an actor.

 Initiates a responding operation by system.

 System operation

 Operation invoked in response to system event.

Choose an Event and Operations Names at Abstract Level

 www.rejinpaul.com
www.rejinpaul.com

SSD with Use Case Text

3. Logical Architecture and UML Package Diagram

 www.rejinpaul.com
www.rejinpaul.com

At this level, the design of a typical OO system is based on several architectural layers, such
as
 UI layer
 Application logic (or "domain") layer
 Technical Service

Layers

 Layer is a coarse-grained grouping of classes, packages, or subsystems that has cohesive

(strongly related) responsibilities for a major aspect of the system.
–E.g. Application Logic and Domain Objects—software objects representing domain
concepts (for example, a software class Sale) that fulfill application requirements, such
as calculating a sale total.
 Application layer is the focus of Use Cases.
 Higher layers (such as UI layer) call upon services of lower layers, but not normally vice
versa.
 In a strict layered architecture, a layer only calls upon the services of the layer directly
below it.
–Common in network protocols
 But not in information systems, which have a relaxed layered architecture, in which a
higher layer calls upon several lower layers.
–For example, UI layer may call upon its directly subordinate application logic layer, and
also upon elements of a lower technical service layer, for logging and so forth.

Software Architecture

Software architecture is
 the set of significant decisions about the organization of a software system,
 the selection of the structural elements and their interfaces by which the system is
composed,
 together with their behaviour as specified in the collaborations among those
elements, and
 the composition of these structural and behavioral elements into progressively larger
subsystems.
 www.rejinpaul.com
www.rejinpaul.com

UML Package Diagram

Mapping Code Organizations to Layers and UML Packages

// ---UI Layer
com.mycompany.nextgen.ui.swing
com.mycompany.nextgen.ui.web
// ---DOMAIN Layer
// packages specific to theNextGenproject
com.mycompany.nextgen.domain.sales
com.mycompany.nextgen.domain.payments
// ---TECHNICAL SERVICES Layer
// our home-grown persistence (database) access layer
com.mycompany.service.persistence
// third party
org.apache.log4j
org.apache.soap.rpc
// ---FOUNDATION Layer
// foundation packages that our team creates
com.mycompany.util
 www.rejinpaul.com
www.rejinpaul.com

Relationship between Domain Layer and Domain Model

Layers and Partitions

Layers of an architecture represent the vertical slices, while partitions represent a

horizontal division of relatively parallel subsystems of a layer.
–E.g., Technical Services layer may be divided into partitions such as Security and
Reporting.
 www.rejinpaul.com
www.rejinpaul.com

Model View Separation Principle

 Model is a synonym for the domain layer of objects (it's an old OO term from the
late 1970s).
 View is a synonym for UI objects, such as windows, Web pages, applets, and reports.

Principle:
 Model (domain) objects should not have direct knowledge of view (UI) objects.
–E.g. Register or Sale objects should not directly send a message to a GUI window
object ProcessSaleFrame, asking it to display something, change color, close, and so
forth.

History:
 Pattern Model-View-Controller (MVC) originally a small-scale Smalltalk-80 pattern.
 The Model is the Domain Layer, the View is the UI Layer, and theControllers are the
workflow objects in the Application layer.

Other part of this Principle

 Domain classes encapsulate the information and behavior related to application logic.
 Window classes are thin; they are responsible for
–input and output, and
–catching GUI events,
 Window classes do not maintain application data or directly provide application logic.
E.g.,
–A JavaJFramewindow or a Web JSP page should not have a method that does a tax
calculation.
 These UI elements should delegate to non-UI elements for such responsibilities.
 Observer pattern, where domain objects can send messages to UI objects viewed only
in terms of an interface such as PropertyListener(a common Java interface for this
situation).
 Then, the domain object doesn't know that the UI object is a UI object—it doesn't know
its concrete window class. It only knows the object as something that implements the
PropertyListenerinterface.
 www.rejinpaul.com
www.rejinpaul.com

Motivation for M-V Principle

 To allow separate development of the model and user interface layers.

 To minimize the impact of requirements changes in the interface upon the domain
layer.
 To allow new (multiple simultaneous) views to be easily connected to an existing
domain layer, without affecting the domain layer.
 To allow execution of the model layer independent of the user interface layer, such as
in a batch-mode system.

Connection between SSD and Layers

 SSDs illustrate system operations, but hide the specific UI objects.

 Nevertheless, it will be objects in the UI layer of the system that capture these system
operation requests.
–UI layer objects will then forward—or delegate—the request from the UI layer onto
the domain layer for handling.
 www.rejinpaul.com
www.rejinpaul.com

4. Logical Architecture Refinement

 Layers
 Information Systems

Layers
Software design is an iterative development, and it is normal to create a design of
layers that starts simple, and evolves over the iterations of the elaboration phase. It is
essential to have the core architecture established (designed and implemented) by the
end of the iterations in elaboration, but this does not mean doing a large up-front
speculative architectural design before starting to program. Rather, a tentative logical
architecture is designed in the early iterations, and it evolves incrementally through
the elaboration phase.

To comment on the above logical architecture diagram of NextGen POS application,

 www.rejinpaul.com
www.rejinpaul.com

 There are other types in these packages; only a few packages are shown to indicate
noteworthy aspects.
 The Foundation layer was not shown in this view; the architect decided that it did
not add interesting information, even though the development team will certainly be
adding some Foundation classes, such as more advanced String manipulation utilities.
 For now, a separate Application layer is not used. The responsibilities of control or
session objects in the Application layer are handled by the Register object. The
architect will add an Application layer in a later iteration as the behavior grows in
complexity, and alternative client interfaces are introduced (such as a Web browser
and wireless networked handheld PDA).

1. Inter-Layer and Inter-Package Coupling

To help someone understand the NextGen logical architecture, it's also informative to
include a diagram in the logical view that illustrates noteworthy coupling between the
layers and packages. A partial example is illustrated in the following figure.

Applying UML:
 www.rejinpaul.com
www.rejinpaul.com

 Dependency lines can be used to communicate coupling between packages or

types in packages. Plain dependency lines are excellent when the communicator does
not care to be more specific on the exact dependency (attribute visibility, subclassing,
...), but just wants to highlight general dependencies.
 Note also the use of a dependency line emitting from a package rather than a
particular type, such as from the Sales package to POSRuleEngineFacade class, and
the Domain package to the Log4J package. This is useful when either the specific
dependent type is not interesting, or the communicator wants to suggest that many
elements of the package may share that dependency.

Another common use of a package diagram is to hide the specific types, and focus on
illustrating the package-package coupling, as in the diagram given below.

2. Inter-Layer and Inter-Package Interaction Scenarios

Package diagrams show static information. To help someone understand the dynamics in
the NextGen logical architecture, it's also useful to include a diagram of how objects
across the layers connect and communicate. Thus, an interaction diagram is helpful. In
 www.rejinpaul.com
www.rejinpaul.com

the spirit of an “architectural view” which hides uninteresting details, and emphasizes
what the architect wants to convey, an interaction diagram in the logical view of the
architecture focuses on the collaborations as they cross layer and package boundaries. A
set of interaction diagrams that illustrate architecturally significant scenarios is thus
useful.

Applying UML:
 The package of a type can optionally be shown by qualifying the type with the UML
path name expression <PackageName>::<TypeName>. For example,
Domain::Sales::Register. This can be exploited to highlight to the reader the inter-
package and inter-layer connections in the interaction diagram.
 Note also the use of the «subsystem» stereotype. In the UML, a subsystem is a
discrete entity that has behavior and interfaces. A subsystem can be modeled as a
special kind of package, or—as shown here—as an object, which is useful when one
wants to show inter-subsystem (or system) collaborations. In the UML, the entire
 www.rejinpaul.com
www.rejinpaul.com

system is also a “subsystem” (the root one), and thus can also be shown as an object
in interaction diagrams.
 Note the use of the '1' in the top right corner to indicate a singleton, and suggest
access using the GoF Singleton pattern.

Fig. Subsystem Sterotypes

Fig. Number of interfaces exposed to Upper Layers

 www.rejinpaul.com
www.rejinpaul.com

Fig. Session Fascades and an Application Layer

Information Systems
Information System (IS) is the most well-known examples of layered architecture.

Fig. Classical view of three layered architecture

 www.rejinpaul.com
www.rejinpaul.com

Deployment of Three-Tier Systems

2 nodes = “Thick Client”
- Visual Basic, Power Builder, Access, …
- Crud = Create, Retrieve, Update, Delete
3 nodes = “Thin Client”
- Java, J2EE, C# .NET

Fig. A three tier logical division deployed in two physical architecture

5. UML Class Diagram

 www.rejinpaul.com
www.rejinpaul.com

UNIT V - CODING AND TESTING

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

Testing – GUI Testing – OO System Testing.

1. Mapping Design to Code

 Write source code for:

o Class and interface definitions

o Method definitions

 Work from OOA/D artifacts

o Create class definitions for Domain Class Diagrams (DCDs)

o Create methods from Interaction diagrams

From Domain Class Diagram (DCD) to Java Class

public class SalesLineItem

{
private int quantity;

private ProductDescription description;

public SalesLineItem(ProductDescription desc, int qty) { ... }

public Money getSubtotal() { ... }

ProductDescription
SalesLineItem
description description : Text
quantity : Integer price : Money
1 itemID : ItemID
getSubtotal() : Money
...
 www.rejinpaul.com
www.rejinpaul.com

From Interaction Diagram to Method

{
ProductDescription desc = catalog.ProductDescription(id);
currentSale.makeLineItem(desc, qty);
}

enterItem(id, qty) 2: makeLineItem(desc, qty)

:Register :Sale

1: desc := getProductDescription(id)

:Product
Catalog

Collection Class

What Collection classes has been added to the design and why?

Sale
public class Sale
{ isComplete : Boolean
... time : DateTime SalesLineItem
lineItems
private List lineItems = new ArrayList(); becomeComplete() quantity : Integer
1..*
} makeLineItem()
getSubtotal()
makePayment()
getTtotal()

A collection class is necessary to

maintain attribute visibility to all the
SalesLineItems.
 www.rejinpaul.com
www.rejinpaul.com

Why implement from least-coupled to most coupled?

Store
7
address : Address
1 2
name : Text
3 ProductDescription
ProductCatalog
addSale(...)
description : Text
... price : Money
1 1..* itemID : ItemID
getProductDesc(...)
...

1
1 Sale
5
6
Register isComplete : Boolean 4
time : DateTime SalesLineItem
...
becomeComplete() quantity : Integer
endSale() 1 1..*
makeLineItem(...)
enterItem(...) getSubtotal()
makePayment(...)
makeNewSale()
getTotal()
makePayment(...)
...
1
* Payment

amount : Money
1
...

Working Example (Project Management System – PM)

 www.rejinpaul.com
www.rejinpaul.com

PM: Use Case Diagram

PM: Class Diagram

PM: Class to Code

 class WorkPackage;
 class Project;
 class Activity;
 class Task;
 class WorkProduct;
 www.rejinpaul.com
www.rejinpaul.com

 class Resource;
 class Skill;
 class ResourceXSkill;

class WorkPackage

{ // Details omitted };

class Project : public WorkPackage

{ private: CollectionByVal<Activity> theActivity; };

class Activity : public WorkPackage

{ private: Project *theProject;

CollectionByVal<Task> theTask;
CollectionByRef<WorkProduct>

theWorkProduct; };

class Project

{ private:

char *Name;

char *Descr;

Date StartDate;

static int NumberOfProjects;

public:

Project (char *Name);

Project (void); ~Project (void);

char *getName (void);

void setName (char *theName);

void setDescr (char *Descr);

char *getDescr (void);

void setStartDate (Date theStartDate);

 www.rejinpaul.com
www.rejinpaul.com

PM: Sequence Diagram

void main (void)

{ char *Name; char *Descr;

Date StartDate; Project aProject;

// provide project Name, descr, and startdate

aProject.setName (Name);

aProject.setDescr (Descr);

aProject.setStartDate (StartDate);

aProject.save (); }
 www.rejinpaul.com
www.rejinpaul.com

2. Testing: Issues in OO Testing

What is a unit in an object orientated system?

 Traditional systems define a unit as the smallest component that can be compiled and
executed.
 Units are normally a component which in theory is only ever assigned to one
programmer.

Two options for selecting units in object orientated systems:

 Treat each class as a unit

 Treat each method within a class as a unit.

Advantages of OO Unit Testing

 Once a class is testing thoroughly it can be reused without being unit tested again.
 UML class state charts can help with selection of test cases for classes.
 Classes easily mirror units in traditional software testing

Disadvantages of OO Unit Testing

 Classes obvious unit choice, but they can be large in some applications
 Problems dealing with polymorphism and inheritance.

Composition Issues

 Objective of OO is to facilitate easy code reuse in the form of classes.

 To allow this each class has to be rigiriously unit tested.
 Due to classes potentially used in unforeseeable ways when composed in new systems I
Example: A XML parser for a web browser.
 Classes must be created in a way promoting loose coupling and strong cohesion

Encapsulation Issues

 Encapsulation requires that classes are only aware of their own properties, and are able to
operate independently.
 If unit testing is performed well, the integration testing becomes more important.
 If you do not have access to source code then structural testing can be impossible.
 www.rejinpaul.com
www.rejinpaul.com

 If you violate encapsulation for testing purposes, then the validity of test could be
questionable

Implication of Inheritance and Polymorphism

 Inheritance is an important part of the object oriented paradigm.

 Unit testing a class with a super class can be impossible to do without the super classes
methods/variables
 One solution is Flattening
 Merge the super class, and the class under test so all methods/variables are
available.
 Solves initial unit test problems.
 Problems:
o The class won’t be flattened in the final product so potential issues may still
arise.
o Complicated when dealing with multiple inheritance

Polymorphism Issues

 Repeatedly testing same methods

 Time can then be wasted if not addressed
 Potentially can be avoided and actually save time
 www.rejinpaul.com
www.rejinpaul.com

3. Class (Unit) Testing

Testing OO Code

Class Integration
tests tests

System Validation
tests tests

 Smallest testable unit is the encapsulated class

 Test each operation as part of a class hierarchy because its class hierarchy defines its
context of use
 Approach:
o Test each method (and constructor) within a class
o Test the state behavior (attributes) of the class between methods
 How is class testing different from conventional testing?
 Conventional testing focuses on input-process-output, whereas class testing focuses on
each method, then designing sequences of methods to exercise states of a class
 But white-box testing can still be applied

Class Testing Process

 www.rejinpaul.com
www.rejinpaul.com

Class Test Case Design

1. Identify each test case uniquely

- Associate test case explicitly with the class and/or method to be tested

2. State the purpose of the test

3. Each test case should contain:

a. A list of messages and operations that will be exercised as a consequence of the test

b. A list of exceptions that may occur as the object is tested

c. A list of external conditions for setup (i.e., changes in the environment external to
the software that must exist in order to properly conduct the test)

d. Supplementary information that will aid in understanding or implementing the test

 Automated unit testing tools facilitate these requirements

Challenges of Class Testing

 Encapsulation:

o Difficult to obtain a snapshot of a class without building extra methods which

display the classes’ state

 Inheritance and polymorphism:

o Each new context of use (subclass) requires re-testing because a method may
be implemented differently (polymorphism).

o Other unaltered methods within the subclass may use the redefined method
and need to be tested

 White box tests:

o Basis path, condition, data flow and loop tests can all apply to individual
methods, but don’t test interactions between methods
 www.rejinpaul.com
www.rejinpaul.com

Testing Methods Applicable at the Class Level

 Random testing - requires large numbers data permutations and combinations, and can
be inefficient

o Identify operations applicable to a class

o Define constraints on their use
o Identify a minimum test sequence
o Generate a variety of random test sequences.

Example:
o An account class in a banking application has open, setup, deposit,
withdraw, balance, summarize and close methods
o The account must be opened first and closed on completion
o Open – setup – deposit – withdraw – close
o Open – setup – deposit –* [deposit | withdraw | balance | summarize] –
withdraw – close. Generate random test sequences using this template

 Partition testing - reduces the number of test cases required to test a class

o state-based partitioning - tests designed in way so that operations that cause state
changes are tested separately from those that do not.
o attribute-based partitioning - for each class attribute, operations are classified
according to those that use the attribute, those that modify the attribute, and those
that do not use or modify the attribute
o category-based partitioning - operations are categorized according to the function
they perform: initialization, computation, query, termination

 Fault-based testing

 best reserved for operations and the class level

 uses the inheritance structure
 tester examines the OOA model and hypothesizes a set of plausible defects that
may be encountered in operation calls and message connections and builds
appropriate test cases
 misses incorrect specification and errors in subsystem interactions
 www.rejinpaul.com
www.rejinpaul.com

4. Integration Testing

 OO does not have a hierarchical control structure so conventional top-down and bottom-
up integration tests have little meaning.
 Kinds of integration testing:
 big bang testing (5 facts) - An inappropriate approach to integration testing in which
you take the entire integrated system and test it as a unit
 incremental testing (2 kinds, 3 facts) - A integration testing strategy in which you test
subsystems in isolation, and then continue testing as you integrate more and more
subsystems.
 Integration applied three different incremental strategies:
o Thread-based testing: integrates classes required to respond to one input or
event
o Use-based testing: integrates classes required by one use case
o Cluster testing: integrates classes required to demonstrate one collaboration

Inter-Class Test Case Design

 Test case design becomes more complicated as integration of the OO system begins –
testing of collaboration between classes
 Multiple class testing

o for each client class use the list of class operators to generate random test
sequences that send messages to other server classes
o for each message generated determine the collaborator class and the
corresponding server object operator
o for each server class operator (invoked by a client object message) determine the
message it transmits
o for each message, determine the next level of operators that are invoked and
incorporate them into the test sequence

 Tests derived from behavior models

o Use the state transition diagram (STD) as a model that represent the dynamic
behavior of a class.
 www.rejinpaul.com
www.rejinpaul.com

o test cases must cover all states in the STD

o breadth first traversal of the state model can be used (test one transition at a time
and only make use of previously tested transitions when testing a new transition)
o test cases can also be derived to ensure that all behaviors for the class have been
adequately exercised

Testing Methods Applicable at Inter-Class Level

 Cluster Testing

 Is concerned with integrating and testing clusters of cooperating objects

 Identify clusters using knowledge of the operation of objects and the system features
that are implemented by these clusters

 Approaches to Cluster Testing

o Use-case or scenario testing
 Testing is based on a user interactions with the system
 Has the advantage that it tests system features as experienced by users
o Thread testing – tests the systems response to events as processing threads through
the system
o Object interaction testing – tests sequences of object interactions that stop when
an object operation does not call on services from another object

 Use Case/Scenario-based Testing

 Based on
o use cases
o corresponding sequence diagrams
 Identify scenarios from use-cases and supplement these with interaction diagrams that
show the objects involved in the scenario
 Concentrates on (functional) requirements
o Every use case
o Every fully expanded extension (<<extend>>) combination
o Every fully expanded uses (<<uses>>) combination
o Tests normal as well as exceptional behavior
 www.rejinpaul.com
www.rejinpaul.com

 A scenario is a path through sequence diagram

 Many different scenarios may be associated with a sequence diagram
 using the user tasks described in the use-cases and building the test cases from the
tasks and their variants
 uncovers errors that occur when any actor interacts with the OO software
 concentrates on what the use does, not what the product does
 you can get a higher return on your effort by spending more time on reviewing the
use-cases as they are created, than spending more time on use-case testing

5. GUI Testing

GUI testing is the process of ensuring proper functionality of the graphical user interface
(GUI) for a given application and making sure it conforms to its written specifications. In
addition to functionality, GUI testing evaluates design elements such as layout, colors, fonts,
font sizes, labels, text boxes, text formatting, captions, buttons, lists, icons, links and content.
GUI testing processes can be either manual or automatic, and are often performed by third -
party companies, rather than developers or end users. GUI testing can require a lot of
programming and is time consuming whether manual or automatic.

There are two types of interfaces in a computer application.

 Command Line Interface is where you type text and computer responds to that
command.
 GUI stands for Graphical User Interface where you interact with the computer using
images rather than text.

Following are the GUI elements which can be used for interaction between the user
and application:

In the below example, if we have to do GUI testing we first check that the images should be
completely visible in different browsers. Also, the links are available, and the button should
 www.rejinpaul.com
www.rejinpaul.com

work when clicked. Also, if the user resizes the screen, neither images nor content should
shrink or crop or overlap.

Need for GUI Testing

A user doesn't have any knowledge about XYZ software/Application. It is the UI of the
Application which decides that a user is going to use the Application further or not. A normal
User first observes the design and looks of the Application/Software and how easy it is for
him to understand the UI. If a user is not comfortable with the Interface or find Application
complex to understand he would never going to use that Application Again. That's why, GUI
is a matter for concern, and proper testing should be carried out in order to make sure that
GUI is free of Bugs.

What do you check in GUI Testing?

The following checklist will ensure detailed GUI Testing.

 Check all the GUI elements for size, position, width, length and acceptance of characters
or numbers. For instance, you must be able to provide inputs to the input fields.
 Check you can execute the intended functionality of the application using the GUI
 Check Error Messages are displayed correctly
 Check for Clear demarcation of different sections on screen
 Check Font used in application is readable
 Check the alignment of the text is proper
 Check the Color of the font and warning messages is aesthetically pleasing
 Check that the images have good clarity
 Check that the images are properly aligned

 Check the positioning of GUI elements for different screen resolution.

 www.rejinpaul.com
www.rejinpaul.com

Approach of GUI Testing

GUI testing can be done through three ways:

Manual Based Testing

Under this approach, graphical screens are checked manually by testers in conformance with
the requirements stated in the business requirements document.

Record and Replay

GUI testing can be done using automation tools. This is done in 2 parts. During Record , test
steps are captured by the automation tool. During playback, the recorded test steps are
executed on the Application Under Test. Example of such tools - QTP .
 www.rejinpaul.com
www.rejinpaul.com

Model Based Testing

GUI Testing Test Cases

GUI Testing basically involves

1. Testing the size, position, width, height of the elements.

2. Testing of the error messages that are getting displayed.
3. Testing the different sections of the screen.
4. Testing of the font whether it is readable or not.
5. Testing of the screen in different resolutions with the help of zooming in and zooming out
like 640 x 480, 600x800, etc.
6. Testing the alignment of the texts and other elements like icons, buttons, etc. are in proper
place or not.
7. Testing the colors of the fonts.
8. Testing the colors of the error messages, warning messages.
9. Testing whether the image has good clarity or not.
10. Testing the alignment of the images.
11. Testing of the spelling.
12. The user must not get frustrated while using the system interface.
13. Testing whether the interface is attractive or not.
14. Testing of the scrollbars according to the size of the page if any.
15. Testing of the disabled fields if any.
16. Testing of the size of the images.
17. Testing of the headings whether it is properly aligned or not.
18. Testing of the color of the hyperlink.
 www.rejinpaul.com
www.rejinpaul.com

Challenges in GUI Testing

The most common problem comes while doing regression testing is that the application GUI
changes frequently. It is very difficult to test and identify whether it is an issue or
enhancement. The problem manifests when you don't have any documents regarding GUI
changes.

6. System Testing

System Testing

– Tests the system as a whole

– Concerned with what happens

– Not how it happens

– Black box

 Types of System Testing:

 Functional Testing
 Structure Testing
 Acceptance Testing
 Installation Testing
 www.rejinpaul.com
www.rejinpaul.com

Functional Testing
Goal: Test functionality of system
• Test cases are designed from the requirements analysis document (better: user manual) and
centered around requirements and key functions (use cases)
• The system is treated as black box.
• Unit test cases can be reused, but new test cases have to be developed as well.

Structure Testing
Goal: Cover all paths in the system design
• Exercise all input and output parameters of each component.
• Exercise all components and all calls (each component is called at least once and every
component is called by all possible callers.)
• Use conditional and iteration testing as in unit testing.

Performance Testing
Goal: Try to break the subsystems
• Test how the system behaves when overloaded.
• Can bottlenecks be identified? (First candidates for redesign in the next iteration)
• Try unusual orders of execution
• Call a receive() before send()
• Check the system’s response to large volumes of data
• If the system is supposed to handle 1000 items, try it with 1001 items.
• What is the amount of time spent in different use cases?
• Are typical cases executed in a timely fashion?

Types of Performance Testing

o Recovery testing: how well and quickly does the system recover from faults

o Security testing: verify that protection mechanisms built into the system will protect
from unauthorized access (hackers, disgruntled employees, fraudsters)

o Stress testing: place abnormal load on the system

 www.rejinpaul.com
www.rejinpaul.com

o Volume testing: Test what happens if large amounts of data are handled

o Configuration testing: Test the various software and hardware configurations

o Compatibility test: Test backward compatibility with existing systems

o Timing testing: Evaluate response times and time to perform a function

o Environmental test - Test tolerances for heat, humidity, motion

o Quality testing: - Test reliability, maintainability & availability

o Human factors testing: Test with end users

Acceptance Testing

Goal: Demonstrate system is ready for operational use

• Choice of tests is made by client
• Many tests can be taken from integration testing
• Acceptance test is performed by the client, not by the developer.
Alpha test:
• Sponsor uses the software at the developer’s site.
• Software used in a controlled setting, with the developer always ready to fix bugs.
Beta test:
• Conducted at sponsor’s site (developer is not present)
• Software gets a realistic workout in target environment