Форум Сообщества Аналитиков
Общий раздел => ПО Аналитика => Тема начата: Vadim от 16 Ноября 2017, 15:48:48
-
Версия MagicDraw 16.5. Не могу создать связь подкласс-суперкласс, если суперкласс - класс-ассоциация, а подкласс - просто класс (не ассоциация).
Если пытаюсь перенести уже созданную (между классом и классом) связь - выдает сообщение-предупреждение: "Между этими элементами отношения заблокированы или не разрешаются".
Может есть какой-то вариант?
Кстати в обратную сторону сделать класс-ассоциацию подклассом просто класса - работает!
-
Вопрос, конечно, не по адресу. Это нужно вендору задавать. Но, думаю стоит посмотреть на стандарт UML, является ли такое отношение допустимым как синтаксически, так и семантически.
Класс ассоциация - это очень близкий аналог таблицы связи в базах данных, которая используется для устранение неспецифичной для реляционной модели связи многие-ко-многим. Что-то не могу себе представить потребность создание категориального кластера, в которой порождающей сущностью будет по сути производная от отношения двух других сушностей.
Можно рассмотреть пример подобной конструкции?
-
Вопрос, конечно, не по адресу. Это нужно вендору задавать.
Ну зачем уж сразу вендору, здесь могут быть те, кто реально поможет.
Но, думаю стоит посмотреть на стандарт UML, является ли такое отношение допустимым как синтаксически, так и семантически.
В стандарте класс-ассоциация не имеет каких-нибудь ограничений, которые мешают быть участником обобщения с любой из сторон.
Класс ассоциация - это очень близкий аналог таблицы связи в базах данных, которая используется для устранение неспецифичной для реляционной модели связи многие-ко-многим.
Скорее ассоциация многие-ко-многим - это очень близкий аналог таблицы связи в базах данных. А класс-ассоциация почти всегда ассоциация многие-ко-многим.
Что-то не могу себе представить потребность создание категориального кластера, в которой порождающей сущностью будет по сути производная от отношения двух других сушностей.
Можно рассмотреть пример подобной конструкции?
Студенты изучают Предметы (ассоциация многие-ко-многим). Надо бы зафиксировать сколько времени Студент потратил на Предмет (ассоциация переходит в класс-ассоциацию - нужен атрибут). Некоторые Студенты по некоторым Предметам уже сдали экзамен: есть дата и оценка (а вот тут и нужен подкласс "Сдан экзамен")
-
Версия MagicDraw 16.5. Не могу создать связь подкласс-суперкласс, если суперкласс - класс-ассоциация, а подкласс - просто класс (не ассоциация).
Если пытаюсь перенести уже созданную (между классом и классом) связь - выдает сообщение-предупреждение: "Между этими элементами отношения заблокированы или не разрешаются".
Может есть какой-то вариант?
Кстати в обратную сторону сделать класс-ассоциацию подклассом просто класса - работает!
Если мы верим в принцип Лизковой, то подкласс класса ассоциации -- не просто класс, но и [класс] ассоциация. В каноническом RUPовом примере наследник явно обозначен как класс ассоциация (хотя, там это оправдано по смыслу).
(http://dl.khadi.kharkov.ua/pluginfile.php/22986/mod_page/content/1/LR_new/LR7.files/image007.png)
Может быть, создатели MagicDraw хотят, чтобы и Вы явно указывали наследника как класс ассоциацию.
В обратную сторону происходит усложнение предка в наследнике. От обычного класса берутся атрибуты, операции, связи. К ним добавляется всё то, что доопределено в наследнике.
-
Студенты изучают Предметы (ассоциация многие-ко-многим). Надо бы зафиксировать сколько времени Студент потратил на Предмет (ассоциация переходит в класс-ассоциацию - нужен атрибут). Некоторые Студенты по некоторым Предметам уже сдали экзамен: есть дата и оценка (а вот тут и нужен подкласс "Сдан экзамен")
Только если студенты сдают по предмету один единственный экзамен (или другое аттестационное мероприятие). Не очень жизненная ситуация, многие предметы имеют одновременно зачет и экзамен, а также несколько зачетов и экзаменов, правда не в одном семестре.
-
Если мы верим в принцип Лизковой, то подкласс класса ассоциации -- не просто класс, но и [класс] ассоциация.
Верим, поэтому конечно "подкласс класса ассоциации -- не просто класс, но и [класс] ассоциация", но это необязательно обозначать на диаграмме, если у этой ассоциации нет ничего нового, по сравнению с исходной.
Кстати "Лизковой" - это здорово, сразу видно, что речь идет о женщине, а то некоторые об этом забывают (а то и не знали никогда).
В каноническом RUPовом примере наследник явно обозначен как класс ассоциация (хотя, там это оправдано по смыслу).
А вот здесь есть новое, поэтому изображение ассоциации на диаграмме оправдано (но это выбор не инструмента, а пользователя, который, правда ошибся - 0..4 не может наследовать 0..2)
Может быть, создатели MagicDraw хотят, чтобы и Вы явно указывали наследника как класс ассоциацию.
Так они могут захотеть чтобы я и остальные наследуемые свойства указывал - какая тогда выгода от такого изображения наследования
В обратную сторону происходит усложнение предка в наследнике. От обычного класса берутся атрибуты, операции, связи. К ним добавляется всё то, что доопределено в наследнике.
В наследнике доопределяется только то, что связано с его "классовой" сутью, поэтому на диаграмме отображается только класс (отображая и ассоциацию, что можно при ней указать - или ничего, или повторить то, что на родительской)
-
Только если студенты сдают по предмету один единственный экзамен (или другое аттестационное мероприятие). Не очень жизненная ситуация, многие предметы имеют одновременно зачет и экзамен, а также несколько зачетов и экзаменов, правда не в одном семестре.
Так ситуации ещё разнообразнее: есть/нет экзамен, есть/нет зачет, если есть экзамен (зачет), то он уже был/не был. Если каждый подкласс сопровождать изображением ассоциации - очень запутанная диаграмма.
-
Так ситуации ещё разнообразнее: есть/нет экзамен, есть/нет зачет, если есть экзамен (зачет), то он уже был/не был. Если каждый подкласс сопровождать изображением ассоциации - очень запутанная диаграмма.
Ничего не понял, если честно :)
-
Ничего не понял, если честно :)
С точки зрения экзамена изучение разбивается на 2 подкласса: "с экзаменом" и "без экзамена". "С экзаменом" тоже разбивается на 2 подкласса: "Экзамен сдавался" (с атрибутами "дата" и "оценка") и "Экзамен не сдавался". С точки зрения зачета - аналогично (и независимо?!).
-
С точки зрения экзамена изучение разбивается на 2 подкласса: "с экзаменом" и "без экзамена". "С экзаменом" тоже разбивается на 2 подкласса: "Экзамен сдавался" (с атрибутами "дата" и "оценка") и "Экзамен не сдавался". С точки зрения зачета - аналогично (и независимо?!).
Что разбивается на подклассы? Класс -ассоциации? Зачем, класс ассоциации имеет четкое назначение, в случае многозначности связи студент- дисциплина - лучше и правильнее использовать отдельный класс, в тернарой ассоциации или в двух бинарных кмк
-
Верим, поэтому конечно "подкласс класса ассоциации -- не просто класс, но и [класс] ассоциация", но это необязательно обозначать на диаграмме, если у этой ассоциации нет ничего нового, по сравнению с исходной.
Если читать стандарт UML 2.5 буквально, то в 11.5.4 (стр. 200) описано как должен изображаться класс ассоциации. И там ничего не говорится о том, что наследование делает какие-то элементы нотации класса ассоциации необязательными. Интересно, что класс ассоциации единый элемент модели, но изображается сразу тремя графическими конструкциями: линией ассоциации (или "ромбиком с лучами", если она n-арная) + пунктирчиком + "висюлькой" класса. И обобщение, по идее, можно рисовать, стартуя от любой части, и финишируя в любой части.
Кстати "Лизковой" - это здорово, сразу видно, что речь идет о женщине, а то некоторые об этом забывают (а то и не знали никогда)
Может быть тут правильнее "принцип Лисковы" (полагая, что Liskov -- Лискова).
А вот Рамбо не верит в LSP. И нам не велит.) [Upd: Перепутало Рамбо с Бертраном Мейером. Да и тот, не то, чтобы не верит в LSP, просто не считает его чем-то значительным и связанным именно с Лисков.] Какой-то зловред вроде него включил в стандарт "isSubstitutable"-свойство обобщения (9.2.3.2), указывающее подчиняется ли наследник LSP или нет.
А вот здесь есть новое, поэтому изображение ассоциации на диаграмме оправдано (но это выбор не инструмента, а пользователя, который, правда ошибся - 0..4 не может наследовать 0..2)
Тут, кстати, интересно разобрать. Экземпляром ассоциации является линк (соединение) у которого нет мощности. LSP оперирует экземплярами.
Так они могут захотеть чтобы я и остальные наследуемые свойства указывал - какая тогда выгода от такого изображения наследования
Ну, линия ассоциации, "пунктирчик" и "висюлька" -- это всё один элемент модели, см. выше. Нигде явно не сказано, что можно лениться и частично его рисовать. Такая вот umlьная "троица".
В наследнике доопределяется только то, что связано с его "классовой" сутью, поэтому на диаграмме отображается только класс (отображая и ассоциацию, что можно при ней указать - или ничего, или повторить то, что на родительской)
Здесь снова (как, может помните, на диаграммах состояний) сталкиваемся с желанием сделать каждый визуальный элемент отдельным элементом модели. А стандарт не велит [пока].
-
Вот предметная область:
Студенты изучают Предметы (ассоциация многие-ко-многим). Надо бы зафиксировать сколько времени Студент потратил на Предмет (ассоциация переходит в класс-ассоциацию - нужен атрибут). Некоторые Студенты по некоторым Предметам уже сдали экзамен: есть дата и оценка (а вот тут и нужен подкласс "Сдан экзамен")
С точки зрения экзамена изучение разбивается на 2 подкласса: "с экзаменом" и "без экзамена". "С экзаменом" тоже разбивается на 2 подкласса: "Экзамен сдавался" (с атрибутами "дата" и "оценка") и "Экзамен не сдавался". С точки зрения зачета - аналогично (и независимо?!).
Во вложении - что от меня требует MagicDraw 16.5. (и это только по экзаменам, без зачетов - зачеты потребуют ещё 4 классов-ассоциаций). Картинка не смотрится. Другие инструменты (ЕА) дают изобразить подчинение через подчинение классов классу-ассоциации и картинка смотрится.
-
Вот предметная область:
Пожалуй без описания задачи, Ваша диаграмма бесполезна для осмысления. Но на вскидку мне кажется странным, что между Студентом и Предметом возможны сразу 5 видов отношений одновременно, даже и взаимоисключающих.
А картинка в ЕА какая?
-
Но на вскидку мне кажется странным, что между Студентом и Предметом возможны сразу 5 видов отношений одновременно, даже и взаимоисключающих.
Отношение одно, остальные 4 - его вариации.
А картинка в ЕА какая?
Во вложении
-
Если что, мне розовая диаграмма кажется симпатичнее чем серая. Только бы редефайнов навставлять и наследование как-нибудь позамысловатее -- начинать от линий ассоциации.) На серой рука тянется объявить, что наследование подчиняется "принципу Рамбо" и считать, что наследники наследуют от класса ассоциации только классовую часть.
А решение с одним классом ассоциацией, у которого опциональные поля и составные части, рассматривалось?
-
Отношение одно, остальные 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]Это уже другая предметная область, для неё и другое решение
Я не нашел правила, что студент может сдать экзамен единожды в описании предметной области. Мой опыт убеждает меня об обратном :)