Unit 3 object analysis-classification
- 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