Object-Oriented Methods

Too Many Methodologies

• 1986: Booch came up with the object-oriented design
concept, the Booch method.
• 1987: Sally Shlaer and Steve Mellor came up with
the concept of the recursive design approach.
• 1989: Beck and Cunningham came up with class-
responsibility- collaboration (CRC) cards.
• 1990: Wirfs-Brock, Wilkerson, and Wiener came up
with responsibility- driven design.
• 1991: Peter Coad and Ed Yourdon developed the
Coad lightweight and prototype-oriented approach.
2
 Too Many Methodologies

• 1991: Jim Rumbaugh led a team at the research labs

of General Electric to develop the object modeling
technique (OMT).
• 1994: Ivar Jacobson introduced the concept of the
use case.

3
Survey of Some of the Object- Oriented
Methodologies

• 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.

4
• Rumbaugh et al. – well-suited for describing the object
model or static structure of the system.

• Booch method – produces detailed object oriented

models.

• Jacobson method – is good for producing user-driven

analysis models.

5
Object Oriented Analysis
(OOA / Coad-Yourdon)

6
10
Object Oriented Design
(OOD/Booch)
 The 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 Methodology (Con’t)
• The Booch method consists of the following
diagrams:
– Class diagrams
– Object diagrams
– State transition diagrams
– Module diagrams
– Process diagrams
– Interaction diagrams
 The Booch Methodology (Con’t)

• The Booch methodology prescribes

– A macro development process

– A micro development process.

The Macro Development Process
• 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.
18
 The Micro Development Process
• The micro development process consists
of the following steps:
1. Identify classes and objects.
2. Identify class and object semantics.
3. Identify class and object
relationships.
4. Identify class and object interfaces and
implementation.
Hierarchical Object Oriented Design
(HOOD)
 Hierarchical Object Oriented Design

• HOOD is a method of hierarchical decomposition

of the design into software units based on
identification of objects, classes and operations
reflecting problem domain entities or more
abstract objects related to digital programming
entities.

• It is intended for the Architectural Design,

Detailed Design and coding for software to be
developed in programming languages such as
 Hierarchical Object Oriented Design

The main process in HOOD is called the Basic Design

Step.

• "A Basic Design Step has as its goal the

identification of child objects of a given parent
object, and of their individual relationships to
other existing objects, or the refinement of a
terminal object to the level of the code. This
process is based on the identification of objects by
means of object-oriented design techniques”
 Hierarchical Object Oriented Design
A basic design step process is further split into four phases, thus
defining a micro life-cycle for a design step: -
1. Problem definition
• Statement of the problem
• Analysis and structuring of requirement data
2. Development of solution strategy
3. Formalization of the strategy
•Object identification.
•Operation identification.
•Grouping objects and operations (object operation table).
•Graphical description.
•Justification of design decisions.
4. Formalization of the solution
24
 Hierarchical Object Oriented Design

Phase 1 Phase 1 : Problem Definition

Problem definition
The context of the object to be designed is stated, with
Phase 2 the goal of organizing and structuring the data
Development of from the requirement analysis phase. This is an
solution strategy opportunity to provide a completeness check on
requirements and traceability to design.
Phase 3 1.Statement of the problem - the designer states the
Formalization of the problem in
strategy correct sentences which provides:
-a clear and precise definition of the problem;
-the context of the system to design.
Phase 4
Formalization of the
solution 2.Analysis and structuring of requirement data - the
designer gathers and analyses all the information
relevant to the problem, including the environment
of the system to be designed.
 Hierarchical Object Oriented Design

Phase 1 Phase 2 : Development of solution strategy

Problem definition

Phase 2 The outline solution of the problem stated above is

Development of described in terms of objects at a high level of
solution strategy abstraction.

Phase 3
Formalization of the
strategy

Phase 4
Formalization of the
solution
 Hierarchical Object Oriented Design

Phase 1 Phase 3 : Formalization of the strategy

Problem definition

Phase 2 The objects and their associated operations are

Development of defined. A HOOD diagram of the proposed
solution strategy design solution is produced, allowing easy
visualization o f t h e c o nc ep ts a n d f u rth er
Phase 3 formalization. There are five sub phases in the
Formalization of the formalization of the strategy:
strategy
1. Object identification.
Phase 4 2. Operation identification.
Formalization of the
solution 3. Grouping objects and operations (object
operation table).
4. Graphical description.
5. Justification of design decisions.
 Hierarchical Object Oriented Design

Phase 1 Phase 4 : Formalization of the solution

Problem definition

Phase 2 The solution is formalized through:

Development of
• formal definition of provided object interfaces.
solution strategy
• formal description of object and operation
Phase 3 control
Formalization of the structures.
strategy

Phase 4
Formalization of the
solution
The main diagram used for describing the structure
of a system is the HOOD object diagram, which
shows a static view of the structure in th e
hierarchical object oriented design. The symbols
used are as follows:
 Person Compa
nam addre nyname
national_insurance works_f Hire addre
e ss _no or
Work Manag Fire ss
Chare_tim phone
er er produ
e
Departm
ct
Earn_salar
ent
y

Produ
proje Product_na ct weig Manu
ct me ht -
Project_na
me
Compone Optional_ext factur
Budget nt ras es
priority

1
2
Object Modeling Technique
(OMT)

31
 Rumbaugh et. al.’s Object Modeling
Technique (OMT)
• OMT describes a method for the analysis,
design, and implementation of a system using
an object-oriented technique.
 OMT (Con’t)
•OMT consists of four phases, which can be
performed iteratively:
1. Analysis. The results are objects and dynamic
and functional models.
2. System design. The result is a structure of the basic
architecture of the system.
3. Object design. This phase produces a design
document, consisting of detailed objects and
dynamic and functional models.
4. Implementation. This activity produces reusable,
extendible, and robust code.
 OMT (Con’t)
• OMT separates modeling into three different
parts:
1. Object model,
2. Dynamic model
3. Functional model
OMT Object Model
OMT Dynamic Model
OMT Functional Model
 Jacobson Methodology
(Object-Oriented Software Engineering)

• 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.
 Object-Oriented Software Engineering

• OOSE consists of 5 models:

1. Requirement model : The aim of this model is to gather

software requirements.
2. Analysis model : The goal of this model is to produce
ideal, robust and modifiable structure of an object.
3. Design model : It refine the objects keeping the
implementation environment in mind.
4. Implementation model : It implements the objects.
5. Test model : The goal of the test model is to validate
and verity the functionality of the system.
Responsibility – Driven Design

40
 Responsibility – Driven Design
• Which should be the basis for actual implementation is developed from the
requirements specification.
• It supports the basic concepts of object orientation, such as classes, objects
and inheritance.
• It consists of two phases:
1. Exploratory phase : consists of
1. Classes
2. Responsibilities of each class
3. Collaborations between classes
2. Refining phase : consists of
1. Hierarchies between classes
2. Subsystems
3. protocols
41
 Case Studies :

ü Warehouse Management System

ü Telecom
Warehouse Management System
 ACME Warehouse Management System

• The system will support warehouse management.

• The company ordering the system, ACME Warehouse Management
Inc., specializes in supporting its customers with warehouse spaces all
over the nation.
• ACME plans to grow and now an information system with which they
can grow.
• The idea is to offer the customers warehouse space and redistribution
services between different warehouses with full computer support.
• The service includes redistribution both within a warehouse and
between warehouses, all dictated by customer needs. All kinds of
items may be stored in the warehouses.
The following people will be using the system:

ü Foreman - responsible for one warehouse

ü Warehouse worker - works in a warehouse, loading and unloading
ü Truck driver - drives a truck between different warehouses
ü Forklift operator - drives a forklift in one warehouse
ü Office personnel - receive orders and requests from customers
ü Customers - own the item in the warehouses an give
instructions as to where and when they want
the items
The Requirements model:
üThe first model to be developed in the requirements model
üThis model is used to gain a better understanding of the system
üInitially the actors may be identified as roles played by people
interacting with our system
49
50
51
The Analysis model:
üThe use cases will now be broken down into the analysis model and we
will thus identify the objects that offer the use cases.
üInitially, the interface objects, entity objects And control objects will be
identified.
üThese objects are normally identifies in an iterative manner over a use
case and then over all use cases offered by them.
üThen, to identify the subsystems

52
53
54
55
56
57
58
Construction:
üThe main purpose of the construction and implementation process is to
customize the logical model for a specific implementation environment
and to implement the system
üInitially, identify the implementation environment
üThen, ideal block structure to be created
üThen, to create usecase design
üFinally, construct the code

59
60
61
62
63
64
65
Telecom
 Telecommunication Switching Systems

• Discuss about the development of a telecom switching system.

• The focus is on the parts handling a local phone call between two
subscribers connected to the same switch.
• The subscriber that calls is called the A-Subscriber. As she or he dials
the number, the exchange analyzes the digits and looks up the line to
the subscriber to be called. This subscriber is called the B-Subscriber.
• The exchange then connects the lines of the two subscribers so that
they can talk to each other.
• When they have finished the exchange to disconnect the two lines.
Actual functional requirements:
1. Call handling
• Call between A-subscriber line and B-subscriber line
• Call between A-subscriber line and Outgoing line
• Call between Incoming line and B-subscriber line
• Call between Incoming line and Outgoing line
2. Operation and maintenance
• Subscription changes
• Changes in Digit Information
• Connection of Devices
The Requirements model:
72
73
74
75
The Analysis model:
üIt is developed from the use cases.

76
77
78
79
80
81
The Design model:
üRefine the analysis model

82
83
84
85
86
87
The Implementation model:

88
89