1. Object Analysis
classification

2. Classification theory
• Process of checking to see if an object
belongs to a category or a class

3. Approaches for identifying classes
1. Noun phrase approach
2. Common class patterns approach
3. Use case driven ,sequence/collaboration
approach
4. Classes, responsibilities and
Collaborators (CRC) approach

4. Noun phrase approach
• Identify Noun phrases from requirements or use
cases
• Nouns - classes
• Verbs - methods
• All plurals singular
• Create a List of nouns
– Divided into 3 categories
• Relevant classes Candidate classes
• Fuzzy classes
• Irrelevant classes
Removed safely

5. cont…
• Identifying tentative classes
• Guidelines
– Look for nouns and noun phrases in the use
case
– Some classes are implicit and taken from
knowledge
– Avoid computer implementation classes (defer
them to design phase). application domain
related classes makes sense
– Carefully choose and define class name

6. Guidelines :Selecting classes from
relevant and fuzzy category
• Redundant classes
– Avoid
– Choose more meaningful name and name used by user
• Adjective classes
– Adjective can suggest
• Different kind of object
• Different use of same object
• Utterly irrelevant
eg: adult member and youth member
• Attribute classes
– Objects used only as value can be treated as attribute instead of
classes
• Irrelevant classes
– Relevant class have statement of purpose.
– Irrelevant classes - have no statement of purpose

7. Initial list of noun classes : in vianet bank
• Account • Client • Record
• Account balance • Client’s • Savings
• Amount account • Savings
• Approval process • Currency account
• Atm card • Dollar • Step
• Atm machine • Envelope • System
• Bank • Four digits • Transaction
• Bank client • Fund • transaction
• Card • Invalid pin history
• Cash • Message
• Check • Money
• Checking • Password
• Checking • PIN
account • Pin code

8. Removing irrelevant classes
• Account • Client • Record
• Account balance • Client’s • Savings
• Amount account • Savings
• Approval process • Currency account
• Atm card • Dollar • Step
• Atm machine • Envelope • System
• Bank • Four digits • Transaction
• Bank client • Fund • transaction
• Card • Invalid pin history
• Cash • Message
• Check • Money
• Checking • Password
• Checking • PIN
account • Pin code

9. Removing redundant classe and
building common vocabulary
• Account • Client • Record
• Account balance • Client’s • Savings
• Amount account • Savings
• Approval process • Currency account
• Atm card • Dollar • Step
• Atm machine • Envelope • System
• Bank • Four digits • Transaction
• Bank client • Fund • transaction
• Card • Invalid pin history
• Cash • Message
• Check • Money
• Checking • Password
• Checking • PIN
account • Pin code

10. Reviewing the classes containing
adjectives
• When class represented by noun behaves
differently when adjective is applied to it,
then separate class has to be created
• In this ex no such classes

11. Reviewing the possible attributes
• Noun phrases used only as values should
be treated as attributes

12. Reviewing possible attributes
• Account • Client • Record
• Account balance • Client’s • Savings
• Amount account • Savings
• Approval process • Currency account
• Atm card • Dollar • Step
• Atm machine • Envelope • System
• Bank • Four digits • Transaction
• Bank client • Fund • transaction
• Card • Invalid pin history
• Cash • Message
• Check • Money
• Checking • Password
• Checking • PIN
account • Pin code

13. Reviewing the class purpose
• Include classes with
– Purpose
– Clear definition
– Necessary in achieving system goal
• Eliminate classes with no purpose
• Ex: Candidate class with purpose are
– ATM machine class
– ATM card class
– Bankclient class
– Bank class
– Account class
– Checking account class
– Saving account class
– Transaction class

14. Common class pattern approach
• Based on knowledge base of the common classes ,
• proposed by researchers like shlaer and mellor
• Patterns for finding class and object
– Concept class
• Particular idea or understanding
– Ex: performance
– Event class
• Are points in time tat must be recorded
• Ex : account, request, order
– Organization class
• Collection of people, resources, facilities or groups to which the user belongs
• Ex : account dept,bank
– People class
• Represents different roles user plays in interacting with the system.
• Ex : bank client
– Places class
• Physical location that the system must keep inform about
• Ex :
– Tangible things and devices
• Includes physical objects or group of objects
• Ex : atmmachine

15. Use case driven approach
• Identifying classes and their usage
through sequence collaboration modelling

16. • Recommended approach
• Problem driven approach
– Prob is considered 1st. Not the relationship bw objects
(like in data driven approach)
• Atleast one senario be prepared for each
significantly different use case instance
• Use case diag – high level view of the system
• Sequence diag – interaction among objects
– By walking through the steps, we can determine what
objects necessary for those steps to take place

17. client atmmachine Bank client
Insert atm card
Request pin
Enter pin number
Verify pin number
Bad pin number
Bad pin number

18. Classes , Responsibilities, and
Collaborators
• Classes ,responsibilities, collaborators
– Leads to identifying its attributes and methods
• CRC index card
– 4” * 6” card
– Cheap, portable, readily available, familiar
– Contains all information
Class name Collaborators
Responsibiliti
es in bullet
format

19. CRC process
• 3 steps
Identify
classes
responsibility(
and identify
classes)
iterate
Assign
Identify responsibiliti
collaborators es

20. Atm system
Account Checking
account
Balance
(sub class)
Number
Saving
account
Withdraw (sub class)
Deposit
getbalance

21. Guidelines: Naming class
• Singular
• Use standard vocabulary
• Reflect its intrinsic feature
• Readable names