工件：分析类
 分析类 |
分析类代表“系统中具备职责和行为的事物”的早期概念模型。 |
| UML 表示： | 类，构造型为 «boundary»、«entity» 或 «control»。 |
| 角色： | 设计员 |
| 详细信息： | |
| 活动的输入： | 活动的输出： |
目的 
分析类用于获取系统中主要的“职责簇”。它们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。如果期望获得系统的“高级”概念性简述，则可对分析类本身进行维护。分析类还可产生系统设计的主要抽象：系统的设计类和子系统。
特征
|
特征名 |
简要说明 |
UML 表示 |
| 名称 | 类名称 | 属性 |
| 说明 | 系统中类角色的简要说明 | 属性 |
| 职责 | 类的职责列表 | 属性 |
| 属性 | 类属性 | 属性 |
时机
分析用例时，分析类主要是在精化阶段中被确定。由于某些用例在进入构建阶段后才可以进行分析，因此某些分析类可能要推迟到构建阶段才被确定。
职责
设计员负责分析类的完整性，确保：
- 分析类完整并且逻辑一致。
- 所有信息（请参见上述特征）已被获取，且正确无误。
定制
分析类作为一个整体来说，代表系统的早期概念模型。随着概念模型的不同表示方法以及它们涵义逐步明确，该概念模型迅速演进，并在一段时期内将不断变化。编制模型的正式文档可能妨碍这一进程，因此您务必注意在维护正式意义的“模型”上所花费的精力；否则，您可能浪费许多时间优化一个可有可无的模型。很少有分析类在设计过程中是一成不变。许多分析类代表对象的整体协作，通常由子系统来封装。
一般来说，类似下例的简单注释卡片就足以说明问题（本例基于著名的 CRC 卡片技术）。在该卡片正面分别记录类的名称及其说明。下面列出课程注册系统中课程的示例：
| 类名称 | 课程 | |
|
说明 |
此课程用于维护一组具有相同主题、需求和教学大纲的教程信息。 | |
| 职责 | 维护有关课程的信息。 | |
| 属性 | 说明 | 类型 |
| 课程标题 | 课程名称 | 字符串 |
| 说明 | 课程的简短说明 | 字符串 |
在卡片的背面绘制类图：
课程的类图
在用例分析研讨过程中发现的每个类都需要准备一个分析类卡片。
