Lecture 4 Class Responsibility Collaboration Cards Object Oriented Analysis and Design K268 SENG2100 Pat Browne Patrick.Browne@comp.dit.ie http://www.comp.dit.ie/pbrowne/ 57 Lecture 2 Fact Finding

Lecture 2 Fact Finding

CRC Object oriented systems are modeled using objects which initially reflect the abstractions identified in the problem domain. CRC cards capture the object model in terms of classes, responsibilities and collaborations, and the class model in terms of subclass and superclass relationships. CRCs are suited to dynamic team work with particular emphasis on role playing. The team member act out the actions of a particular class. CRCs encourage an antropomorphic view. Fact Finding

Class Responsibility Collaboration cards A CRC card is a physical index card that is annotated and used in a group setting to represent a class of objects the behaviour and interactions of both class and object. There is a card for each class, on which we write the responsibilities and other classes collaborated with. Role play during “brainstorming session”. Model three dimensions of a problem. Portable and anthropomorphic. Fact Finding

Class Responsibility Collaboration cards Side 1 Typical Card has: --------------------------------------------- Class name Subclasses Superclasses Responsibilities Collaborators Side 2 has brief textual description of class and its attributes. Fact Finding

Class Responsibility Collaboration cards As with real-world classification, a class groups together objects that the programmer considers to be similar. The class gives the description of a set of objects with similar characteristics and attributes. One class description serves to describe all instances (members) of that class. The class describes the common protocol followed by the individual members (instances). Fact Finding

Class Responsibility Collaboration cards Objects of the same class respond to the same set of messages (the instance protocol), have the same attributes and respond in the same way to each message. (in analysis) A class describes the behaviour of a set of objects of the same kind. What are classes in design and programming? Fact Finding

Class Responsibility Collaboration cards Responsibilities Responsibilities are the information or data that a class maintains and services that it provides. With a bank account these could include to ‘know balance’ or ‘perform credit’ Collaborators A collaborator is is a class whose services are needed to fulfil a responsibility. Fact Finding

Class Responsibility Collaboration cards Collaborators are listed directly across from the responsibilities that they help fulfil. Collaborators may be listed on more than one card if they help fulfil responsibilities for several classes (1:M). Collaborations only exist to fulfil responsibilities. Collaborations will only be listed when one object actually sends a message to its collaborators . Collaborations are modelled as one way communications from initiator class to collaborator , the response is a message answer. Fact Finding

Creating a classes The Classes can be listed as a group before any cards are used. Alternatively, classes can be encountered and created as part of execution of scenarios. New classes may be discovered at any time during analysis. One person should write the names of classes as they are suggested, not much discussion here. When list is complete remove redundancies. Lecture 2 Fact Finding

Creating a classes Use textual analysis techniques. How about user-interface design? Filtering Classes: classes examined more closely e.g. Book class could be defined as the set of objects that represent books borrowed from a library. Lecture 2 Fact Finding

Assigning Cards After filtering, classes are assigned to cards. Each participant takes an index card which they annotate with the class name and check for agreement. Annotate side 2. Lecture 2 Fact Finding

Assigning Subclass/Superclass Only obvious subclass/superclass relations should be developed at this stage. Lecture 2 Fact Finding

Responsibilities/Attributes We can now assign behaviours. Attributes can be identified by reading the negotiated statement of requirement. Nouns that are not classes but characteristics of classes are best represented as attributes (e.g. the Book class may have a ‘known due date’ attribute). Lecture 2 Fact Finding

Scenarios Next follows a set of walk-throughs of the relevant scenarios from the application area. Scenarios are detailed examples of functions of the system. They describe what happens in the system from a high level point of view. For example in a library: checking out an item, returning an item, searching for an item. A generic scenario is sometimes called a use case. Lecture 2 Fact Finding

Scenarios The simulation for the scenario should be dynamic and anthropomorphic. The cards on the table are static classes. When the cards are held they represent dynamic objects. While executing a scenario the team should be holding the relevant cards. Raising and lowering cards provides visual clues about execution. Note related scenarios. Lecture 2 Fact Finding

CRC uses CRC used during: Can also be used to: Analysis: Looking at problem domain. Design: Refining responsibility. Can also be used to: Select core classes Act out class relationships and scenarios Refine project requirement. Assist project management(giving a idea of the number and complexity of the required classes) Serve as a guide to coding (to some degree) Fact Finding

CRC uses Role play during “brainstorming session”. Model three dimensions of a problem CRC.  Analysis: Exploring at problem domain Design: Refining responsibility. Lecture 2 Fact Finding

CRC session The Classes can be listed as a group before any cards are used. Alternatively, classes can be encountered and created as part of execution of scenarios. New classes may be discovered at any time during analysis. One person should write the names of classes as they are suggested, not much discussion here. When list is complete remove redundancies. Use textual analysis as described. Lecture 2 Fact Finding

CRC session Filtering Classes: classes examined more closely e.g. Book class could be defined as the set of objects that set that represent books borrowed from a library After filtering classes are assigned to cards. Each participant takes an index card which they annotate with the class name and check for agreement. Annotate side 2. Lecture 2 Fact Finding

CRC session Only obvious subclass/superclass relations should be developed at this stage. Assigning behaviours. Attributes can be identified by reading the negotiated statement of requirement. Nouns that are not classes but characteristics of classes are best represented as attributes (the Book class may have a ‘known due date’ attribute). Lecture 2 Fact Finding

CRC session Next follows the walk-throughs (scenarios) of the application area. Scenarios are detailed examples of functions of the system. They describe what happens in the system from a high level point of view. For example in a library: checking out an item, returning an item, searching for an item. Lecture 2 Fact Finding

CRC session The simulation for the scenario should be dynamic and anthropomorphic. The cards on the table are static classes. When the cards are held they represent dynamic objects. While executing a scenario the team should be holding the relevant cards. Physically raising and lowering cards provides visual clues about execution. This promotes an anthropomorphic view of classes and objects. Note related scenarios   Lecture 2 Fact Finding

A quick look at UML use cases Use cases describe the behaviour of a system from a user's standpoint by using actions and reactions. They facilitate the definition of the system's boundary, and the relationships between the system and the environment. A use case diagram consists of an actor linked with one or more uses cases. A use case corresponds to a specific kind of system use. It is an image of a system's functionality, which is triggered in response to the stimulation of an external actor. Use cases have good support tools and standard UML notation Use case is well integrated into RUP. Lecture 2 Fact Finding

CRC and use cases. Use cases alone are not sufficient to build systems; · developers may focus use cases losing sight of class structure and architecture. ·  mistaken design for requirement, user requirement may be improved by design. ·   missing a requirement, not all requirements can be found by identifying actors. and their associated use case. Lecture 2 Fact Finding

CRC and use cases. The examination of use cases on its own is not a good way to find objects and classes. A class model is also required, techniques such as CRC cards are still useful. For example, a customer may never directly interact with a sales system (say its done by a sales person), however a customer would certainly be a class in a sales system. Also other concepts such as architecture need to be developed. Lecture 2 Fact Finding

CRC and use cases. With the emphasis on interaction and anthropomorphism CRC are more appropriate for team collaboration. CRC can be used to develop both the class diagram (structural model) and the sequence diagram (dynamic model). Use case focus more on the requirements from the actors perspecitve. Lecture 2 Fact Finding

Case study (Requirement) A bank plans a new to build ATM system using OO methods. The ATM system will interface with the customers through a display screen, numeric and special input keys, a bank card reader, a deposit slot, and a receipt printer. Customers may make deposits, withdrawals, and balance enquiries using the ATM machine but the update of acounts will be handled by an interface to the Accounts system. Customers will be assigned a PIN and a clearance level by the Security system which can be verified prior to transactions. In the future we would also like to allow customers to update routine information such as change of address or phone number using the ATM. Fact Finding

ATM candidate classes ATM Financial Tranasction CashDispencer Screen Message Display Fact Finding

Lecture 2 Fact Finding

Lecture 2 Fact Finding

Lecture 2 Fact Finding

CRC Summary Class A class describes the behaviour of a set of objects of the same kind. The class is essential when acting out scenarios. Responsibilities are the knowledge that a class maintains and services that it provides. Again when acting out scenarios analyst must be able to develop or know the current responsibilities of a class. Collaborators A collaborator is is a class whose services are needed to fulfil a responsibility. Fact Finding

CRC Summary Use of card during development High level description of role at different stages: 1) Analysis: Exploring at problem domain 2) Design: Refining responsibility. Fact Finding

CRC Summary Use of card during development Details of usage: Teams can use the CRC technique to accomplish a variety of tasks, including: Initially discovering classes Selecting the core classes Acting out class relationships and scenarios or role play during “brainstorming session”. Refining the project requirements Furthering project management, can be used to estimate the number of classes required. Serving as a guide to the design of code. Fact Finding

CRC on the web For further information see: http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/ http://c2.com/doc/oopsla89/paper.html http://www.extremeprogramming.org/rules/crccards.html http://alistair.cockburn.us/crystal/articles/ucrcc/usingcrccards.html Fact Finding