需求模型定义了一组分析类。每个部分都描述了问题域的某些元素，着重于可见问题的一个方面。分析类的抽象水平较高。设计类集完善了分析类，并提供了设计细节，使类可以执行支持业务解决方案的软件基础结构。
类型：
有5种不同类型的设计类，它们代表可以开发的设计体系结构的不同层：
- 用户界面类定义了人机交互[HCI]所必需的抽象。在某些情况下，HCI发生在隐喻的上下文中，并且接口的设计类可能是隐喻元素的可见表示形式。
- 业务域类通常是对先前定义的分析类的改进。该类标识实现业务域的某些元素所需的属性。
- 流程类实现较低级别的业务专注于管理业务域类的需求。
- 持久性类表示将在软件执行之后继续存在的数据存储。
- 系统类实现软件管理和控制函数，允许系统在其计算环境中以及与外界进行操作和传输
随着体系结构的形成，随着每个分析类转换为两个设计表示形式，抽象级别降低了。即，分析类使用业务域的术语表示数据对象。设计类特别提供了更多的技术细节，以作为实现的指南。
Arlow和Neustadt建议审查每个设计类别，以确保其“格式正确”。它们定义了格式良好的设计类的四个特征：
特征：
- 完整且足够：设计类应完全封装可以合理预期存在于类中的所有属性和方法。例如，为视频编辑软件定义的类场景只有在其包含可以与视频场景的创建完全相关联的所有属性和方法时，才是完整的。充分确保设计类仅包含足以实现类意图的那些方法，且不能多于或少于此。
- 原始性：与设计类关联的方法应专注于为类提供一项服务。一旦使用该方法实现服务，该类就不应提供完成同一件事的另一种方法。例如，用于视频编辑软件的视频剪辑类可能具有属性起点和终点，以指定剪辑的起点和终点。
- 高内聚性：/ strong>内聚性设计类具有少量集中的权限，并且一心一意地应用属性和方法来实现这些职责。例如，类视频剪辑可能包含用于编辑视频剪辑的一组方法。只要每种方法仅专注于与视频剪辑关联的属性，就可以保持凝聚力。
- 低耦合：在设计模型中，设计类必须相互融合。但是，聚会应保持在可接受的最低限度。如果设计模型是高度耦合的，则随着时间的流逝，系统很难实现测试和维护。通常，子系统内的设计类应该仅对其他类有有限的了解。此限制称为Demeter法则，表明方法应仅向邻近类中的方法发送消息。