原标题：为测试而设计和为安全而设计——为测量而设计的软件架构

　　连接的设备和系统已成为我们日常生活中不可或缺的一部分，我们认为这是理所当然的。使用智能手机寻找到达目的地的最快方式，坐在沙发上阅读平板电脑上的新闻，或者使用智能手机应用程序控制我们的智能供暖系统——这些系统让生活更加便捷。然而，这种便利性的提高要求更严格的安全和安全要求，这些要求必须由开发此类系统的人员进行管理。对于以高效安全概念为重中之重的自动驾驶来说尤其如此(图 1)。

　　图 1选择适合项目的软件架构的目的。

　　软件架构师应具备的知识和技能

　　不断增加的产品复杂性和更强大的硬件都导致嵌入式系统中的软件范围不断扩大。软件在大多数系统中实现了大部分功能。嵌入式软件开发部门正在不断增长。这在汽车行业和当前的劳动力市场中尤为明显。例如，梅赛德斯奔驰计划从 2030 年开始通过基于软件的系统产生大部分收入。软件开发不再是一个人的表演，而是由分布在全球多个地点的大型团队完成。在过去的几年里，嵌入式软件在嵌入式行业的大多数公司中获得了显着的意义——即使在机电一体化领域也是如此。但这只是开始。

　　更加关注敏捷软件开发方法

　　敏捷软件项目使用基于测试驱动的软件开发技术的进化软件架构开发等。这是两种主要方法：

　　功能架构：软件系统由功能或特性及其依赖关系表示。

　　组件架构：开发一个粗略的草案以及几个包含微调的软件结构的详细草案。

　　软件架构是项目成功的关键

　　想要满足其负责工作要求的软件架构师需要涵盖以下关键方面的广泛专业知识：

　　对软件架构的基本理解：在抽象层面上，软件架构是软件需求和实现之间的桥梁。在软件中，体系结构描述了由软件组件、软件层、软件子系统、接口及其依赖项组成的粗略结构(在特殊情况下也包括模块和类)。对于这些架构元素，也可以描述交互和个体行为。运行时架构是软件架构的另一个关键元素。

　　软件架构师的角色：拥有所需知识的每个人都可以在公司中担任软件架构师的角色。然而，对于真正专业的方法，个人角色应该是首选。一个或多个软件架构师可以参与一个项目，具体取决于项目的规模。

　　首席架构师管理软件架构师团队：软件架构师协调项目中的多个角色，因此需要技术和非技术知识——经验越多越好。软件架构师的角色可能不应该分配给没有经验的大学毕业生——它需要外向、创新、果断和经验丰富的个性。

　　图 2软件架构师的各种角色。

　　设计过程——创建软件架构

　　设计过程描述了软件(架构)的开发过程。每家公司都必须确定并实施最适合他们的流程。软件架构师在定义这个过程中起着关键作用。基于V-model 类型表示，设计过程可以应用于完整的嵌入式系统的开发，即不仅仅应用于软件的开发。

　　需求(什么)和相关架构(如何)

　　在分析过程中，分析师(在大多数情况下也是架构师)在各个层面上识别并记录各自的需求(“什么”)。这些要求是创建架构的基础(“如何”)(图 3)。基于子系统架构，软件架构师为子系统开发软件架构，与同一级别的其他开发领域(例如，硬件开发)协调。

　　根据需求，测试团队开发测试用例，以在开发过程后期证明正确的实现。这也在不同的层次上进行。“为测试而设计”和“为安全而设计”是软件架构上下文中的基本主题。

　　图 3嵌入式系统的设计过程。

　　设计依据及影响因素

　　软件需求(功能性和非功能性)来源于图 3 所示的 X 分析(这里：软件分析)。基于安全性和可靠性的软件质量属性分别如表 1和表 2所示。

　　通过分析影响因素，软件架构师确定：

　　软件架构需求的相关性

　　未来需求的可变性

　　软件架构后果的推导

　　非功能性软件需求包括软件的软件质量属性，例如：

　　可移植性

　　可维护性

　　可靠性

　　安全保障

　　资源需求

　　表现

　　实时兼容性

　　表 1从相关软件质量属性的角度来看的安全性。

　　表 2从相关软件质量属性的角度看的可靠性。

　　一些质量属性是一致的，其他的也可能有相反的效果。考虑到这一点，我们可以提出以下问题：哪些需求对架构的影响更大，功能性的还是非功能性的?正确答案是非功能性需求。因此，除了子系统架构之外，软件需求及其影响因素是软件架构最重要的设计基础。

　　沟通和文件

　　通过全面的软件架构文档，软件架构师为所有利益相关者提供项目的基础，从而为参与项目的每个人提供全面的可追溯性，确保公司的连续性。文件也是与利益相关者持续协调的沟通基础。

　　这里最重要的利益相关者是软件开发人员，他们对软件架构进行了详细的提炼，并最终用目标编程语言实现了它。除了软件开发人员之外，其他角色，如测试团队，在软件架构中拥有合法权益。除非您知道需要什么，否则您无法验证实现是否正确。

　　统一建模语言 (UML) 是用于记录软件架构的各种视图和方面并在设计中细化它们直至自动代码生成的符号。图 4所示的包图对不同的软件层进行了建模。

　　图 4分层软件架构的示例。

　　软件设计原则提高软件质量

　　我们的整个生活都是由规则决定的——即使有些人认为他们不必遵守规则。我们所有人都面临着 COVID 大流行和相关的规章制度。你小时候肯定玩过乐高积木，或者今天你和自己的孩子一起玩，关于如何正确安装积木有一些规则。

　　软件架构师随着他不断增长的知识，为软件开发绘制风格指南，描述软件架构开发的规则。这些规则不能应用于任何架构，因为它们取决于特定要求。在任何情况下，将规则应用于软件架构都可以提高软件质量。

　　高内聚是架构设计原则。它旨在通过在一个架构元素中处理逻辑相关的任务来减少冗余，而不是将相似的任务分布在多个架构元素中。已经发布了可以应用于嵌入式软件架构的特定设计原则。软件架构师可以通过软件架构模式在真实系统中实现设计原则。

　　架构开发和架构模式必须满足安全要求

　　基于他们的技术知识，软件架构师使用他们的模式目录开发软件架构。一般来说，模式是已知的、经过验证的、经过评估的和可调整的解决方案，可以解决反复出现的问题(挑战)。例如，在安全相关系统中必须考虑和注意功能安全性和可靠性等方面。在为我们提供全自动支持(想想自动驾驶)的系统中，安全性和可靠性是产品成功的关键。

　　在软件架构开发中使用模式可能是一个挑战(表 3和表 4)。例如，只有方形积木可用，但一个要求可能是圆形轮廓。这可以通过将积木分级组装来解决——根据乐高原理——一排或几排。由于我们不是第一代开发软件的人，因此已经为几乎所有软件开发领域甚至软件架构的开发创建了模式。

　　表 3实现安全性和可靠性的软件架构结果。

　　表 4实施安全的软件架构结果。

　　一个例子是分层模式(严格或不严格)。图 4 显示了一个非严格的软件层架构。非严格意味着它涉及跨层访问，这对于嵌入式软件实现所需的性能特别有帮助。在此示例中，除了经典的水平图层外，还包含垂直图层。

　　质量保证和质量评估

　　软件架构师负责软件质量和质量保证。必须在开发架构之前定义质量属性。软件架构师知道这些属性对其软件架构的影响，软件测试团队知道如何证明它们。顺便说一句，属性不能在开发过程结束时“测试”到产品中。

　　在质量方面，有以下区别：

　　内部质量(例如，软件架构)和

　　外部质量(客户看到的)。

　　工艺质量对产品质量有重大影响。再次回到乐高的类比——所有的积木都必须组装成支撑结构，否则，一旦进行额外的扩展，它就会崩溃。对于软件架构也是如此。它们必须满足所有质量要求并提供之前定义的所有功能(图 5)。

　　图 5软件架构的质量保证和评估。

　　过去，软件架构预计将保持 20 年或更长时间的功能。今天，由于新出现的要求、法规和法律，它们正在不断扩展和改进。出于这个原因，开发过程应适应这一方面，因为它是产品进一步开发的关键。

　　保证质量的最简单方法

　　与其他架构师和利益相关者进行评审是确保软件架构质量的最简单方法。它们用于评估架构是否符合所需的质量属性。通过 UML 模型生成的软件架构文档是审查的合适基础。

　　在基于场景的评审中，参与者通过架构的预定义案例。例如，如果要求一个架构在硬件方面是可移植的，这个过程包括硬件的交换，以证明软件架构可以满足这个要求。卡内基梅隆大学软件工程研究所 (SEI) 为此开发了一种广泛的方法，称为架构权衡分析方法 (ATAM)。进一步的质量保证方法是，例如，原型或数学模型、执行模拟或确定指标。

　　工具使开发软件架构变得更容易

　　软件架构师负责或至少共同负责软件开发的工具环境。他或她了解工具市场，能够识别需求、开发工具需求、评估并最终选择工具。在没有工具组的公司里，他还负责工具集成。这些工具使参与软件开发的每个人的工作变得更轻松，尤其是软件架构师。

　　图 6使用工具使软件架构师的工作更简单。

　　工具使软件架构师的工作更轻松：

　　需求管理

　　版本和配置管理

　　造型

　　生成文档和程序代码

　　构建系统

　　静态分析

　　动态分析

　　软件架构的实现

　　软件架构师将整个架构或其中的一部分传递给一个或多个软件开发人员，以进行进一步的改进(设计和实现)。由软件架构师与软件开发人员合作创建的编码风格指南，展示了软件架构是如何在目标编程语言中实现的。嵌入式系统编程的典型目标语言是 C 和 C++(图 7)。

　　图 7编码风格指南。

　　在 C++ 中，软件架构可以通过命名空间在程序代码中有效地表示。软件架构师和软件开发人员必须确保已定义的软件架构在其整个生命周期内得到保留，并且不会被编程“致死”——也称为软件侵蚀。

　　如果软件开发人员确定需要更改架构，则所有相关决策和架构更改都由负责的软件架构师协调。对产品的安全性、保密性和模块化要求越高，软件架构师在整个开发过程中的作用就越关键和重要。

　　作者

　　Thomas Batt在德国奥芬堡的应用科学大学学习通信工程。他为多家公司的嵌入式和实时系统开发硬件和软件。自 1999 年以来，他一直是 MicroConsult 的认证培训师和教练，负责嵌入式和实时系统的系统工程/软件工程以及流程指导。

　　Ingo Pohle是 MicroConsult 的联合创始人兼董事总经理。他是国际知名的嵌入式解决方案专家，在嵌入式微控制器、总线系统和 RTOS 领域拥有广泛的经验。