Как условия времени компиляции могут быть представлены в диаграммах действий UML?
Я работаю с устаревшим кодом C, который мне нужно документировать в UML. Нет непосредственного требования использовать эти UML-диаграммы для синтеза, но есть желание пойти в этом направлении в будущем.
Теперь код пронизан функциями, которые можно включить или отключить во время компиляции:
#if(FEATURE_X == ON)
deal_with_x();
#endif
Поскольку в UML нет способа различить условия времени компиляции и времени выполнения (не так ли?), Я в конечном итоге использую один и тот же блок принятия решений для обоих, что означает, что мои диаграммы действительно представляют следующий код:
if(FEATURE_X == ON) {
deal_with_x();
}
Хотя я ожидаю, что компилятор исключит вызов, когда функция X отключена, это не совсем тот же код по крайней мере по двум причинам:
deal_with_x()должен быть определен, даже если функция X отключена- статический анализ кода будет жаловаться на мертвый код
Как правильно справиться с ситуацией? Может ли помочь функция UML, о которой я не знаю? Или я должен создать отдельные диаграммы деятельности для разных конфигураций (вполне работа)? Или я должен полагаться на компилятор, чтобы исключить ненужные вызовы и вообще избегать использования директив прекомпилятора?
Хотя мой вопрос касается директив C-кода и директив прекомпилятора, я вижу, что та же проблема может возникнуть с шаблонами C ++, особенно если статический if вводится на языке.
Решение
Просто перейдите на помеченные значения, чтобы описать это.
Это не имеет никакого отношения к диаграмме активности. Это чисто статическое развертывание. Таким образом, вы можете создавать компоненты, которые используют разные теговые значения для разных компиляций.
Условия времени компиляции говорят вам, как генерировать ваш код. Так что это перейдет к некоторой части развертывания вашей модели. Диаграмма активности относится к поведению вашей системы. Если у вас есть целевой компонент, который компилируется тем или иным способом, и вы показываете его различные использования на диаграммах действий, вы можете сигнализировать об этом различными способами. Одним из них является соглашение об именовании, которое описано где-то еще в модели или в сопроводительной документации. Другой способ — создать требования, в которых указывается создать общий источник и связать эти требования с действиями и последующими компонентами.
В качестве (личного) примечания: использование (особенно чрезмерное использование) параметров времени компиляции делает ваш код трудным для чтения до нечитаемого. Действительно, каждое использование параметра времени компиляции делает один и тот же источник совершенно другой вещью. Поэтому лучше начать с «Я хочу иметь один и тот же источник для этой функции и, следовательно, склонен использовать флаги компилятора», пойти другим путем. Сконцентрируйтесь на функциях, а когда дело доходит до развертывания, в конце концов подумайте об «оптимизации» в направлении использования флагов компилятора. Так что на самом деле, оставьте мысли об этом полностью вне диаграмм деятельности.
Другие решения
Других решений пока нет …