Com S 362: Object-Oriented Analysis and Design Class, Responsibilities, Collaborations, CRC Cards Com S 362: Object-Oriented Analysis and Design Oct 18, 2006

Com S 362: Object-Oriented Analysis and Design From Analysis to Design Input artifacts: use cases, domain model, system sequence diagrams Refine these artifacts, one step closer to the executable system

Com S 362: Object-Oriented Analysis and Design Key Steps Finding entities in your system –These entities will become classes Assigning responsibilities to these classes –Often become operations that a class support Identifying collaborations between classes –Represent relationships between classes –Often describe dependence

Com S 362: Object-Oriented Analysis and Design Relation to Previous Phases Analysis: Domain Model Identify conceptual classes Identify attributes of conceptual classes Identify association between conceptual classes Design: Class Diagrams Identify solution classes Identify responsibilities of solution classes Identify collaboration between solution classes

Com S 362: Object-Oriented Analysis and Design Finding Solution Classes Conceptual Classes in Domain Model –Not every conceptual class may be required –Example: Copyright law, a conceptual class, but may not be a solution class –Some conceptual classes may become attributes –Example: Library, a conceptual class, but may just be an attribute, if only name is useful Use cases

Com S 362: Object-Oriented Analysis and Design Example: Domain Model Initial Class List: Patron, Book, Fine, Librarian, Manager, Library, Partner Library

Com S 362: Object-Oriented Analysis and Design Refining Class List: Redundancy Initial class list: patron, book, fine, librarian, manager, library, partner library Question: Are all user types (patron, librarian, manager) necessary?

Com S 362: Object-Oriented Analysis and Design Refining Class List: Redundancy Alternative: can we have a generic user type with different permissions for patrons, librarians, and managers? Refined class list : user, permissions, book, fine, library, partner library

Com S 362: Object-Oriented Analysis and Design Refining Class List: Redundancy Alternative rejected: Coupling between different user types in one class Change in any user type’s behavior affects this class Refined class list : patron, book, fine, librarian, manager, library, partner library Low coupling [Larman page ]

Com S 362: Object-Oriented Analysis and Design Refining Class List: Relations Initial class list: patron, book, fine, librarian, manager, library, partner library Question: Are patrons, librarians, managers related?

Com S 362: Object-Oriented Analysis and Design Refining Class List: Relations Alternative: Can we have another class user, the patrons, librarians, managers are all users at some level? Refined class list : user, patron, book, fine, librarian, manager, library, partner library

Com S 362: Object-Oriented Analysis and Design Refining Class List: Attribute or Class Initial class list: patron, book, fine, librarian, manager, library, partner library Question: Is fine a property of a patron? Can fines exist by themselves?

Com S 362: Object-Oriented Analysis and Design Refining Class List: Attribute or Class Alternative: Can we have fines as an attribute of patrons? Refined class list : patron, book, librarian, manager, library, partner library

Com S 362: Object-Oriented Analysis and Design Refining Class List: Discovery Initial class list: patron, book, fine, librarian, manager, library, partner library Question: Does library owns items other than books?

Com S 362: Object-Oriented Analysis and Design Refining Class List: Discovery Alternative: Can we have another set of classes videos, CDs, DVDs? Refined class list: patron, book, videos, CDs, DVDs, fine, librarian, manager, library, partner library

Com S 362: Object-Oriented Analysis and Design Refining Class List: 1 st Change Initial class list: patron, book, videos, CDs, DVDs, fine, librarian, manager, library, partner library Question: Is library ever going to own anything that we have not thought about here?

Com S 362: Object-Oriented Analysis and Design Refining Class List: 1 st Change Alternative: Can we have another type Item, an abstraction of books, videos, CDs, DVDs? Refined class list: patron, Item, book, videos, CDs, DVDs, fine, librarian, manager, library, partner library

Com S 362: Object-Oriented Analysis and Design Refining Class List: 2 nd Change Initial class list: patron, Item, book, videos, CDs, DVDs, fine, librarian, manager, library, partner library Question: Is library ever going to support multiple level of memberships? e.g, platinum can borrow unlimited, gold can borrow 25 items, silver can borrow 5 items, bronze can borrow 1 item only

Com S 362: Object-Oriented Analysis and Design Refining Class List: 2 nd Change Alternative: Can we have another type IPatron, an abstraction of different type of patrons? Refined class list: IPatron, patron, Item, book, videos, CDs, DVDs, fine, librarian, manager, library, partner library

Com S 362: Object-Oriented Analysis and Design Refining Class List: 3 rd Change Initial class list: IPatron, patron, Item, book, videos, CDs, DVDs, fine, librarian, manager, library, partner library Question: Is library ever going to support different type of librarians with different job responsibilities? Some will work at circulation desk, other kind at the reference desk, yet another kind are allowed to modify the library catalog and add new books.

Com S 362: Object-Oriented Analysis and Design Refining Class List: 3 rd Change Alternative: Can we have another type ILibrarian, an abstraction of different type of librarians? Refined class list: IPatron, patron, Item, book, videos, CDs, DVDs, fine, ILibrarian, librarian, manager, library, partner library

Com S 362: Object-Oriented Analysis and Design Assign Responsibilities Where do responsibilities come from? –Use case scenarios –Objective is to fulfill user’s goals

Com S 362: Object-Oriented Analysis and Design Example Scenario Success Scenarios #1: A patron approaches the library administration machine with books to borrow. The patron enters her/his membership information. The machine verifies the membership information. The patrons enters the book information. The machine updates the library catalog to reflect that the book is checked out. The machine outputs a receipt containing the due date. The patron receives a receipt from the machine. Responsibilities are underlined

Com S 362: Object-Oriented Analysis and Design Identified Responsibilities Prompt and store membership information Verify membership information Prompt and store book information Update the library catalog Output a receipt {Due date} Class list: IPatron, patron, Item, book, videos, CDs, DVDs, fine, ILibrarian, librarian, manager, library, partner library

Com S 362: Object-Oriented Analysis and Design Prompt and Record Member Info Do we need to refine class list? –How to prompt? –How to store? Class list: IPatron, patron, Item, book, videos, CDs, DVDs, fine, ILibrarian, librarian, manager, library, partner library

Com S 362: Object-Oriented Analysis and Design Classic case for 3-tiered architecture User Interface IPatron, patron, Item, book, videos, CDs, DVDs, fine, ILibrarian, librarian, manager, library, partner library Database

Com S 362: Object-Oriented Analysis and Design Information Expert Which class has the necessary information to prompt? Which class has the necessary information to store? Class list: IPatron, patron, Item, book, videos, CDs, DVDs, fine, ILibrarian, librarian, manager, library, partner library, User Interface, Database

Com S 362: Object-Oriented Analysis and Design Assigning Responsibilities Class Name: UI Subclasses: Super classes: Responsibilities Collaborators Prompt IPatron Class Name: IPatron Subclasses: Patron Super classes: Responsibilities Collaborators Store

Com S 362: Object-Oriented Analysis and Design Summary Identifying Solution Classes –Based on domain models –Based on use cases Refining Solution Class List Assigning Responsibilities to Classes