3.2.6 使用ROPES软件开发模型做设计

使用ROPES软件开发模型进行设计涉及将系统开发过程分为分析、设计和优化的不同阶段。

分析模型与设计模型

• 分析模型：定义系统所需的属性集合，它是理解和表述系统需求的第一步。它更注重于"应该做什么"而不是"如何去做"。
• 设计模型：更具体的系统蓝图，描述了如何实现分析模型中确定的属性。设计模型涉及到选择特定的技术和策略来满足分析模型的要求。

服务质量（QoS）与设计优化

设计过程需要同时优化多种服务质量（QoS）属性，这些属性可能包括性能、可靠性、可用性等。优化过程可能涉及权衡不同的QoS属性，因为它们之间可能存在冲突。

设计决策的三个层次

• 架构设计（Architectural Design）：涉及整个系统层面的设计，包括选择系统的总体结构和交互方式。
• 机制设计（Mechanistic Design）：更关注于系统内部各个部分如何协作，涉及更小范围内的优化和决策。
• 详细设计（Detailed Design）：针对单个对象或类的内部结构和行为进行详细规划和优化。

1. 体系结构设计阶段

ROPES软件开发模型中体系结构有5个主要的视图包括：

• 子系统和构件视图
• 并发和资源视图
• 分布视图
• 安全性和可靠性视图
• 部署视图

在体系结构设计阶段，设计师会根据当前原型的具体需求，详细地阐述一个或多个架构视图。这一过程主要通过应用各种体系结构设计模式来完成，这些模式具有广泛的影响范围，可能涉及大部分或整个系统，并与许多已提出的模式有相似之处。

通常使用类图和序列图等来表示系统的结构和协作行为。

体系结构设计的表现形式借鉴了系统工程和对象分析中相同的视图，包括使用类图来描述系统的结构，使用序列图来描述系统内各部分的协作行为。在这个框架下，构件被视作子系统的类似物，可以单独或混合地在子系统图中表示。由于子系统、构件和类图都具有结构性质，设计师可以根据需要在结构图中适当地混合这些元素。

此外，并发和资源视图会特别强调«活动»对象和其他在该视图中重要的对象，如事件队列和信号量等。而部署视图则主要采用部署图来展现软件单元如何映射到硬件处理器上，从而为系统的最终实现提供清晰的指导。

2. 机制设计阶段

机制设计阶段是软件设计中的一个关键部分，主要关注于对系统内部各个组件或对象间的协作进行优化。与体系结构设计相比，机制设计着眼于更具体、更细粒度的系统部分，通常涉及的范围较小，关注点更为集中。这个阶段通常使用类图、序列图、活动图和状态图来表示协作的结构和行为。

在这个阶段，设计师将通过应用各种设计模式来进行优化，这些模式通常具有较小的作用范围，专注于解决具体的设计问题或挑战。经典的“四人帮”（Gang of Four，GoF）设计模式以及其他更细粒度的模式在此阶段常常被使用，以提升系统组件的协作效率和整体的性能。

为了详细展现机制设计的各个方面，设计师通常会利用类图和序列图来描述组件之间的结构和协作顺序。类图展现了对象和类的静态结构，包括它们之间的关系，如继承、组合和关联等；而序列图则描述了对象间在时间序列上的交互，揭示了它们如何共同完成特定的任务或功能。此外，活动图和状态图也被用来更具体地表现系统的行为，活动图揭示了执行流程或操作的顺序，而状态图则描述了对象可能处于的各种状态以及在这些状态之间转换的触发条件。

总的来说，机制设计阶段是将分析和体系结构设计阶段定义的高层次要求转化为具体实现的桥梁。通过细致的设计和优化，确保系统内部的每一个组件都能高效、准确地完成其职责，从而整个系统能够以预定的方式高效运行。

3. 详细设计阶段

详细设计阶段深入到对象和类的内部构造，专注于单个对象或类的精细化设计。在这一阶段，设计者致力于对以下方面进行优化：

• 数据结构：设计和选择合适的数据结构来有效地存储和管理数据。
• 算法分解：将复杂的问题分解成更小、更易于管理和实现的算法。
• 对象状态机优化：优化对象的状态机以提高效率，确保对象状态的正确转换和管理。
• 对象实现策略：确定如何实现对象，包括对象的创建、生命周期管理和资源回收等。
• 关联实现：实现对象之间的关系，如关联、聚合和组合等。
• 可见性和封装问题：确定哪些信息和功能应该公开，哪些应该隐藏，以保持模块的独立性和安全性。
• 确保运行时符合前提条件不变性：例如，确保方法参数的范围和类型符合预期，以防止运行时错误。

详细设计关注的是深入到单个对象或类的内部，进行精细化的调整和优化。它需要设计者对对象和类的实现有深刻的理解，以及对不同设计选择可能带来的影响有透彻的认识。

虽然详细设计有许多经验法则和指南，但它们更多的是被视为"惯用型"而非"模式"。这是因为详细设计通常涉及到语言或平台特定的实现细节。对于大多数对象，详细设计可能是直截了当的，但对于系统中的关键部分（大约5%到10%），需要更加细致和专注的设计考虑。

在实际设计中，对象属性通常被推荐为基本类型，如整数、浮点数和字符串等，这被认为是良好的设计实践。有时为了优化，可能需要更复杂的数据结构，这时组织和管理这些结构就变得尤为重要。算法分解和状态机通常通过活动图和状态图来表示，而对象的其他细节则通常内部存储在设计工具中，因为在大多数情况下，图形化表示这些细节并不实际。

总体来说，详细设计阶段是精细调整和优化系统的关键步骤，它要求设计者对每个对象或类的实现进行深入的思考和规划。通过精心的详细设计，可以确保每个部分都能以最佳状态运行，从而提高整个系统的效率和质量。

3.2.7 转换

转换阶段是软件开发过程中将设计模型转换为实际工作软件的关键步骤。这一阶段的主要任务是确保架构元素被正确地构建并能够正常工作。下面是对转换阶段内容的详细解释：

1. 代码生成：这包括从模型元素生成源代码的过程。代码生成可以是完全自动化的，如使用模型驱动开发工具直接生成代码；也可以是手工编写，或者是自动生成与手工编写的结合。目标是生成能够反映设计意图且可运行的代码。

2. 单元级测试：对生成的源代码进行测试，确保每个部分（即单元）按照预期工作。这包括编写和执行测试用例，以及验证相关的模型元素。单元测试旨在发现每个部分的错误和问题，确保它们在整合到更大的系统之前是可靠的。

3. 整合遗留源代码：在很多情况下，新系统需要与既有的遗留系统协作或使用遗留组件。转换阶段需要处理这种整合，确保新旧代码能够无缝协作。

4. 架构元素的链接：这涉及到将设计阶段定义的各个架构元素实际链接起来，形成一个工作的系统。这可能包括链接自动生成的代码、手工编写的代码以及任何遗留组件。

5. 架构元素的单元测试：除了测试单个代码单元，还需要对整个架构元素进行测试，确保它们作为一个整体正常工作。这包括对整合后的系统进行测试，验证所有部分在一起时的行为。

转换阶段的主要输出包括：

• 源代码：从模型元素生成或手工编写的源代码。
• 单元测试计划、程序和结果：这些文本文档描述了如何测试代码，包括测试用例、执行程序和测试结果。
• 源代码的检查报告：对源代码进行检查（如代码审查）的报告，以确保质量和符合标准。
• 编译和测试过的软件组件：经过编译和测试的软件组件，准备好被集成到最终系统中。

转换阶段是将设计模型具体化、验证并集成为可工作系统的阶段。它要求细致的技术实现、严格的测试以及对遗留系统的考虑，以确保最终的软件系统不仅满足设计要求，而且是可靠和可维护的。

3.2.8 测试

测试阶段是软件开发过程中验证原型功能和性能的关键环节。它涵盖从架构元素构建原型，确保所有部分正确组合（集成测试），以及验证整个原型作为一个单元是否满足预定目标（验证测试）的全过程。以下是对测试阶段内容的详细解释：

集成和测试（Integration and Test）

• 目的: 确保所有架构元素正确无误地组合在一起，形成一个功能完整的系统。
• 灰盒测试: 这类测试不仅关注外部行为，也关注内部结构和逻辑，以确保架构元素的接口被正确使用且没有违反设计约束。
• 迭代测试: 测试通常遵循集成计划逐步进行，逐一添加架构元素并验证其功能，以保证每一步的集成都符合预期。
• 硬件-软件集成: 对于包含硬件元素的原型，这一阶段也包括硬件和软件的正式集成。

验证测试（Validation Test）

• 目的: 测试组装完成的原型是否满足其使命，即是否能够完成定义好的用例或降低特定的风险。
• 计划和程序: 一旦原型的需求明确，即可开始编写针对原型的验证测试计划和程序。

缺陷处理

• 发现和修复: 测试过程中发现的缺陷要么立即修复，特别是那些严重到可能阻碍测试继续进行的缺陷；要么记录下来，留待下一个原型周期处理。

主要输出

• 集成测试计划、方案和结果: 包含了集成过程中每一步的计划、执行步骤及其测试结果。
• 验证测试计划、方案和结果: 包含了针对原型使命进行的验证测试的计划、步骤和结果。
• 经测试的可执行原型: 经过集成和验证测试的、可运行的软件原型。
• 缺陷报告: 记录在测试阶段发现的所有缺陷及其相关信息的文档。

测试阶段是确保软件产品质量的关键环节，通过细致的测试计划和执行，软件产品能够以高质量和高可靠性满足用户的需求和期望。