How to update use-case with CRC class name?

Question

I'm an information engineer student and I'm studying for an exam. I have to replace nouns in use case in form of bulleted list with the name of the classes extracted with CRC cards. I'm in trouble with that because I don't know how to do it right.

• EXAMPLE A: "the system update the page" -> "Totem update the page"

Does CRC cards have to include classes that control the view? Does this control must pass through a "controller" class like (in my case) "Connection"?

• EXAMPLE A 2.0: "the system update the page" -> "Totem ask Connection to update the page"

Does CRC cards have to include classes that control the database?

• EXAMPLE B: "the system add product in database" -> "Connection add object Product to Catalogue

Can someone help me to understand how to do this correctly? Sorry for my English and sorry for the "strange" question

NOTE: ALL THE EXAMPLES ARE CREATED BY ME, SO I DON'T KNOW IF THEY ARE CORRECT

Answer 1

There's no direct relation

CRC cards and use-cases are two independent techniques:

• CRC card are about classes, their responsibilities and their collaboration (with other classes). It is a tool that helps to explore potential classes and interactions between classes. It can work with any classes, including view classes and control classes.

• Use-cases are goal oriented. The focus is on the reasons why an external actor may interact with a system. It is a tool that help to catch the purpose of a system and its boundaries with the external world. It is in principle independent of any internal classes.

Start to derive classes with an indirect relation

Use-cases can be mapped to classes, using the Entity-Control-Boundary technique. Let's imagine an actor Sales admin and a use-case Manage products:

• every use-case is mapped to a specific control class, e.g. ManageProduct;
• every link between an actor and a use case is mapped to a boundary class, e.g. ManageProductsForSalesAdmin;
• identified business objects that matter to the the actors are also mapped to entity classes, e.g. Product.

Use the CRC cards to fine-tune the design

This could be the start for 3 first CRC cards, which would clarify clarify what class does what (including UI and DB persistence). You'd quickly find out that these initial "analysis classes" need to be broken down further and enriched.

For example:

• the user interface may need different classes depending on your favourite framework. Therefore, break the ManageProductsForSalesAdmin down into more detailed classes such as ManageProductsView and ManageProductsListener or whatever is needed. If all the responsibilities of the initial card were moved to the new cards, you may retire it.
• you may suddenly realize that a Product is associated to a ProductCategory: enrich your set with a new CRC card for the newly discovered entity.
• the ManageProducts could require some specializations to deal with different behaviors such as CreateProduct, DuplicateProduct, ChangeProduct, DeleteProduct. Probably the initial card will keep some common responsibility and will co-exist with the more specialized ones.

You may continue to enrich your CRC set and play with the cards, until you’re satisfied with the classes and reached a stable split of responsibilities. CRC is ideal for iterative work ;-)

Additional comments

The main benefit of the EBC approach is its ability to relate classes to use-cases. This is not only a theoretical benefit, but also a very practical: if you change a class, you may then easily determine potential impact for the users (and points of attention for tests). So every time you create a new CRC card, you may simply keep a trace of the related use-case(s).

A final word on use-cases: “the system updates the page” is not a use-case: this is not a goal for an actor. It is some action the system has to perform in some larger context.

P.S: Sorry if this might come to late for your exam