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

Общий раздел => Примеры => Задачи студентов => Тема начата: b099ard от 25 Апреля 2012, 11:39:06

Название: Отношение между классами
Отправлено: b099ard от 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 является шаблоном. Как это изобразить? Можно ли спроектировать эту зависимость без использования шаблона? Как?

 (http://imglink.ru/pictures/25-04-12/8d8718cf66811ac4c354db1fe04202c9.jpg) (http://imglink.ru)
Название: Re: Отношение между классами
Отправлено: Galogen от 25 Апреля 2012, 14:02:54
не знаю, что автор пытался изобразить. но он допустил грубейшую ошибку.

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

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

кстати AbstractBase - это абстрактный класс? Если да, то не понятно экземпляр какого класса будет содержаться в атрибуте Data класса Concretedata
Название: Re: Отношение между классами
Отправлено: Thyestes от 25 Апреля 2012, 16:03:28
Цитировать
класс ConecreteData является шаблоном. Как это изобразить

В UML существует несколько разновидностей класса: интерфейс, шаблон, утилита и др.
Для указания вида класса в UML введено понятие стереотипа (stereotype). Стереотип как бы определяет подтип некого глобального типа Класс. Соответственно, классы-интерфейсы имеют стереотип "interface", а классы-утилиты - "utility". Существует стандартный набор стереотипов, который, при необходимости, можно расширять.
Название: Re: Отношение между классами
Отправлено: Galogen от 25 Апреля 2012, 18:14:32
Соглашусь по всем разве кроме шаблонов. Тут следует понять, что автор под этим понимает. Возможно он понимает template/ UML имеет средства выражения для этого отличные от стереотипов. т.к. они совершенно иную задачу выполняют
Название: Re: Отношение между классами
Отправлено: b099ard от 25 Апреля 2012, 18:28:49
Добрый день.
С шаблонами я разобрался. Под шаблонами я подразумевал параметризованный класс.

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

Ошибка в том что шаблоны не могут наследоваться, но я не знаю как изобразить эту схему без наследования шаблонов.(http://www.kolobok.us/smiles/madhouse/dash2.gif)

 (http://imglink.ru/pictures/25-04-12/a75acbbc3a21c0ff3eb7803adbae969e.jpg) (http://imglink.ru)
Название: Re: Отношение между классами
Отправлено: b099ard от 26 Апреля 2012, 15:18:42
В общем кому интересно. Для такого отношения используется слово "bind".

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

Лучше рисовать, чем писать ;) Наверняка в вашей галактике это понимают как ни в какой иной.
Название: Re: Отношение между классами
Отправлено: [прилетело НЛО и...] от 16 Сентября 2017, 12:53:22
Композиция не тождественна связям металлов в составе сплава.
Можно представить, что Группа -- это часть Рисунка, а частью Группы является (другой) Рисунок. Композиция/агрегация не накладывает ограничения на сами классы и связи между ними. Накладываются ограничения на соединения между экземплярами классов, связанных композицией/агрегацией. Правда, мощности всё же надо указывать верно, чтобы не возникало противоречий.
Название: Re: Отношение между классами
Отправлено: Galogen от 17 Сентября 2017, 00:53:14
Композиция не тождественна связям металлов в составе сплава.
Кто это утверждает?
Название: Re: Отношение между классами
Отправлено: [прилетело НЛО и...] от 17 Сентября 2017, 02:19:00
Я утверждаю, что нетождественная, т. е. обращаю внимание на то, что композицией могут быть промоделированы более "слабые" связи, чем связи внутри сплава. Пример был приведён.
Название: Re: Отношение между классами
Отправлено: Galogen от 17 Сентября 2017, 19:42:19
Я утверждаю, что нетождественная, т. е. обращаю внимание на то, что композицией могут быть промоделированы более "слабые" связи, чем связи внутри сплава. Пример был приведён.
Правильно ли я понимаю, что композиция мало отличается от агрегации? Композиция в ООП - это не композит в реальном мире, а агрегация - это вовсе не про агрегат?
Название: Re: Отношение между классами
Отправлено: [прилетело НЛО и...] от 17 Сентября 2017, 21:57:04
По UML-ному стандарту есть два отличия (указанные мною в другой ветке).
UMLьная агрегация говорит о том, что объект-целое группирует объекты-части. Объектам-частям можно входить в несколько групп (если позволяет мощность полюса). Существование объектов-частей не [очень] зависит от существования объектов-групп.
Полисемия зашумляет обсуждение. Мои извинения за то, что не разобрало в каком ключе тут разбирают композиции и агрегации.
Название: Re: Отношение между классами
Отправлено: Galogen от 17 Сентября 2017, 22:26:22
По UML-ному стандарту есть два отличия (указанные мною в другой ветке).
UMLьная агрегация говорит о том, что объект-целое группирует объекты-части. Объектам-частям можно входить в несколько групп (если позволяет мощность полюса). Существование объектов-частей не [очень] зависит от существования объектов-групп.
Полисемия зашумляет обсуждение. Мои извинения за то, что не разобрало в каком ключе тут разбирают композиции и агрегации.
Полисемия?? Настройте уже свой прибор на порядочный русский :)

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

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

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

В такой концепции возможно, колеса должны просто идентифицироваться тем автомобилем, с которым они были собраны при комплектации. Т.е. до сборки, колеса шли как отдельные, после сборки стали идентифицироваться иначе. Хотя наверняка у колеса есть свой ID, иначе что-то криминалисты распутывали.
Название: Re: Отношение между классами
Отправлено: [прилетело НЛО и...] от 18 Сентября 2017, 21:37:05
Колёса и машины были приведены как иллюстрация -- пример, подкреплённый авторитетом, и выдержавший[?] проверку в редакции Journal of Object Technology. Если пример не годится, то можно подобрать более наглядную и понятную иллюстрацию вместо того, чтобы закапываться в учёт колёс и авто.
Вопрос идентификации решается в UML другими средствами. У атрибутов, входящих в состав идентификатора, ставится пометка {id}. UMLьная композиция (и агрегация) не указывает на то, как именно идентифицируются объекты-части.
Заявка на другой пример: Составное3ДТело◆-0..1---2..*-Простое3ДТело. Тут из двух или более кубов можно создать композит. Кубы до создания композита могли существовать сами по себе как простые тела. Перед уничтожением композита все его кубы, кроме обязательных двух могут сбежать. Двум, как древнеегипетским рабам, придётся сопроводить композита-фараона в долину мертвых.
Название: Re: Отношение между классами
Отправлено: [прилетело НЛО и...] от 19 Сентября 2017, 21:14:35
Или вот другая история.
Сначала на нашей планете думали, что: Человек◆-1---1..2-Почка.
Потом прилетели пришельцы и научили трансплантологии. Выяснилось, что:  Человек◆-0..1---0..2-Почка (с двумя почкам рождается, с 1-2 живёт, из трупа можно вырезать все и пересадить, до пересадки не более чем 72 часа почка живет сама по себе в холодильнике). Трансплантологи подзуживают, что на самом деле Человек◆-0..1---0..3-Почка, так как можно вшить доп. почку к имеющимся двум, и такое было. На нашей планете.
Название: Re: Отношение между классами
Отправлено: Galogen от 19 Сентября 2017, 22:36:48
А чего композиция? Уж тогда агрегация :)
Название: Re: Отношение между классами
Отправлено: [прилетело НЛО и...] от 21 Сентября 2017, 14:08:39
Агрегацию нарисуем, когда почка станет искусственной, т. е. "имплантируемым в организм гемодиализным аппаратом".
Сейчас композиция показывает, что, например, при кремации невырезанные почки сгорают вместе с трупом.
[Б-р-р. Улетаю. Тема зашла куда-то не туда.]
Название: Re: Отношение между классами
Отправлено: Galogen от 21 Сентября 2017, 17:18:33
Да, оставим почки человеку.