UML 的实时扩展是由一家公司推广的，目前该公司的名字让我无法理解。我记得几年前写过一篇关于它的论文。Bruce Powell Douglass 写了几本关于使用 UML 对嵌入式系统建模的书，但他的公司并不是我所想的那家。

也就是说，为了呼应 Wouter，嵌入式软件本身并没有什么特别之处。我每天都为在奔腾级处理器上运行的系统编写嵌入式软件；UML 非常适用。另外，请记住，随着时间的推移，控制软件的许多方面已经添加到 UML 中：在序列图中有指定同步或异步事件以及响应时间的语法，Petri 网类型行为可以在活动图中找到，状态图模型行为甚至更好比状态图可以，等等。

OTOH，很多人更喜欢使用结构化设计和数据流概念对嵌入式软件进行建模。这完全取决于您正在设计的系统类型以及最有效的系统。

转向 RTOS 时，我们通常会处理具有许多并发任务的应用程序，这些任务需要进行最佳调度，以使每个任务都能按时按时完成或安全地共享资源。您选择的 RTOS 框架实现了一个任务调度程序，您的工作（通常）是编写具有特定属性集（周期、优先级等）的这些单独的任务，然后将其交给调度程序。因此，对于文档，我将采取的方法是仔细记录每项任务。

大多数嵌入式软件，据我所知，大多数 RTOS 都不是用面向对象的语言编写的，因此可能无法从许多面向类图的东西中受益。

然而，在记录您的 RTOS 任务时，任何能很好地描述任务的图表都会有很大的好处。例如，我想每个任务的序列图可能会非常有帮助。除此之外，您还可以指定其硬性要求，例如其周期/频率、优先级、它可能使用的任何共享资源、抢占要求等。还有价值可能是记录您如何配置 RTOS，也许还有一个状态-机器的调度算法。

不管你喜欢什么建议，我从大学时代就没有搞砸过 RTOS 的东西，也从来没有真正“记录”过这项工作。

建模就是一切

• 了解您的应用程序中哪些方面是困难和复杂的，

• 找到适合该方面的建模工具/语言/抽象/约定/符号

• 设计那个方面

因此，没有任何建模工具/方法/等适用于所有情况。卫星很可能是一个实时多任务系统，可能有多个处理器。任务结构图、STD 和序列图可能很有用（仅举几例）。如果项目是用 C 完成的，那么类图就不太可能有用（如果结果证明它非常有用，那么选择 C ​​可能是错误的）。我不太喜欢 UseCases，而且卫星 an-sich 没有用户。用例最适合您想与非技术用户讨论系统要求的情况。如果这是您在卫星项目中遇到的情况，则出现问题。

我没有设计任何符合太空要求的东西。但我曾为国防部 (DoD) 航空分包商工作，我的许多设计都符合飞行要求。他们需要大量关于您的设计的文档，并提供数据项描述 (DID)，详细说明他们希望看到的内容。

如果您在“标题中的单词”字段中键入“软件”并单击提交，您可以使用 DoD ASSIST 快速搜索来查看可能需要的文档的所有 DID。（我觉得 DoD 网站抛出证书安全警告很有趣，但我向你保证，它是安全的）。

由于您专门询问设计文档，因此这里是软件设计描述(SDD) DID。他们强调使用文字来描述设计的每个部分。但是如果使用UML、状态图、流程图、伪代码等，可以增强对设计的理解，那么他们当然希望你把它包括进来。

正如其他人所说，您选择哪种建模方法取决于您的设计。但我认为看到航空航天软件的 DID 可能会帮助您编写设计文档，因为您的项目与空间相关。