前几篇文章探讨了设计嵌入式软件架构的前四个步骤。本文通过研究最后一步来结束这个系列;模拟、迭代和缩放。当然可以有更多或更少的步骤，但这无关紧要。相反，这五个步骤可以帮助嵌入式开发人员确定他们需要做什么以及他们将遵循的一般过程。

　　步骤 5–模拟、迭代和扩展

　　开发嵌入式软件架构通常不是软件开发生命周期(SDLC)中的单一事件。如果嵌入式软件架构设计是发生在单个点的单个事件，这将表明我们知道了在系统开始时需要知道的一切，并且在整个项目中没有什么会改变。迄今为止，在我大约20年的经验和我参与的大约150个项目中，这种情况从未发生过。客户通常试图在产品发货前进行更改，在某些情况下甚至在发货后!

　　软件架构开发是一个迭代的过程。通常，我们从最高级别开始，也就是众所周知的30，000英尺的视图，然后逐步深入到越来越多的细节。好的架构通常是有界的，这意味着它被分成几个独立或半独立的域。我们可以利用模拟来测试并向自己证明高级架构不仅适合我们的需求，也适合我们客户的需求。如果我们发现问题，我们迭代并改进我们的设计。

　　随着客户需求的发展，软件架构也必须发展和扩展。软件架构和软件开发永远做不完。总是有更多的事情要做，无论是消除缺陷、添加新功能，还是重构以提高代码质量和理解。对于一个嵌入式开发团队来说，开发一个核心架构作为创建几十个产品的平台是很常见的。这种架构必须能够很好地伸缩，以应对未知的未来需求。

　　嵌入式软件仿真

　　模拟嵌入式软件的想法并不新鲜，但是如果你向开发人员和架构师询问模拟，你可能会听到它并不适用。

　　模拟有几种不同的形式。首先，我们可以编写应用程序代码模块，然后创建一个与这些模块挂钩的框架，并为我们提供关于模块行为和执行情况的视觉和日志反馈。其次，我们可以将这些模块部署到模拟硬件上，从而获得关于系统的总体反馈，并探索其行为。前两个选项依赖于我们实现架构。最后一个模拟方法是使用建模工具来创建我们架构的模型。建模工具通常可以模拟模型并探索其行为。有时，这些模型甚至可以生成可用于生产的代码。

　　嵌入式软件架构诱惑

　　一个好的架构师知道软件架构将会发展。因此，示例性架构将保持高水平的细节，允许开发者以他们认为合适的方式实现该架构。然而，诱惑折磨着每一个嵌入式架构师和嵌入式开发人员。诱惑是深入系统的底层细节，让他们来决定设计。

　　例如，当试图为一个功能制定一个用户故事时，几乎每个开发人员都会立即陷入这样的问题：微控制器上使用的是什么引脚，是GPIO还是通过I2C连接的某个设备。他们应该考虑用户如何与系统交互，以及用户的需求。尽管如此，他们的脑海中立即跳转到实现细节。

　　一个重要的技巧是将所有不需要现在决定的低级细节推迟到以后。对于嵌入式软件开发人员来说，这种想法非常痛苦，并且不太符合我们的自然思维方式。一些嵌入式开发人员需要被指导，他们的思维需要被调整以正确地构建系统。不要屈服于诱惑!让您的架构来指导实现，而不是被它紧紧耦合和支配。否则，您会发现您的架构将无法很好地发展或扩展。

　　软件架构设计第5步结论

　　在本系列中，我们已经探索了如何设计嵌入式软件架构的现代概念。复杂系统的现代固件要求将软件体系结构分解为独立于硬件和依赖于硬件的体系结构。传统的嵌入式软件开发人员通常很难做到这一点。通过关注系统的数据资产并允许它们决定设计，可以在一定程度上缓解这种矛盾。结果通常是软件架构更容易与用户的需求联系起来，使得架构更具可伸缩性和可发展性。此外，一个精心架构的系统可以利用现代工具，如单元测试和模拟，并且可以是非常可移植的。

　　在这五篇文章中，我们研究了设计嵌入式软件架构时可以遵循的几个简单步骤。请记住，我们只是触及了表面。正如人们常说的，细节决定成败。然而，这些概念应该可以帮助你启动、更新和革新你的嵌入式开发工作。