Object Oriented Analysis

Classification

•Classification is the process of checking to see if an

object belongs to a category or a class, is regarded as a
basic attribute of human nature.

•Classification guides us in making decisions about

modularization.
• Classification also plays a role in allocating
process to procedures

• Classes are an important mechanisms for

classifying objects.

• A class is a specification structure., behavior

and the description of the object
• Intelligent classification is intellectually hard work
and may seem rather arbitrary.
• Martin and Odell have observed in object-oriented
analysis and design  “an object can be categorized
in more than one way.”`

Employer Employee

Pet owner Woman

• So classification is defined as the
categorization of input data (things) into
identifiable classes via the extraction of the
significant feature of attributes of the data
from a background of irrelevant details`
 Approaches to identifying classes
• Noun phase approach
• The common class pattern approach
• Use case driven/sequence/collaboration
modeling approach
• Classes, responsibilities, collaborators (CRC)
 Noun phase approach
• It was proposed by Rebecca Wirfs-Brock
• As seen through the requirements or use cases looking
for noun phases

• Noun in the textual description are considered

to be classes and verbs to be methods of the
classes.
• All plurals are changed into singular
• Nouns are listed
• List divided into three categories
– Relevant classes
– Fuzzy classes (those classes that are not sure
about)
– Irrelevant classes
 Identifying Tentative classes
Guidelines
– Look for nouns and noun phrases in the use
cases
– Some classes are implicit or taken from
general knowledge.
– All classes must make sense in the
application domain
– Carefully choose and define the class names
 Selecting classes from
relevant and fuzzy categories
Guidelines (to select classes from problem domain)

• Redundant classes:- Do not keep two classes

that express the same information.
• If more than one word is being used to
describe the same idea, select the one that is
the most meaningful in the context of the
system.
• Choose vocabulary carefully
Guidelines (to select classes from problem domain)…

• Adjectives classes:
- Be wary of the use of adjectives.
• Adjectives can be used in many ways
• An adjective can suggest a different kind of
object, different use of the same object, or it
could be utterly irrelevant.
• Ex: adult members behave different from
young members so the two should be
classified a different classes
 Guidelines (to select classes from problem domain)…

• Attribute classes: tentative objects that are

used only a values should be defined or
restated as attributes not as a class.
• For ex: client status and demographic of client
are not classes but attributes of the client
classes
 Guidelines (to select classes from problem domain)…

• Irrelevant classes:-
• Each class must have a purpose and every
class should be clearly defined and necessary.
• You must formulate a statement of purpose for
each candidate classes.
• If you cannot come up with a statement of
purpose, simply eliminate the candidate class
 Review redundant classes

Review adjectives
Review irrelevant classes

Review attributes
• Case study : The vianet bank system -identifying
classes by using noun phrase approach
Initial list of noun phrases: candidate classes:
– Account
– Account Balance
– Amount
Four digit
– ATM card
Review PIN code/no
– PIN
=====> Checking
– Four digit Client’s Account
classes
– PIN code/no Client’s Balance
– Checking
– Client
– Client’s Account
– Client’s Balance
 Guidelines for identifying
super-sub class relationship

Top-down
Bottom-up
Reusability
Multiple inheritance
 Defining super-sub relationship
• Top-down : Look for noun phrases composed of
various adjectives in the class name

• Bottom-up: Look for classes with similar attributes

or methods

• Reusability : Move attributes and behaviors as high

as possible in the hierarchy

• Multiple inheritance: Avoid excessive use of

multiple inheritance
 Top-down
• Look for noun phrases composed of various
adjectives in a class name.
• Avoid excessive refinement.
• Specialize only when the subclasses have
significant behavior.
• For example, a phone operator can be
represented as a cook as well as a clerk or
manager because they all have similar
behavior
 Bottom-up
• Look for classes with similar attributes or
methods

• You can group them by moving the common

attributes and methods to an abstract class

• You may have to alter the definitions a bit; this

is acceptable as long as generalization truly
applies
 Reusability
• Move attributes and behaviors (methods) as high as
possible in the hierarchy.

• Do not create very specialized classes at the top of the

hierarchy.

• The balancing act can be achieved by several

iterations

• This process ensures that you design objects that can

be reused in another application.
 Multiple inheritance
• Avoid excessive use of multiple inheritance
• It give more complications
• How to determine which behavior to get from which
class , particularly several ancestors define the same
method
• One way to achieve the benefits of MI is to inherit
from the most appropriate class and add an object of
another class as an attribute
 Multiple Inheritance

Single inheritance Aggregation

 A-part of relationships-Aggregation
• A-part of relationships also called Aggregation,
represents the situation where a class consists of
several component classes.

• A class that is composed of other classes does not

behave like its parts.

• For example a car consist of many other classes, one

of which is radio, but a car does not behave like a
radio.
 Two major properties
• Transitivity :- the property where
• If a-> b and b->c so a->c

• For example a carburetor is part of an engine

and engine is a part of car, therefore a
carburetor is a part of car.
• Anti symmetry:- the property of a-part-of
relation where, if A is a part of b, then B is not
part of A

Car For example

an engine is part of car,
but a car is not part of
engine.
Engine Radio

carburetor
• Does the part class belong to a problem domain?
• Is the part class within the system’s
responsibilities?
• Does the part class capture more than a single
value?
• Does it provides a useful abstraction in dealing
problem domain?
• Hallow diamond represents Aggregation?
A-part-of-relationship patterns
• Assembly: an assembly is constructed from its
parts and an assembly-part situation physically
exists

• For example a French onion soup is an

assembly of onion, butter, flour, French bread,
cheddar cheese and so on.
• Container:- a physical whole encompasses but
is not constructed from physical parts.

House
• For example
a house can be considered
as a container for furniture
and appliances

Furniture Appliances
• Collection–member:- a conceptual whole
encompasses parts that may be physical or
conceptual
Football Team

• For example
a football teams is
a collection of players.

Player
 Case study Relationship analysis for
vianet bank ATM system
• Identifying classes relationships
• One of the strengths of object-oriented analysis
is the ability to model objects as they exist in
the real world.
• Several different relationships exist in the
vianet bank ATM system
• Developing a UML class diagram based on the use-
case analysis

BANK Account

– Bank client
– ATM machine
– Transaction
– Savings Account
– Checking Account
 Defining associations
• Part-of ,next-to, works-for
• Location association:
– next to, part of, contained in
• Communication association
– talk to, order to
 BANK

Account
Has

1,2