This document discusses identifying object relationships, attributes, and methods in object-oriented analysis and design. It covers the three main types of relationships between objects: association, generalization (superclass-subclass), and aggregation. Guidelines are provided for identifying each type of relationship by examining object dependencies and common patterns. The document also discusses defining class attributes and methods by analyzing use cases, class responsibilities, and identifying nouns, verbs, and states. An example analysis of classes in an ATM banking system is included to demonstrate identifying relationships, attributes, and methods.

1. UNIT – IV
CHAPTER – 8
Identifying Object Relationships, Attributes and Methods
Introduction
Objects relate with each other
Three types of relationships among objects are
1. Association: how are objects associated? This information
will guide in designing classes
2. Super – sub structure: how are objects organized into
superclass and subclass? This information provides us the
direction of inheritance
3. Aggregation and a – part – of structure: what is the
composition of complex classes? This provides information
in defining mechanisms that properly manage object
within - object

2. Relationships among objects are known as
associations
E.g.: placing an order
A – part – of structure is a familiar means of
organizing components of a bigger object
e.g. : walls, windows, doors are a – part – of a
bigger object building
Associations
Association represents a physical or conceptual
connection b/w two or more objects
Binary associations are shown as lines connecting
tow class symbols

3. Ternary and higher – order associations are shown
as diamonds connecting to a class symbol by lines
and the association name is written above or below
the line
diagram

4. Identifying Associations
Any dependency relationship b/w two or more
classes is an association. The responsibilities has to
be examined to determine dependencies
The following questions can help us to identify
association
Is the class capable of fulfilling the required task by
itself?
If not, what does it need?
From what other class can it acquire what it needs?

5. Guidelines for Identifying Association
1. A dependency b/w two or more classes may be an
association
Association verb or prepositional phase such
as part of , next to, works for, or contained in
2. Reference from one class to another is an
association. Some associations are implicit or
taken from general knowledge
Common Association Patterns
1.Location association – next to, part of, contained in
e.g.: cheddar cheese is a – part – of soup.
Wheel is a – part – of cart

6. 2.Communication association - talk to, order to
e.g.: customer orders to supplier
diagram

7. Eliminate Unnecessary Associations
1.Implementation association are concerned with the
implementation or design of the class within certain
programming or development environments and
not relationships among business objects
2.Ternary associations is an association where more
than two classes are involved
3.Directed actions (or derived) associations can be
defined in terms of other associations
e.g.: Grand Parent of ken can be defined in terms of
the parent association

8. •Diagram

9. Super – Sub Class Relationships
Represents inheritance b/w the related classes
Also known as generalization hierarchy
Takes advantages of the commonality b/w classes to
create new classes
Is a relationship b/w classes, where one class is the
parent class of another(derived) class
Parent class is also known as base or super class or
ancestor
Real advantage is use can build on what we already
have and reuse what use already have

10. Guidelines for Identifying Super – sub Relationship, a
Generalization:
1.Top – down
Look for various adjectives in a class
Avoid over refinement
Specialize only when subclasses have significant
behavior
2.Bottom – up
Look for classes with similar attributes
Apply the generalization principles
3.Reusabiltiy
Do not create very specialized classes at the top of the
hierarchy
Using generalized classes, create new classes for reuse

11. 4. Multiple inheritance
Avoid excessive use of multiple inheritance
Diagram
Benefits:
inherit from the most appropriate class and add an
object of another class as an attribute

12. A – part – of Relationships – Aggregation
A – part – of relationship, 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 but it behaves differently
E.g.: car consists of many classes, one class is radio,
but car does not behave like radio
2 major properties
(i) transitivity
(ii) antisymmetry

13. Transitivity
A B C
A part of B and B is a part of C so A is a part of C
e.g.: diagram
Antisymmetry
A is a part of B then B is not a part of A
e.g.: engine is a part of car, but car is not a part of car
A clear distinction b/w the part and the whole can help
us determine where the responsibilities of certain
behavior must reside
Does the part class belong to a problem domain?
Does the part class capture more than a single
value?(yes, include as an attribute with whole class)

14. Fig – a – part – of composition
diagram

15. Aggregation is represented as container or
collection as hollow diamonds and use a solid
diamond to represent composition – strong form of
aggregation
A – part – of Relationship Patterns
1.Assembly is constructed from the parts and an
assembly – part situation physically exists
e.g.: soup is an assembly of onion, butter, flour,
cheese and so on.
2.Container
A physical whole encompasses but is not
constructed from physical parts

16. Diagram
3.Collection – member
A conceptual whole encompasses parts that may be
physical or conceptual
e.g.: football team is a collection of players
diagram

17. Case study : Relationship Analysis for the ViaNet Bank
ATM System
The system is developed using an iterative process
where the analysis is completed before the design
starts
Identifying Classes Relationships
(i) Bank (ii) Bank Client (iii)Account (iv) ATM Machine
(v) Transaction (vi) Checking Account (vii) Savings
Account
Different relationships exist in the ViaNet Bank system
and use we have to define each one of the
relations separtely

18. Developing a UML Class Diagram Based on the Use –
case Analysis
UML class diagram is the main static analysis and
design diagram of a system
The analysis consists of the following class diagrams
One class diagram for the system shows the identity
and definition of classes in the system, their
interrelationships and various packages containing
groupings of classes
Multiple class diagrams that represent various
pieces, or views of the system class diagram
Multiple class diagrams, that show the specific
static relationships b/w various classes

19. Create the classes
diagram

20. Defining Association Relationships
Identifying association begins by analyzing the
interactions of each class
General Guidelines
1.Association corresponds to verb or prepositional
phrases
e.g.: part of, next to, works for, or contained in
2.Some associations are taken from general
knowledge
some common patterns of association are
1.Location association: next to, part of, contained in
(part – of relation is a special type of association)

21. 2.Directed actions association
3.Communication association: talk to , order from
e.g.:
Each account belongs to a bank client
therefore there is association b/w Bank client and
account class
Establish cardinality among these classes
All associations are considered one to one (one
client can have only one account)
Therefore each Bank client have one or two
accounts so change the cardinality of association

22. diagram

23. Associations among the ViaNet bank ATM system
classes
Diagram

24. Defining Super – Sub Relationships
Guidelines for identifying super – sub relationships
 Top – down – noun phrase composed of various
adjective in the class name
 Bottom – up – look for classes with similar
attributes or methods
 Reusability – move attributes and behavior as high
as possible in the hierarchy
 Multiple Inheritance – avoid excess usage

25. Fig. Super – Sub relationships among the Account,
Savings Account and Checking Account classes
diagram

26. Identifying the aggregation / a – part – of Relationship
1.Assembly
2.Container
3.Collection – Member
Association, generalization and aggregation among
the ViaNet bank classes
diagram

27. Class Responsibility: Identifying Attributes and
Methods
Identifying attributes and methods is like finding
classes – difficult activity and an iterative process
Questions – for identifying responsibilities of
classes
What information about an object should we keep
track of ?
Help to identify attributes of a class
What services must a class provide?
help to identify a class’s method

28. Class Responsibility: Defining Attributes By Analyzing use
cases and other UML Diagrams
Attributes can be derived from scenario testing
Main goal – understand what the class is responsible
for knowing. Responsibility is the key issue
As an object in an object oriented environment the
questions to be asked are
How am I going to be used?
How am I going to collaborate with other classes?
How am I described in the context of this system’s
responsibility?
What do I need to know?
What state information do I need to remember over
time?
What states can I be in?

29. Guidelines for Defining Attributes
i. Attributes usually correspond to nouns followed
by prepositional phrases such as cost of the soup
 Attributes also may correspond to adjectives or
adverbs
ii. Keep class simple: define attributes for a particular
object stats
iii. Attributes are less likely to be defined in the
problem statement
iv. Omit derived attributes (e.g.) do not use time
elapsed since other
v. Do not carry discovery of attributes to excess

30. Defining Attributes for the ViaNet Bank Objects
Defining Attributes for the BankClient Class
Attributes of BankClient
firstName
lastName
pinNumber
cardNumber
account:Account
PINnumber
cardNumber

31. Defining Attributes for the Account Class
AcctNumber
balance
Defining Attributes for the Transaction Class
transID transTime amount
transDate transType postBalance
Defining Attributes for the ATM machine class
address
state

32. Object Responsibility: Methods and Messages
Methods and messages are the workhorses of
object – oriented systems
Object must provide some services
In OO environment, every piece of data, or object is
surrounded by a rich set of routines called methods.
These methods do everything from printing the
object to initializing its variables
every class is responsible for storing certain
information from the domain knowledge. If an
object requires certain information to perform
some operation for which it is responsible, it is
logical to assign it the responsibility for maintaining
the information

33. Methods are responsible for managing the value of
attributes such as query, updating, reading and
writing; we need a set of operations that can
maintain or change values
Defining Methods by Analyzing UML Diagrams and
use cases
An event is considered to be an action that
transmits information. These actions are operations
that the objects must perform and, as in attributes,
methods also can be derived from scenario testing
To define methods for Account class, look to the
sequence diagram for use cases

34. Deposit Checking
Deposit Savings
Withdraw Checking
Withdraw More from Checking
Withdraw Savings
Withdraw Savings Denied
Checking Transaction History
Savings Transaction History

35. Defining methods for ViaNet Bank Objects
Defining Account class Operations
Methods
deposit
Withdraw
Create Transaction
Defining BankClient Class Operations
method to validate client’s passwords
Defining CheckingAccount Class Operations
withdraw service

36. Fig: a more complete UML class diagram of the ViaNet
bank ATM system