OBJECT-ORIENTED

METHODOLOGIES

1
 Chapter’s Objective

 You should be able to define and understand:

 O-O Methodolgies
 The Rumbaugh et al. OMT
 The Booch methodology
 Jacobson’s Methodologies
 Patterns (Very Important)
 Frameworks
 Unified Approach (UA)

2
 INTRODUCTION: TOWARDS UNIFICATION –
TOO MANY METHODOLOGIES
 BEST PRACTICES ARE UNIFIED- DUE TO TOO MANY
METHODOLOGIES:
- Booch-1986 object-oriented design concept, Booch method
 Sally Shaler & Steve Mellor (1989 – 91) OO Systems Analysis
+ Object Lifecycles
 Peter Coad & Ed Yourdon (1991) (OOA & OOD) prototype-
oriented approach
 Wirfs-Brock-1990 Class-Responsibility-Collaboration (CRC)
Methodology

3
INTRODUCTION: TOWARDS UNIFICATION –
TOO MANY METHODOLOGIES
 Booch/Rational work on Ada (1994 – 95) OO Analysis and
Design with Apps.
 Rumbaugh (GE) Object Modeling Technique (OMT) 1991
 Jim Odell & James Martin ( IS applications )(1994 – 96)
 Jacobson (Ericsson) OO Software Engineering (1994-95)
 Rumbaugh joins Rational to work with Booch (1994)
 Rational bought Objectory & Jacobson (1995)
 Through OMG & Rational, UML was born.
• UML unifies the methods of James Rumbaugh, Grady Booch,
and Ivar Jacobson.
4
 SURVEY OF SOME OF THE O-O
METHODOLOGIES

 Rumbaugh et al. method is well suited for

describing the object model or the static
structure of the system and dynamic model.
 The Jacobson et al. method is good for producing
user-driven analysis models.
 The Booch method produces detailed object-
oriented design models.

5
 RUMBAUGH ET AL’S OBJECT
MODELING TECHNIQUE (OMT)

 Jim Rumbaugh and his co workers

 Method for the analysis, design, and implementation of
a system using an o-o technique.
 OMT is fast, intuitive approach for identifying &
modeling all objects making up the systems.
 OMT consists of :
 Static(Object), Dynamic(State transistion) and
Functional(Process description & consumer-
producer) models.
6
 RUMBAUGH ET AL’S OBJECT
MODELING TECHNIQUE (OMT) contd..

 OMT consists of 4 phases:

1. Analysis: The results are objects dynamic & functional
models.
2. System design: Basic architecture & high level strategy
of the system.
3. Object design: Design document produced containing
object static, dynamic and functional model.
4. Implementation: Reusable, extendible & robust code.

7
 RUMBAUGH ET AL’S OBJECT
MODELING TECHNIQUE (OMT) contd..

 OMT separates modeling into three parts:

1. Object model: Presented by the object model and
data dictionary.(Class diagrams)
2. Dynamic model: presented by the state transition
diagrams, and event flow diagrams.
3. Functional model: presented by data flow and
constraints. (DFD)

8
RUMBAUGH – OBJECT MODEL

 Describes the structure of the system

 Identity, relationship with other class, attributes
and methods
 Association represents a set of links from objects
of one class to objects of another class

9
RUMBAUGH – OBJECT MODEL

10
RUMBAUGH - DYNAMIC MODEL

 Detailed dynamic model with states, transitions,

events and actions.
 Each states receives one or more events and
make transition to next state
 Next state depends on current state and events

11
RUMBAUGH - DYNAMIC MODEL

12
RUMBAUGH FUNCTIONAL MODEL

 OMT- data flow diagram – flow of data between

different process in a business
 Process – function being performed
 Data Flow – direction of data element movement
 Data store – location where data stored
 External entity – source/ destination of data element

13
RUMBAUGH FUNCTIONAL MODEL

14
RUMBAUGH FUNCTIONAL MODEL

15
 THE BOOCH METHODOLOGY

 Widely used o-o methods to design systems using

object paradigm.
 Booch method consists of :
 Class Diagrams
 Object Diagrams
 State Transition Diagrams
 Module Diagrams
 Process Diagrams
 Interaction Diagrams
16
 THE BOOCH METHODOLOGY

 Booch methodology consist of Macro and Micro

development process
 Macro development process: It serves as a controlling
framework for micro process consists of:
- conceptualization
- analysis and development of the model
- design or create the system architecture
- evolution or implementation
- maintenance

17
THE BOOCH METHODOLOGY

18
 THE BOOCH METHODOLOGY contd..
 Each macro development process has its own micro
development processes.
 Micro process is a day-to-day activities
 Micro development process consists of :
- identify classes and objects
- identify class and object semantics
- identify class and object relationships
- identify class and object interfaces and
implementation

19
THE BOOCH METHODOLOGY

20
 BOOCH NOTATIONS

Class Notation
Object Notation
21
BOOCH – Class Diagram

22
BOOCH – Object Diagram

23
BOOCH – Interaction Diagram

24
BOOCH – State Diagram

25
BOOCH – Process Diagram

26
BOOCH – Module Diagram

27
THE JACOBSON ET AL. METHODOLOGY

 This methodologies covers the entire life cycle and

stress traceability between the different phases both
forward & backward. It consists of:
 OOBE (O-O Business Engineering)
 OOSE (O-O Software Engineering) also called:
 OBJECTORY (Object Factory for Software Development)

28
 THE JACOBSON ET AL.
METHODOLOGY contd..

 Concept of use-case
- scenarios for understanding the system
requirements
- is an interaction between user and
system
- captures the goal of the user and
responsibility of the system to its users

29
 THE JACOBSON ET AL.
METHODOLOGY contd..

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 or will store data in the system.
 Exceptions to the flow of events.
 How and when concepts of the problem domain are
handled.
30
 THE JACOBSON ET AL.
METHODOLOGY contd..

 Every single use case should describe one main flow of

events.
 An exceptional or additional flow of events could be
added.
 The use case model employs extends and uses
relationships.
 Extend relationship extends the functionality of the
original use case (like a subclass).
 The Uses relationship reuses common behavior in different
use cases.
31
 THE JACOBSON ET AL.
METHODOLOGY contd..

O-O Software Engineering: Objectory

 OOSE also called objectory is a method of O-O
development with the specific aim to fit the
development of large, real time systems.
 The development process is called use-case driven
process. Used across:
 Analysis, Design, Validation & Testing

32
 THE JACOBSON ET AL. METHODOLOGY
contd..
Objectory is built around several different models
such as:
 Use-case model
 Domain Object model: The object of the real
world are mapped into the domain object model.
 Analysis Object model: It presents how the
source code(implementation) should be carried
out and written.
 Implementation model:
 Test model: It includes the test plans,
specifications, and reports.
33
 THE JACOBSON ET AL. METHODOLOGY
contd..

O-O Business Engineering

 OOBE is object modeling at the enterprise level. (Use
case are also central here)
 OOBE consists of :
 Analysis phase
 Design & Implementation phases
 Testing phase: Unit, integration & system testing.

34
 PATTERNS
 A system can be analyzed, designed & built from
Prefabricated & predefined system components – An
Emerging Idea.
 Sound documentation is the need in this case.
 The use of design patterns originated by a building architect
called Alexander in 1970s.
 He motivated O-O researcher to describe commonly
occurring design solutions and programming paradigms.

35
 PATTERNS

 According to Gamma, Helm, Johnson & Vlissides design

pattern :
“Identifies the key aspects of a common design structure that
makes it useful for creating a reusable O-O design.”
“Further it identifies the participating classes and instances,
their roles and collaborations, and the distribution of
responsibilities.”

36
 PATTERNS
“Design Patterns describes when it applies, whether it can
be applied in view of other design constraints and the
consequences and trade-offs of its use.”
 According to Riehle & Zullighoven:
“A pattern is [an] instructive information that captures the
essential structure and insight of a successful family of
proven solution to a recurring problem that arises within
a certain context and system of forces.”

37
 PATTERNS

According to Coplien a good pattern will do the

following:
 It solves a problem.
 It is a proven concept.
 The solution is not obvious.
 It describes a relationship. (i.e system structure &
mechanism)
 The pattern has a significant human component.

38
 PATTERNS

Patterns are used for :

 Software architecture & design
 Organization
 Specification models
 Software development process
 Project planning
 Requirements engineering
 Software configuration management

39
 GENERATIVE & NON GENERATIVE
PATTERNS
Types of patterns are:
 Generative Patterns: describe a recurring problem.
 It tells how to generate something and can be
observed in the resulting system architectures they
help shape.
 Nongenerative patterns are static and passive: They
describe recurring phenomena without necessarily saying
how to reproduce them.
 Most of the patterns are generative.

40
 PATTERNS TEMPLATE

Patterns Template:
 Name: A meaningful pattern name.
 Problem: A statement of the problem.
 Context: The precondition under which the problem
and its solution seem to recur and for which solution
is desirable.
 Forces: Relevant forces & constraints under which the
system has to work.

41
 PATTERNS TEMPLATE

 Solutions: Static relationships & dynamic rules

describing how to realize the desired outcome.
 Examples: Sample application of pattern.
 Resulting context: The state of or configuration of the
system after the pattern has been applied. (It
describes the postconditions & side effects of the
patterns, which is called resolution of forces.)

42
 PATTERNS TEMPLATE

 Rationale: A justifying explanation of steps or rules in

the pattern.
 Related patterns: The static & dynamic relationship
between this pattern and others.
 Known uses: The known occurrences of the patterns
and its application within existing system.

43
 How Patterns Arise-A Summary
Problem

Forces

Solution

Benefits Consequences

Related Patterns

44
 Some more Examples of Patterns
Observer and MVC
 An application with Model - View - Controller setup usually uses the
Observer Pattern.
 In a Java webserver environment the Model will be represented by
Java classes encompassing the business logic,
 The View is represented by Java Server Pages which display HTML in
the client's browser &
 We will have a Servlets as Controllers.

45
 ANTIPATTERNS

 A pattern represents a “best practice”.

 Antipattern represents “worst practice” or a “lesson
learned”. Two varieties of it are:
 Those describing a bad solution to a problem that
resulted in a bad situation.
 Those describing how to get out of bad situation and
how to proceed from there to a good solution.
 It is an important research activity.

46
 CAPTURING PATTERNS

 Writing good pattern is very difficult.

 The process of looking for patterns to document is
called pattern mining or reverse architecting.
 It is important to note that a solution in which no
forces are present is not a pattern.

47
 CAPTURING PATTERNS

 Buschmann et al guidelines for capturing patterns

are:
 Focus on practicability: Pattern should describe proven
solutions.
 Aggressive disregard of originality : Pattern writer need
not be the original inventor.
 Nonanonymous review : To improve upon.
 Writers’ workshop instead of presentation:
 Careful editing :

48