IDENTIFYING OBJECT RELATIONSHIPS,

ATTRIBUTES AND METHODS

Goals:
• – Analyzing relationships among classes
• – Identifying association
• – Association patterns
• – Identifying super- & subclass hierarchies
• Three Types of Objects Relationships
• Association
• Super-sub structure (also known as
generalization hierarchy)
• Aggregation and a-part-of structure
 Association, Aggregation, Composition, Generalization,
Realization, Dependency

• Association
• Association is a relationship between two objects. In other
words, association defines the multiplicity between
objects. You may be aware of one-to-one, one-to-many,
many-to-one, many-to-many all these words define an
association between objects. Aggregation is a special form
of association. Composition is a special form of
aggregation.

• Example: A Student and a Faculty are having an

association.
Degree of an Association
• Degree of an association denotes the number of classes involved in a
connection. Degree may be unary, binary, or ternary.
• A unary relationship connects objects of the same class.
• A binary relationship connects objects of two classes.
• A ternary relationship connects objects of three or more classes.
Cardinality Ratios of Associations
• Cardinality of a binary association denotes the number of instances
participating in an association. There are three types of cardinality ratios,
namely −
• One–to–One − A single object of class A is associated with a single object of
class B.
• One–to–Many − A single object of class A is associated with many objects of
class B.
• Many–to–Many − An object of class A may be associated with many objects of
class B and conversely an object of class B may be associated with many
objects of class A.
Aggregation
• Aggregation is a special case of association. A
directional association between objects.
When an object ‘has-a’ another object, then
you have got an aggregation between them.
Direction between them specified which
object contains the other object. Aggregation
is also called a “Has-a” relationship.
• Composition
• Composition is a special case of aggregation. In a more
specific manner, a restricted aggregation is called
composition. When an object contains the other object, if
the contained object cannot exist without the existence of
container object, then it is called composition.

• Example: A class contains students. A student cannot exist

without a class. There exists composition between class
and students.
• Generalization
• Generalization uses a “is-a” relationship from a
specialization to the generalization class. Common
structure and behaviour are used from the specializtion
to the generalized class. At a very broader level you can
understand this as inheritance. Why I take the term
inheritance is, you can relate this term very well.
Generalization is also called a “Is-a” relationship.

• Example: Consider there exists a class named Person. A

student is a person. A faculty is a person. Therefore
here the relationship between student and person,
similarly faculty and person is generalization.
• Dependency
• Change in structure or behaviour of a class
affects the other related class, then there is a
dependency between those two classes. It need
not be the same vice-versa. When one class
contains the other class it this happens.

• Example: Relationship between shape and circle

is dependency.
• Realization
• Realization is a relationship between the blueprint
class and the object containing its respective
implementation level details. This object is said to
realize the blueprint class. In other words, you can
understand this as the relationship between the
interface and the implementing class.

• Example: A particular model of a car ‘GTB Fiorano’

that implements the blueprint of a car realizes the
abstraction.
Guidelines for Identifying Super-sub Relationships:

• Top-down
• Look for noun phrases composed of various adjectives on class
name.
• Example, Military Aircraft and Civilian Aircraft.
• Only specialize when the sub classes have significant behavior.

• Bottom-up
• Look for classes with similar attributes or methods.
• Group them by moving the common attributes and methods to
super class.
• Do not force classes to fit a preconceived generalization structure.
Reusability
• Move attributes and methods as high as possible in the
hierarchy.
• At the same time do not create very specialized classes at the
top of hierarchy.
• This balancing act can be achieved through several iterations.
Multiple inheritance
• Avoid excessive use of multiple inheritances.
• It is also more difficult to understand programs written in
multiple inheritance system.
• Class Responsibility: Identifying Attributes and Methods
• Identifying attributes and methods, like finding classes, is a
difficult activity.
• The use cases and other UML diagrams will be our guide for
identifying attributes, methods, and relationships among
classes.

• Identifying Class Responsibility by Analyzing Use Cases and

Other UML Diagrams
• Attributes can be identified by analyzing the use cases,
sequence/collaboration, activity, and state diagrams.
• Guidelines for Identifying Attributes Of
Classes
• Do not carry discovery of attributes to excess.
• You can always add more attributes in the
subsequent iterations.
METHODS FOR ATM BANKING SYSTEM

• The ViaNet Bank ATM system: Identifying

classes by using Noun Phrase Approach. Here
we start by reading use cases & applying the
principles discussed for identifying classes
• Initial list of Noun Phrases: Candidate classes
are identified from initial study of use cases of
bank
• The following irrelevant classes eliminated because they do not
belong to problem statement: Envelope, Four Digits and Steps –
Strikeout the eliminated classes (3) in above candidate classes
• Reviewing redundant classes & building a common vocabulary:
The following are different
• class names that are being used to refer to same concept, one
class of group is chosen and rest eliminated
– Client, Bank Client = Bank Client
– Account, Client‘s a/c = Account PIN,
– PIN Code = PIN Checking,
– Checking a/c = Checking a/c
• 4 classes are been eliminated in this step (Client, PIN code,
Client‘s a/c, Checking)
• Reviewing classes containing Adjectives: We have no classes
containing Adjectives to eliminate
• Reviewing possible attributes: Next review focuses on
identifying the noun phrases that are attributes, not classes. The
noun phrases used only as values should be restated as
attributes. The following attributes are been identified and
eliminated from the list of classes (6 classes)
• Amount: A value, not a class
• Account Balance: An attribute of a/c class
• Invalid PIN: A value, not a class
• Password: An attribute of Bank Client class
• PIN: An attribute of Bank Client class
• Transaction History: An attribute of Transaction class
Reviewing Class Purpose: The classes that add no purpose to system have
been deleted form list. The candidate classes are these
• ATM Machine class: Provides an interface to Via Net bank
• ATM Card class: Provides a client with a key to a/c
• Bank Client class: Client is an individual that has checking a/c & possibly a
saving a/c
• Bank class: It is a repository of accounts & processes the a/c‘s transactions
Account class: An account is a formal class; it defines the common
behaviors that can be inherited by more specific classes such as
• Checking a/c & saving a/c Checking Account class: It models a client‘s
checking a/c & provides more specialized withdrawal service
• Saving Account class: It models a client‘s savings a/c
• Transaction class: Keeps track of transaction, time, date, type, amount,
balance
• Thus, at last right from 33 initially identified classes, only 8 classes are cut
listed by this approach