Generalization Set (для определенности будем рассматривать только {disjoint, complete}) могут быть:

• любой объект не может изменить свой подкласс, например суперкласс - Человек, подклассы - Мужчина, Женщина
• любой объект может изменить свой подкласс, например суперкласс - Человек, подклассы - Одинок, В браке, Разведен, Вдов

Как это можно формально отразить на диаграмме классов?

Есть такой вариант - делаем ассоциацию с PowerType (1 Пол, 2 СемейноеПоложение) и указываем или не указываем {readOnly} на конце ассоциации, примыкающем к PowerType. Но он такой громоздкий, хотелось бы чего-нибудь попроще!

Все-таки рисунок проще воспринимать, чем только текст

Возьмем картинку (она из стандарта UML 2.5!).
http://analyst.by/wp-content/uploads/2016/09/ClassDiagram2.png
На ней не всегда {disjoint, complete}, но мы будем считать, что {disjoint, complete} всегда.
Как увидеть, что для объектов класса HealthInsurancePolicy значение CoverageType (и принадлежность к подклассу) не может измениться, а значение InsurancePlan - может?
Пока знаю только один путь:

• на диаграмме и Generalization Set, и ассоциация
• указана связь между ними
• конец ассоциации помечен или нет ограничением {readOnly}

Громоздко (много элементов) и ненаглядно (связь между ассоциацией и Generalization Set не в виде линии, а по совпадению имен)!
Вот если бы при Generalization Set ставить какую-нибудь отметку, чтобы знать может измениться подкласс объекта именно в этом Generalization Set или нет.
Собственно в этом и вопрос - знает ли кто-нибудь такую отметку стандартными средствами UML?
Понятно что всегда можно сделать примечание или комментарий, но хотелось бы больше формальности!

UML, на моей планете), предпочитает не касаться вопроса о том, может ли менять свой тип экземпляр класса. С него достаточно, что он позволяет через запятую указать несколько не конфликтующих (текущих) типов экземпляра (в этом месте у многих кодеров может взорваться мозг). Но это _имеющиеся_ у экземпляра типы. Может ли объект менять тип -- это свойство ОО-среды реализации, например, OO-языка программирования. Многие UML-модели делаются так, как-будто типы экземпляров статичны (с единственной поблажной имени Барбары Лисковы). Например, в классическом RUP-овом примере от Rational используется делегирование, чтобы показать, что студенты бывают разных типов и могут менять свой тип:

Смена типа студента состоит в том, что один "хвост" ему отрезают, а другой -- пришивают.

Мне нравится, как легко "развинчивается" UML. Достаточно взять примитивы языка и соединить в таком сочетании, которое авторы языка / стандарта / книг на публике не использовали. И вуаля.
Если требуется комментарий к решению с powertype, то он есть в книжке Milicev "MDD with xUML". В таком ключе: powertype придумали бизнес-аналитики, пусть они им и пользуются.

Многие UML-модели делаются так, как-будто типы экземпляров статичны (с единственной поблажной имени Барбары Лисковы). Например, в классическом RUP-овом примере от Rational используется делегирование, чтобы показать, что студенты бывают разных типов и могут менять свой тип:

Это тоже вариант. У него свои недостатки:

• громоздко
• если представить, а Student имеет подклассы, например Left и Right, то будет непонятно: 1) это Student может менять FullTime на PartTime и обратно, а Classification нарисована, чтобы помочь это показать или 2) это Classification может менять Left на Right и обратно, а Student нарисован, чтобы помочь это показать

Смена типа студента состоит в том, что один "хвост" ему отрезают, а другой -- пришивают.

Причем отрезанный "хвост" надо сразу уничтожить, а пришиваемый - прямо перед "этим" (или даже в ходе "этого") создать, да ещё с тем же значением maxCourceLoad!

Если требуется комментарий к решению с powertype, то он есть в книжке Milicev "MDD with xUML". В таком ключе: powertype придумали бизнес-аналитики, пусть они им и пользуются.

Перечитал Milicev "MDD with xUML". Он просто своим OOIS UML никак не обрабатывает powertype, поэтому тоже не знает, может ли объект менять тип (или считает, что всегда не может).

Есть такой диалект - ontoUML. Там стереотип <<Phase>> означает, что подкласс может меняться.

Это тоже вариант. У него свои недостатки

Цитировалась та картинка, что нашлась в сети.
На "нормальной" старшинство по отношению к "хвосту" было бы размечено композицией / агрегацией.

На "нормальной" старшинство по отношению к "хвосту" было бы размечено композицией / агрегацией.

Согласен с необходимостью внести на диаграмму (в модель) для ассоциации между Student и Classification какой-то "несимметричности".
Как вариант - конец при Student {readOnly} для обозначения

Смена типа студента состоит в том, что один "хвост" ему отрезают, а другой -- пришивают.

- студент может сменить "хвост", а "хвост" не может сменить студента - только "умереть", освободив место для свежерождённого "хвоста". И maxCourceLoad можно переместить в Student, чтобы не передавать его значение из старого "хвоста" в новый.

любой объект может изменить свой подкласс, например суперкласс - Человек, подклассы - Одинок, В браке, Разведен, Вдов

Есть такой диалект - ontoUML. Там стереотип <<Phase>> означает, что подкласс может меняться.

По ссылке пример прямо в тему:
https://ontouml.org/ufo/wiki/catalogue-ontological-patterns/phase-partition-pattern/

Интересный ресурс -- столько разных диаграммок.
Спасибо, Vadim! [Без шуток.]

По Power Type https://pdflegend.com/download/using-a-well-founded-multi-level-theory-to-support-the-analysis-and-representation-of-the-powertype-pattern-in-conceptual-modeling-_59feb1a2d64ab29c64ea2119_pdf