CRC（类职责协作）建模全面指南

Table of Contents hide

3.6 步骤6：用例场景测试（“传球”练习）

基于面向对象（OO）分析的基本原则，本指南概述了CRC建模过程。CRC建模是一种高效且低技术含量的方法，旨在弥合开发人员与用户之间的沟通鸿沟，确保在编写代码之前准确识别并理解业务需求。

1. 核心概念：CRC卡片的结构

CRC建模依赖于标准索引卡，这些卡片被划分为三个不同的部分，每个部分代表面向对象设计中的一个核心概念。

A CRC Card by Visual Paradigm

A. 类（卡片顶部）

类代表一组相似的对象。对象可以是与系统相关的人员、地点、事物、事件、概念、屏幕或报告。

命名规则：使用一个或两个单数词（例如，客户，而不是客户们).
示例：在运输/库存系统中，类包括库存项目, 订单, 订单项, 客户，以及表面地址.

B. 职责（左侧栏）

职责是指类所知道或所做的任何事情.

它所知道的（数据/属性）： 示例：一个客户类知道其姓名、客户编号和电话号码。
它所执行的（行为/方法）： 示例：一个客户类可以订购产品、取消订单并进行付款。

C. 协作者（右栏）

当一个类需要从另一个类获取信息或协助以履行责任时，协作就会发生。

示例：一个订单对象有责任“计算总额”。然而，它并不知道商品的价格或订购数量。因此，它必须与协作订单项（知道数量）以及库存项（知道价格）来计算最终总额。

2. CRC建模团队

一次成功的CRC会议需要特定的角色，以确保流程顺利进行，并准确捕捉业务逻辑。

业务领域专家（BDEs）：系统的实际使用者（通常为4到5名一线员工）。他们拥有日常业务知识。注意：高管通常不适合参与CRC；他们更适合用于高层次的用例。
主持人：主持会议，解释技术方法，提出相关问题，确保卡片填写正确，并引导场景测试。
记录员：1到2名坐在后方或侧边的人。他们不直接参与建模，而是记录无法写在小型索引卡上的详细业务逻辑和规则。
观察者：坐在后方观看但不参与的学员或利益相关者。

3. 六步CRC建模流程

6-step CRC Modeling Process

步骤1：组建团队

召集4到5名一线BDE，1名引导员和1到2名记录员。确保管理层支持，以便参与者能投入必要的时间。

步骤2：布置房间

可书写表面：用于头脑风暴和原型设计的便签板或白板。
建模桌：一张大型中央桌子，供BDE们放置和移动卡片。
记录员位置：放置在不显眼但视野清晰的位置的桌子。
用品：索引卡、记号笔以及一个柔软的海绵球（稍后用于场景测试）。

步骤3：头脑风暴

提出想法而不加以评判。引导员提出开放式问题以了解业务需求。

示例问题：“这个系统是为谁设计的？”，“它支持哪些业务需求？”，“我们如何做得更快/更便宜/更好？”，“有没有我们可以自动化的琐碎任务？”

步骤4：解释技术

引导员花费10到15分钟解释CRC概念，将定义醒目地展示在墙上，并指导团队制作几张示例卡片。

步骤5：迭代式CRC建模

BDE们站在或坐在桌子周围，迭代地构建模型：

寻找类：追踪资金流向，查找报表/屏幕，并立即识别出3到5个主要类。
寻找职责：询问该类知道什么、能做什么。
定义协作者：确定谁持有完成职责所必需的缺失信息。
整理卡片： 关键步骤。经常协作的卡片被放置在桌面上靠近的位置。“繁忙”的卡片放在中心。将卡片实际移动有助于团队可视化它们之间的关系和关联。

步骤6：用例场景测试（“传球”练习）

这是一个验证练习，团队通过“模拟”系统的工作流程来确保模型的准确性。

提出一个场景：主持人描述一个用例（例如：“客户下订单”），并将软球扔给持有初始责任卡片的BDE（例如，订单).
确定责任：团队确认该卡片负责此项任务。如果不是，则更新或创建一张新卡片。
描述逻辑：持球的BDE向记录员描述逐步的业务逻辑（伪代码）。
协作：如果BDE需要从另一个类获取信息（例如，库存项目），他们就将球传给持有该卡片的BDE。该BDE随后描述其逻辑部分。
将球传回：任务完成后，球被传回给上一个人，最终回到主持人手中，以开始下一个场景。

4. CRC如何融入SDLC

CRC建模并非孤立存在；它是更广泛的面向对象建模过程的一部分，该过程在宏观上是顺序的（从需求到设计再到编码），在微观上是迭代的（在模型之间来回切换）。宏观上是顺序的（从需求到设计再到编码），以及微观上是迭代的（在模型之间来回切换）。

详细程度：CRC处于中间位置。你从简单的用例和 用户界面原型，转向中等详细程度的CRC模型，最后完成高详细程度的类图.
交付物驱动交付物：用例图由用例来记录，用例由顺序图来记录，最终驱动源代码。CRC模型可直接用于类图绘制。

5. 最佳实践与成功技巧

发送议程：提前几天分发议程，以便BDE们做好准备。
展示定义：将一张大型的CRC卡片布局和定义贴在房间前方。
使用领域术语：避免使用技术术语；使用BDE们在日常工作中使用的准确词汇。
保持低技术性：CRC工具仅为可选。索引卡价格低廉、便于携带且非常有效。
预期要进行原型设计：在会议期间于翻页纸上绘制屏幕和报表，有助于用户可视化系统。
计划多天进行：大型系统需要多次会议。这是正常且必要的。
获得管理层支持：确保管理层理解在编码之前进行建模的价值。
面向一线员工：CRC非常详细，最适合日常使用者，而非高层管理者。

6. 优势与劣势

优势

专家进行分析：真正从事工作的人来构建模型。
用户高度认同：积极的参与能够提高用户的满意度和归属感。
打破障碍：用户和开发人员并肩协作。
简单且无威胁性：这不过是一叠索引卡。用户不会被复杂的软件工具吓到，也不会觉得自己的工作正被一台“机器”取代。
成本低廉且便于携带：只需几美元，就能放进公文包里。
无缝过渡：与原型设计完美结合，并可直接过渡到正式的类图。

缺点

对部分开发人员构成威胁：一些开发人员错误地认为，他们的技术知识超过了用户的业务知识。
安排时间困难：让4到5位关键用户同时在场需要提前规划。
卡片有限：对于大多数组织而言，一叠索引卡并不是可接受的正式交付成果。CRC必须辅以正式的用例、原型和类图。

结论

应用程序开发的最终目标是解决业务问题，而不是为了满足开发人员对新技术的好奇心。CRC建模迫使开发人员与用户合作，而不是与之对抗。与用户合作，而不是与之对抗。通过利用低技术、高度协作的环境，团队可以在编写任何代码之前准确地捕捉、验证和优化业务需求。