编译时条件如何在 UML 活动图中表示？

Question

我正在使用需要在 UML 中记录的遗留 C 代码。没有立即要求使用这些 UML 图进行综合，但希望在未来朝着这个方向发展。

现在，代码充满了可以在编译时启用或禁用的功能：

#if(FEATURE_X == ON)
    deal_with_x();
#endif

由于在 UML 中无法区分编译时条件和运行时条件（有吗？），我最终对两者使用相同的决策块，这意味着我的图表实际上代表了以下代码：

if(FEATURE_X == ON) {
    deal_with_x();
}

虽然我希望编译器在禁用功能 X 时消除调用，但至少有两个原因，这不是完全相同的代码：

• 即使功能 X 被禁用，deal_with_x() 也必须定义
• 静态代码分析会报错代码

处理这种情况的正确方法是什么？是否有我不知道的 UML 功能可以提供帮助？或者我应该为不同的配置创建单独的活动图（相当工作）？还是应该依靠编译器来消除不必要的调用并完全避免使用预编译器指令？

虽然我的问题是关于 C 代码和预编译器指令的，但我发现 C++ 模板也会出现同样的问题，尤其是在语言中引入了 static if 时。

Answer 1

只需使用标记值来描述它。

这与任何活动图无关。这是一个纯静态部署的事情。因此，您可以为不同的编译创建使用不同标记值的组件。

编译时条件告诉您如何生成代码。因此，这将转到模型的某些部署部分。活动图是指系统的行为。如果您有一个以一种或其他方式编译的目标组件，并且您在活动图中显示它的不同用法，您可以通过各种方式发出信号。一种是在模型或随附文档中的其他地方描述的命名约定。另一种方法是创建需求，声明创建一个公共源并将这些需求链接到活动和后续组件。

作为（个人）旁注：编译时选项的使用（尤其是过度使用）会使您的代码难以阅读，甚至无法阅读。事实上，每次使用编译时选项都会使同一个源成为完全不同的东西。因此，宁可从“我希望此函数具有相同的源，因此倾向于使用编译器标志”开始，而是另辟蹊径。专注于功能，当涉及到部署时，最终会考虑使用编译器标志的“优化”。所以实际上，完全不要考虑活动图。