Как можно представить условия времени компиляции в диаграммах активности UML?

Question

Я работаю с унаследованным кодом 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++, особенно если static if вводится на этом языке.

Answer 1

Просто перейдите для отмеченных значений, чтобы описать это.

Это не имеет никакого отношения к какой-либо диаграмме деятельности. Это чисто статическое развертывание. Таким образом, вы можете создавать компоненты, которые используют разные тегированные значения для разных компиляций.

Условия компиляции говорят вам, как сгенерировать ваш код. Таким образом, это перейдет к некоторой части развертывания вашей модели. Диаграмма активности относится к поведению вашей системы. Если у вас есть целевой компонент, который скомпилирован так или иначе, и вы показываете его различные применения в диаграммах деятельности, вы можете сигнализировать об этом по-разному. Один - это соглашение об именах, которое описано где-то еще в модели или сопроводительной документации. Другим способом является создание требований, которые приводят к созданию общего источника и связывают эти требования с действиями и более поздними компонентами.

В качестве (личной) стороны примечание: использование (особенно задержка использования) параметров времени компиляции делает ваш код трудным для чтения до нечитаемого. В самом деле, каждое использование параметра времени компиляции сделает тот же источник совершенно другой. Поэтому, скорее, для начала: «Я хочу иметь один и тот же источник для этой функции и поэтому, как правило, использовать флагов компилятора», идем в другую сторону. Сосредоточьтесь на функции, и когда дело доходит до развертывания, в конечном итоге подумайте о «оптимизации» в отношении использования флагов компилятора. Так что на самом деле, одумайтесь о нем полностью из диаграмм деятельности.