Automating Business Process via MuleSoft Composer | Bangalore MuleSoft Meetup...
Chapter 8 ooad
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
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
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)
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
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
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