Lecture 4 Class Responsibility Collaboration Cards

1
Lecture 4Class Responsibility Collaboration
Cards

• Object Oriented Analysis and Design
• K268 SENG2100
• Pat Browne
• Patrick.Browne_at_comp.dit.ie
• http//www.comp.dit.ie/pbrowne/

2
(No Transcript)
3
CRC

• Object oriented systems are modelled 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.

4
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 that
  collaborate with it.
• Role play during brainstorming session.
• Portable and anthropomorphic.

5
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.

6
Class Responsibility Collaboration cards

• CLASS
• 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).

7
Class Responsibility Collaboration cards

• CLASS
• 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?

8
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.

9
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 (1M).
• 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.

10
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.

11
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.

12
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.

13
Assigning Subclass/Superclass

• Only obvious subclass/superclass relations should
  be developed at this stage.

14
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).

15
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.

16
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.

17
CRC uses

• CRC used during
• 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)

18
CRC uses

• Role play during brainstorming session.
• Model three dimensions of a problem CRC.
•  Analysis Exploring at problem domain
• Design Refining responsibility.

19
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.

20
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.

21
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).

22
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.

23
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

24
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.

25
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.

26
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.

27
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
  perspective.

28
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 accounts
  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.

29
ATM candidate classes

• ATM
• Financial Transaction

CashDispencer Screen Message Display
30
(No Transcript)
31
(No Transcript)
32
(No Transcript)
33
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.

34
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.

35
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.

36
CRC on the web

• For further information see
• http//www.csc.calpoly.edu/dbutler/tutorials/wint
  er96/crc_b/
• http//c2.com/doc/oopsla89/paper.html
• http//www.extremeprogramming.org/rules/crccards.h
  tml
• http//alistair.cockburn.us/crystal/articles/ucrcc
  /usingcrccards.html