В процессе проработки http://www.uml2.ru/forum/index.php?topic=6532.msg40739#msg40739всплыл вопрос о лучшем диаграммировании ситуации из вложения.
Все SetGeneralization полные (complete) и непересекающиеся (disjoint).
Недостаток: Transition обобщает IncomingTransition и OutgoingTransition, а на диаграмме этого явно не видно.

Ссылка у вас ведет почему-то на ftp. Может быть Вы тезисно повторить исходную проблему?

Ссылку поправил, но по ней можно не ходить - это не принципиально.
Принципиально - уменьшить недостатки диаграммы.
Например диаграмма во вложении частично преодолевает указанный в исходном топике недостаток (явно видно, что Transition обобщает IncomingTransition), но вносит новый недостаток - теряется симметричность диаграммы, хотя исходная проблема явно симметрична. По-прежнему все SetGeneralization полные (complete) и непересекающиеся (disjoint).

Если не ходить по ссылке:
почему outgoingtransition - это не transition?
begintransaction - что это за понятие? и не кажется ли вам, что оно выпадает из общей сравнительной классификации:
начальный переход
внешний переход
внутренний переход

и разве начальный переход не подвид внешнего перехода?

почему outgoingtransition - это не transition?

outgoingtransition - это transition, но на диаграмме этого сразу не видно, а хотелось бы!

begintransaction - что это за понятие? и не кажется ли вам, что оно выпадает из общей сравнительной классификации:
начальный переход
внешний переход
внутренний переход

и разве начальный переход не подвид внешнего перехода?

По UML-стандарту начальный переход это подвид внешнего перехода, хотя некоторые UML-инструменты имеют визуальный элемент, который объединяет и начальное состояние, и переход из него. Но в данной теме хотелось обсуждать не это, а диаграммирование конкретной ситуации, а названия классов могли быть просто a, b, c, d, e, f.

Если отвлечься от надписей, то почему бы не так:
A родитель перекрывающихся B и C, В родитель не перекрывающихся D и E, С родитель не перекрывающихся E и F.
Если принять во внимание надписи, то можно подумать над набором классов -- все ли нужны.

A родитель перекрывающихся B и C, В родитель не перекрывающихся D и E, С родитель не перекрывающихся E и F.

Допустимыми должны быть только конфигурации: (ABD), (ABCE), (ACF). А так получается, что допустимой является и конфигурация ABCDF.

Если принять во внимание надписи, то можно подумать над набором классов -- все ли нужны.

Все нужны - на диаграмме этого нет, но каждый имеет особенность: или атрибут, или участие в ассоциации, или ограничение, или ещё что-нибудь.

Допустимыми должны быть только конфигурации: (ABD), (ABCE), (ACF). А так получается, что допустимой является и конфигурация ABCDF.

Раз так, то просто провести явно неявные стрелочки на 1й диаграмме.

Все нужны - на диаграмме этого нет, но каждый имеет особенность: или атрибут, или участие в ассоциации, или ограничение, или ещё что-нибудь.

Авторы стандарта просто завели атрибут, чтобы хранить вид перехода. Почему бы не последовать их дурному примеру?)
Кстати про ABCDF. См. Figure 14.35. Ах, да. Про это писали выше.
P. S. Рисунок гармонирует с ограничением state_is_external из 14.5.11.8. Как тут не вспомнить Джеймса Рамбо с его сакраментальным: "В ставке Гитлера все малахольные!"

Раз так, то просто провести явно неявные стрелочки на 1й диаграмме.

Тогда на диаграмме будут обозначены и базовые факты, например "D подкласс B" и "B подкласс A", что хорошо, и производный факт "D подкласс A", что обычно не делается. Начиная тему, я предполагал, что  идеального варианта может и не быть, хотелось совместно выбрать лучший.

Авторы стандарта просто завели атрибут, чтобы хранить вид перехода. Почему бы не последовать их дурному примеру?)

Диаграмма, как её рисует стандарт (без constraint'ов) упрощается (правда появляется кратность 0..1 вместо 1..1 для атрибутов и ассоциаций), но модель в целом - усложняется (где-то constraint'ы надо указать).

Кстати про ABCDF. См. Figure 14.35.

Не уловил.

Ах, да. Про это писали выше.

Не уловил.

P. S. Рисунок гармонирует с ограничением state_is_external из 14.5.11.8.

Не уловил.

Как тут не вспомнить Джеймса Рамбо с его сакраментальным: "В ставке Гитлера все малахольные!"

Не уловил (откуда цитата знаю, наверное с чувством юмора проблемы).

Не уловил.

Стандарт говорит, что initial transition является external transition. Буковки E и F у меня попутались. Указанное ограничение странно написано, но опять таки скобки у меня попутались. Рамбо в книжке интервью резко отзывался об IBM.
Приношу всем свои извинения.

Лучший (по-моему) вариант.

Интересно. Не припомню примеров derived классов.

http://infocat.ucpel.tche.br/disc/mc/cmis.pdf глава "8 Derived Types".
Пункт "8.3.2 Derived by Specialization" на стр.170 содержит аналогичную ситуацию:
 context Square::allInstances():Set(Square)
 body: Rectangle.allInstances()->
 intersection(Rhombus.allInstances())

И в целом книга интересна, и другие произведения автора.

EnterpriseArchitect (не знаю с какой версии, но в 12 есть) даёт возможность в свойствах класса указать, что derived.

Клевая ссылка, спасибо.
В стандартной метамодели UML нет места, чтобы запомнить isDerived у класса. Можно без экзотики написать инвариант, запрещающий плохие комбинации наследования.

В стандартной метамодели UML нет места, чтобы запомнить isDerived у класса.

Я тоже не нашёл. Но:

• В стандартной метамодели UML ассоциация имеет isDerived, а значит и некоторые классы (которые класс-ассоциации) могут быть производными
• В книге Рамбо и Блаха в 4.10. прямо сказано: "Производными могут быть классы, ассоциации и атрибуты" и пример есть (правда не очень хороший)

В книге есть попытка решить исходную проблему топика, но неудачная (рис.4.16.) - Vehicle может быть Car и Boat одновременно.

Можно без экзотики написать инвариант, запрещающий плохие комбинации наследования.

Такой инвариант может быть в контексте любого из остальных 5 (кроме ExternalTransition) классов и только в классе Transition сохранит симметричность модели (но не простоту написания).

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