标识概念类和对象
用户可以通过主要的特征指定每一项产品，包括产品的名字和产品的号码。如果条形码和产品不匹配，信息窗口会报告错误并且将其保存到错误日志。所有交易信息的最终报告必须按照7.A节中规定的结构。
原则
- 类，表示一组具有相同行为，属性的对象
- 类，在表示对象群体的时候，一般用单数
- 根据类，可以创建所需要数量的对象个体类名的选择很重要！要能够帮助大家理解
如Customer？Or User：哪个更好，视情况而定
可能的抉择：一个名词，是作为概念类合适，还是作为某个类的属性合适？
eg：员工的地址应该作为单独的类还是属性
一般原则
对问题了解的约细越透彻，越有把握做出决定。
练习：
eg：产品描述与产品
eg：手机的PIN吗与手机用户？因为PIN码本身可以处在“激活”，“锁定”，“正常”，“失效”等状态
在适当的细节层面定义概念类
当发现一个类非常复杂时，要考虑拆分成多个小一点的类
但是，又不能有太多的类
这些都取决于我们要解决的问题
类的选择依赖于应用领域
在标识概念类的过程中
- 同时要考虑每个类的职责分配
- 但是不需要在领域模型中明示
总的原则
- 即将要开发的系统，每项任务（每个职责）都需要有一个或多个类去处理
- 标识成类的操作（一般是动词）
- 在分析，设计的早期，不必要定义每个类的每个操作
- 一开始，标识成较为粗狂的职责描述
CRC方法标识概念类（Class类 Responsibilities职责 Collaborations协作）
一种发现概念类并分配职责的途径
从“领域类，用例”到设计类
CRC的输入信息：用例模型
用例模型：用例图，边界，用户描述，清楚地面熟了系统需求，作为CRC概念类分析的起点
用例描述的正常事件流，异常事件流，可以作为CRC的“角色扮演”的脚本。
CRC案例：绘图工具软件
用例：画图 移动图形 修改大小 连接形状 擦掉一个形状 擦掉连接
CRC方法建模的一些规则
CRC指导
CRC的card由团队来实现，由1-2个领域专家，1-2分析师，1个面向对象分析师，一位引导者，客户
头脑风暴：收集各种各样的想法，比较这些想法并进行合成
头脑风暴的原则：
所有想法都是好的想法
提出问题时很激烈，之后沉思分析
每一个人都有机会表达
有点小幽默
头脑风暴的步骤
案例分析
