软件模型可以帮助开发人员理解、阐明和交流关于他们的代码和它必须支持的用户需求的想法。但不幸的是，嵌入式开发人员在开发软件模型方面是出了名的糟糕。以下是一些经验，每个开发人员在设计下一代嵌入式系统时都应该考虑。

　　1.指定模型的用途

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

　　为了帮助指定目的，建议开发人员向模型添加一个任务声明来陈述其目的。一个简短的使命陈述不仅可以作为一个提醒来指导模型的开发者，还可以告知未来的维护者模型的目的。

　　2.80%的建模被三个UML图覆盖

　　一个嵌入式系统的大部分可以用三种图表类型来建模。最常用的图是类图、状态图和序列图。

　　类图为嵌入式开发人员提供了一种定义软件块或类以及它们在软件系统中的交互的方法。然后，这些图表帮助开发人员理解更大的图景，并看到不同的代码块将如何相互作用。

　　状态图，帮助开发人员描绘系统的不同软件状态，以及系统如何从一个状态转移到下一个状态。

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

　　偶尔可能需要的额外图表是流程图，这可能是几乎每个开发人员都熟悉的图表。

　　3.需求可以建模

　　通常开发人员获得或开发一个软件需求文档，然后用于开发软件的设计，那份文件很重要。开发人员可以利用UML用例图，以可视化和精确的方式建模和定义软件的需求。

　　4.重用成熟解决方案的设计模式

　　如果一个问题有一个已知的解决方案，为什么要重新发明轮子呢?计算机科学为嵌入式开发人员提供了许多在几乎每个嵌入式系统中遇到的常见问题的成熟解决方案。设计模式为开发人员提供了一种利用他人经验的方式，比他们从零开始更快、更健壮地开发系统。

　　5.持续验证和测试

　　嵌入式软件开发人员通常会在编写代码时抽查他们的工作，但大部分测试真正是在最后进行的。通常，大量的代码被写出来，然后交给QA团队去证明没有缺陷。

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

　　结论

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