软件模型帮助开发人员理解、澄清和交流关于他们的代码和它必须支持的用户需求的想法。 不幸的是，众所周知，嵌入式开发人员不擅长开发软件模型。 以下是每个开发人员在设计下一代嵌入式系统时都应该考虑的一些经验教训。

1. 明确模型的用途

如果目标明确，模型可以让嵌入式软件开发人员在编写一行代码之前更好地理解系统。 它们用作回答有关系统的特定问题的表示。 在开发人员开始随机填充模型之前嵌入式系统软件教程，他们应该停下来定义模型的目的和要回答的具体问题。

为帮助指定目的，建议开发人员向模型添加任务说明以说明其目的。 除了作为指导模型开发人员的提醒之外，简短的任务说明还可以告知未来的维护人员模型的目的。

2. 80%的建模被三个UML图覆盖

大多数嵌入式系统都可以使用三种图表类型进行建模。 最常用的图是类图、状态图和序列图。

类图为嵌入式开发人员提供了一种定义软件块或类及其在软件系统中的交互的方法。 稍后，此图可帮助开发人员了解更大的图景并了解不同的代码片段将如何交互。

状态图，可帮助开发人员概述系统的不同软件状态以及系统如何从一种状态转换到另一种状态。

序列图可用于描述输入、输出和系统组件之间的一系列事件和行为。

可能不时需要的附加图表是流程图，这可能是几乎每个开发人员都熟悉的图表。

3.需求可以建模

通常，开发人员获取或开发软件需求文档，然后用于开发软件的设计。 那份文件非常重要。 开发人员可以在 UML 用例图的帮助下以直观和精确的形式建模和定义软件需求。

4. 重用经过验证的解决方案的设计模式

如果问题有已知的解决方案，为什么还要重新发明轮子？ 计算机科学为嵌入式开发人员提供了经过验证的解决方案，以解决几乎每个嵌入式系统中遇到的许多常见问题。 设计模式为开发人员提供了一种方法嵌入式系统软件教程，可以利用他人的经验来比从头开始更快、更稳健地开发系统。

5. 持续验证和测试

嵌入式软件开发人员通常会在编写代码时抽查他们的工作，但大多数测试实际上是在最后才进行的。 通常，编写大量代码，然后交给 QA 团队，以证明它没有缺陷。

越早发现缺陷，成本越低，所以嵌入式系统的测试和验证应该在系统的每个阶段和迭代中进行。 将系统分解成小块进行建模和测试，然后实施和测试是开始证明系统正常工作的好方法。 随着每次迭代，可以添加更多部件，并且可以在将更多部件添加到系统之前再次测试和验证这些部件。

推理

嵌入式开发人员需要在编写一行代码之前更好地建模他们的软件和系统。 以上五个教训是开发人员开始构建更好模型的良好开端，这些模型会产生更可靠且更具成本效益的系统。