核对表:设计
关系
检查项
设计是可理解的
  • 设计是否按某种易于团队成员查找所需信息的方式进行组织?
  • 在满足设计目标并给出足够的实现方向的同时,设计是否足够简单?
  • 设计是否既不过于简单也不过于先进?设计的复杂度应该适合于其他团队成员和技术利益相关人的经验水平。这同时适用于概念和表达的设计。
  • 设计是否表达了设计人员所想要表达的内容?
设计是一致的
  • 设计是否遵循某些标准?
  • 设计是否应用了一致的术语?
  • 设计元素的名称是否一致并易于理解?
  • 任何部分的设计之间是否存在矛盾?
  • 如果设计是可视化的,那么用来描述设计的符号是否一致,是否能够理解并没有歧义?
设计是可维护的
  • 设计的结构是否足够好利于维护?
  • 设计是否能够恰当的容纳预期的变化?设计不应该过度处理任何可能的变化,仅仅需要合理预期的变化。
  • 有冗余的设计可以被删除吗,以使实现不包含冗余的代码?
设计是可跟踪的
  • 设计如何和需求关联是否清晰?这不需要使用重量级的跟踪策略,但是否有某种方式指出了设计的那个部分支持某个特定的需求?
  • 每个设计元素由哪些实现部分支撑是否清晰?
设计反映了系统的架构目标
  • 设计是否遵循了指定的架构?
  • 设计是否恰当的应用了架构模式?
  • 是否使用了合适的架构机制?它们是否适用于所有的应用场景?
设计元素是模块化的
  • 设计元素是否是高内聚的?单元间的交互程度是否证明了所有的内部部件是一个整体?
  • 设计元素是否低耦合?设计元素之间的依赖关系是否最小化?当设计元素依赖于其它设计元素时,是否已尽可能的简单,当在供应方元素内部应用变更时客户端元素是否不受影响?
  • 设计元素是否定义了抽象接口,当内部实现发生变更时不影响客户端设计元素?
  • 是否每一个设计元素都表示了一个清晰定义的抽象?
通过设计中的信息能够实现系统
  • 是否包含了足够的细节以指导实现?
  • 设计是否仅在需要的是否约束了实现?设计是否给予了实现者以合适的方式实施的自由?
  • 设计是否可行?在项目的时间段内,设计是否能够被团队使用所选技术合理的实现?
设计为开发人员测试提供了足够的信息
  • 设计是否为开发人员测试提供了足够的信息?方法的期望行为和约束是否清晰?
  • 设计元素间的协助是否足够清晰从而进行集成测试?
设计在恰当的抽象级别描述了系统

设计是否在合适的抽象级别描述了系统?这通常意味在几个不同的抽象级别和不同的视角描述系统。

设计支持系统的粗粒度视角
  • 设计是否作为一系列高阶子系统而被理解?
  • 子系统的依赖关系是否被记录?
  • 是否清晰定义了每个子系统的接口?每个子系统是否被设计为可通过接口访问它们的服务而不需要访问它们的内部组成?
  • 每个子系统是否被设计为使用某个部件时不需要考虑其他元素的内部组成?
分包与组织

分包是否符合逻辑并一致?对团队成员和利益相关人是否有意义?

包的名字是否准确的描述了包的内容,以及它们在架构中扮演的角色?是否遵循了命名规范?

公共包和接口是否提供了逻辑上内聚的服务?

是否列出了包中所有的内容?包中的类是否内聚?

包依赖关系是否与所包含的类的依赖关系相符?

包或包中包含的类是否可被划分为独立的子包?

视图

是否每个图形都有助于设计人员解释设计,或向团队沟通关键的设计决策?

当使用多个图形描述行为时,图形之间的关系是否清晰?

是否易于在关联的图形中导航?

是否每个图形都聚焦于相关的视角?例如,使用一系列的图来展示某个类和其直接的关联关系,而不是使用一个或两个图来表示所有的类?

每个图形是否完整并最小?是否显示了视图有关的所有事物而没有更多?

图形是否整洁易于理解?

UML

可视化模型是否符合UML标准,从而所有的利益相关人可以理解模型?更多信息参见:OMG UML Resource Page

可视化模型是否符合项目或组织特定的模型标准?

可视化模型内部是否一致?例如,如果某个对象图显示了对象之间的关系,那么此关系是否存在于对应的类中?

每个类的名称是否清晰的反映了其扮演的角色?

每个类是否提供了所需的行为?

是否为每个接口的协作定义了至少一个实现?实现可能代表某个第三方实现的子系统?

每个子系统到其使用的接口是否存在依赖的协作?

子系统接口中的每个操作是否在序列图中进行了描述?或者至少直接映射到某个类中的操作?

每个类是否表示了某个单一良好定义的抽象?

泛化关系是否仅在继承定义中使用,而不是行为(实现)?换句话说,行为是否只通过协作、聚合和包含关系进行共享,而不是泛化?

泛化关系中的父类是否抽象?泛化关系中的“叶子”类是否仅是具体类?

使用的原型是否一致并有意义?

有复杂或限制性状态变化的类是否存在对应的状态图?

关系是否描述了角色或协作名称(一个或其它但不是全部),以及正确的多样性?

类之间的关系是否尽可能是单向的?

非UML可视化模型

可视化模型语言的语义是否被清晰定义、记录,并能被团队成员理解?语义应该对模型的使用者有意义。

模型语言的语义随着时间流逝是否仍旧可被理解?语言记录是否足够好,从而使团队成员即使在做出设计决策之后很久都能够理解该模型?

是否对团队成员和利益相关人进行了使用模型语言的培训?

可视化模型是否符合可视化模型语言的语义?换句话说,模型和图中的符号意义是否一致?