作者：gnuhpc
出处：http://www.cnblogs.com/gnuhpc/
CRC卡片的背面往往记载着这个类的详细描述和在CEC设计中的一些注意事项。
2.如何使用CRC卡组织团队成员？
我们可以使用CRC卡完成设计团队成员的组织工作，但是需要限制在6人以下以提高效率，否则可能会增加沟通成本。我们的成员组成一般有以下三类，职责、人数建议、及其特征描述如下：
· 用户
o 人数：3-5
o 特征：
§ 丰富的行业知识
§ 清晰的业务流程
§ 逻辑思维和良好沟通
§ 对系统设计感兴趣
· OO设计人员
o 人数：1-2
o 特征：
§ 通晓CRC建模流程和方法
§ 通晓OO设计思路和方法
§ 有实际开发OO系统的经验
· 项目协调人
o 人数：1
o 特征：
§ 良好的会议沟通和管理技巧
§ 通晓CRC建模流程和方法
3.CRC分析流程
1）准备工作：
召集人员，拿到相关业务流程的需求——Statement of work，SOW工作陈述，从SOW中提炼出需求，以项目符号列表的形式表示每一个特定的需求。
2）CRC卡的建立：
a.类对应于名词，读完需求分析后，你可以划出一些名词作为类设计的切入点。当然，要习惯于迭代的方式，一开始列出的名词并不见得都要最终设计为一个类，而后续可能因为可用性等需要设计额外的类。
b.我们可以通过这个名词列表进行一一筛选分析，适当把握抽象与具体的关系，比如一个司机、一个秘书、一个经理可能都能抽象为人这个类，但是在第一轮迭代中，若无明显的需求，我们可以先暂时不用去考虑。对于普通的一般的关系，我们可以考虑超类的设计，也可以考虑通过构造函数重载完成。
c.在设计中，我们要注意目标之一是保证可扩展性，重构也是我们要考虑的一个隐性需求。
d.通过第一轮迭代我们就找出了我们需要关注的类。接着我们需要明确类的职责。职责的一个切入点是动词，从动词的列表中就可以得到职责初步列表，然后就行迭代。在这个过程中，并不是每一个动词都会成为一个职责，几个动词可能组成一个职责，最终选择的一些职责可能并没有出现在最初的职责中，对于共享的职责我们要特殊标识，以便在后续的详细设计中特殊处理（比如Java中的接口）。
e.在完成类的职责分析后我们开始根据这些职责及其交互关系明确协作关系，我们此时可以通过用例场景（系统对用户请求或事件作出响应时完成的一个事务或相关操作序列），对于每一个用例，明确交换的对象和消息。在这个过程中，参与的人可以通过角色扮演的方式，既活跃了气氛，又能在沟通交互中体现每一个类职责与协作。
f.完成CRC后就可以通过UML完成正式的初步设计了。