本文为华东师范大学开设的面向对象分析与设计慕课课程第四周笔记，系统地介绍了面向对象分析法的CRC法，同时举了一些例子帮助理解。
首先，我们再来复习一下面向对象分析的三种方法：
- Conceptual model (Larman) 概念模型，又称“名词法”
- Analysis model with stereotypes (Jacobson) 分析模型
- CRC cards (Beck, Cunningham) CRC 法
A good analyst knows more than one strategy and even may mix strategies in order to identify the objects and relationships for the design phase. 一个好的分析师掌握多种技术，知道如何混合使用各种技术，目标只有一个：发现对象、定义对象之间的关系。
标识概念类和对象
原则：
- 类，表示一组具有相同行为、属性的对象 Remember that a class represents a group (classification) of objects with the same behaviors
- 类，在表示对象群体的时候，一般用单数 Generally, classes that represent objects should be given names that are singular nouns
- 根据类，可以创建所需要数量的对象个体 We are free to instantiate as many of each object as needed
可能的抉择：
- 一个名词，是作为概念类合适，还是作为某个类的属性更合适 ？ Sometimes it is challenging to decide whether something should be represented as a class
- 主要还是根据实际情况，取决于我们要解决的问题。一般来说，对问题了解得越细越透彻，越有把握做出决定
在适当的细节层面定义概念类 We want to define classes with the proper amount of
detail
- 当发现一个类非常复杂时，要考虑拆分成多个小一点的类 When a class becomes too complex, it often should be decomposed into multiple smaller classes to distribute the responsibilities
- 但是，又不能有太多的类！But , not too many classes
在表示概念类的过程中，同时要考虑每个类的职责分配，但是不需要在领域模型中明示。
总的来说，对于即将要开发的系统，每项任务 (每个职责) 都需要有一个或多个类去处理，在一开始表示成较为粗狂的职责描述，不必要定义每个类的每个操作
CRC方法标识概念类
CRC (Class Responsibility Cooperation) 分别代表什么？
- Classes (of objects) 类
- Responsibilities (of the objects in each class) 职责
- Collaborations (with objects in other classes) 协作
- In UML, these will be examples of “associations”
CRC又称为索引卡片 (CRC card)，每张卡片代表一个类，每张卡片上写出这个类承担的职责、与其合作交互的其他类名
例子：
CRC的特点
- 非正式的、不是很细节的 Informal, non-detailed
- 采用小组“头脑风暴”的形式提出概念 Used for group brain-storming
- CRC的目标不是提供完整的设计 Not intended to provide a complete design
- CRC产生的结果需要进一步精化 End result is a first cut at classes for an object-oriented model
CRC的输入信息：用例模型
用例图、边界、用例描述，清楚地描述了系统需求，作为CRC概念类分析的起点 A good starting point for CRC analysis is a clear statement of all of the use-cases.
用例描述的正常事件流、异常事件流，可以作为CRC的“角色扮演”的脚本 Use-cases, or their accompanying scenarios, can be used as a kind of script for the role-playing method (角色扮演) of checking the CRC cards
- “角色扮演” 也可以用顺序图代替
CRC方法建模案例：ATM取款机软件
需求描述
University Bank will be opening in January, 2020. We plan to use a
full service automated teller machine (ATM) system
- The ATM system will interact with the customer through a display screen, numeric and special input keys, a bankcard reader, a deposit slot, and a receipt printer
- Customers may make deposits, withdrawals, and balance inquires using the ATM machine, but the update to accounts will be handled through an interface to the Accounts system
- Customers will be assigned a Personal Identification Number (PIN) and clearance level by the Security system. The PIN can be verified prior to any transaction
- In the future, we would also like to support routine operations such as a change of address or phone number using the ATM
通过头脑风暴，列出概念，已加粗表示
标识核心概念类 Identifying Core Classes
Moving from brainstorming to analysis, divide the candidate classes into categories in the following order:
关键的critical classes (i.e., the “winners”), for which we will definitely write CRC cards Items that directly relate to the main entities of the application
在ATM例子中，如：Account, Deposit, Withdrawal, BalanceUnquiry 这些类
无关的 irrelevant candidates (i.e., the “losers”), which we will definitely eliminate Items that are clearly outside the system scope
在ATM例子中，如：Printer, Prompt 这些与我们软件无关的类，可能与用户界面相关，但与模型无关
待定的 undecided candidates (i.e., the “maybes”), which we will review further for categorization
- Items that we may not be able to categorize without first clarifying the system boundaries and definition
明确系统范围 Clarifying System Scope
To continue design, we must determine what is and what is not part of the system
Scope of the ATM system
- Does it handle everything—the banking application, the user
interface, and the interactions between them? - Is the ATM responsible for updating accounting records or just recording and mediating the transaction activity?
- 更新账户的操作一般也不会让ATM操作，一般是传到银行服务器上操作
在ATM例子中，我们需要明确以上问题，有时画图是一个不错的方法来确定系统边界 (如：用例图)
去掉不必要的核心类
进一步检查，发现不适合应用系统的类，检查那些与系统相关、但是在系统外部的类；系统需要有接口与它们通信，但不需要在系统内部为它们建模
在ATM的例子中，比如用户类，ATM并不关心用户的各种信息，比如年龄性别，它只关心用户手里拿的银行卡的信息，以及用户在界面上的操作。
可能你还需要合并同义词
在ATM例子中，BankCustomer和AccountHolder其实是一个概念。但特别要注意的是，同一个名词在不同的地方表示不同的含义时，可能需要增加一个新的核心类。
辨析一个概念是属性还是类，符合以下两点的，一般是属性
它不做具体的事情 it does not do anything — it has no operations
在ATM例子中，Balance and FundsAvailable have few meaningful operations and both are closely associated with Account
它不能改变状态 it cannot change state
If a PIN is viewed as being immutable(不变的), not changing state, then it probably should be an attribute of Account. However, if a PIN can change state — say from among valid, invalid, and suspended — then it should be a class
通过以上分析，我们可以得到ATM的核心类：FinancialTransaction, Account, BalanceInquiry, Withdrawal, Deposit, AuthorizeSystemInteraction, BankCard
为核心类分配职责
为每个核心类准备一个CRC卡，写上职责 Write responsibilities on CRC cards for each core class
为概念类定义协作者，此过程与定义职责的过程是交错进行的 Task of finding collaborators for classes often intermixed with finding responsibilities
集中在 What, 而不是 How
定义职责的方法
- 首先，以“头脑风暴”为核心类列出各种可能的职责，然后再精化，
- 如果大多数职责都归属于少数几个类，则设计出了点问题
- 没有充分利用多态、封装等特性
- 很多类的功能退化为”记录信息”，只知道自己的信息
ATM example: class Account
A tendency might be to give most of the responsibility to the Account class, which becomes a strong, busy “manager” procedure giving commands to relatively weak, ill-defined “worker” classes
- 这样Account这个类可重用性就差了
应该给与每个类一个明确的职责 Give each class a distinct role in the system. Strive to make each class a well-defined, complete, cohesive abstraction
ATM example: class Withdrawal
the responsibility “Withdraw Funds”, making it potentially useful to any other class needing to do a withdrawal
- 取钱应该是ATM例子中比较灵活的功能，如果设计的好，就能在多个地方重用
Factoring out complexity (分解复杂性) also involves identifying specialized behaviors that occurs repeatedly and, as appropriate, spinning off(引出) new classes 如果有一件非常繁琐的事情，可以由几个类共同完成，也可以定义出新的类
ATM example: The capturing and responding to user requests might be factored out into a new class ‘Form’ to ask user for information
使用抽象 Use abstraction
- Build hierarchies of classes. Abstract the essence of related classes by identifying
- where they have common responsibilities
- where they do the same thing, but do it differently
- same “what”, different “how”
- That is, look for opportunities for the classes to use polymorphism to implement the same responsibility differently
- The new parent classes may be abstract classes. The abstract class exists to link together similar concrete types of objects
ATM example: Create an abstract class Transaction that is a superclass for Withdrawal, Deposit, etc. It can have an abstract responsibility “execute a financial transaction”, that is implemented differently for each subclass
分配协作 Assigning Collaborations
标识类之间的关系 Identify relationships among classes
- Each class is specialist in some set of knowledge and behaviors
- Classes must cooperate to accomplish nontrivial tasks
使用“基于场景”的角色扮演，发现/测试协作 Use scenariobased role-play to find and/or test these collaborations
- Scenario is a system behavior and sequence of system events to realize it