MODULE 1

CHAPTER 1

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Object-Oriented Systems
Development:
Using the Unified Modeling
Language

Object Basics

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Goals

• Define Objects and classes

• Describe objects’ methods,
attributes and how objects
respond to messages,
• Define Polymorphism,
Inheritance, data abstraction,
encapsulation, and protocol,

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Goals (Con’t)
• Describe objects relationships,
• Describe object persistence,
• Understand meta-classes.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 What is an object?
• The term object was first formally
utilized in the Simula language to
simulate some aspect of reality.
• An object is an entity.
– It knows things (has attributes)
– It does things (provides services
or has methods)

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 It Knows things (attributes)
I am an Employee.
I know my name,
social security number and
my address.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Attributes (Con’t)

I am a Car.
I know my color,
manufacturer, cost,
owner and model.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Attributes (Con’t)
I am a Fish.
I know my date of
arrival and
expiration.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 It does things (methods)
I know how to
compute
my payroll.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Methods (Con’t)

I know how
to stop.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Methods (Con’t)

I know how
to cook myself.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 What is an object? (Con’t)
• Attributes or properties describe
object’s state (data) and methods
define its behavior.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Object is whatever an
application wants to talk about.
• For example, Parts and assemblies
might be objects of bill of material
application.
• Stocks and bonds might be
objects of financial investment
applications.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Objects
• In an object-oriented system,
everything is an object: numbers,
arrays, records, fields, files, forms,
an invoice, etc.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Objects (Con’t)
• An Object is anything, real or
abstract, about which we store
data and those methods that
manipulate the data.
• Conceptually, each object is
responsible for itself.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Objects (Con’t)
A window object is responsible
for things like opening, sizing,
and closing itself.
A chart object is responsible for
things like maintaining its data
and labels, and even for drawing
itself.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Two Basic Questions
When developing an O-O
application, two basic questions
always arise.
• What objects does the
application need?
• What functionality
should those objects
have?
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 Traditional Approach
• The traditional approach to
software development tends
toward writing a lot of code to do
all the things that have to be done.
• You are the only active entity and
the code is just basically a lot of
building materials.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Object-Oriented Approach
• OO approach is more like creating
a lot of helpers that take on an
active role, a spirit, that form a
community whose interactions
become the application.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Object’s Attributes
• Attributes represented by data
type.
• They describe objects states.
• In the Car example the car’s
attributes are:
• color, manufacturer, cost, owner,
model, etc.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Object’s Methods
• Methods define objects behavior
and specify the way in which an
Object’s data are manipulated.
• In the Car example the car’s
methods are:
• drive it, lock it, tow it, carry
passenger in it.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Objects are Grouped in Classes
• The role of a class is to define the
attributes and methods (the state
and behavior) of its instances.
• The class car, for example, defines
the property color.
• Each individual car (object) will
have a value for this property,
such as "maroon," "yellow" or
"white."
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 Employee Class

John object Jane object Mark object

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 A Class is an Object Template, or
an Object Factory.

B o e in g A i r p l a n e O b j e c ts
( B o e in g in s ta n c e s )

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Class Hierarchy
• An object-oriented system
organizes classes into subclass-
super hierarchy.
• At the top of the hierarchy are the
most general classes and at the
bottom are the most specific

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Class Hierarchy (Con’t)
• A subclass inherits all of the
properties and methods (procedures)
defined in its superclass.
Motor Vehicle

Bus Truck Car

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Inheritance
(programming by extension )
• Inheritance is a relationship
between classes where one class is
the parent class of another
(derived) class.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Inheritance (Con’t)
• Inheritance allows classes to share
and reuse behaviors and
attributes.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Inheritance (Con’t)
• The real advantage of inheritance
is that we can build upon what we
already have and,
• Reuse what we already have.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Inheritance (Con’t)
V ehicle

C ar
I know how to stop
stop m ethod is reusable
F ord

M ustang Taurus Thunderbird

I don’t know how to stop

stop (m yM ustang)
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 Multiple Inheritance
• OO systems permit a class to inherit
from more than one superclass.
• This kind of inheritance is referred
to as multiple inheritance.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Multiple Inheritance (Con’t)
• For example utility vehicle inherents
from Car and Truck classes.
MotorVehicle

Truck Car Bus

UtilityVehicle

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Encapsulation and Information
Hiding
• Information hiding is a principle
of hiding internal data and
procedures of an object.
Permissible operations

Data
Private Protocol
Messages
Public Protocol
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 Encapsulation and Information
Hiding (Con’t)
• By providing an interface to each
object in such a way as to reveal as
little as possible about its inner
workings.
• Encapsulation protects the data
from corruption.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Protocol
• Protocol is an interface to the
object.
• TV contains many complex
components, but you do not need
to know about them to use it.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Message
• Objects perform operations in
response to messages.
• For example, you may
communicate with your computer
by sending it a message from
hand-help controller.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 A Case Study - A Payroll Program
• Consider a payroll program that
processes employee records at a small
manufacturing firm. This company has
three types of employees:
• 1. Managers: Receive a regular salary.
• 2. Office Workers: Receive an hourly wage
and are eligible for overtime after 40 hours.
• 3. Production Workers: Are paid according to
a piece rate.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Structured Approach
FOR EVERY EMPLOYEE DO
BEGIN
IF employee = manager THEN
CALL computeManagerSalary
IF employee = office worker THEN
CALL computeOfficeWorkerSalary
IF employee = production worker
THEN CALL
computeProductionWorkerSalary
END
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 What if we add two new types of
employees?
• Temporary office workers
ineligible for overtime,
• Junior production workers who
receive an hourly wage plus a
lower piece rate.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 FOR EVERY EMPLOYEE DO
BEGIN
IF employee = manager THEN
CALL computeManagerSalary
IF employee = office worker THEN
CALL computeOfficeWorker_salary
IF employee = production worker THEN
CALL computeProductionWorker_salary
IF employee = temporary office worker THEN
CALL computeTemporaryOfficeWorkerSalary
IF employee = junior production worker THEN
CALL computeJuniorProductionWorkerSalary
END
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 An Object-Oriented Approach
• What objects does the application
need?
– The goal of OO analysis is to
identify objects and classes that
support the problem domain and
system's requirements.
– Some general candidate classes are:
– Persons
– Places
– Things
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 What are some of the
application’s classes?
• Employee
• Manager
• Office Workers
• Production Workers

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Class Hierarchy
• Identify class hierarchy
• Identify commonality among the
classes
• Draw the general-specific class
hierarchy.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Class Hierarchy (Con’t)
Employee
name
address
salary
SS#

OfficeWorker Manager ProductionWorker

dataEntry dataEntry dataEntry

ComputePayroll ComputePayroll ComputePayroll
printReport printReport printReport

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 OO Approach
FOR EVERY EMPLOYEE DO
BEGIN
employee computePayroll
END

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 If a new class of employee were
added
E m p lo yee
n am e
ad d ress
salary
SS#

O fficeW o rk er M a n a g er P ro d u ctio n W o rk er

d ataE n try d ataE n try d ataE n try

C o m p u teP ay ro ll C o m p u teP ay ro ll C o m p u teP ay ro ll
p rin tR ep o rt p rin tR ep o rt p rin tR ep o rt

T e m p o ra ry O ffic e W o rk er J u n io rP ro d u c tio n W o rk e r

C o m p u teP ay ro ll C o m p u teP ay ro ll

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Polymorphism
• Polymorphism means that the
same operation may behave
differently on different classes.
• Example: computePayroll

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Associations
• The concept of association
represents relationships between
objects and classes.
• For example a pilot can fly planes.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Associations (Con’t)

Pilot can fly flown by Planes

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Clients and Servers
• A special form of association is a
client-server relationship.
• This relationship can be viewed as
one-way interaction: one object
(client) requests the service of
another object (server).

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Clients and Servers (Con’t)

PrintServer Request for printing Item

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Objects and Persistence
• Objects have a lifetime.
• An object can persist beyond
application session boundaries,
during which the object is stored
in a file or a database, in some file
or database form.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Meta-Classes
• Everything is an object.
• How about a class?
• Is a class an object?
• Yes, a class is an object! So, if it is
an object, it must belong to a class.
• Indeed, class belongs to a class
called a Meta-Class or a class'
class.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 Meta-Classes (Con’t)
• Meta-class used by the compiler.
For example, the meta-classes
handle messages to classes, such
as constructors and "new."

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Summary
• Rather than treat data and
procedures separately, object-
oriented programming packages
them into "objects."
• O-O system provides you with
the set of objects that
closely reflects the
underlying application

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Summary (Con’t)
Advantages of object-oriented
programming are:
• The ability to reuse code,
• develop more maintainable
systems in a shorter amount of
time.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Summary (Con’t)

• more resilient to change, and

• more reliable, since they are built
from completely tested and
debugged classes.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Object-Oriented Systems
Development:
Using the Unified Modeling
Language

Chapter 2:
Object-Oriented Methodologies

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Goals
• Object-Oriented Methodologies
– The Rumbaugh et al. OMT
– The Booch methodology
– Jacobson's methodologies

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Goals (Con’t)
• Patterns
• Frameworks
• Unified Approach (UA)
• layered Architecture

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 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.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 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.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 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

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 OMT Dynamic Model
No account has been selected

Account has been

Nothing is selected
selected

Select Checking or Select Checking

saving account account

Select transaction
type (withdraw, Enter the amount
deposit, transfer)

Confirmation

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 OMT Functional Model
Data
Store

Process Client Account

Data
Flow
Card
Reader PIN Code Process PIN Code

External
Entity

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 The Booch Methodology (Con’t)
Car

color
manufacturer
superclass
cost

inherits

Ford

inherits

Mustang Taurus Escort

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 The Booch Methodology (Con’t)
Operator::TurnOffAlarm

Enabled
SoundAlarm
Silenced Sounding
SilenceAlarm

Enable Disable

AlarmFixed
Disabled

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 The Booch Methodology (Con’t)
• The Booch methodology
prescribes
– A macro development process

– A micro development process.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 The Macro Development Process
1. Conceptualization.
• Establish the core requirements of the system.
• Establish a set of goals and develop a prototype to
prove the concept.
2. Analysis and development of the model.
• Use the class diagram to describe the roles and
responsibilities objects are to carry out in
performing the desired behavior of system.
• Use the object diagram to describe the desired
behavior of the system in terms of scenarios.
• Use the interaction diagram to describe behavior
of system in terms of scenarios.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 The Macro Development Process
3. Design or create the system architecture.
• Use the class diagram to decide what classes exist
and how they relate to each other.
• Use the object diagram to decide what
mechanisms are used to regulate how objects
collaborate.
• Use the module diagram to map out where each
class and object should be declared.
• Use the process diagram to determine to which
processor to allocate a process.
• Determine the schedules for multiple processes
on each relevant processor.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 The Macro Development Process

4. Evolution or implementation.
• Successively refine the system through many
iterations.
• Produce a stream of software implementations
(or executable releases), each of which is a
refinement of the prior one.
5. Maintenance.
• Make localized changes to the system to add
new requirements and eliminate bugs.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Use Cases (Con’t)
– How and when the use case will
store data in the system.
– Exceptions to the flow of events.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Library

Checking out books

Getting an
Interlibrary loan

Doing research

Reading books,
Member
Newspapers

Purchasing Supplies
Supplier

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Objectory (Con’t)
• Objectory is built around several different models:
• Use case model. The use case model defines the
outside (actors) and inside (use case) of the system's
behavior.
• Domain object model. The objects of the "real" world
are mapped into the domain object model.
• Analysis object model. The analysis object model
presents how the source code (implementation) should
be carried out and written.
• Implementation model. The implementation model
represents the implementation of the system.
• Test model. The test model constitutes the test plans,
specifications, and reports

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 OOBE (Con’t)
• OOBE consists of :
– Analysis phase
– Design
– Implementation phases and
– Testing phase.
• Analysis phase It should not take into account
the actual implementation environment. This
reduces complexity and promotes maintainability
over the life the system, since the description of the
system will be independent of hardware and
software requirements.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 • Design and implementation phases.
– The implementation environment must be identified for the
design model.
– This includes factors such as DBMS, distribution of process,
constraints due to the programming language, available
component libraries, and incorporation of graphical user
interface tools.
– It may be possible to identify the implementation
environment concurrently with analysis.
– The analysis objects are translated into design objects that fit
the current implementation environment.
• Testing phase.
– Jacobson describes several testing levels and techniques.
– unit testing
– integration testing
– system testing.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.
• A design pattern is a general reusable
solution to a commonly occurring problem
in software design.
• A design pattern is not a finished design
that can be transformed directly into code.
• It is a description or template for how to
solve a problem that can be used in many
different situations.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Capturing Patterns
• Guidelines for capturing patterns:
– Focus on practicability.
– Aggressive disregard of originality.
– Nonanonymous review.
– Writers' workshops instead of
presentations.
– Careful editing.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Capturing Patterns contd…
• Focus on practicability. Patterns should
describe proven solutions to recurring
problems rather than the latest scientific
results.
• Aggressive disregard of originality. Pattern
writers do not need to be the original
inventor or discoverer of the solutions that
they document.
• Nonanonymous review. Pattern submissions
are shepherded rather than reviewed. The
shepherd contacts the pattern author(s) and
discusses with him or her how the patterns
might be clarified or improved on.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Capturing Patterns contd…
• Writers' workshops instead of presentations.
Rather than being presented by the individual
authors, the patterns are discussed in writers'
workshops, open forums where all attending
seek to improve the patterns presented by
discussing what they like about them and the
areas in which they are lacking.
• Careful editing. The pattern authors should
have the opportunity to incorporate all the
comments and insights during the
shepherding and writer's workshops before
presenting the patterns in their finished form.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 Differences Between Design
Patterns and Frameworks
• Design patterns are more abstract than
frameworks.
– Frameworks can be embodied in code, but only examples of patterns can
be embodied in code.
• Design patterns are smaller architectural
elements than frameworks.
– A typical framework contains several design patterns but the
reverse is never true.
• Design patterns are less specialized than
frameworks.
– Frameworks always have a particular application domain. In contrast,
design patterns can be used in nearly any kind of application.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Develop Use- Develop Identify classes,
Cases, activity Refine
interaction relationships, and
diagrams diagrams attributes &
Identify Actors prototyping iterate
methods

Construction O-O Analysis

Component Layered
Based Repository Approach
Development 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
Design classes, Apply Design Designv view User satisfaction &
their attributes, Axioms and access Usability tests
methods, Layers and based on use cases
association, Build UML class
diagram prototypes
structure ...
Continuous Testing

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

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

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 UA Processes (Con’t)
• The processes are:
– Use-case driven development.
– Object-oriented analysis.
– Object-oriented design.
– Incremental development and
prototyping.
– Continuous testing.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 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.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 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.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 Iterative Development and
• The UAContinuous Testing
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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Modeling Based on the Unified
Modeling
• The UA uses the Language
unified modeling
language (UML) to describe and
model the analysis and design
phases of system development.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.
• Traceability is the ability to verify the
history, location, or application of an item
by means of documented recorded
identification.
• This allows us to produce designs that are
traceable across requirements, analysis,
design, implementation, and testing.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Problem With the Two-Layer
Architecture
• This approach results in objects
that are very specialized and
cannot be reused easily in other
projects.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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
Title
Owner Data

Workstation

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 User Interface layer
This layer is typically responsible
for two major aspects of the
applications:
• Responding to user interaction
• Displaying business objects.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Business Layer: Real Objects
(Con’t)
These objects should not be
responsible for:
• Displaying details
• Data access details

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Access Layer
• The access layer has two major
responsibilities:
• Translate request
• Translate result

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Three-Layered Architecture

Access
Layer

Business
Layer

View
Layer

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Summary
• we looked at current trends in
object-oriented methodologies,
which have been toward
combining the best aspects of
today's most popular methods.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 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.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 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.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 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.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Object-Oriented Systems
Development:
Using the Unified Modeling
Language

Chapter 3:
Unified Modeling Language

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Goals
• Modeling.
• Unified modeling language.
– Class diagram.
– Use case diagram.
– Interaction diagrams.
•Sequence diagram.
•Collaboration diagram.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Goals (Con’t)
– Statechart diagram.
– Activity diagram.
– Implementation diagrams.
•Component diagram.
•Deployment diagram.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Introduction
• A model is an abstract representation
of a system, constructed to
understand the system prior to
building or modifying it.
• Most of the modeling techniques
involve graphical languages.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Static or Dynamic Models
• Models can represent
– static or
– dynamic situations.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Static Model
• A static model can be viewed as a
"snapshot" of a system's
parameters at rest or at a specific
point in time.
• The classes’ structure
and their relationships
to each other frozen
in time are examples of
static models.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 Dynamic Model
• Is a collection of procedures or
behaviors that, taken together,
reflect the behavior of a system
over time.
• For example, an order interacts
with inventory to determine
product availability.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Why Modeling?
• Turban cites the following
advantages:
• Models make it easier to express
complex ideas.
• For example, an architect
builds a model to
communicate ideas
more easily to clients.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Advantages of Modeling (Con’t)
• Models reduce complexity by
separating those aspects that are
unimportant from those that are
important.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Advantages of Modeling (Con’t)
• Models enhance learning.
• The cost of the modeling analysis
is much lower than the cost of
similar experimentation
conducted with a real system.
• Manipulation of the model
(changing variables) is much
easier than manipulating a real
system.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 Modeling Key Ideas
• A model is rarely correct on the
first try.
• Always seek the advice and
criticism of others.
• Avoid excess model revisions, as
they can distort the essence of
your model. Let simplicity and
elegance guide you through
the process.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 The Unified Modeling Language
(UML)
• The unified modeling language
(UML) is a language for specifying,
constructing, visualizing, and
documenting the software system
and its components.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 UML Diagrams
The UML defines nine graphical
diagrams:
1. Class diagram (static)
2. Use-case diagram
3. Behavior diagrams (dynamic):
– 3.1. Interaction diagram:
•3.1.1. Sequence diagram
•3.1.2. Collaboration diagram

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 UML Diagrams
– 3.2. Statechart diagram
– 3.3. Activity diagram
4. Implementation diagram:
4.1. Component diagram
4.2. Deployment diagram

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 UML Class Diagram,
• The UML class diagram is the
main static analysis diagram.
• Class diagrams show the static
structure of the model.
• Class diagram is collection of
static modeling elements, such as
classes and their relationships.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Class Notation
• In class notation, either or both the
attributes and operation compartments
may be suppressed.
Boeing 737 Boeing 737
length: meter
fuelCapacity: Gal
Boeing 737 doors: int

length: meter
fuelCapacity: Gal lift ()
doors: int break ()

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Class Interface Notation
• Class interface notation is used to
describe the externally visible
behavior of a class.
• For example, an operation with a
public visibility.

Person BankAccount

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Binary Association Notation
• A binary association is drawn as a
solid path connecting two classes or
both ends may be connected to the
same class.
worksFor
Company Person
employer employee

Person

marriedTo

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Association Role
• A simple association—the
technical term for it is binary
association—is drawn as a solid
line connecting two class symbols.
• The end of an association, where
it connects to a class, shows the
association role.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 UML Association Notation
• In the UML, association is represented
by an open arrow.

BankAccount Person

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Qualifier
• A qualifier is an association attribute.
For example, a person object may be
associated to a Bank object.
• An attribute of this association is the
account#.
• The account# is the Bank
qualifier of this account#
*
association.
0..1
Person
.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Multiplicity
• Multiplicity specifies the range of
allowable associated classes.
• It is given for roles within
associations, parts within
compositions, repetitions, and other
purposes.
• lower bound .. upper bound.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 OR Association
• An OR association indicates a
situation in which only one of several
potential associations may be
substantiated at one time for any
single object.
Person
Car {or}

Company

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Association Class
• An association class is an association
that also has class properties.
• An association class is shown as a class
symbol attached by a dashed line to an
association path(constraints).
Company Person
employer employee

WorksFor
salary

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 N-Ary Association
• An n-ary association is an association
among more than two classes.
• Since n-ary association is more
difficult to understand, it is better to
convert an n-ary association to binary
association. semester Year*
* *
Class Student
class student

GradeBook
grade
exam
lab

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Aggregation

• Aggregation is a form of association.

• A hollow diamond is attached to the end
of the path to indicate aggregation.

1 c o n s is tO f *
T eam P la y e r
c la s s

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Composition
• Composition, also known as the a-
part-of, is a form of aggregation with
strong ownership to represent the
component of a complex object.
• The UML notation for composition is a
solid diamond at the end of a path.
Car
1 1 1 1

1 graphical composition
4 4,10 2,5
Wheel Light Door Engine
Car Car
4 4 Wheel
Wheel
4,10 nested composition
Light 4,10 Light
2,5 2,5
Door Door
1 1
Engine Engine

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Generalization
• Generalization is the relationship
between a more general class and a
more specific class.
• Generalization is displayed as directed
line with a closed, hollow Separate target style

arrowhead at the Vehicle

superclass end. Bus Truck Car

Shared target style

BoeingAirplane

Boeing 737 Boeing 757 Boeing 767

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Use-Case Diagram
• The description of a use case
defines what happens in the
system when the use case is
performed.
• In essence, the use-case model
defines the outside (actors) and
inside (use case) of the system's
behavior.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Use-Case Diagram (Con’t)
• A use-case diagram is a graph of actors, a set
of use cases enclosed by a system boundary,
communication (participation) associations
between the actors and the use cases, and
generalization among the use cases.
HelpDesk
Makingacall

Takethecall
Operator
Client Doresearch

Returnacall

Support
representative
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 Actor Notations
• The three representations of an actor
are equivalent.

<< actor>> << actor>>

Customer Customer Customer

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Use-Case Diagram (Con’t)
• These relationships are shown in
a use-case diagram:
– Communication.
– Uses.
– Extends.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Behavior or Dynamic Diagrams
• Interaction diagrams:
– Sequence diagrams
– Collaboration diagrams
• Statechart diagrams
• Activity diagrams

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 UML Interaction Diagrams
• Interaction diagrams describe how
groups of objects collaborate to
get the job done.
• Interaction diagrams capture the
behavior of a single use case,
showing the pattern of interaction
among objects.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 UML Sequence Diagram
• Sequence diagrams are an easy and
intuitive way of describing the
behavior of a system.
• A sequence diagram shows an
interaction arranged in a time
sequence. Telephone Call
Caller Exchange Receiver Talk

OffHook

DialTone
Dial Number

RingTone

OffHooke

OnHook

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 UML Collaboration Diagram
• A collaboration diagram represents a
set of objects related in a particular
context, and the exchange of their
messages to achieve a desired
outcome. Telephone
Object
Call
Caller Message

1: OffHooke
2: DialTone 3: Dial Number

Exchange
4: RingTone

Receiver

5: OffHook

6: OnHook
Talk

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 UML Collaboration Diagram
(Con’t)
Telephone Call
Object Caller Message

1.1: OffHooke 2.1: DialTone 1.2: Dial Number

Exchange
2.2: RingTone

Receiver

3.1: OffHook

4.1: OnHook
Talk

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 UML Statechart Diagram
•A statechart diagram (also
called a state diagram) shows
the sequence of states that an
object goes through during its
life in response to outside
stimuli and messages.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Idle
lift receiver and get dial tone

State

Dialing

Start Dial [Link]()

entry and start dialog
entry and [Link](n)
exit/ stop dial tone

digit(n)

Substates
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 Complex Transition

i j

A B
k l

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 UML Activity Diagram
•An activity diagram is a
variation or special case of a
state machine, in which the
states are activities
representing the performance
of operations and the
transitions are triggered by the
completion of the operations.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 UML Activity Diagram (Con’t)
Prepare
document
incoming
s

Index
documents

Make electronic
file

Complete
Request

Check data for Draw up contract

life
insurance
Mortgage-deed

Calculate data
for Pay provision
construction to
insurance
mortgag
agent
e

Draw up insurance
policy

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 UML Activity Decision

[hours < =40]

Calculate payroll Normal payroll

[hours > 40]

Overtime, get authoriation

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Swimlanes.
office clerk InsuranceAgent Loanofficer

Prepare incoming
documents

Make electronic
file Index documents

Complete
request

Check data for life Draw up concept

insurance mortgage-deed

Calculate data for

Pay provision to
construction
mortgage insurance agent

Draw up insurance
policy

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Implementation diagrams
•These diagrams show the
implementation phase of
systems development.
•Such as the source code
structure and the run-time
implementation structure.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Implementation diagrams
(Con’t)
•There are two types of
implementation diagrams:
– Component diagrams show the
structure of the code itself.
– Deployment diagrams show the
structure of the run-time system.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Component diagrams

Access Update

UI

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Deployment Diagram

Node 1: AdminServer

Access Update

Node 2: John’s PC

UI

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Model Management: Package
•A package is a grouping of
model elements.
•Packages themselves may
contain other packages.
•A package may contain both
subordinate packages and
ordinary model elements.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 A Package and Its Contents
GradeNoteBook

Year
semester *
* *
Class Student
class student

GradeBook
grade
exam
lab

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 A Package and Its Dependencies

Customer

Business Model

Clients
Bank

Account

Checking Saving

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Model Constraints and Comments
• Constraints are assumptions or
relationships among model elements
specifying conditions and
propositions that must be maintained
as true otherwise the system described
by the model would be invalid.
* WorkFor *
Person {subset}
Department
1 ManagerOf 1

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Note
• A note is a graphic symbol containing
textual information; it also could
contain embedded images.

Person employee employer Company

Represents
an incorporated
Static models & entity
revision levels
released yesterday

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Stereotype
• Stereotypes represent a built-in
extendibility mechanism of the UML.
• User-defined extensions of the UML
are enabled through the use of
stereotypes and constraints.
Flow Flow
Copy Copy

NumberOfCopy NumberOfCopy

makeCopy makeCopy

Copy

Copy
NumberOfCopy

makeCopy

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 UML Meta-Model
•A meta-model is a model of
modeling elements.
•The purpose of the UML meta-
model is to provide a single,
common, and definitive
statement of the syntax and
semantics of the elements of
the UML.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 UML Meta-Model (Con’t)
Relationship

Generalization Association
1

Association Role

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Summary
•A model is a simplified
representation of reality.
•The unified modeling
language (UML) was
developed by Booch, Jacobson,
and Rumbaugh and
encompasses the unification of
their modeling notations.
Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill
 Summary (Con’t)
• UML consists of the following
diagrams:
– Class diagram.
– Use case diagram.
– Sequence diagram.
– Collaboration diagram.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill

 Summary (Con’t)
– Statechart diagram.
– Activity diagram.
– Component diagram.
– Deployment diagram.

Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill