分析类代表早期的概念模型,表示“系统中有职责和行为的事物”。 
其它关系:  部分的 分析模型
角色: 设计员 
可选/发生: 可选。精化和构造阶段。
模板和报告:
     
示例:
     
UML 表示: 类,定型为 <<boundary>>、<<entity>> 或 <<control>>。 
更多信息:  
活动的输入:   活动的输出:  

用途 到页首

分析类用于获取系统中主要的“职责块”。它们表示系统的原型类,是系统必须处理的主要抽象的“第一遍”。如果希望对系统进行“高度”的概念性概述,则可以对分析类单独维护。分析类还允许进行系统设计的主要抽象化:系统的设计类及子系统。

属性 到页首

属性名 

简短描述 

UML 表示 

名称 类名称 属性
描述 关于类在系统中的角色的简短描述 属性
职责 该类的一系列职责 属性
属性 类的属性 属性

计时 到页首

分析类主要在精化阶段确定(分析用例时)。某些分析类可能延后到在构造阶段确定(对于直到构造阶段才分析的用例是这样的)。

职责 到页首

设计人员负责分析类的完整性,确保:

  • 它是完整的,并且逻辑上是一致的。
  • 所有信息(请参阅上面的属性)均已记录并且是正确的。

定制 到页首

分析类组合在一起就表示早期的系统概念模型。该概念模型快速演化并在一段时间内保持灵活性,同时探索不同的表示法及它们的含义。正式文档可能会阻碍该流程,所以请正式地仔细计划维护该“模型”将花多少精力;您会浪费大量时间来完善很不必要的模型。分析类很少在设计中保持不改动。许多分析类代表着对象的整体协作,这通常由子系统封装。

通常,简单的注释卡片(如下例中所示)就足够了(这基于众所周知的 CRC 卡片技术 - 参阅 [WIR90] 可了解有关该技术的详细信息)。在卡片的正面,记录类的名称和描述。下面列出了课程注册系统中的课程示例:

类名 课程
描述 “课程”负责维护有关具有共同主题、需求和大纲的一批课程章节的信息。 
职责 维护关于课程的信息。 
属性
名称 描述 类型
课程标题 课程的名称 字符串
描述 课程的简短描述 字符串

在卡片的背面,绘制类图:

课程的类图

课程的类图

对于用例分析研讨会期间发现的每个类,只有一个分析类卡片。



Rational Unified Process   2003.06.15