Изображение статического полиморфизма в диаграмме классов UML

у меня есть объект, который создается во время компиляции в зависимости от конфигурации сборки. Что касается рассматриваемого окружающего программного обеспечения, объект предоставляет тот же интерфейс. Я хотел бы смоделировать тот факт, что решение о создании экземпляра принимается во время компиляции (т. е. static polymorphism), в отличие от обычного динамического полиморфизма.

есть ли способ изобразить статический полиморфизм в UML class diagram?

здесь более или менее то, что я нужно:

enter image description here

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

5 ответов


Я думаю, что представление UML будет одинаковым для статического и динамического полиморфизма. Язык UML-это о том, как классы взаимодействуют во время выполнения: я не верю, что есть формат UML для описания шаблонов, но я могу ошибаться.


Я бы использовал стереотипы для решения проблемы. Таким образом, вы можете отметить dynamic и static


Я думаю, что ваша схема-это хорошо. То, что вы описываете, лучше всего описывается как диаграмма последовательности, описывающая процесс компиляции. (Вроде того, как вы нарисуете диаграмму заводской последовательности, я думаю)

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

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

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


объединение из @ChiragDesai и @user2004268 ответов и связанного вопроса (определение и реализация статического полиморфизма):

  1. тип полиморфизма является деталью реализации, и как таковой, он не имеет активной роли в расчетные схемы.
  2. детали реализации могут присутствовать на диаграмме UML, но имеют дополнительную и неформальную роль. Стереотипы и примечания могут использоваться для уточнения намерений.

используйте утилиту пустой класс со стереотипом Singleton с общим логическим параметром, например #ifdef(YOUR_FLAG), которого true специализация имеет экземпляр в качестве статического члена с видимостью public или implementation.

редактировать (в ответ на комментарий)

ничья это в вашем инструменте UML:

псевдо-C++-код:

class Foo; 

template <
   Boolean #ifdef(WHATEVER)
> struct Bar {};

template <> 
struct Bar<true> {
  public: 
    static Foo the_foo;
};

и добавить utility и Singleton стереотипы (но не пытайтесь генерировать код от этого ;))