CRC(Class Responsibility Collaborator) 模型简介

      Class Responsibility Collaborator（以下简称CRC）模型（Beck & Cunningham 1989; Wilkinson 1995; Ambler 1995）是一种收集并整理卡片的开发方式。一个CRC卡片由三个组成部分构成：1、首先构成相似现实对象的类；2、明确此类应该知道或者应该做的职责；3、找出在此类实现职责过程中产生相互作用的其他类作为协作者。这是第一步，在讨论中进行，如图1所示。

 

图1：CRC卡片结构

 

      一般来讲，我们的卡片都是手绘的。如图2所示。

 

图2：手绘CRC卡片

 

      虽然一开始的时候CRC卡片被设计来进行面向对象（Object-Oriented）思想的授课，但它也被证实是一种成熟的建模方式。就我的经验来讲，CRC建模在建立概念模型和详细设计上都让人难以置信地有效。作为一种设计方式，CRC卡片在极限编程（XP,eXtreme Programming）中也可以起到非常重要的作用。我在这里所关注的是，如何将CRC卡片在我们的概念建模中使用起来。

 

      类代表了一组相似的对象，对象是人物、地点、事物、事件，甚至即将创建的系统相关的一个概念。例如，在一个大学管理系统中，多个学生、多个终身教授和多个研讨会就成为一组类。类的名字写在卡片的最上方，横穿整个卡片。这个名字通常是一个突出的名词或者一个名词词组。例如学生、教授或研讨会。使用突出的名称，是因为每一个类都代表了单个对象的普遍版本。虽然我们可能通过学生John构建一个名称为“学生”的卡片，但是这些信息将描述的是一个人，而不是一群人。因此，在这里使用“学生”而不是“学生群体”就显得更加合理。同样的，类的名字也应该简洁简单。例如，“学生”和“参加研讨会的人”，哪一个更好一些？

 

      职责是类知道或者做的任何事情。例如，学生有姓名、地址和电话号码。这是学生所知道的东西。学生也会参加研讨会、退出研讨会和请求查看成绩单。这是学生所做的事。类所知道的东西和所做的事构成了类的职责。重要的是：类可以对自己所知道的东西更改值，而不能对其他类所知道的东西更改值。

 

      有时候，类需要执行自己的某个职责，但是发现没有足够的信息支持而无法进行。例如图3所示，学生可以参加研讨会。学生在执行这个职责时，需要知道这个研讨会中是否有空的座位，如果有，他才需要加入研讨会。但是，学生仅仅有他自己的一系列信息（如姓名等等），并没有研讨会的信息。学生需要做的事必须协作/配合标签为“研讨会”的卡片以便加入研讨会。因此，“研讨会”出现在“学生”卡片的协作者列表中。

图3：学生CRC卡片

 

      协作者包含一至两个方面：需要的信息或者需要的事务。例如，学生卡片需要研讨会卡片提供是否有空座位的信息，这是一个需要的信息。学生卡片也需要加入到研讨会卡片中去，这是一个需要的事务。我们也可以从另外一个角度去看这个逻辑，学生卡片简单地请求研讨会卡片把自己加入到其中。那么研讨会卡片就必须做出判断，如果有空座位那么加入学生，如果没有则提示学生没有被加入。

 

      因此，如何构建CRC模型呢？只要循环进行一下步骤：

• 找出类。找类是进行分析任务的基础工作，因为它可以为你的程序标示出每个构建块。一个好的经验是，我们应该首先立即找出3至5个主要类，如图4所示，找出学生、教授和研讨会等。有时也会包括一些UI（User Interface界面）类，如成绩报告单或学生安排都是报告，尽管其他的类将保持为实体类（Entity Class）。同样，当客户很难于确定显示中学生（角色）的概念与系统中学生（实体）的对应时，有时也会用卡片代表角色。
• 找出职责。你不但应该问自己一个类应该做什么还应该问自己关于它的哪些信息你需要保留。你也经常会为类标示出一个与其他类一起协作的职责
• 界定协作者。类经常会在执行其职责时发现没有足够的信息支持。因此，它通常会配合（主导）其他类以便能完成工作。协作应该是以下两者之一：一个信息请求或者一个任务执行请求。对类中的每一个职责标示协作者时，都应该问问自己“这个类有能力完全自己执行这个职责吗？”。如果不是，那么就应该查找另外一个类，或者可以有能力弥补缺少的设计部分，或者它就应该执行这个职责。这样做了，会经常发现其他类需要一些新的职责或者可能是我们需要一两个新的类。
• 移动卡片。为了让所有人都理解这个系统，所有的卡片应该按照某种容易理解的方式进行排列。有2张卡片与另外1张卡片有协作关系的话，我们应该将他们放在一起。反之没有协作关系的卡片应该互相远离。此外，如有超过2张卡片一起协作，尽量将这些卡片靠近些。这样做了，就更直观且容易地了解各个类的关系——靠近则协作。

图4：CRC模型

 

      那如何让你的CRC模型更加敏捷呢？根据 Model in Small Increments ，最好的方法是对单个需求都创建一个CRC模型，例如 user story （用户流程）business rule （业务规则）, 或者 system use case （系统用例），而不是为系统收集整个的需求。CRC卡片是一种包容性很强的简便工具，熟练掌握需要多做练习，最好是根据Active Stakeholder Participation。

 

      也要认识到，CRC卡片并不是一成不变的。当你将CRC模型转化为UML图（ UML class diagram），或者直接构建代码时，应该根据情况有所改变。一些职责会被重构，引入一些新类，抛弃一些存在的类等等。当开发逐渐发展的时候，这些都可能发生。

 

资源：本文摘录自《The Object Primer 3rd Edition: Agile Model Driven Development with UML 2》（对象入门-使用UML2进行敏捷开发）第8章

 

原文地址：Introduction Class Responsibility Collaborator (CRC) Models