通过利用合同设计来改进嵌入式应用

嵌入式软件开发团队面临的最大挑战之一是，他们花费太多时间来调试软件。当我与全球团队和工程师交谈时，在我参加的各种会议上，显然，开发人员平均将其40%的时间或更多时间用于调试软件。

直言不讳，花很多时间的调试是不可接受的，在许多情况下，不必要。开发人员可以使用许多技术来更好地管理其错误，但是一种有趣的技术可以用来防止错误并在轨道上捕捉它们，这是一种设计方法，即逐项合同(DBC)。

在今天的帖子中，我们将检查DBC以及如何使用它来改善嵌入式软件。

逐一介绍

逐一编程背后的想法是，C程序员的每个接口或功能都应明确定义，精确和可验证。这意味着每个功能都应与之相关：

· 前条件- 在调用函数之前确保满足的条件。前提条件是在组件合同中指定的，该合同使该功能不必内部检查条件。

· 条件后- 如果满足所有前条件，则可以在组件完成执行后确保满足条件。

· 副作用- 执行时，调用函数对系统的效果对系统的效果。副作用是该函数执行的有用工作。

· 不变- 在整个应用程序上指定的条件必须满足以使用该组件。例如，正在与指针一起使用限制，该指针告诉编译器该输入不会在程序中的其他任何地方使用。

通过正式定义这四个项目，该功能已完全指定，并为使用该功能了解的任何开发人员提供：

· 在调用功能以使其正确操作之前需要发生什么

· 调用功能后，预期的系统状态将是什么

· 进入和退出时将要维护的属性

· 将对系统进行的更改

逐一设计创造了使用函数的开发人员必须遵循的义务，以使调用该函数受益。如果他们不遵守这些义务，则将错误注入其应用程序中!

在C应用中利用逐项合同

乍一看，逐一合同是添加已经超负荷的开发周期的另一个超重过程。逐一使用可能非常简单，可以改善您的代码库文档并减少软件中的缺陷，这具有改善软件质量的额外好处。逐项合同不必超级正式，而是可以在代码文档中完全处理。例如，查看下面的doxygen函数标头。

从示例中可以看到，该注释块与其相关联的其他行，可以阐明该功能的条件和后条件。在这种情况下，对于dio_init，我们指定：

· 一个指定PIN功能和状态的配置表需要填充

· MCU上的引脚数的定义必须大于0

· 引脚端口数的定义必须大于0

· 必须启用GPIO时钟

如果满足这些条件，则开发人员调用Dio_Init函数并提供指定的参数时，我们可以期望该函数的输出将使用匹配预定义配置表的GPIO引脚配置。

使用断言核实合同

我们可以使用文档和评论来指定我们的前提条件和条件是什么，但这并不意味着开发人员会遵循它们。可能会在复杂的应用程序中忽略条件。如果发生这种情况，他们将违反合同，无法知道!相反，它们最终会遇到一个可能难以找到和解决的错误。需要有一些方法来验证合同;对于在C中工作的开发人员，该方法是使用断言。

我发现的断言的最佳定义是，断言是：

“除非程序中有一个错误，否则在程序中的特定点上的布尔表达式将是真实的。” (来源：未知，我找不到参考，但定义被燃烧到我的脑海中!)

我认为我们应该用该定义中的缺陷替换错误，但是就我们目的而言，我们不要让我们分散我们的注意力。

关于上述定义，我们需要注意三个重要点，其中包括：

· 主张将表达式评估为真或错误

· 断言是代码中特定点的系统状态的假设

· 主张验证了一个系统假设，即如果不是真的，则在代码中揭示了一个错误

从定义中可以看到，断言对于验证函数，模块或接口的合同特别有用。它们不是用于错误处理的，而是用于检测代码中的缺陷。

关于断言有很多要知道的事情，但是在考虑主张和逐项合同时，使用断言来评估合同非常简单。例如，考虑中查看的dio_init函数。如果要包含代码来验证我们先前在评论中写的合同，我们可能会有一个函数，看起来像下面。

如您所见，我们对每个前条件都有一个主张。我们还可以使用断言来执行有关后条件和不变性的检查，但是您在这一点上可以明白。

断言为您提供了一种干净，简单的机制，以通过合同执行设计。虽然某些时钟周期将用于评估表达式，但是一旦开发完成，在系统验证之前，您可以禁用断言以获得一些额外的性能。通常，我通常会启用它们，但是遵循NASA的规则很重要：

“驾驶测试的东西”

因此，如果启用断言测试，则启用与它们一起运送。如果您禁用它们并发货，则系统的时机可能会改变，从而导致种族条件或其他有趣的缺陷。凭借当今的现代处理器，例如Cortex-M4，Cortex-M23，Cortex-M33等，评估表达式的开销通常很低。

结论

逐一设计是一种简单的技术，开发人员可以用来完全指定其功能，组件和接口。完全指定的界面会减少实现混乱，并可以验证以确保满足所有前条件。无法使用断言抓住任何条件，这告诉开发人员的应用程序中存在缺陷以及该缺陷在哪里!这可以大大减少收到嵌入式系统，节省时间，开发成本以及对开发人员的压力的时间。