软件概述应该使用哪个UML图，而软件概述将用C语言编写，用于微控制器？

Question

我想知道如何使用UML图来呈现软件概述。该代码将用C语言编写，用于微控制器。因此，我不能使用类图/对象图/复合结构图。然后,

1. 我应该使用哪个UML图？

1. 可以用于此活动图吗？如果是这样的话，是否有任何方法将所有的活动组合在一个图中，以获得整个软件的视图？

1. 如果UML图不合适，那么哪个是适合这个目的的？

提前谢谢。

Answer 1

理想情况下，程序设计应该与您的需求规范相结合，这样对于每个需求都有一个代码模块，对于该代码模块有一个测试来演示它是如何实现需求的。这是一种乌托邦，很少有人在实践中坚持，但这种设计是一个很好的抱负。

然后，一般来说，它并不是重要的，如何记录程序设计，只要总体设计得到完全记录-这是令人惊讶的罕见，甚至在专业设置。但是UML的所有迂腐细节实际上都是可选的，在您为它们找到案例的地方使用它们，而不是仅仅为了它们而使用它们。我经常使用UML类图来记录代码依赖关系，以及用于记录应用程序行为的状态图。依此类推--在没有实现的情况下保持宽泛--细节。

类的C等价物通常是同名的.h/.c对，它们共同构成一个“模块”或"ADT“或任何您希望称之为它的东西。

您需要记录所有A类使用B类依赖项，以及所有B类依赖项是A类依赖项(继承)。继承在嵌入式系统中并不常见，但是实现HAL是使用HAL的一个典型例子。在硬件驱动程序之上有一个抽象的API。

显然，您需要尽早决定这种抽象是否合理--该程序最终会移植到另一个MCU上吗?还是您依赖于硅厂商“长寿”的保证，即MCU不会在预期的产品寿命内结束生命？从今天这个完全崩溃的硅市场来看，我认为任何一个微控制器项目都需要在其生命周期内移植大量的数据。

Answer 2

为了对用C编写的大型应用程序的静态结构进行建模，我建议使用包图。图中的包表示子系统，很可能与应用程序的高层目录结构相对应。这些包之间的依赖箭头将指示哪个子系统使用哪个子系统。

对于每个顶层包，您可以创建一个单独的包图，显示子系统/子目录及其依赖项。