中文翻译《ASPICE in practice》之“ENG.5 软件设计”

2.7 ENG.5 软件设计

2.7.1 目的

软件设计过程的目的是为软件提供可实现且可根据软件要求进行验证的设计。

软件设计用于说明如何用代码实现软件需求以及软件由哪些组件组成。描述了组件的功能、操作模式和交互。软件设计以软件需求为基础，并提供编码所需的规范。设计过程通常由几个迭代步骤组成，从软件架构设计开始，设计变得越来越精细和详细，直到详细设计完成。系统架构和软件架构之间存在重叠区域，因为软件架构的组件可能列在系统架构中，反之亦然。

在许多情况下，要开发的软件是平台组件（重用代码）和新代码的组合。通常，重用设计和代码元素必须满足更高的要求，例如，可以在设计评审中进行检查。设计评审还可用于考虑和回答与容错相关的设计相关问题：

1. 是否检测到故障，如何检测到？
2. 如何对故障进行分类？
3. 发生故障时系统的行为是什么？

稍后执行的压力测试可能会提供有关设计稳健性的信息，例如有关传感器故障、电缆断裂、启动行为或中断突然急剧增加的信息。在系统测试期间执行与硬件相关的测试才有意义（参见 ENG.10）。

2.7.2 汽车行业特有的特征

在汽车行业，软件开发通常非常低级，即与硬件相关，这意味着在设计中还必须考虑超出纯功能开发的其他问题。例如时序行为（中断和时隙）和通信协议。就时序行为而言，需要考虑所涉及组件（如处理器、内存芯片和总线控制器）的反应和交互。在此过程中，描述了可能的状态（例如，从初始化和操作到睡眠模式）。如果需要，还会描述故障场景。就通信行为而言，主要指定和描述通信消息的顺序和内容，受事件影响。在实践中，设计描述和设计建模（例如，通过状态图）越来越多地基于工具。这有几个优点。一方面，如果工具支持这一点，则可以确保正式标准（例如设计一致性），另一方面，在 PC 上实际编码之前，某些功能和状态已经可以进行模拟和评估。较新的工具通常也支持代码生成。

2.7.3 基本实践

BP1：开发软件架构设计。使用功能性和非功能性软件需求来开发软件架构，该架构描述顶层结构和所有软件组件，包括可重用的软件组件。

注：另请参阅 REU.2—重用程序管理

ENG.4 中确定的软件需求被转化为软件架构（也称为顶层设计），作为最高级别的描述，并记录下来。在这里做出必要的中央设计决策。理想情况下，软件架构组件在开发过程中保持稳定，以便在剩余的开发阶段无需修改它们或它们的接口。此步骤是软件详细设计的前奏（参见 BP6），必须与之保持一致。

实际上，通常需要软件架构的多个视图才能完成完整的映射。例如，这些可能包括以下内容：

1. 结构视图（架构、使用的架构模式）
2. 行为/状态视图（睡眠模式、启动、关闭、引导块描述、监控技术等）
3. 用例视图（架构中用例的实现）
4. 流程视图（任务设计、时间安排、内存布局）
5. BIOS 和服务视图（CAN 和 LIN 驱动程序、硬件抽象层、看门狗、操作系统集成等）
6. 调用层次结构，例如，作为框图
7. 资源视图（计划的 RAM/ROM 消耗）

如果必须做出困难或影响深远的架构设计决策，则提交多个架构提案并根据上述标准对其进行评估是有意义的。一旦做出架构决策，就应该以可追溯的方式记录下来，以便在项目后期始终可以重建决策过程并避免进一步修改。越来越重要的标准是架构的重用部分，以及其对未来重用的适用性。

BP2：分配软件需求。将所有软件需求分配给软件架构设计的组件。

所有与软件架构相关的软件需求都分配给软件架构的软件组件。例如与校准相关的需求、启动任务的需求以及高抽象级别的接口需求。

分配可以在可追溯性矩阵（参见第 2.24 节）中完成，只需列出或标记相应的软件组件即可。或者，可以根据软件架构构建软件需求规范，为详细设计做准备，以验证是否已涵盖所有需求。

BP3：定义接口。识别、开发和记录软件组件之间的内部接口以及软件组件的外部接口。

接口描述包括要外部（例如，与其他系统、外围设备、用户）和内部（在各个软件组件之间）交换的信息的定义。在大多数情况下，BIOS 和服务视图（包括硬件抽象层和操作系统的集成）也在此处指定。接口交互的运行时性能在 BP4 中指定。接口描述至少应包含以下两点：

1. 考虑的接口和涉及的软件组件的全局映射，包括 BIOS 和服务视图
2. 通过接口交换的数据列表以及相应的规范（例如，名称、值范围、通信协议）

BP4：描述动态行为。评估并记录软件组件的动态行为和交互。

注意：动态行为由操作模式（例如，启动、关闭、正常模式、校准、诊断等）、进程和进程间通信、任务、线程、时间片、中断等决定。

软件系统特别以其动态行为为特征。因此，软件组件的时序行为和交互是软件架构的重要组成部分。如果需要，BP3 提供的接口描述应通过以下项目进行扩展：

1. 考虑中的接口的全局映射（例如，通过交互图）和所有涉及的软件组件
2. 不同操作模式的描述（例如，启动、关闭、正常操作、校准模式、诊断模式、监控技术），包括所有进程和进程间通信，以及操作所需的任务或线程
3. 交互的描述，例如，时序行为、调用层次结构、中断。

软件动态行为的描述也可以通过动态模型来完成，其中对象的变化及其相互关系随着时间的推移而考虑。相关组件包括：

1. 控制流
2. 对象的交互
3. 软件系统同时活动对象的进程控制

在程序执行期间，各个对象对事件做出反应，执行相应的操作并改变其状态。动态工作对象可以用术语“状态-事件-条件-动作-后续状态”来描述。软件系统的整个动态模型由任意数量的此类对象组成，其中模型显示整个系统的活动总和。所有动态对象并行工作，并且可以彼此独立地改变其状态。这种动态建模与其在目标系统上的实现无关。

市场上有支持这种方法的工具，涵盖设计、编码、测试和文档领域。动态对象表示为有限状态机；可以随意创建状态、事件和动作，并可以进一步修改以用于后续工作步骤（例如模拟）。总是有不同的方式来描述由此创建的对象或状态（例如，以状态图的形式）。集成模拟器可以创建设计场中已有的动态行为的序列图。

BP5：定义资源消耗目标。确定并记录所有软件组件的资源消耗目标。

注意：资源消耗通常针对内存（ROM、RAM、外部/内部 EEPROM）、CPU 负载等资源确定。

在汽车行业，资源通常非常有限，并且存在相关的成本约束。因此，尽早规划、测量和记录资源消耗目标（即 ROM、RAM、外部/内部 EEPROM 的负载因子，以及 CPU 负载29）在开发阶段如何变化至关重要。尽管存在成本压力，但保留一定的资源缓冲以应对开发结束时的后期变化可能是一个好主意。软件架构应至少扩展以下几点：

1. 每个开发阶段定义的软件组件的计划和使用资源的概述描述
2. 组件内存布局的描述

BP6：制定详细设计。将软件架构设计分解为描述所有软件单元及其接口的每个软件组件的详细设计。

注意：任务执行时间高度依赖于目标30和目标上的负载，应予以考虑和记录。

基于软件架构，详细设计通常是迭代开发的。在复杂系统中，这通常意味着多个描述级别。目标是得到一个明确指定的设计，该设计足够精确，可以在后续实施阶段进行编码或代码生成。

软件详细设计包括要实施的所有详细功能和算法、所有输入和输出值、使用的数据结构以及（如果需要）资源消耗（例如存储分配）。在此阶段，通常需要澄清和提高需求的准确性，并且经常会发现需求方面的弱点和不一致之处。

BP7：制定验证标准。根据软件架构设计，定义每个组件的动态行为、接口和资源消耗方面的验证标准。

请参阅第 2.24 节附记“验证标准”。验证标准是后续测试规范的基础，尤其是 ENG.7。

通常，设计评审是为了检查设计的正确性和可测试性。检查可测试性的其他方法是测试规划和测试用例的创建。通常，以下评估标准对软件组件的可测试性起着重要作用：

1. 软件设计的复杂性（数量和单元大小、调用层次结构、依赖关系、递归、变量的使用等）
2. 接口和通信的定义
3. 软件设计模块化、封装

关于可测试性，另请参阅 ENG.2 BP2。软件设计将根据设计评审的结果进行修改。如果有较大的更改，则必须重新进行设计评审。评审结果和决定应记录在案。

BP9：确保软件需求与软件架构设计的一致性和双向可追溯性。确保软件需求（包括验证标准）与软件架构设计（包括验证标准）的一致性。通过建立和维护软件需求（包括验证标准）与软件架构设计（包括验证标准）之间的双向可追溯性来支持一致性。

一致性，在此上下文中，是指软件需求和软件架构之间的一致性。这假定软件需求（如果相关）已在软件架构中正确实现，并且所有相关软件需求都已在软件架构中考虑。

为了判断一致性，我们必须知道哪些软件需求已进入相应的架构元素。一致性检查可以在设置可追溯性时部分完成，尽管主要手段仍然是 BP8 中已经描述的设计审查。总体而言，部分“垂直”可追溯性是在此处创建的。第 2.24 节“Automotive SPICE 中的可追溯性”中的陈述也适用于此处。

BP10：确保软件架构设计与软件详细设计之间的一致性和双向可追溯性。确保软件架构设计（包括验证标准）与软件详细设计（包括验证标准）之间的一致性。通过在软件架构设计（包括验证标准）和软件详细设计（包括验证标准）之间建立和维护双向可追溯性来支持一致性。

与 BP9 类似，一致性在这里定义了软件架构和软件详细设计之间的一致性。同样，检查一致性的主要方法是 BP8 中已经描述的设计评审。BP10 中要求的可追溯性的实施完成了“垂直”可追溯性。现在，所有软件需求都可以通过软件架构垂直和双向追踪到软件详细设计。第 2.24 节“Automotive SPICE 中的可追溯性”中的陈述也适用于此处。

2.7.4 指定工作产品

04-04 高级软件设计

软件架构概述了整个软件系统的结构，并描述了不同组件之间的交互。它通常由一个或多个框图组成，说明软件组件及其相互关系（见图 2-8）。这些概览图通常会补充技术描述（例如，接口描述）。在复杂的软件系统中，描述可能由多个相关文档组成，其详细程度各不相同。

图2-8 顶级软件架构示例

04-05 低级软件设计

软件详细设计提供软件项目的详细规范、它们的交互、接口描述（输入和输出数据）、算法、内存空间分配、数据规范以及有关程序结构的规范。除了自然语言描述外，还通常使用各种其他形式。这些包括流程图、符号编程语言、有限状态机、状态图、消息序列图或数据关系模型。此外，软件详细设计包括命名约定的定义、所需数据结构的格式、数据字段以及每个所需数据元素的用途。在实践中，软件详细设计通常是在工具支持下生成的，目的是以后自动生成源代码。单个功能的建模和仿真是在 PC 上完成的。例如，这样，有限状态机就用图形编辑器绘制成图表。允许的状态转换由事件和条件指定。创建的模型可以集成到硬件在环或快速控制原型系统中，以进行进一步的建模操作。

13-22 可追溯性记录

见ENG.2

2.7.5  2 级的特征

关于绩效管理

软件设计的创建必须系统地进行。实际上，很少详细规划将在多次迭代中重复的“小”工作步骤。但是，肯定需要规划“大”工作步骤（例如，设计评审和预计不同软件设计版本可用的里程碑），并应将其记录在项目计划等文件中。如果可以预见到某些里程碑将对软件设计进行更大的更新，则需要将其包括在项目计划中。

关于工作产品管理

过程属性 PA 2.2 的要求特别适用于软件设计文档。它们包括进行设计评审，并根据情况由客户接受软件设计。基线包括在每种情况下有效的设计文档。