Форум Сообщества Аналитиков

×


Отношение между классами(Прочитано 6038 раз)
Отношение между классами : 25 Апреля 2012, 11:39:06
Добрый день. Я учусь в институте и мне дали задание составить диаграмму UML.

Проблема в следующем:

Есть три класса:

Класс A, B, C

Все три класса наследники одного базового класса AbstractBase.
Класс AbstractBase является часть класса ConecreteData который содержит еще один член m_A простого типа.

Единственное отличие наследников A,B, C друг от друга это поле Data. в классе A оно имеет размер byte. В классе B поле содержит объект ConecreteData инициированного с классом типа A в члене AbstractBase. Соответственно в классе С
член с типом AbstractBase на самом деле является типом B.

Примерную UML диаграмму можно увидеть в приложении.
Как мне кажется она ошибочна, на ней не видно того что класс ConecreteData является шаблоном. Как это изобразить? Можно ли спроектировать эту зависимость без использования шаблона? Как?





Re: Отношение между классами Ответ #1 : 25 Апреля 2012, 14:02:54
не знаю, что автор пытался изобразить. но он допустил грубейшую ошибку.

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

согласно принципу Лисков - каждый экземпляр класса В и С - есть класс AbstractBase, который является частью класса Concretedata, который почему-то является часть классов В и С

кстати AbstractBase - это абстрактный класс? Если да, то не понятно экземпляр какого класса будет содержаться в атрибуте Data класса Concretedata



Re: Отношение между классами Ответ #2 : 25 Апреля 2012, 16:03:28
Цитировать
класс ConecreteData является шаблоном. Как это изобразить

В UML существует несколько разновидностей класса: интерфейс, шаблон, утилита и др.
Для указания вида класса в UML введено понятие стереотипа (stereotype). Стереотип как бы определяет подтип некого глобального типа Класс. Соответственно, классы-интерфейсы имеют стереотип "interface", а классы-утилиты - "utility". Существует стандартный набор стереотипов, который, при необходимости, можно расширять.
«Сделай первый шаг, и ты поймешь, что не все так страшно.»
-- L. A. Seneca --



Re: Отношение между классами Ответ #3 : 25 Апреля 2012, 18:14:32
Соглашусь по всем разве кроме шаблонов. Тут следует понять, что автор под этим понимает. Возможно он понимает template/ UML имеет средства выражения для этого отличные от стереотипов. т.к. они совершенно иную задачу выполняют



Re: Отношение между классами Ответ #4 : 25 Апреля 2012, 18:28:49
Добрый день.
С шаблонами я разобрался. Под шаблонами я подразумевал параметризованный класс.

Вот еще одна версия того что я хочу изобразить, но опять же с ошибкой.

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

« Последнее редактирование: 25 Апреля 2012, 19:17:02 от b099ard »



Re: Отношение между классами Ответ #5 : 26 Апреля 2012, 15:18:42
В общем кому интересно. Для такого отношения используется слово "bind".

Всем спасибо.



Re: Отношение между классами Ответ #6 : 14 Сентября 2017, 22:30:05
Цитировать
композиция - связь несимметричная, это означает...
... это означает, что нельзя нарисовать ромбики на обоих концах одной композиции.
В общем случае, ошибки, на которую указано, нет. Экземпляр B может быть целым для экземпляра ConcreteData. Этот экземпляр ConcreteData может быть целым для другого экземпляра В. В общем случае между классами A и B можно нарисовать две композиции: у одной ромб рядом с A, у другой -- рядом с B. 
[...и улетело НЛО.]



Re: Отношение между классами Ответ #7 : 15 Сентября 2017, 22:56:34
... это означает, что нельзя нарисовать ромбики на обоих концах одной композиции.
В общем случае, ошибки, на которую указано, нет. Экземпляр B может быть целым для экземпляра ConcreteData. Этот экземпляр ConcreteData может быть целым для другого экземпляра В. В общем случае между классами A и B можно нарисовать две композиции: у одной ромб рядом с A, у другой -- рядом с B. 
Хорошо.
Есть объект типа Металл - в смысле химэлемент (медь) и есть объект типа Сплав (Мельхиор)
т.е. объект типа Сплав (Мельхиор) может стать частью объекта типа Металл???

Лучше рисовать, чем писать ;) Наверняка в вашей галактике это понимают как ни в какой иной.



Re: Отношение между классами Ответ #8 : 16 Сентября 2017, 12:53:22
Композиция не тождественна связям металлов в составе сплава.
Можно представить, что Группа -- это часть Рисунка, а частью Группы является (другой) Рисунок. Композиция/агрегация не накладывает ограничения на сами классы и связи между ними. Накладываются ограничения на соединения между экземплярами классов, связанных композицией/агрегацией. Правда, мощности всё же надо указывать верно, чтобы не возникало противоречий.
[...и улетело НЛО.]



Re: Отношение между классами Ответ #9 : 17 Сентября 2017, 00:53:14
Композиция не тождественна связям металлов в составе сплава.
Кто это утверждает?



Re: Отношение между классами Ответ #10 : 17 Сентября 2017, 02:19:00
Я утверждаю, что нетождественная, т. е. обращаю внимание на то, что композицией могут быть промоделированы более "слабые" связи, чем связи внутри сплава. Пример был приведён.
[...и улетело НЛО.]



Re: Отношение между классами Ответ #11 : 17 Сентября 2017, 19:42:19
Я утверждаю, что нетождественная, т. е. обращаю внимание на то, что композицией могут быть промоделированы более "слабые" связи, чем связи внутри сплава. Пример был приведён.
Правильно ли я понимаю, что композиция мало отличается от агрегации? Композиция в ООП - это не композит в реальном мире, а агрегация - это вовсе не про агрегат?



Re: Отношение между классами Ответ #12 : 17 Сентября 2017, 21:57:04
По UML-ному стандарту есть два отличия (указанные мною в другой ветке).
UMLьная агрегация говорит о том, что объект-целое группирует объекты-части. Объектам-частям можно входить в несколько групп (если позволяет мощность полюса). Существование объектов-частей не [очень] зависит от существования объектов-групп.
Полисемия зашумляет обсуждение. Мои извинения за то, что не разобрало в каком ключе тут разбирают композиции и агрегации.
[...и улетело НЛО.]



Re: Отношение между классами Ответ #13 : 17 Сентября 2017, 22:26:22
По UML-ному стандарту есть два отличия (указанные мною в другой ветке).
UMLьная агрегация говорит о том, что объект-целое группирует объекты-части. Объектам-частям можно входить в несколько групп (если позволяет мощность полюса). Существование объектов-частей не [очень] зависит от существования объектов-групп.
Полисемия зашумляет обсуждение. Мои извинения за то, что не разобрало в каком ключе тут разбирают композиции и агрегации.
Полисемия?? Настройте уже свой прибор на порядочный русский :)

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

В концепции реального мира, часть всегда (одновременно) принадлежит одной части целого, кроме вопросов классификации, ну например при описании систем автомобиля можно предположить, что зажигание является часть системы электроснабжения, системы топливной, двигательной и т.п. Это что тогда, агрегация, композиция или и то и другое?

Ну, мы на форуме аналитиков, я сюда вас клоню :)



Re: Отношение между классами Ответ #14 : 17 Сентября 2017, 22:47:32
Сиамские близнецы могут разделять общую часть тела.)
Модель лишь с некоторой достаточной степенью точности описывает реальное положение дел. Если модель формальна, то в ней используются термины, которые в некоторой степени идеальны, вроде математических терминов.
Я понимаю, что есть разные аспекты:
1) смысл, вкладываемый в термины, которые используются при моделировании;
2) адекватность моделей реальному положению дел.
Готово обсуждать первый. Со вторым сложнее.
В моей тарелке и зажигания-то нет, летаю на чистой возобновляемой энергии. И как там с колёсами дело обстоит, тоже затрудняюсь. Есть не-бок-овские примеры, где колёса к авто крепят агрегацией. Но это, мне кажется, мало говорит о том, как правильнее крепить, а скорее указывает на то, что для одних задач (где важно сжигать авто вместе с его колёсами) одна модель подойдёт лучше другой.
[...и улетело НЛО.]




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19