核对表:设计类
此核对表有助于确保已对设计类正确建模。
关系
主要描述


检查项
概述
  • 类名明确反映它所扮演的角色。
  • 类的描述明确传达类的目的。
  • 类代表一个定义良好的抽象。
  • 类的属性和操作对于履行类的职责都是最根本的。
  • 每个类表示一小组一致且唯一的职责。
  • 类的职责是定义良好、明确陈述的,并与类的目的明确相关。
  • 每个类是相对自我包含的,并与其他类低耦合。
  • 类的职责的抽象级别一致(即,高级(应用级别)和低级(实施级别)职责不是混在一起的)。
  • 在同一继承层次结构中的类拥有唯一的类属性、操作和关系(即,它们继承所有公共的属性、操作和关系)。
  • 说明了类实例的完整生命周期。每个对象由一个或多个用例实现创建、使用或除去。
  • 类满足了由用例实现建立的行为需求。
  • 满足了需求规范中的类的所有需求。
  • 类的需求(如类描述和时序图的对象所反映)与类的状态机一致。
  • 类的所有职责是相关的,这样,类要存在于系统中,就不可能使用它的某些职责,而不使用它的其他职责。
  • 没有两个类在本质上有相同的目的。
泛化/专门化
  • 泛化关系层次结构是平衡的,因此不存在层次结构非常扁平或非常深的类。
  • 明显的共性反映在继承层次结构中。
  • 没有任何超类看上去是子类属性的合并。
  • 继承层次结构中没有具有不相关的属性的中间抽象类,示例包括继承树两边的重复子类。
  • 继承用于捕获公共设计抽象,而不主要用于实施考虑事项(即:复用代码位或类结构)。
命名约定
  • 类名指示目的。
  • 类名遵循在项目设计指南中指定的命名约定。
操作
  • 每个操作名都是描述性的和可理解的。
  • 状态机和操作是一致的。
  • 状态机和操作完整地描述类的行为。
  • 每个操作的参数在数量、名称和类型方面都是正确的。
  • 定义的每个操作的实施规范都是正确的。
  • 操作特征符符合目标编程语言的标准。
  • 每个操作至少由一个用例实现使用。
属性
  • 需要类的所有关系来支持类的某个操作。
  • 每个属性表示一个概念上的含义。
  • 每个属性名都是描述性的并正确传达它存储的信息。
关系
  • 聚集和关联的角色名描述关联和被关联的类之间的关系。
  • 关系的多重性是正确的。
状态机
  • 状态机尽可能简单,但仍能表达必需的行为。
  • 状态机不包含任何多余的状态或转移。
  • 状态机具有明确的环境。
  • 所有引用的对象对包含它的对象都是可见的。
  • 状态机是高效的,并在时间和资源最佳平衡(由它分派的操作定义)的条件下执行它的行为。
  • 状态机是可理解的。
    • 状态和转移名称在系统领域环境中是可理解的。
    • 状态名称表明正在等待或发生什么,而不是已经发生了什么。
    • 状态和转移名称在状态机中是唯一的(虽然不是严格的要求,但在调试中它有助于实施唯一名称)。
    • 状态的逻辑分组包含在组合状态中。
    • 组合状态用于有效减少复杂度了吗?
    • 转移标注反映转移的底层原因。
    • 关于状态转移的代码片段,其详细代码不会超过 25 行;相反地,有效地使用函数来减少转移代码复杂度。
    • 已检查状态机嵌套,确保嵌套深度不会太深而不可理解;对于大多数复杂行为,一级或两级子状态通常就足够了。
  • 已用活动类代替了并发子状态;活动类几乎总是比并发子状态更好的备选方案并更易理解。
  • 在实时系统中,已使用封装体表示逻辑控制线程。
  • 已说明了错误或维护状态。
  • 在扩展的状态变量的位置已使用了子状态;转移警戒条件测试几个变量来确定转移应出现的状态是没有根据的。
  • 状态机不同于流程图。
  • 状态机不是过度分解的,它由带单个子状态的嵌套的状态机组成。 在嵌套的子状态是占位符(用于未来的设计工作或划分子类)的情况下,倘若选择是有意的,这可能暂时可被接受。