1. Object-Oriented Analysis & Design
Dr. M.E. Fayad, Professor
Computer Engineering Department, Room #283I
College of Engineering
San José State University
One Washington Square
San José, CA
2003
SJSU -- CmpE

2. Object Identification - 2
Lesson 10:
Object Identification - 2 2
2003
SJSU – CmpE -- M.E. Fayad

3. 3 Lesson Objectives + Learn how to identify:
Associations and aggregations
Attributes
Behaviors
Inheritance
+ Understand how to use the following approaches:
Use Case
CRC
Questioning Techniques
+ Understand how to refine objects and associations
+ Learn how to define responsibility & collaborations
+ Learn how to eliminate unnecessary classes, associations, and attributes 3
2003
SJSU – CmpE -- M.E. Fayad

4. Automated Teller Machine (ATM)
Stop bothering me!
I told you I don’t have
any money! 4
2003
SJSU – CmpE -- M.E. Fayad

5. 5 Actors Automated Teller Machine
Customer
Automated
Teller
Machine
Bank System
ATM Operator
In Use Cases, Everything that interacts with the system will be modeled as an actor, such as persons as well as machines. 5
2003
SJSU – CmpE -- M.E. Fayad

6. 6 Use Cases in ATM Automated Teller Machine Customer Bank System
Cash Withdrawal
Customer
Transfer Funds
Bank System
Deposit Funds
Balance Inquiry 6
System Start
ATM Operator
2003
SJSU – CmpE -- M.E. Fayad

7. A Use Case Description: Cash Withdrawal
Use Case: Cash Withdrawal
When a customer inserts a card in the ATM, the machine reads the code from the card and checks if it is a valid card. If the card is valid then the machine queries the customer for a PIN number, else the card is ejected.
When the machine matches customer coded in the PIN number, the machine checks the validity of the PIN number. If the PIN number is correct and matches the card number then the machine asks for the desired transaction the customer wishes to perform.
When the customer selects cash withdrawal the machine asks for the desired amount with a warning indicating only multiple of $10 is allowed.
When .... 7
2003
SJSU – CmpE -- M.E. Fayad

8. 8 Candidate Objects Account ATM Balance Inquiry Bank Card Reader
Cancel Key
Cash Dispenser
Deposit Slot
Deposit Funds
Display Screen (Bank System Interface)
Menu (Graphical User Interface)
User Message
Numeric Keypad
Numeric Input Key
PIN
Cash
Receipt Printer
Special Input Key
Transfer Funds
Cash Withdrawal 8
2003
SJSU – CmpE -- M.E. Fayad

9. System Responsibilities & Collaborations
Define Responsibilities
What are the goals of the system
What must objects know to meet goals
What steps must each object accomplish
Determine Collaborations
Decompose responsibilities into interactions among objects
Define clients and servers
Where should knowledge be held 9
2003
SJSU – CmpE -- M.E. Fayad

10. 10 CRC Cards ATM (role) Collaboration Responsibility Clients Server
General
Each class is described on a separate 3X5 or 4X6 card
The cards are known as CRC card. They have 3 sections:
Class
Responsibilities
Collaborations
ATM (role)
Responsibility
Collaboration
Clients Server
Access & modify account balance Account Balance Inquiry
Deposit Transaction
Funds Transfer
Withdrawal Transaction 10
2003
SJSU – CmpE -- M.E. Fayad

11. Other Techniques Help Refine Objects
Generalize and Specialize objects
Associate Objects
Recognize Accidental Objects
Challenging and Testing Objects
Ask Questions 11
2003
SJSU – CmpE -- M.E. Fayad

12. Explore Generalizations and Specializations
Generalization exposes commonalities
Exercise helps to identify new classes
Considerations for generalizations and specializations
Is it in the problem domain?
Is it within the system’s responsibilities?
Will there be inheritance? 12
2003
SJSU – CmpE -- M.E. Fayad

13. Avoid Accidental Objects
Essential objects represent genuine high-level abstractions
Accidental objects represent qualitative judgments 13
2003
SJSU – CmpE -- M.E. Fayad

14. 14 Challenge Objects Needed Remembrance -- attributes
Needed Behavior -- methods
Usually Multiple Services per Object
Usually More than One Object per Class 14
2003
SJSU – CmpE -- M.E. Fayad

15. 15 Other Object Tests Uniformity Test More than a Name Test Or Test
Each instance must have the same set of characteristics and be subject to the same rules - Car license
More than a Name Test
Every object has attributes, if not it is probably an attribute of another object -- home address
Or Test
If inclusion criteria should not use “OR” in any significant way -- driver’s license number or learner’s permit number
More Than a List Test
If inclusion criteria is only a list of instances -- decadent foods includes croissant , cappuccino, chocolate pie, ice cream. 15
2003
SJSU – CmpE -- M.E. Fayad

16. Final Object Checklist
Something universal and real for reuse
Should encapsulate some reasonably complex behavior to justify existence
Methods that don’t make use of its current class’s own attributes is probably encapsulated in the wrong object.
Small and simple stable interfaces
Self sufficient and complete 16
2003
SJSU – CmpE -- M.E. Fayad

17. Questioning Techniques Help Elicit Domain Knowledge
Play Twenty Questions
Is it animal, vegetable, or mineral?
Does it have fur or feathers?
Can it fly?
Define Boundaries
What else?
What about..?
Quantify Qualities as Attributes
How fast?
How hot? 17
2003
SJSU – CmpE -- M.E. Fayad

18. Eliminating Unnecessary Associations
Irrelevant Associations
outside problem domain
Implementation Associations
Examples: concurrent process, contains a list
Associations Between Eliminated Classes 18
2003
SJSU – CmpE -- M.E. Fayad

19. Eliminating Unnecessary Associations (cont’d)
Actions or Transient Events
Examples: “Interacts with the Robot”, “ATM accepts cash card.”
Ternary Associations
Decompose as binary associations or rephrase to one binary association.
Derived Associations
These are redundant
Examples: “Younger than ..” derived from age 19
2003
SJSU – CmpE -- M.E. Fayad

20. Refine Association List
Choose meaningful association names
Add role names where appropriate
Add attributes or associations which qualify existing associations
Example: “Standard Oil of Ohio” uses state attribute to qualify company name.
Specify one-to-many and many-to-many associations in the class diagram
Add missing associations
Not in problem statement
from knowledge of application domain 20
2003
SJSU – CmpE -- M.E. Fayad

21. Identifying Attributes
Attributes can be thought as a simple association with a value which is not an object
Examples: name, age, weight
Usually corresponding to nouns followed by possessive phrases
Examples: “color of the car”, “age of the donor”
Less likely to be fully described in the problem statement
Included in the class box diagram
Not as relevant to the problem structure as associations 21
2003
SJSU – CmpE -- M.E. Fayad

22. 22 Descriptive Attributes Naming Attributes Referential Attributes
Attribute Types
Descriptive Attributes
Naming Attributes
Referential Attributes 22
2003
SJSU – CmpE -- M.E. Fayad

23. Descriptive Attributes
Provide facts intrinsic to each instance of the object.
Examples Account.balance, Cat.weight
If the value of a descriptive attribute changes, it means only that some aspect of an instance has changed, but the instance is still the same instance. 23
2003
SJSU – CmpE -- M.E. Fayad

24. 24 Naming Attributes Are used to name or label instances.
Examples:Account.number, Flight.number
Names are typically somewhat arbitrary
Naming attributes are frequently used as an identifier or part of an identifier.
If the vale of a naming attribute changes, it means only that a new name has been given to exactly the same instance 24
2003
SJSU – CmpE -- M.E. Fayad

25. Referential Attributes
Are used to tie an instance of one object to an instance of another.
Examples: Cat.owner name indicates which person owns this cat.
If the vale of a referential attribute changes, it means that different instances are now being associated. 25
2003
SJSU – CmpE -- M.E. Fayad

26. 26 Rules of Attributes First Rule:
One instance of an object or a class has exactly one value for each attribute at any given time.
Employee M/S Phone
M. Fayad
G. Smee
7890
L. Harris OK
Not OK 26
[Shlaer-Mellor 90]
2003
SJSU – CmpE -- M.E. Fayad

27. Rules of Attributes (cont’d)
Second Rule:
An attribute must contain no internal structure
Examples:
Age, balance, size are all OK.
A name consists of first name, middle initial, and last name (Not OK)
An address contains house number, street name, city, state, zip code, and country name (Not OK) 27
2003
SJSU – CmpE -- M.E. Fayad

28. Rules of Attributes (cont’d)
Third Rule:
When an object has a compound identifier -- that is, one made up of two or more attributes -- every attribute that is not part of the identifier represents a characteristic of the entire object.
Juice Transfer
storage Tank ID
cooking Tank ID
gallons
plannedTime
The juice Transfer.gallons attribute means that the number of gallons transferred from the storage tank to the cooking tank and not the number of gallons in either the storage tank or the cooking tank. 28
2003
SJSU – CmpE -- M.E. Fayad

29. Rules of Attributes (cont’d)
Fourth Rule:
Each attribute is not part of an identifier that represents a characteristic of the instance named by the identifier and a characteristic of some other non-identifier attribute
Batch
batch ID
recipe ID
gallons
cookingTime
The Batch.cookingTime attribute must
represent the actual time the batch was
cooked, and not the cooking time
specified by the recipe 29
2003
SJSU – CmpE -- M.E. Fayad

30. Eliminating Unnecessary Attributes
Do not keep attributes that have an object as a value, they are associations
Do not keep attributes that depend on a context, these are qualifiers for associations
If an object can have more that one name, then the name qualifies an association of that object with another 30
2003
SJSU – CmpE -- M.E. Fayad

31. Eliminating Unnecessary Attributes (cont’d)
Do not put attributes of the association in one or the other of the objects involved in the association, put the attributes in the association itself
Eliminate attributes which are only used internally by the object
Keep initial analysis of attributes at a high level
Eliminate attributes which are too low level
Attributes which are in some instances of a class, but not in others, indicate that the class should be split into two or more classes 31
2003
SJSU – CmpE -- M.E. Fayad

32. Identifying Inheritance
Identify classes which share common information
Three basic approaches:
Bottom Up
Look for classes with repeated associations, attributes or behaviors, and group together into higher level classes
This approach is easier for inexperienced modelers
Top Down
Look for Noun phrases describing different kinds of things in the problem statement.
Examples: Family cars, Sports cars, Luxury cars
Combination of the two approaches works the best.
Do Top Down when doing initial analysis
Identify repeated information in the late passes. 32
2003
SJSU – CmpE -- M.E. Fayad

33. Identifying Inheritance (cont’d)
Always use the “AKO” test
All inheritance specifications should identify one or more classes which are “A Kind Of” a higher level class.
NEVER use inheritance for “Part / Part-of” relationships
Use multiple inheritance only when necessary
Some object-oriented programming languages do not even have this feature. 33
2003
SJSU – CmpE -- M.E. Fayad

34. Identifying Behaviors
Done in latest stages
List of behaviors can become large and get detailed quickly.
May correspond to queries about attributes and associations
Operations to read or write attribute or association value
Examples: user name, property value, etc.
May correspond to events or activities
Examples: begin simulation, alert, calculate balance, computer distance 34
2003
SJSU – CmpE -- M.E. Fayad

35. Experience and Domain Knowledge
Good objects come from language of domain
If you are not an expert -- consult users
Experience will tune decisions
Slowly at first
Much faster later
Just do it! 35
2003
SJSU – CmpE -- M.E. Fayad

36. Discussion Questions
Define with examples: CRC cards, associate objects, referential attributes.
Describe the third norm for testing objects
What are the differences between essential objects and accidental objects
What are questioning techniques and their purposes?
Describe how do you identify: associations , aggregations, inheritance, attributes, and behaviors
Describe how to refine objects and associations
Explain how to define responsibilities and collaborations 36
2003
SJSU – CmpE -- M.E. Fayad

37. Questions for the Next Lecture
Define:
Type
Type vs. Class
Type specifications
Interface
Signatures
Elements of behavior 37
2003
SJSU – CmpE -- M.E. Fayad