CIS490

Software Engineering
Object Oriented Analysis
Object oriented
analysis
The world is made of objects. Just open your eyes
and ears. They are out there. Bank customers,
students, cats, elephants, cars, balls of string,
atoms, molecules, tubs of ice cream, Madonna,
stars, bureaucrats, Robin Hood. The world is built
of objects. Objects are built of smaller objects, and
so ad infinitum. Objects combine to make bigger
objects. We already live in an object-oriented
world.
The first thing an object analyst must do is to remove
the scales from his or her eyes. Object modeling
consists of looking for objects. Of course, there has to
be some boundary. Even sitting at my desk I can see
more objects than I could reasonably list. But that is
where the beauty of object modeling comes in. It uses
observation.
Objects can be described by their attributes and
operations. Attributes are the changeable
characteristics of an object. Cats have color, size,
weight and a preference for either Kit-E-Kat or
Whiskers. Operations are the things an object does
or can have done to it. Cats can catch mice, eat,
miaow, worm up to owners, and be stroked. In our
notation we draw an object such as a cat like this.
The name is shown at the top. The
attributes are listed underneath. The
operations are listed below that.
Actually, strictly speaking, this is the
most very simple class diagram.
In an object model, all data is stored as attributes
of some object. The attributes of an object are
manipulated by the operations. The only way of
getting at the attributes is through an operation.
In an object model, all functionality is defined
by operations. Objects may use each others
operations, but the only legal way one object can
manipulate another object is through an
operation. An operation may inform, say "mass
of ball", or change the state of an object, say
"throw ball".
Object modeling is about finding objects,
their attributes and their operations, and
tying them together in an object model.
Nothing more. Here are some more objects:
Some of these objects may seem jockey, but
they could reasonably be part of a system, be it a
computer game or a multimedia story. Do not be
constrained to be those dull systems that most
software engineers drag out. Object modeling
can be used to design lots of things.
By now you should be getting the idea that
object modeling is, at its simplest level, very
straightforward. The trick comes in knowing
what objects are appropriate, and what their
appropriate attributes and operations are. It is a
question of focus. We will consider some ways
of controlling focus later in the course.
How do objects relate to other concepts in design
methods?
Remember entity-relationship models? SSADM, JSD and so
on have a notion of entity. These are really objects. All we are
doing in object modeling is relabelling entity modeling.
However, we put the emphasis on capturing and grouping
together both functions and data (operations and attributes in
our terminology). That is the elegant simplicity of object
modeling. We will look at object models later which look
remarkably like entity-relationship models (because they are).
We will now look one powerful way of
arranging objects - inheritance hierarchies.
Inheritance
Often we will find that there are objects which have
something in common. It is then useful to create an
abstract object which groups together the common
features, and to use inheritance to define the
original objects.
For example, consider our two fairy story creatures:

Now we can see that they both have the same operations
"arrive" and "meet". We can therefore create an abstract
creature
which has the common operations. We can then draw the original
objects grouped under the abstract object as follows
Inheritance means that all the attributes and operations of an
abstract object are available in the specialized object below.
The triangle in the diagram indicates inheritance. The point of
the triangle indicates where operations and attributes are
inherited from.

Now we can enter a debate about whether nose, teeth and

appetite are characteristics of all creatures or not. It they are,
we can revise the diagram above as:
By this device Red Riding Hood has also appetite,
nose and teeth as operations. The latter two may be of
relevance when she goes to charm the woodcutter,
provided they are petite and pearly bright respectively.
Okay, so let's have some more practical examples for
those of you who have to do real work. Firstly, the
frighteningly dull student-lecturer example. You can
do the same with the equally dull employee-customer
example.
The big deal about inheritance
Inheritance is considered good for the software re-use and for
clarity of description.

Re-use
When new objects are created which are similar to other
objects, they can have many of their attributes and operations
ready defined. Let us suppose we now introduce Grandma into
our fairy story hierarchy.
Here we get a Grandma who already had an appetite,
nose and teeth and who can arrive and meet. Actually
these are not in the normal scope of the fairy story, but
the principle should be clear.
We might be writing a simple geometry program
Now to add circles we simply put in another object under 2D
shape

So the circle object need not define the area and position
attributes or the get area operation
It is now possible to buy or obtain ready-built class hierarchies
written in object-oriented languages which can be extended in
this way to produce a new application.
Designing complex class hierarchies takes time and good
design requires experience. But the basic principles outlined
above, with some intuitive guidelines, are the basis for the
design of good, re-usable designs.
Re-use can be viewed from two directions. Components can
be re-used, which is a sort of bottom-up approach to re-use. Or
designs can be re-used. Both elements are important in the
production of re-usable software.
Relationships
Objects can be related in other ways than by inheritance and
aggregation. Any relationship between real world objects can
be modeled: cats eat canaries, dogs bite postmen, the
woodcutter murders the wolf, cars run over little old ladies,
employees work for organizations, patients visit hospitals,
patients stay in hospitals.
One to one relationships
In a one-to-one relationship, one object is associated with exactly one of its related
objects. This is modelled by a straight line drawn between the objects. If the
relationship is one-way, then an arrow is used to indicate the direction. The line can be
labelled.
Thus a man marries one woman (at a time) and a
woman marries one man (at a time). A cat eats
one canary (before being battered to death by the
little old lady who owned the canary). Canaries
do not (in general) eat cats, so the eats
relationship is one way.
One to many relationships
Sometimes one object can be related to many objects. This is indicated
by different marks at the end of the line.

A player plays for one football team. There are at least 11 players for a
given football team. Football teams do not play for players.
Many to many relationships

Sometimes objects at either end of a relationship may be related to many

objects at the other end

A dog may bite zero or more postmen. A postman may be bitten by zero
or more dogs.
A lubricant is recommended for at least one engine. An engine has at
least one lubricant recommended for it.
The OOA Process - I

Steps and Rules

Objects and Structures
 The Steps of OOA - Part 1
• identify objects (classes)
• identify structures
– generalization - specialization (“ISA”)
– whole - parts (“PART-OF”)
– association (relationship)
• define attributes

===> Static Objectdiagram

===> incomplete Object Dictionary
 The Steps of OOA - Part 2
• define services via scenarios
– services per object
– message passing between objects
– coordination of message passing
– states and transitions

===> Scenarios
===> complete Object Dictionary
 OOA - Object
• generalization of
a set of real-life entities/objects
label • groups a set of attributes (schema)
• can be active (services)
• has memory (states)
label • participates in structures
• label: typically a noun
• specified in the object dictionary
OOA - Object Class & Instance
• A symbol for
an object class and
its object instances.
• a description of one or more
label objects with a uniform set of
attributes and services, and the
actual object instances belonging
to the given class
• “usual way” to model an object
 OOA - Whole-Part
• groups objects by combining
whole smaller parts into larger units
(min,max) (min,max) • forms a hierarchy by
– aggregation
– decomposition
(min, (min,
max) max) • cardinalities must be specified
part1 part2 (min , max)
• no inheritance
 OOA - Generalization-
Specialization
• groups objects based on similarity
gen
of attributes and services
• forms a class hierarchy by
– generalization
– specialization
• attributes, services, etc. are
spec1 spec2
inherited by the more specialized
from the more general objects
 Employee
name Inheritance
address

Manager Programmer
experience list of prg-lang.
courses
 OOA - Object Class
• Object Class only
• NO instantiations possible
• a generalization of one or more
objects with a uniform set of
label attributes and services
• can have attributes, services,
states
• used in classification structures
to organize object hierarchies
 Employee Student
name Major Multiple
address GPA Inheritance
==>
Inheritance
Lattices

Teaching Assistant
 OOA - Association
• provides free mapping between
obj1 objects
• complements the two predefined
(min,max)
structural types
label • forms a network of objects by
using binary relationship types
(min,max)
obj2
• cannot carry attributes
• supports access to partner-object
(via “foreign key”)
 Manages which department? Follow association.
Since when? Attribute of ...?

Manager access Department

(1,N) manages (1,1)

OOA

An Example
 ACCOUNT

Static OOAD acct #

balance
Diagram sec-code TRANS_REC
state
has trans_type
withdrw date_time
dep (0,N) (1,1) amount
ATM prov_balance teller_ID
atm #

req_withdrw
req_dep
req_balance
req_int_rate

STD_ACCT SAVINGS_ACCT

int_rate
add_on_interest
prov_int_rate
Scenario 1
ACCOUNT

acct #
balance
sec-code TRANS_REC
state
trans_type
withdrw date-time
dep amount
ATM
teller_ID
atm #

req_withdrw
req_dep

withdrw / deposit create

Scenario 2 ACCOUNT

acct #
balance
sec-code
state

prov_balance
ATM

req_balance

prov_balance
 ACCOUNT

Scenario 3 acct #
sec-code
state

ATM

req_int_rate

SAVINGS_ACCT

prov_int_rate int_rate

prov_int_rate
HOW TO ?
 Building an Object Model starts with
identifying Objects and Classes. Candidate
Objects and Classes can usually be found by
looking at the nouns in the problem
statement; they can be physical entities as
well as concepts.
Rules for Identifying Objects
Objects ...
• Are actors. Objects can be viewed as actors that play a role in the system
to be built. For example some of the actors on the stage of the purchasing system
are the vendor, the purchaser, the purchase order and the purchase requisition.
• Are nouns.
nouns Objects often appear as nouns in problem descriptions.
Example: "A purchase order cannot be created until a purchase requisition is
received."
• Have Uniqueness.
Uniqueness Objects can be uniquely defined. That is instances of
one object can be differentiated from another. For example, a person can be male
or female. By contrast money has no distinguishing attributes. It only takes on
importance as an attribute of some object; for example a bank account.
• Have attributes.
attributes Objects can be described by one or more attributes. To
be distinguishable from one another, objects must have attributes. For example,
one automobile is distinguished from another by model, make, colour etc.
• Are data stores.
stores Objects are the data stores in a data flow diagram.
 I D E N T I F Y I N G O B JE C T S

JA C O B S O N T H R E E T Y P E S O F O B JE C T S

E N T I T Y O B JE C T S U S E R I N T E R F A C E O B JE C T S C O N T R O L O B JE C T S

EVEN T AN D STATE CO NC EPTUAL CO NCR ETE

O B JE C T S O B JE C T S O B JE C T S
An object can be:
• A tangible thing
something you can touch
Example: plane, car, truck, purchase order, person, book, invoice, target
• A role
the purpose or assignment of a person, item of equipment or organisation
Example: operator, customer, pilot, vendor, purchaser, scheduler
• An incident
something that happens
Example: delivery, attack, landing, telephone call, accident
• An interaction
objects that result from associations between other objects
Example: A purchase results from the association of a vendor and a customer.
• A specification
a representation of rules, standards or criteria
Example: recipe, articles of association, quality criteria
 ATM Problem Statement
Design the software to support a computerized banking network including
both human cashiers and automatic teller machine (ATMs) to be shared by a
consortium of banks. Each bank provides its own computer to maintain its
own accounts and process transactions against them. Cashier stations are
owned by individual banks and communicate directly with their own bank's
computers. Human cashiers enter account and transaction data. Automatic
teller machines communicate with a central computer which clears
transactions with the appropriate banks.
An automatic teller machine accepts a cash card, interacts with the user,
communicates with the central system to carry out the transaction,
dispenses cash, and prints receipts. The system requires appropriate
recordkeeping and security provisions. The system must handle concurrent
accesses to the same account correctly. The banks will provide their
network. The cost of the shared system will be apportioned to the banks
according to the number of customers with cash cards.
 ATM Problem Statement
(SOLUTION)
Design the software to support a computerized banking network including
both human cashiers and automatic teller machine (ATMs) to be shared by a
consortium of banks. Each bank provides its own computer to maintain its
own accounts and process transactions against them. Cashier stations are
owned by individual banks and communicate directly with their own bank's
computers. Human cashiers enter account and transaction data. Automatic
teller machines communicate with a central computer which clears
transactions with the appropriate banks.
An automatic teller machine accepts a cash card, interacts with the user,
communicates with the central system to carry out the transaction,
dispenses cash, and prints receipts. The system requires appropriate record
keeping and security provisions. The system must handle concurrent
accesses to the same account correctly. The banks will provide their
network. The cost of the shared system will be apportioned to the banks
according to the number of customers with cash cards.
 Banking
Cashier ATM CONSORTIUM BANK
Software Network

BANK Cashier Account Transaction

Account Transaction
COMPUTER Station Data Data

Central
Cash Card User Cash Receipt System
Computer

Record Security External

Access Cost Customer
Keeping Provision Interactor

Communication Transaction
Line Log

ATM Classes Extraxted From Problem Statement Nouns

The correct Classes can be
detected by following the next
guidelines:
 1. Discard redundant
Classes

customer and user are redundant ,

customer is retained because it is
more descriptive
2. Discard irrelevant Classes

apportioning cost is outside the

scope of the ATM transaction
software
 3. Discard vague Classes

record keeping is vague in ATM

problem , this is part of transaction
4. Do not model Attributes as
Classes
account data is under specified but in
any case probably describes an
account
5. Do not model Operations
as Classes
if we are simply building telephones ,
then Call is part of the dynamic
model not an object class
 6. Do not model
implementation constructs

communications links can

be shown as associations
communication line is
simply the physical
implementation of such a
link
7. Do not model roles that
objects play

the proper class is person(or

possibly customer , which
assumes various different roles
such as owner and driver.
 GOOD
CLASSES
VAGUE IMPLEMENTATION REDUNDUNT IRRELEVANT ATTRIBUTE

External cashier
transaction cashier CONSORTIUM BANK
interactor station

BANK central
account customer ATM cash card
COMPUTER computer

account banking
software user cost
data network

communication
line
receipt system

transaction security
cash
log provision

transaction record
access data keeping

Eliminating Necessary Classes From ATM Problem

Initial Object Diagram for ATM

Consortium Bank Customer

Account
After identifying Objects and Classes
the necessary Associations
between Classes can be identified
. Associations can often be found by
looking at the verbs or verb
phrases in the problem statement.
1. Physical location
next to
part of
contained in
2. Directed action
drives
3. Communication
talks to
4. Ownership
has
part of
5. Satisfaction of some
condition
works for
married to
manages
 Associations guide-lines
1 Review the concept of associations.
2 Identify verb phrases in problem statements, requirement
statements, business rules and concepts of operation. For
example:
a customer purchases a book (class=customer, book;
association=purchases)
a customer complains about a
product(class=customer, product ;
association=complains about)
3 Eliminate irrelevant associations that are:
a) Outside the problem domain
b) Specify implementation approaches (e.g. the transaction takes a
record lock)
4 Discard actions. Associations describe class structure not
transient events. For example "accountant creates a credit note"
describes an action on a credit note it does not imply an
association between accountant and credit note that needs to be
recorded.
5 Omit derived associations. Omit associations that can be
defined in terms of other associations. For example, given the
business rule, "a credit note is issued on an invoice for validated
customer complaints", an association need not be defined between
complaint and invoice. It is redundant as it can be derived by
identifying the credit note the complaint was associated with and
accessing the related invoice from the is issued on association.
6 Identify associative classes.
7 Define the cardinality of the
association
From David Brown Book
Establishing the cardinality:
sentence = subject + verb + number + object
“ customer buys many products”
 ATM example :Verb phrases

Banking network includes cashiers and ATMs

Consortium shares ATMs
Bank provides bank computer
Bank computer maintains accounts
Bank computer processes transaction against
account
Bank owns cashier station
Cashier enters transaction for account
Cashier station communication with bank computer
ATM accepts cash card
ATM interacts with user
ATM dispenses cash
ATM prints receipts
System handles concurrent access
Banks provide software
Cost apportioned to banks
 Implicit verb phrases

Consortium consists of bank

Bank holds account
Consortium owns central computer
System provides record keeping
System provides security
Customers have cash cards

Knowledge of problem domain

Cash card accesses accounts

Bank employs cashiers
 For keeping the correct
associations the next
guidelines have to be applied:
1. Discard associations
between Classes that are
eliminated .
ATM case we can eliminate:
Banking network includes cashiers and
ATM’s
Cost apportioned to banks
ATM prints receipts
ATM dispenses cash
System provides record keeping
System provides security
Banks provide software
2. Discard implementation
associations

System handles concurrent

access is an implementation
concept
 3. Don't model actions
we can eliminate:
ATM accepts cash card
describes part of the
interaction cycle between
an ATM and a customer
ATM interacts with user
4. Decompose ternary
associations if possible into
binary associations

Cashier enters transaction for

account can be broken into:
* Cashier enters transaction
and
*transaction concerns account
5. Don't model associations that
can be derived

Consortium shares ATMs is a

composition of the associations:

consortium owns central computer

and
central computer communicates with
ATM’s
 Notes

• Be careful not all associations from multiple

paths between classes indicate redundancy.
• Although derived associations do not add
information , they are useful in the real
world and in design, they should be drawn
using dotted lines.
 Next the identified
associations have to be
refined applying the next
guidelines:
 1. Find a good name for
every association

bank computer maintains

accounts
is a statement of action ; rephrase
as
bank holds account
 2. Add role names to
associations if this is
necessary

in the
works-for association
company has the role employer
and
person has the role employee
3. Use qualified associations
whenever possible

The context combines with the

name to uniquely identify the
object

The qualifier bank code

distinguishes the different
banks in a consortium
 4. Specify multiplicity
(cardinality) of associations
5. Find missing associations

cashier authorized on cashier

station is needed if cashiers are
restricted to specific stations
 Identify Associations
Consortium Bank Account Customer
Holds
The next step is identifying Attributes .
Attributes can usually be found in
nouns with possessive phrases and
adjectives.
adjectives For derived Attributes it's
important to either label them as derived,
or discard them. Link Attributes also have
to be identified.
Guidelines for identifying Attributes:
 Identifying attributes
Identify the characteristics that are common to all possible
instances of objects in the class.
Types of Attribute
Candidate key A set of one or more attributes that uniquely
distinguishes one instance of an object from another. For example,
an invoice number.

Descriptive attributes Facts intrinsic to each instance of the object.

For example, invoice date and invoice total.
Referential attributes An attribute that ties an instance of one
object to an instance of another. For example, customer code.
Rules for Identifying Attributes
Single valued. One instance of an object has exactly one value of
each attribute at any given instant in time
Atomic. An attribute is atomic - cannot be described by other
attributes
legal attribute : phone-number
illegal attribute : shipping address => street-address, city, postcode
Uniquely identify the object. A set of attributes (the candidate
key) must uniquely identify all instances of the object
legal candidate key : customer-code
illegal candidate key : last-name
A property of the object. Each non-candidate key attribute is a
characteristic of the instance named by the candidate key and not of
some other non-candidate key attribute
legal attributes : invoice = invoice-number + invoice-date +
customer-code
illegal attribute (street-address): invoice = invoice-number + invoice-
date + customer-code + street-address
Note that street-address is an attribute of customer not invoice.
1. Don't model Objects as
Attributes

boss is an object and salary is an

attribute
 2. Use qualifiers wherever
possible (names can often be
modeled as qualifier)

employee number is not a unique

property of person with two jobs
; it qualifies the association:
company employs person
 Names Are Often Better
Modeled As Qualifiers Rather
Than Object Attributes
 3. Don't model identifier
attributes that are made to
identify
(For example 'Person ID')
4. Model link Attributes
 5. Don't model internal
values (states) of an Object
6. Don't model fine details
 7. Discordant attributes
Attributes that are very
different from other Attributes
of an Object often indicate the
need for adding a new Class
 Identify Attributes
Consortium Account Customer
Bank
bank code Holds account-
bank code
name balance
credit limit
account type
 Using Inheritance to organize the
Class Hierarchy can refine Object
Classes. Common aspects of Classes
like Attributes, Operations or Associations
can be generalized into Super classes
and existing Classes can be
specialized into Subclasses.
Subclasses
Specialization can be found in noun
phrases with adjectives.
adjectives Multiple
Inheritance is also possible but should
only be used if it is really necessary.
Generalization : bottom - up
specialization : top - down
Top down specialization are often
apparent from the application
domain like:
fixed-menu
pop-menu
sliding-menu
remember brown notations:
canbea and isakinda
Remote transaction and
cashier transaction are
similar and can be
generalized by
transaction
To control the adequateness of the Object
Model it is recommended to test several
access paths through the Object model
to find missing and unnecessary Classes,
missing and unnecessary Associations
and incorrect placement of Associations
and Attributes.
 The last step for building the Object model is
the grouping of sets of Classes that capture a
logical subset of the model into Modules
For grouping Classes the analyst should look at
cut points between Classes. The number of
bridges between Classes in different Modules
should be minimized.
For grouping Classes into Modules it is possible
to look at earlier made Modules, it may be
possible to reuse previous made Modules.
ATM modules examples are :
tellers :
cashier , entry station , cashier ,
ATM
banks:
consortium , bank
 Determine Generalization and
Aggregation
Consortium Bank Account Customer

bank-code Holds account-code

bank-name balance
credit-limit
account-type