Отношение одно, остальные 4 - его вариации.

Я что-то не догоняю, разве так можно? НЛО? Разве нотация позволяет в данном случае читать розовую модель как одно из возможных отношений?

И также интересно почему выбрана иерархия наследования, а не простое включение?

Только бы редефайнов навставлять

Обычно не использую редефайны - они утяжеляют диаграмму. Считаю, что если подкласс имеет свойство с тем же именем, что и суперкласс, то редефайн подразумевается.
Тут есть ещё один момент - поясню на примере: полюс класса-ассоциации от Студента к Предмету отображает и то, что Студент имеет свойство "предмет" с множественностью "*", и то, что Изучение имеет свойство "предмет" с множественностью "1" (по крайней мере OCL так считает). 

и наследование как-нибудь позамысловатее -- начинать от линий ассоциации.)
 

Во вложении. MagicDraw позволяет рисовать наследование от любой из 3 частей (класс, ассоциация, пунктирный соединитель) к любой (можно подчинить класс ассоциации и наоборот, класс подчинить соединителю, соединитель - ассоциации и т.д.)!

На серой рука тянется объявить, что наследование подчиняется "принципу Рамбо" и считать, что наследники наследуют от класса ассоциации только классовую часть.

Наоборот, наследники наследуют всё, просто только в классовой части есть отличия, поэтому на диаграмме наследник нарисован не в виде класса-ассоциации, а в виде класса.

А решение с одним классом ассоциацией, у которого опциональные поля и составные части, рассматривалось?

Для точного специфицирования возможных ситуаций (а их в примере 3: без экзамена, экзамен не сдавался, экзамен сдан), мало указать опциональность полей, надо добавлять ещё ограничения. А что такое "составные части" - группы полей или что-нибудь другое?

Исправленная диаграмма - свойства должна иметь разные имена!

В стандарте в самом конце 11.5.3.2 есть фраза "An AssociationClass cannot be a generalization of an Association or a Class.". Я согласен, что элемент модели, который наследует от AssociationClass, тоже должен быть AssociationClass. Но это не значит, что на диаграмме этот элемент модели должен изображаться как AssociationClass, если для цели диаграммы достаточно только изображения класса (ассоциации), то хороший инструмент (который четко различает модель и диаграмму) должен:

• не разрешать подчинять классу-ассоциации просто класс или просто ассоциацию
• давать возможность на диаграмме представлять класс-ассоциацию как класс или как ассоциацию

MagicDraw не выполняет 2, EA не выполняет 1.
Кто-нибудь знает такие инструменты, которые выполняют оба?

• не разрешать подчинять классу-ассоциации просто класс или просто ассоциацию
• давать возможность на диаграмме представлять класс-ассоциацию как класс или как ассоциацию

MagicDraw не выполняет 2

Не совсем понял, это как? ЕА может?

EA (Sparx Enterprise Architect) позволяет подчинять классы классу-ассоциации. Пример на "серой" диаграмме. Правда он не позволяет ассоциациям наследовать друг друга.

EA (Sparx Enterprise Architect) позволяет подчинять классы классу-ассоциации. Пример на "серой" диаграмме. Правда он не позволяет ассоциациям наследовать друг друга.

А ответ на первую часть вопроса:))

MagicDraw разрешает подчинять: класс классу, ассоциацию ассоциации, класс-ассоциацию - и классу, и ассоциации, и классу-ассоциации. И это правильно (и соответствует стандарту).
Но MagicDraw изображает на диаграмме класс-ассоциацию только как совокупность 3 графических элементов: класса [прямоугольник], ассоциации [сплошная линия] (правда не n-арной, но это уже другая тема), соединителя между ними [пунктирная линия], добавляя и удаляя их с диаграммы только вместе. Правда дает тянуть линию обобщения от(к) любого из этих 3 элементов. Это не очень хорошо, если у подчиненного класса-ассоциации нет никаких отличий от родительского класса-ассоциации как класса (ассоциации) - на диаграмме все равно будут присутствовать все 3 элемента, включая не добавляющие новой информации ассоциацию (класс) и соединитель.

ЕА вообще не имеет такого элемента, как класс-ассоциация - только классы и ассоциации, соединенные или нет между собой (когда якобы создается класс-ассоциация, на самом деле создаются и класс, и ассоциация, причем соединенные друг с другом, в дальнейшем это соединение можно и отключить, и создать новое между любыми "свободными" классом и ассоциацией). Может это и правильно, в конце концов то, что в метамодели класс-ассоциация наследует и классу, и ассоциации можно представить и по-другому - между "классами" и "ассоциациями" метамодели сделать связь кратности 0..1 к 0..1. Обобщение строится только между классами (независимо от того, соединены ли они с ассоциациями). 

Очень круто. Но интересна практическая значимость всех этих знаний. Пример приводимой в ветке мне показался не очень убедительным. Возможно я плохо его читаю, не так совершенен в нотации. Было бы интересно представить некоторое сранвнение подходов к какой-то моделируемой задачи и показать что и почему лучше хуже.

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

Класс-ассоциация сам (сама) по себе не очень обязательная конструкция и легко заменяется:

• для бинарной ассоциации - просто классом с 2 ассоциациями с кратностью 1 от него и кратностью как у класса-ассоциации к нему + ограничение уникальности на сочетание значений полюсов ассоциаций от него
• для n-арной ассоциации - просто классом с n ассоциациями с кратностью 1 от него + ограничение уникальности на сочетание значений полюсов ассоциаций от него + ещё ограничения, заменяющие ограничения кратности у класса-ассоциации (нужны, если хоть одна кратность класса-ассоциации отличается от 0..*)

Популярность/желательность класса-ассоциации в том, что эта конструкции часто встречается на практике (если предметная область не "игрушечная") и хочется выразить ее графически - почти всегда она оказывает значительное влияние на использующего диаграмму (разработчика интерфейса, разработчика БД, ...).

Популярность/желательность класса-ассоциации в том, что эта конструкции часто встречается на практике (если предметная область не "игрушечная") и хочется выразить ее графически - почти всегда она оказывает значительное влияние на использующего диаграмму (разработчика интерфейса, разработчика БД, ...).

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

Вот предметная область:

• Студенты изучают Предметы
• Надо зафиксировать сколько времени Студент потратил на Предмет
• При записи Студента на изучение Предмета фиксируется будет ли сдаваться экзамен (в жизни обычно не так, будет ли экзамен определяется Предметом, но у нас же не жизнь, а пример!)
• Некоторые Студенты по некоторым Предметам уже сдали экзамен: есть дата и оценка

Я бы хотел, чтобы диаграмма (которая полностью отражает модель!) выглядела как "серая" - по мне она и полна, и неизбыточна.
MagicDraw требует "розовую", она полна, но избыточна.
Если есть ещё какой-то вариант диаграммы, который будет и полным, и неизбыточным, и выглядеть по-проще - я с удовольствием его приму. 

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

Ну, просто для экспериментов у меня нет времени. Едва хватает читать и что-то отвечать.
Но хорошо. Вы вот формируете какую-то запись. Можно же нарисовать диаграмму объектов. Судя по серой диаграмме между студентом и предметом может быть
1. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени.
Или
2. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени и сдавать экзамен не будет
или
3. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени и сдавать экзамен будет
или
4. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени и сдавать экзамен будет, но еще не сдавал
или
5. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени и сдавать экзамен будет, и закончил обучение сдав экзамен

Разве тут нет логических ловушек?
Если мы выберем вариант 1, то так и не поймем есть экзамен или его нет, вернее это совершенно не важно, т.е. по сути это почти эквивалентно варианту 2
Аналогично, если мы выберем вариант 3, то остановимся на факте, что нужно сдавать экзамен, следовательно такая конструкция нелогична, нужно либо вариант 4 либо 5

Итого должны быть валидны только 2, 4 или 5

Итого имеем то, что можно смоделировать 4 атрибутами
Затрачено времени
Будет экзамен?
Дата экзамена
Оценка

Вся избыточность только в случае отсутствия экзамена.

Возможные решения

Между Студент и Предмет две связи с двумя классами-ассоциациями: Записан на курс (Затрачено времени), Есть экзамен (Дата, Оценка)

Может быть ввести отдельный класс - Экзамен - соединив его с классом ассоциацией Изучение - 1 ко многим, то есть фиксируется не одна а несколько попыток сдачи экзамена. Экзамен класс который как мы помним определяется в том момент когда Студент записывается на Предмет и тогда как-то определяется нужно ли ему сдавать экзамен или достаточно просто изучить предмет

Вы вот формируете какую-то запись. Можно же нарисовать диаграмму объектов. Судя по серой диаграмме между студентом и предметом может быть
1. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени.
Или
2. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени и сдавать экзамен не будет
или
3. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени и сдавать экзамен будет
или
4. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени и сдавать экзамен будет, но еще не сдавал
или
5. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени и сдавать экзамен будет, и закончил обучение сдав экзамен

Разве тут нет логических ловушек?
Если мы выберем вариант 1, то так и не поймем есть экзамен или его нет, вернее это совершенно не важно, т.е. по сути это почти эквивалентно варианту 2
Аналогично, если мы выберем вариант 3, то остановимся на факте, что нужно сдавать экзамен, следовательно такая конструкция нелогична, нужно либо вариант 4 либо 5

Итого должны быть валидны только 2, 4 или 5

Здесь мой косяк - привык к тому, что если на диаграмме линии обобщения имеют общую стрелку (полый треугольник), то это означает, что имеется SetGeneralization с {complete, disjoint}. UML требует явного указания. Давайте считать, что для всех объединений стрелок обобщения на всех диаграммах указано {complete, disjoint}.

Итого имеем то, что можно смоделировать 4 атрибутами
Затрачено времени
Будет экзамен?
Дата экзамена
Оценка

Вся избыточность только в случае отсутствия экзамена.

Возможные решения

Между Студент и Предмет две связи с двумя классами-ассоциациями: Записан на курс (Затрачено времени), Есть экзамен (Дата, Оценка)

Не обозначено:

• связь "Есть экзамен" может быть только если есть связь "Записан на курс"
• в связи "Есть экзамен" надо делать атрибуты "Дата" и "Оценка" необязательными [0..1], но тогда возможны 4 варианта (оба незаполнены, заполнена только "Дата", заполнена только "Оценка", оба заполнены), а допустимы - только первый и последний 

Может быть ввести отдельный класс - Экзамен - соединив его с классом ассоциацией Изучение - 1 ко многим, то есть фиксируется не одна а несколько попыток сдачи экзамена. Экзамен класс который как мы помним определяется в том момент когда Студент записывается на Предмет и тогда как-то определяется нужно ли ему сдавать экзамен или достаточно просто изучить предмет

Это уже другая предметная область, для неё и другое решение

Не обозначено:

• связь "Есть экзамен" может быть только если есть связь "Записан на курс"

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

• в связи "Есть экзамен" надо делать атрибуты "Дата" и "Оценка" необязательными [0..1], но тогда возможны 4 варианта (оба незаполнены, заполнена только "Дата", заполнена только "Оценка", оба заполнены), а допустимы - только первый и последний 

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

[/list]Это уже другая предметная область, для неё и другое решение

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