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.
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"?
Does CRC cards have to include classes that control the database?
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
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.
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
:
ManageProduct
;ManageProductsForSalesAdmin
;Product
.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:
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.Product
is associated to a ProductCategory
: enrich your set with a new CRC card for the newly discovered entity.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 ;-)
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