1. Software Engineering Object-Oriented Analysis (CRC Cards) James Gain (jgain@cs.uct.ac.za)jgain@cs.uct.ac.za http://people.cs.uct.ac.za/~jgain

2. Objectives 1.Explain the Class-Responsibility-Collaborator (CRC) modelling process: A.Identify and select Classes B.Incorporate Responsibilities C.Incorporate Collaborators D.Review the Model 2.Provide a case study of CRC Modelling in action 3.Do an exercise on CRC Modelling

3. Road Map ProcessModel Output 1. Elicit customer requirements and identify use-cases Use-Case Diagrams 2. Extract candidate classes, Identify attributes and methods, Define a class hierarchy Class Responsibility Collaborator (CRC) Cards 3. Build an object-relationship model Class Diagram 4. Build an object-behaviour model Interaction Diagram

4. Class-Responsibility-Collaborator Modelling lA simple means of identifying and organizing classes lNot an official part of UML lA CRC model is a collection of index cards that represent classes lEach CRC card contains:  Class name, type, characteristic  Responsibilities  Collaborators lSteps in CRC modelling: 1.Identify and select Classes 2.Incorporate Responsibilities 3.Incorporate Collaborators 4.Review the Model

5. CRC Benefits lPortable:  No computers are required so they can be used anywhere. Even away from the office lTangible:  They allow the participants to physically experience how the system will work lLimited Size:  Index cards can only hold a limited amount of information. This enforces a high-level analysis lTestable:  CRC cards derive from Use-Cases and can be tested against them

6. CRC Cards CRC Cards class name: class type: (e.g., device, property, role, event,...) class characteristics: (e.g., tangible, atomic,...) responsibilities: collaborators:

7. [A] Identifying Classes lClasses and Objects are extracted from the Use-Case narratives by doing a grammatical parse lGrammatical Parse:  Underline nouns or noun clauses (these describe candidate objects)  Enter the candidate objects (and their associated classes) into a table  Remove synonyms  Solution Space (objects required to implement the solution) vs. Problem Space (objects required to describe the problem) l“The really hard problem [in OO] is discovering what are the ‘right’ objects in the first place”

8. Accepting Classes lObjects accepted if they satisfy most of the following requirements: 1.Retained Information: the system needs to remember data about the object 2.Needed Services: the object must have an identifiable set of operations 3.Multiple Attributes: during analysis we focus on major information only. Objects should have many attributes 4.Common Attributes: A set of attributes apply to all occurrences of the object 5.Common Operations: A set of operations apply to all occurrences of the object 6.Essential Requirements: external entities that produce or consume essential information

9. Case Study: Identifying Classes lUse Case Narrative for Draw Edges:  A transparent overlay image is placed over the original reference picture.  The draftsman draws black edges of a consistent thickness onto the overlay using the mouse.  The draftsman is also able to erase edges that are incorrect.  The draftsman can save the overlay as a black and white image with the same resolution as the reference picture. lPotential Objects/Classes  Overlay ImageReference Picture  DraftsmanEdge  ThicknessMouse  Black-and-white ImageResolution

10. Case Study: Accepting Classes Potential Object/ClassClass requirements Overlay ImageAccepted: all apply Reference PictureAccepted: all apply DraftsmanRejected: 1 (retained info) fails, system user EdgeAccepted: all apply ThicknessRejected: 3 (multiple attributes) fails, attribute of edge MouseRejected: 1 (retained info) fails Black-and-white ImageAccepted: all apply ResolutionRejected: 3 (multiple attributes) fails, attribute of image

11. Class Types lAccepted classes are assigned a type:  External entities - other systems, devices, people  Things - reports, displays, signals  Occurrences or events - property transfer, completion of a series of robot movements  Roles - manager, engineer, sales person  Organizational Units - division, group, team  Places - manufacturing floor, loading dock  Devices - four-wheeled vehicles, computers  Property - of the problem, e.g. credit rating  Interaction - model interaction that occur among other objects, e.g. a purchase or a license

12. Class Characteristics lAccepted classes are assigned a set of characteristics:  Tangibility: does the class represent a tangible (physical) or abstract (information) entity?  Inclusiveness: is the class atomic (includes no other classes) or aggregate (has at least one nested object)?  Sequentiality: is the class concurrent (has its own thread of control) or sequential (scheduled by outside resources)?  Persistence: is the class transient (created and removed during program operation), temporary (created during program operation and removed at termination) or permanent (stored in a database)?  Integrity: is the class corruptible (does not protect its resources from outside influence) or guarded (the class enforces access control)?

13. Case Study: CRC Card class name: Overlay Image class type: Thing class characteristics: abstract, aggregate, sequential, transient responsibilities: collaborators:

14. [B] Identifying Responsibilities lResponsibilities (attributes and methods) are extracted from the Use-Cases descriptions lAttributes:  Describe the object  Select those things that reasonably belong to an object  Question: What data items fully define this object in the context of the particular use-case? lMethods (Operations):  Define the behaviour of the object and alter the object’s attributes  Types of operations – data manipulation, computation, event monitoring  Do a grammatical parse of the Use-Case description and isolate verbs and verb clauses

15. Guidelines for Allocating Responsibilities to Classes 1.System intelligence should be evenly distributed. 2.Each responsibility should be stated as generally as possible. 3.Information and the behavior that is related to it should reside within the same class. 4.Information about one thing should be localized with a single class, not distributed across multiple classes. 5.Responsibilities should be shared among related classes, when appropriate.

16. Case Study: Identifying Responsibilities lNarrative:  A transparent overlay image is placed over the original reference picture.  The draftsman draws black edges of a consistent thickness onto the overlay using the mouse.  The draftsman is also able to erase edges that are incorrect.  The draftsman can save the overlay as a black-and-white image with the same resolution as the reference picture. lExample Operations:  Placed over Reference (belongs to Overlay Image)  Draw (belongs to Edge)  Erase (belongs to Edge)  Save (belongs to Overlay Image) lRemember some may be rejected

17. [3] Identifying Collaborators lCollaborations represent requests from a client to a server in fulfillment of a client responsibility lOne object collaborates with another if it needs to send a message lRelationships:  is-part-of (classes that are contained within an aggregate class as attributes)  has-knowledge-of (one class must acquire information from another)  depends-upon (dependency not covered by part-of or knowledge-of) lCase Study: Edge is-part-of Overlay Image. Overlay Image has-knowledge-of Reference Picture

18. Case Study: CRC Card class name: Overlay Image class type: Thing class characteristics: abstract, aggregate, sequential, transient responsibilities: collaborators: Place Save Resolution Edge Reference Image Black-and-white image

19. [4] Reviewing the CRC Model 1.All participants in the review (of the CRC model) are given a subset of the CRC model index cards. 2.All use-case scenarios (and corresponding use-case diagrams) should be organized into categories. 3.The review leader reads the use-case deliberately. As the review leader comes to a named object, she passes the token to the person holding the corresponding class index card. 4.When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities satisfies the use-case requirement. 5.If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards.

20. Case Study: CRC Review lReview:  A transparent overlay image [pass token] is placed over the original reference picture [pass token].  The draftsman draws black edges [pass token] of a consistent thickness onto the overlay [pass token] using the mouse.  The draftsman is also able to erase edges [pass token] that are incorrect from the overlay [pass token].  The draftsman can save the overlay [pass token] as a black-and- white image [pass token] with the same resolution as the reference picture [pass token]. lCRC Tips: 1.Don’t generate long lists of responsibilities. This is missing the point. The responsibilities should easily fit on a card. 2.The review stage is crucial. Spend a lot of time here.

21. Exercise: Identifying Classes lNarrative:  SafeHome software enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through a keypad and function keys contained in the SafeHome control panel.  During installation, the SafeHome control panel is used to “program” and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs.  … lIdentify Potential Classes and Accept or Reject based on:  [1] Retained Information, [2] Needed Services, [3] Multiple Attributes, [4] Common Attributes, [5] Common Operations, [6] Essential Requirements

22. Exercise: Identifying Responsibilities lNarrative:  SafeHome software enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through a keypad and function keys contained in the SafeHome control panel.  During installation, the SafeHome control panel is used to “program” and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs. lDo a grammatical parse for verbs and select possible operations.

23. Solution: CRC Review lUse-Case Narrative:  The homeowner observes the control panel to determine if the system is ready for input. If the system is not ready, the homeowner must physically close window/doors so that the ready indicator is present [a not ready indicator implies that a sensor is open]. lWhen review leader comes to “control panel” token is passed to the person holding the control panel CRC card. lPhrase “implies that a sensor is open” means a responsibility must validate this. lThe control panel CRC card has sensor as a collaborator lThe token is next passed to the sensor CRC card.