Introduction to the CRC (class responsibility collaborator) Model

Class responsibility collaborator (CRC) model (Beck & cunnheim 1989; Wilkinson 1995; Ambler 1995) is a way to collect and organize cards. A crc card consists of three parts: 1. First, a class similar to a realistic object; 2. specify the responsibilities that such a card should know or be responsible; 3. Identify other types that interact with each other in the process of implementing such duties as collaborators. This is the first step, as shown in 1.

 

Figure 1: CRC card structure

 

Generally, our cards are hand-painted. 2.

 

Figure 2: hand-drawn CRC cards

 

Although the CRC card was designed to teach the object-oriented idea at the beginning, it was also proven to be a mature modeling method. In my experience, CRC modeling is incredibly effective in both conceptual modeling and detailed design. As a design method, CRC cards can also play a very important role in extreme programming (XP, eXtreme Programming. What I am concerned about here is how to use CRC cards in our conceptual modeling.

 

ClassRepresents a group of similar objects. objects are people, places, things, events, and even concepts related to the system to be created. For example, in a university management system, multiple students, multiple life-long professors, and multiple seminars become a group. The class name is written at the top of the card, crossing the entire card. This name is usually a prominent noun or a noun phrase. For exampleStudents and professorsOrSeminar. Use a highlighted name because each class represents a common version of a single object. Although we may build a card named "student" through student John, this information will describe a person, not a group of people. Therefore, it is more reasonable to use "student" instead of "student group" here. Similarly, the class name should be concise and simple. For example, Which of the following is better?

 

ResponsibilitiesIs anything the class knows or does. For example, a student has a name, address, and phone number. This is what students know. Students will also attend the seminar, exit the seminar, and request to view the transcript. This is what students do. What the class knows and what it does constitute the responsibility of the class. The important thing is that a class can change the value of what you know, rather than the value of what other classes know.

 

Sometimes, a class needs to perform its own duties, but it cannot be performed without sufficient information support. As shown in Example 3, students can attend the Seminar. When performing this role, students need to know whether there are free seats in this Seminar. If so, they need to join the seminar. However, students only have a series of their own information (such as their names) and have no information about the seminar. What students need to do must collaborate/cooperate with cards labeled as "seminars" to join the seminar. As a result, the workshop appears in the collaborators list of the student card.

Figure 3 student CRC card

 

CollaboratorsContains one or two aspects: required information or required transactions. For example, a student card needs a seminar card to provide information about whether there is an empty seat. The student card also needs to be added to the seminar card, which is a required task. We can also look at this logic from another perspective. The student card simply asks the seminar card to add itself to it. Then the seminar card must be judged. If there is an empty seat, join the students. If not, the students are prompted not to join.

 

Therefore, how can we build a CRC model? Perform the following steps in a loop:

• Find the class.Searching for classes is the basic work of an analysis task, because it can mark each build block for your program. A good experience is that we should first immediately find 3 to 5 main classes, as shown in 4, to find outStudents, professors and seminars. Sometimes there are some UI (User Interface interface Interface) classes, such as the score report or student arrangement are both reports, although other classes will be kept as entity classes ). Similarly, when it is difficult for a customer to determine the relationship between the concept of a middle school student (role) and that of a system middle school student (entity), cards are sometimes used to represent the role.
• Identify responsibilities.You should not only ask yourself what a class should do, but also ask yourself what information you need to keep about it. You will also often mark a responsibility for collaboration with other classes for the class.
• Define collaborators.Classes often find insufficient information to support when performing their duties. Therefore, it usually works with (dominant) other classes to complete the work. Collaboration should be one of the two: an information request or a task execution request. When marking the co-author for every responsibility in the class, you should ask yourself, "Is this class capable of fully performing this responsibility on its own ?". If not, you should look for another class, or be able to make up for the missing design part, or it should perform this responsibility. By doing so, we often find that other classes require some new responsibilities or maybe we need one or two new classes.
• Move the card.To make everyone understand the system, all cards should be arranged in a way that is easy to understand. If there are two cards in collaboration with the other one, we should put them together. Otherwise, cards with no collaboration relationship should be kept away from each other. In addition, if more than two cards work together, try to keep these cards closer. By doing so, you will be more intuitive and easy to understand the relationships of various classes-collaboration when approaching.

Figure 4: CRC model

 

So how can we make your CRC model more agile? Based on Model in small increments, the best way is to create a CRC model for a single requirement, such as user story (user process)Business Rule(Business Rules), orSystem use case(System use cases), rather than collecting overall requirements for the system. CRC cards are a simple and inclusive tool. You must be familiar with them and need to do more exercises.Active stakeholder participant.

 

We must also realize that CRC cards are not static. When you convert a CRC model to a UML diagram (UML class digoal), Or directly build the code, it should be changed according to the situation. Some responsibilities will be restructured, some new classes will be introduced, and some existing classes will be discarded. This may happen when development develops gradually.

 

Resources: This article is excerpted from Chapter 8th "the object primer 3rd edition: Agile Model Driven Development with UML 2" (getting started with objects-using UML2 for agile development)

 

Original article: Introduction Class responsibility collaborator (CRC) Models