Unit-2

 Rumbaugh Methodology
 Booch Methodology
 Jacobson Methodology
 Patterns
 Frameworks
 Unified Approach
 Unified Modeling Language
 Use case
 class diagram
 Interactive Diagram
 Collaboration Diagram
 State Diagram
 Activity Diagram.
 Chapter Objectives
You should be able to define and understand
Object Oriented methodologies.
- The Rumbaugh OMT
- The Booch methodology
- Jacobson’s methodologies
Patterns
Frameworks
Rumbaugh’s Object Modeling Technique (OMT)
-A method for analysis,design and implementation by
an object oriented technique.
-fast and intuitive approach for identifying and
modeling all objects making up a system.
-Class attributes, methods, inheritance and association can
be expressed easily.
-Dynamic behavior of objects can be described using
the OMT dynamic model.
-Detailed specification of state transitions and their
-descriptions within a system
Four phases of OMT
(can be performed iteratively)
 Analysis: objects,dynamic and functional
models
 System Design: Basic architecture of the
system.
 Object Design: static, dynamic and
functional models of objects.
 Implementation: reusable, extendible and
robust code.
Three different parts of OMT modeling

 An object model - object model & data

dictionary
 A dynamic model - state diagrams & event
flow diagrams
 A functional model - data flow &
constraints
Object Model
 structure of objects in a system.
 Identity, relationships to other objects,
attributes and operations.
 Object diagram
Object Diagram
 Classes interconnected by association
lines
 Classes- a set of individual objects
 Association lines- relationship among
classes (i.e., objects of one class to
objects of another class)
OMT Dynamic Model
 States, transitions, events and actions
 OMT state transition diagram-network
of states and events
OMT Functional Model
 DFD- (Data Flow Diagram)
 Shows flow of data between different
processes in a business.
 Simple and intuitive method for describing
business processes without focusing on the
details of computer systems.
Data Flow Diagram
 Four primary symbols
Process- any function being performed
Data Flow- Direction of data element movement

Data Store – Location where data is stored

External Entity-Source or Destination

of a data element
The Booch Methodology
 Widely used OO method
 Uses the object paradigm
 Covers the design and analysis phase of
an OO system
 Criticized for his large set of symbols
Diagrams of Booch method
 Class diagrams-
describe roles and responsibilities of objects
 Object diagrams
describe the desired behavior of the system in terms
of scenarios
 State transition diagrams
state of a class based on a stimulus
 Module diagrams
to map out where each class & object should be
declared
 Process diagrams
to determine to which processor to allocate a process
 Interaction diagrams
describes behavior of the system in terms of scenarios
Booch method prescribes:
 Macro Development Process

 Micro Development Process

Macro Development Process
 Controlling framework for the micro
process.
 Primary concern-technical management
of the system.
Steps for macro development
process
1. Conceptualization
2. Analysis & Development of the model
3. Design or create the system architecture
4. Evolution or implementation
5. Maintenance
Micro Development Process
Each macro process has its own micro
development process
Steps:
- Identify classes & objects
- Identify class & objects semantics
- Identify class & object relationship

- Identify class & objects interface and

implementation
 JACOBSON METHODOLOGIES

 Use Cases.
 Object Oriented Software Engineering.
 Object Oriented Business Engineering.

Use Cases
Understanding system requirements
 Interaction between Users and Systems
 The use case description must contain
 How and when the use case begins and ends.
 The Interaction between the use case and its actors,
including when the interaction occurs and what is
exchanged.
 How and when the use case will need data stored in the
system.
 Exception to the flow of events
 How and when concepts of the problem domain are
handled.
OOSE
 Object Oriented Software Engineering.
 Objectory is built models
 Use case model
 Domain object model
 Analysis object model
 Implementation model
 Test model
OOBE
 Object Oriented Business Engineering
 OOBE is object modeling at the
enterprise level.
 Analysis phase
 Design and Implementation phase
 Testing phase
 E.g. Unit testing, integration and system
testing.
PATTERNS
 It is an instructive information that
captures the essential structure and
insight of a successful family of proven
solutions to a recurring problem that
arises within a certain context and
system of forces.
Good Pattern will do the
following
 It solves a problem.
 It is a proven concept.
 The Solution is not obvious.
 It describes a relationship.
 The pattern has a significant human
component.
 Patterns

Patterns

Generative Patterns Non Generative Patterns

(describe recurring phenomena (describe recurring phenomena
with saying how to without saying how to
reproduce them) reproduce them)
Patterns Template
 Essential Components should be clearly recognizable
on reading a pattern:
 Name
 Problem
 Context
 Forces
 Solution
 Examples
 Resulting context
 Rationale
 Related Patterns
 Known uses
Frameworks
 Way of delivering application
development patterns to support best
practice sharing during application
development.

 Can be viewed as the implementation

of a system of design patterns.
Benefits of Frameworks
 Reusability
 Modularity
 Extensibility
 Inversion of Control
Difference between Patterns and
Frameworks
 Design patterns are more abstract than
frameworks.
 Design patterns are smaller
architectural elements than
frameworks.
 Design patterns are less specialized
than frameworks.
Model
 An abstract representation of a
system.
 Types of model
1. Use case model
2. Domain model
3. Analysis object model
4. Implementation model
5. Test model
Model
 Types of model
1. Use case model  defines the outside (actors)
& inside (use case) of the system’s behavior.
2. Domain model  maps real world object into
the domain object model.
3. Analysis object model  how source code
should be carried out & written.
4. Implementation model represents the
implementation of the system.
5. Test model  test plans, specifications &
reports.
 Model
 Model is an iterative process.
 It can represent static or dynamic
situations.
 Model

Static Dynamic

Provides a system’s Represents a system’s behaviors

parameters at rest or at a that, taken together, reflect its
specific point in time. behavior over time.
(e.g.) class diagram (e.g.) interaction & activity diagrams
Why modeling
 Blue print
 Clarity
 Familiarity
 Maintenance
 Simplification
Advantages of modeling
 Easy to express complex ideas
 Reduce complexity
 Enhance & reinforce learning and
training
 Low cost
 Easy to change the model
What is Unified Modeling
Language (UML)?
 The UML is a graphical / standard
language for visualizing,
specifying, constructing &
documenting the artifacts of a
software system.
History of UML
 1980 – 1990  Many different
methodologies

1. Booch method by Grady Booch

2. Object Modeling Technique (OMT) by Jim Rumbaugh
3. Object Oriented Software Engineering (OOSE) by Ivar
Jacobson

 Each method had its strengths &

weaknesses.
1. Booch was great in design
2. OMT & OOSE were great in analysis
History ofUMLUML
1.0 (January 1997)

UML 1.1 (November 1997)

UML 1.3 (Current Minor revision 1999)

UML 1.4 (Planned Minor revision 2000)

UML 2.0 (Planned Major revision 2004)

UML Concepts

 UML can be used to support your

entire life cycle.
1. The interaction of your application with the outside
world (use case diagram)
2. Visualize object interaction (sequence &
collaboration diagrams)
3. The structure of your system (class diagram)
4. View the system architecture by looking at the
defined package.
5. The components in your system (component
diagram)
What are Diagrams ?
 Graphical presentation of model
elements.
 A diagram is a graphical means to view
a system’s parts
UML Diagrams
 8 diagrams
 You will model the following 5 diagrams only:
1. Use case diagram
2. Activity diagram
3. Sequence diagram Interaction
4. Collaboration diagram diagram
5. Class diagram
 The other UML diagrams that can be modeled in
Rose are:
1. State chart diagram
2. Component diagram
3. Deployment diagram
Behavior Diagram
Interaction
 Sequence diagram diagram
behavior
 Collaboration diagram diagram

 State chart diagram

 Activity diagram
UML Diagrams

1. Class diagram
2. Use case diagram
3. Activity diagram
4. Sequence diagram
5. Collaboration diagram
6. State chart diagram
7. Component diagram
8. Deployment diagram
1. Class diagram
 Class  a set of objects that share the
same attributes, operations & relationships.
 It represented by a compartmentalized
rectangle.
 It shows the structure of your software.
 3 compartments
1. Top
2. Middle
3. Bottom
1. Class diagram
1. Top  shows class name
2. Middle  shows class attributes
3. Bottom  shows class operation
1. Class diagram
1. Attributes  defines the characteristics or
structure of a class.
 displayed in the middle of the
compartmentalized rectangle.

Attributes
 1. Class diagram
2. Operation  the service provided by the class.
 displayed in the bottom of the
compartmentalized rectangle.

Operations
 2.Use case diagram
 It shows a set of use cases and actors and
their relationships.
 Address the static view of a system.
 Actor  user (or) someone / something
outside the system that interacts with the
system (it must be a noun) & it is
represented by a stickman.
……contd
 2.Use case diagram
 Use case  a sequences of actions (it must be
a verb) & it is represented by an oval.
 Relationship illustrates a connection among
model elements.
Unidirectional Bi-directional

 It is created to visualize the interaction of your

system with the outside world.
 (e.g.) ATM
……contd
2. Use case diagram (ATM)

WITHDRAW
CASH
CUSTOMER DISPENSER

CHECK BALANCE

PRINTER
CHANGE PIN
LOGIN
2. Use case diagram (Pay roll)
 Actors  employee & account

 Use case  count leave, disburse

salary, check loans, calculate PF,
prepare IT returns, calculate HRA &
check salary
 Count leave

Customer

Disburse salary

Check loans

Calculate HRA
Calculate PF

Check salary

Prepare IT returns
3.Activity Diagram
 It shows the flow of events with our
system & what is going on inside a use
case.
 We draw the activity diagram for each
& every use case.
 Login (use case) – (e.g.) ATM
 It is showing flow of control from
activity to activity.
3.Activity Diagram
 Activity  it represents the performance of a
task within the workflow.
 Activity is represented by a lozenge
(horizontal top and bottom with convex sides)
 Start state shows the beginning of a workflow
on an activity diagram.
 There is only one start state.
3.Activity Diagram
 A start state is represented by a solid
circle.

 An end state represents a final or

terminal state on an activity diagram.
 A end state is represented by a bull’s
eye.
3.Activity Diagram
 A state transition shows what activity
follows after another.
 It is represented by a solid line with an
arrow.
3.Activity Diagram
 A decision is a point in an activity diagram
where guard conditions are used to indicate
different possible transitions.
 It is represented by a diamond.
 Guard conditions control the transition of a
set of alternate transitions that follows after
the activity has been completed.
 3.Activity Diagram
AND
Synchronization bar

Joint
3.Activity Diagram
 A synchronization bar allows you to
show concurrent threads in a work flow
of a use case.
 It represented by a thick horizontal or
vertical line.
3.Activity Diagram
 A swimlane is used to partition an
activity diagram to help us better
understand who or what is initiating an
activity.
3.Activity Diagram – Login Use case

Cus tom er Enters

the login details

Sys tem retrives

the details

Sys tem validates

the cus tom er

[ Fals e ]
Sys tem prompts to
reenter
[ True ]

Sys tem welcomes

the cus tom er
4.Sequence Diagram
 It shows step by step what must happen
to accomplish a piece of functionality
provided by the system.
 It has 2Ds.
1. Vertical dimensions  represents time
2. Horizontal dimensions  represents
different objects.
 Vertical line is called the object’s life line.
4.Sequence Diagram

 Life line  the existence object at a

particular time.

 Objects are shown at the top.

 The object role is shown as a vertical

dashed line, the life line.
4.Sequence Diagram

 A message is the communication between 2

objects that triggers an event.

 It is represented by a labeled arrow.

 Each message is represented by an arrow

between the life lines of 2 objects.
4.Sequence Diagram

 A focus of control shows the period of

time during which an object is
performing an action, either directly or
through a subordinate procedure.

 It represented by a tall, thin rectangle.

4.Sequence Diagram – login
success

: Customer : LoginForm : LoginController : CustomerInfo

Enter Login Detail...

Submit( )

Validate( )

getLoginDetails( )
5.Collaboration Diagram
 It displays objects and their links to one
other.

 It is also known as an interaction diagram.

5.Collaboration Diagram
 It is made up of the following basic
elements :
1. Actors
2. Objects
3. Links
4. Messages
5.Collaboration Diagram
1. Actors  user
2. Objects
 data + logic / the representation
of some real world entity.
3. Links  a pathway for communication
between objects.
 represented by a solid line
between 2 objects
4. Messages  the communication between
objects that triggers an event.
 represented by a labeled arrow
above
the link.
5.Collaboration Diagram –
Login use case
1: Enter Login Details ( )
2: Subm it( )

: LoginForm
: Cus tom er

3: Validate( )

4: getLoginDetails ( )

: LoginController
: Cus tom erInfo
6. State Chart Diagram
 It shows the sequence of states.
 A state is represented as a rounded box,
which may contain one or more
compartments.
 Name compartment  holds the name of
the state.
 Internal transition compartment  list of
actions / activities
 Start & end states
7.Component Diagram
 It shows relationship between the
components in the system.

 A component may be a software

component [for (e.g.) a.h file in C++
(or) a .java file in Java], a run time
component [for (e.g.) a.DLL file]
8. Deployment Diagram
 It shows the configuration of run time
processing elements & the software
components, processes & objects that
live in them.
 It shows the nodes in the system & the
connections between them.