Добрый день. Я учусь в институте и мне дали задание составить диаграмму UML.

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

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

Класс A, B, C

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

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

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

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

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

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

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

класс ConecreteData является шаблоном. Как это изобразить

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

Соглашусь по всем разве кроме шаблонов. Тут следует понять, что автор под этим понимает. Возможно он понимает template/ UML имеет средства выражения для этого отличные от стереотипов. т.к. они совершенно иную задачу выполняют

Добрый день.
С шаблонами я разобрался. Под шаблонами я подразумевал параметризованный класс.

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

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

В общем кому интересно. Для такого отношения используется слово "bind".

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

композиция - связь несимметричная, это означает...

... это означает, что нельзя нарисовать ромбики на обоих концах одной композиции.
В общем случае, ошибки, на которую указано, нет. Экземпляр B может быть целым для экземпляра ConcreteData. Этот экземпляр ConcreteData может быть целым для другого экземпляра В. В общем случае между классами A и B можно нарисовать две композиции: у одной ромб рядом с A, у другой -- рядом с B. 

... это означает, что нельзя нарисовать ромбики на обоих концах одной композиции.
В общем случае, ошибки, на которую указано, нет. Экземпляр B может быть целым для экземпляра ConcreteData. Этот экземпляр ConcreteData может быть целым для другого экземпляра В. В общем случае между классами A и B можно нарисовать две композиции: у одной ромб рядом с A, у другой -- рядом с B. 

Хорошо.
Есть объект типа Металл - в смысле химэлемент (медь) и есть объект типа Сплав (Мельхиор)
т.е. объект типа Сплав (Мельхиор) может стать частью объекта типа Металл???

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

Композиция не тождественна связям металлов в составе сплава.
Можно представить, что Группа -- это часть Рисунка, а частью Группы является (другой) Рисунок. Композиция/агрегация не накладывает ограничения на сами классы и связи между ними. Накладываются ограничения на соединения между экземплярами классов, связанных композицией/агрегацией. Правда, мощности всё же надо указывать верно, чтобы не возникало противоречий.

Композиция не тождественна связям металлов в составе сплава.

Кто это утверждает?

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

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

Правильно ли я понимаю, что композиция мало отличается от агрегации? Композиция в ООП - это не композит в реальном мире, а агрегация - это вовсе не про агрегат?

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

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

Полисемия?? Настройте уже свой прибор на порядочный русский

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

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

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

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