工件:
|
![]() |
分析类代表早期的概念模型,表示“系统中有职责和行为的事物”。 |
其它关系: |
部分的 分析模型
|
---|---|
角色: | 设计员 |
可选/发生: | 可选。精化和构造阶段。 |
模板和报告: |
|
示例: | |
UML 表示: | 类,定型为 <<boundary>>、<<entity>> 或 <<control>>。 |
更多信息: | |
活动的输入: | 活动的输出: |
分析类用于获取系统中主要的“职责块”。它们表示系统的原型类,是系统必须处理的主要抽象的“第一遍”。如果希望对系统进行“高度”的概念性概述,则可以对分析类单独维护。分析类还允许进行系统设计的主要抽象化:系统的设计类及子系统。
属性名 |
简短描述 |
UML 表示 |
---|---|---|
名称 | 类名称 | 属性 |
描述 | 关于类在系统中的角色的简短描述 | 属性 |
职责 | 该类的一系列职责 | 属性 |
属性 | 类的属性 | 属性 |
分析类主要在精化阶段确定(分析用例时)。某些分析类可能延后到在构造阶段确定(对于直到构造阶段才分析的用例是这样的)。
设计人员负责分析类的完整性,确保:
分析类组合在一起就表示早期的系统概念模型。该概念模型快速演化并在一段时间内保持灵活性,同时探索不同的表示法及它们的含义。正式文档可能会阻碍该流程,所以请正式地仔细计划维护该“模型”将花多少精力;您会浪费大量时间来完善很不必要的模型。分析类很少在设计中保持不改动。许多分析类代表着对象的整体协作,这通常由子系统封装。
通常,简单的注释卡片(如下例中所示)就足够了(这基于众所周知的 CRC 卡片技术 - 参阅 [WIR90] 可了解有关该技术的详细信息)。在卡片的正面,记录类的名称和描述。下面列出了课程注册系统中的课程示例:
类名 | 课程 | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
描述 | “课程”负责维护有关具有共同主题、需求和大纲的一批课程章节的信息。 | |||||||||
职责 | 维护关于课程的信息。 | |||||||||
属性 |
|
在卡片的背面,绘制类图:
课程的类图
对于用例分析研讨会期间发现的每个类,只有一个分析类卡片。
Rational Unified Process
|