Помогите с пониманием. все было бы хорошо если бы не раскрыл внутреннюю структуру класса.
Вот например есть диаграмма сооружения (см. вложение)
Как мне отразить, что в колодце Колесо в роли Воротка, а в гончарной установки, роль гончарного круга?
НА диаграмме роль колесо:Колесо, одинаково для всех потомков (наследуется от Сооружения).
Что неужели надо рисовать отдельные композиции от Колеса к Колодцу и к Гончарной установки?

А что, это одно и то же колесо? Чем вызвана необходимость такой абстракции - тем, что гончарный круг и вороток колодца имеют круглую форму?

Тогда на этой диаграмме не хватает Солнца, оно тоже круглое.

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

Как мне отразить, что в колодце Колесо в роли Воротка, а в гончарной установки, роль гончарного круга?

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

НА диаграмме роль колесо:Колесо, одинаково для всех потомков (наследуется от Сооружения).

это есть инструменты такие умные, что понимают распостранение композиции на подклассы, да еще знают про альтернативную нотацию для композиции? Если да, то назовите такие инструменты, пожалуйста.

То, что колесо выступает в разных ролях уже отражено, просто эти роли называются не "Вороток" и "Круг", а "колесо колодца" и "колесо гончарной установки".

Если смотреть на диаграмму как есть, то [Имя роли]: [Тип] это колесо:Колесо т.е. роль одинаковая.

это есть инструменты такие умные, что понимают распостранение композиции на подклассы, да еще знают про альтернативную нотацию для композиции? Если да, то назовите такие инструменты, пожалуйста.

А почему не распространять композицию на подклассы? Композицию можно представить атрибутом (в инструменте так и отображается), а атрибуты наследуются (может надо переопределить "колесо" в потомках, но как это делается я не знаю.).
По поводу инструмента это - "IBM Rational Software Architect 7.0" из всех испробованных инструментов наиболее четко соответствует спецификации UML 2.0, но возникают порой трудности (чаще из за недопонимания).

Спасибо за

"IBM Rational Software Architect 7.0

мне именно

распространять композицию на подклассы

и требовалось, только хотелось уточнить: инструмент просто разрешает нарисовать какую угодно структуру подкласса или предлагает взять готовые элементы структуры класса (композицию с "колесо") и отбразить их в той или иной нотации (в виде внутренней структуры, беря в качестве [Тип] "Колесо" - имя Класса, в качестве [Имя роли] "колесо" - имя полюса, которое по умолчанию совпадает с именем класса, только первая буква в нижнем регистре)?

Если смотреть на диаграмму как есть, то [Имя роли]: [Тип] это колесо:Колесо т.е. роль одинаковая

Имена - одинаковые, но сам факт размещения в подклассах предполагает отличия (у вас на диаграмме их нет, но это можно сделать, например только от колесо:Колесо внутри "Колодец" сделать ассоциацию с "Гвоздь").

Сложно объяснить понятней было бы самому в инструменте попробовать что хотите, но попробую.

инструмент просто разрешает нарисовать какую угодно структуру подкласса или предлагает взять готовые элементы структуры класса

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

Имена - одинаковые, но сам факт размещения в подклассах предполагает отличия (у вас на диаграмме их нет, но это можно сделать, например только от колесо:Колесо внутри "Колодец" сделать ассоциацию с "Гвоздь").

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

Может быть странный вопрос,но зачем делать простое сложным?

Неочень понятно, почему колесом обозначаются по сути два разных устройства.
Т.е. все что круглое и вращается - это колесо?
Далее продолжим экзекуцию.
Часы - это сооружение, в котором есть масса шестеренок - это колесо?

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

Эдуард, вы задаете тот же вопрос, что и greesha, на который я думал что ответил.
Может я не очень удачную аналогию привел, но у нас в действительности есть один класс который в зависимости от места установки будет играть разные роли.
Колесо это не нечто круглое вращающееся, это определенное колесо (деревянное, определенного диаметра и толщины  и.т.п). Могу на стену повесить, и тогда уже роль украшения будет играть. Гончарное колесо я могу заменить на колодезное или снять со стены. Это даже не наследники, это все объекты одного класса.

Эдуард, в
Колесо это не нечто круглое вращающееся, это определенное колесо (деревянное, определенного диаметра и толщины  и.т.п). Могу на стену повесить, и тогда уже роль украшения будет играть. Гончарное колесо я могу заменить на колодезное или снять со стены. Это даже не наследники, это все объекты одного класса.

Понимаете, вы как-то не от того идете. Типа у меня вот есть реализация, а тем я под нее хочу подстроить некую модель. Причем под реализацией у вас какое-то свое понимание, которое но нас не доходит.

Почему кто-то в проекте принял решение что у нас есть колесо, которое может быть гончарным кругом и т.п.
Понимаете принцип Лисков никто не отменял. А следовательно беря гончарный круг - мы подразумеваем что можем использовать его как колесо везде где такое колесо нужно. Правильная ли трактовка для вашего случая?

А следовательно беря гончарный круг - мы подразумеваем что можем использовать его как колесо везде где такое колесо нужно. Правильная ли трактовка для вашего случая?

Да беря колесо мы везде его можем использовать где это нужно. Давайте от абстрактного примера я сформулирую конкретную задачу:
У нас есть Универсальный Контроллер, который можно установить в разного типа Устройства.
При установки Контроллер определяет тип устройства и выполняет одну роль (например Шлюз), если он определил другой тип то выполняет другую роль (обработка алгоритма), если определил третий тип то и выполняет третью роль ( управление приводом).
Но Универсальный контроллер это один класс и у него нет потомков, это он один выполняет разные роли в зависимости от места установки.
Как описать эту ситуацию?

Так может и не описывать эти роли классов для ассоциаций? Оставить так, как у Вас есть, а в каждом конкретном классе Устройства добавить метод, который и будет описывать использование атрибута Контроллер для данного класса. Либо добавить этот метод еще в абстрактном классе Устройства и переопределить его в потомках.

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

Давайте без аналогий. Ответьте на два простых вопроса:

1. Что это в действительности за объект?
2. Какую задачу вы собираетесь решать?

Спасибо.

Давайте без аналогий. Ответьте на два простых вопроса:
1. Что это в действительности за объект?
2. Какую задачу вы собираетесь решать?
Спасибо.

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

Так может и не описывать эти роли классов для ассоциаций?
НО мне надо описать деятельность и поведение Контроллера в разных ролях!

Оставить так, как у Вас есть, а в каждом конкретном классе Устройства добавить метод, который и будет описывать использование атрибута Контроллер для данного класса.

Простите не очень понял, это получается всю функциональность переложить на Устройство (поясните пожалуйста вашу идею по подробней)?

Как описать эту ситуацию?

Один и тот же класс в контексте устройства выполняет разные роли, в целом оставаясь тем же самым?
Возможно для этого следует сделать параметризированную кооперацию. Лучше всего ответит Денис Иванов.

С другой стороны  разве это не полиморфизм? то есть Контроллер - абстрактный класс, но и должны быть конкретные классы роли со своим определением абстрактной операции.

Либо иначе. контроллер - как некий интерфейс, который разные устройства реализуют ппо-разному