Object-Oriented Systems
Development:
Development
Using the Unified Modeling Language
Chapter 4:
Object-Oriented Methodologies
Goals
• Object-Oriented Methodologies
–The Rumbaugh et al. OMT
–The Booch methodology
–Jacobson's methodologies
Goals (Con’t)
• Patterns
• Frameworks
• Unified Approach (UA)
• layered Architecture
Basic Definitions
• 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.
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.
Too Many Methodologies (Con’t)
• 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.
Too Many Methodologies (Con’t)
• 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.
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.
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.
OMT (Con’t)
–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 Modeling
• OMT separates modeling into three
different parts:
–1. An object model, presented by the
object model and the data dictionary.
–2. A dynamic model, presented by the
state diagrams and event flow
diagrams.
–3. A functional model, presented by
data flow and constraints.
OMT Object Model
Client
firstName
lastName
pinCode ClientAccount Account Transaction
number AccountTransaction transDate
balance transTime
transType
deposit
amount
withdraw
createTransaction postBalance
CheckingAccount
Withdraw
CheckingSavingAccount
SavingsAccount
OMT Dynamic Model
No account has been selected
Acc ount has been
Nothing is selected
selected
Select Checking or Select Checking
saving account account
Select transaction
type (withdraw, Enter the amount
depos it, transfer)
Confirmation
OMT Functional Model
Data
Store
Process Client Account
Data
Flow
Card
Reader PIN Code Process PIN Code
External
Entity
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)
Car
color
manufacturer
superclass
cost
inherits
Ford
inherits
Mustang Taurus Escort
The Booch Methodology (Con’t)
Operator::TurnOffAlarm
Enabled
SoundAlarm
Silenced Sounding
SilenceAlarm
Enable Disable
AlarmFixed
Disabled
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.
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.
The Jacobson et al. Methodologies
• The Jacobson et al. methodologies
(e.g., OOBE, OOSE, and
Objectory) cover the entire life
cycle and stress traceability
between the different phases.
Use Cases
• Use cases are scenarios for
understanding system requirements.
• A use case is an interaction between
users and a system.
• The use-case model captures the goal
of the user and the responsibility of
the system to its users.
Use Cases (Con’t)
• 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.
Use Cases (Con’t)
–How and when the use case will store
data in the system.
–Exceptions to the flow of events.
Library
Checking out books
Getting an
Interlibrary loan
Doing research
Reading books,
Member
Newspapers
Purchasing Supplies
Supplier
Object-Oriented Software
Engineering: Objectory
• 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.
Objectory (Con’t)
• Objectory is built around several
different models:
–Use case model.
–Domain object model.
–Analysis object model. Implementation
model.
–Test model.
Object-Oriented Business
Engineering (OOBE)
• Object-oriented business
engineering (OOBE) is object
modeling at the enterprise level.
• Use cases again are the central
vehicle for modeling, providing
traceability throughout the
software engineering processes.
Use-case model
Tested in
Realized by
Express in Structured by
Implemented by
OK
NOT OK
Domain Object Analysis Design model Implementation Testing model
model model model
OOBE (Con’t)
• OOBE consists of :
–Analysis phase
–Design
–Implementation phases and
–Testing phase.
Patterns
• A pattern 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.
Patterns (Con’t)
• The main idea behind using
patterns is to provide
documentation to help categorize
and communicate about solutions
to recurring problems.
• The pattern has a name to facilitate
discussion and the information it
represents.
Patterns (Con’t)
• A good pattern will do the
following:
• It solves a problem. Patterns capture
solutions, not just abstract
principles or strategies.
• It is a proven concept. Patterns
capture solutions with a track
record, not theories or speculation.
Patterns (Con’t)
• The solution is not obvious. The best
patterns generate a solution to a
problem indirectly—a necessary
approach for the most difficult
problems of design.
• It describes a relationship. Patterns
do not just describe modules, but
describe deeper system structures
and mechanisms.
Patterns (Con’t)
• The pattern has a significant human
component.
• All software serves human comfort
or quality of life; the best patterns
explicitly appeal to aesthetics and
utility.
Capturing Patterns
• Guidelines for capturing patterns:
–Focus on practicability.
–Aggressive disregard of originality.
–Nonanonymous review.
–Writers' workshops instead of
presentations.
–Careful editing.
Frameworks
• A framework is a way of presenting
a generic solution to a problem
that can be applied to all levels in
a development.
• A single framework typically
encompasses several design
patterns and can be viewed as the
implementation of a system of
design patterns.
Differences Between Design
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.
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.
Develop Use- Develop Identify classes,
Cases, activity Refine
interaction relationships, and
diagrams diagrams attributes &
Identify Actors prototyping iterate
methods
Construction O-O Analysis
C om ponent Layered
B a sed Repository Approach
D e v e lo p m e n t of use-cases,
analysis,
Continuous design, UI,
Testing and past
Experiences
Patterns
User satisfaction Documentation UML Based
usability tests, & Traceability Modeling
quality assurance
test O-O Design
D e s ig n c la s s e s , A p p ly D e s ig n D e s ig n v v ie w U s e r s a tis f a c tio n &
th e ir a ttrib u te s , A x io m s and access U s a b ility te s ts
m e th o d s , L a ye rs a n d b ased o n use cases
a s s o c ia tio n , B u ild U M L c la s s
d iag ra m p r o to ty p e s
s t r u c tu r e ...
C o n tin u o u s T e s tin g
The Unified Approach (UA)
• The unified approach to software
development revolves around (but
is not limited to) the following
processes and components.
UA Processes (Con’t)
• The processes are:
–Use-case driven development.
–Object-oriented analysis.
–Object-oriented design.
–Incremental development and
prototyping.
–Continuous testing.
UA Methods and Technology
• The methods and technology
employed includes:
–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.
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.
Modeling Based on the Unified
Modeling Language
• The UA uses the unified modeling
language (UML) to describe and
model the analysis and design
phases of system development.
The UA Proposed Repository
• The requirement, analysis, design, and
implementation documents should be
stored in the repository, so reports can
be run on them for traceability.
• This allows us to produce designs that
are traceable across requirements,
analysis, design, implementation, and
testing.
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.
Name
Address
Title
Owner Data
Workstation
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:
–they are represented to the user
(through an interface) or
–how they are physically stored.
Name
Address
Tit le
Owner Data
Workstatio n
User Interface layer
This layer is typically responsible
for two major aspects of the
applications:
• Responding to user interaction
• 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.
Business Layer: Real Objects
(Con’t)
These objects should not be
responsible for:
• Displaying details
• Data access details
Access Layer
• The access layer contains objects
that know how to communicate
with the place where the data
actually resides,
• Whether it be a relational database,
mainframe, Internet, or
file.
Access Layer
• The access layer has two major
responsibilities:
• Translate request
• Translate result
Three-Layered Architecture
Access
Layer
Business
Layer
View
Layer
Summary
• we looked at current trends in
object-oriented methodologies,
which have been toward
combining the best aspects of
today's most popular methods.
Summary (Con’t)
• Each method has its strengths.
Rumbaugh et al. have a strong method
for producing object models.
• Jacobson et al. have a strong method for
producing user-driven requirement
and object-oriented analysis models.
• Booch has a strong method for
producing detailed object-oriented
design models.
Summary (Con’t)
• Each method has weakness, too. While
OMT has strong methods for modeling
the problem domain, OMT models
cannot fully express the requirements.
• Jacobson, although covering a fairly wide
range of the life cycle, does not treat
object-oriented design to the same level
as Booch, who focuses almost entirely
on design, not analysis.
Summary (Con’t)
• The UA is an attempt to combine the
best practices, processes, and
guidelines along with UML
notations and diagrams for better
understanding of object-oriented
concepts and object-oriented
system development.
