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

×


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



Re: внутренняя структура Ответ #1 : 16 Ноября 2010, 14:36:02
А что, это одно и то же колесо? Чем вызвана необходимость такой абстракции - тем, что гончарный круг и вороток колодца имеют круглую форму?

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

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: внутренняя структура Ответ #2 : 16 Ноября 2010, 15:11:13
Нет это в принципе одно и тоже, деревянное колесо, одинакового диаметра, одинаковой толщины, с одинаковым отверстием по середине (это взаимозаменяемые детали, объекты одного класса). В зависимости от того где это колесо установлено оно будет играть разные роли, в нашем случае либо Вороток либо Круг



Re: внутренняя структура Ответ #3 : 17 Ноября 2010, 15:17:45
Цитировать
Как мне отразить, что в колодце Колесо в роли Воротка, а в гончарной установки, роль гончарного круга?
То, что колесо выступает в разных ролях уже отражено, просто эти роли называются не "Вороток" и "Круг", а "колесо колодца" и "колесо гончарной установки".
Добавлю сложности (не с целью затруднить, а с надеждой прояснить): пусть колесо в роли "Вороток" ("колесо колодца") должно описываться количеством ручек (штуки за которые крутят), а колесо в роли "Круг" ("колесо гончарной установки") должно описываться направлением вращения (гончары бывают правши и левши).

Цитировать
НА диаграмме роль колесо:Колесо, одинаково для всех потомков (наследуется от Сооружения).
это есть инструменты такие умные, что понимают распостранение композиции на подклассы, да еще знают про альтернативную нотацию для композиции? Если да, то назовите такие инструменты, пожалуйста.



Re: внутренняя структура Ответ #4 : 18 Ноября 2010, 07:36:10
То, что колесо выступает в разных ролях уже отражено, просто эти роли называются не "Вороток" и "Круг", а "колесо колодца" и "колесо гончарной установки".
Если смотреть на диаграмму как есть, то [Имя роли]: [Тип] это колесо:Колесо т.е. роль одинаковая.

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



Re: внутренняя структура Ответ #5 : 18 Ноября 2010, 11:25:02
Спасибо за
Цитировать
"IBM Rational Software Architect 7.0
мне именно
Цитировать
распространять композицию на подклассы
и требовалось, только хотелось уточнить: инструмент просто разрешает нарисовать какую угодно структуру подкласса или предлагает взять готовые элементы структуры класса (композицию с "колесо") и отбразить их в той или иной нотации (в виде внутренней структуры, беря в качестве [Тип] "Колесо" - имя Класса, в качестве [Имя роли] "колесо" - имя полюса, которое по умолчанию совпадает с именем класса, только первая буква в нижнем регистре)?

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



Re: внутренняя структура Ответ #6 : 18 Ноября 2010, 12:00:48
Сложно объяснить понятней было бы самому в инструменте попробовать что хотите, но попробую.
инструмент просто разрешает нарисовать какую угодно структуру подкласса или предлагает взять готовые элементы структуры класса
Инструмент отображает готовую (часть) структуру, т.е. если вы нарисовали, что в класс композитно входит другой класс, с третьим классом он связан ассоциацией, то на внутренней структуре отобразится две части (композиция отобразится как внутренняя часть, а ассоциация как внешняя часть(пунктирный контур)), то есть части он рисует автоматически, а соединители между частями вы сами прорисовываете и типизируете. 

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



Re: внутренняя структура Ответ #7 : 18 Ноября 2010, 14:47:42
Может быть странный вопрос,но зачем делать простое сложным?

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

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



Re: внутренняя структура Ответ #8 : 18 Ноября 2010, 15:12:42
Эдуард, вы задаете тот же вопрос, что и greesha, на который я думал что ответил.
Может я не очень удачную аналогию привел, но у нас в действительности есть один класс который в зависимости от места установки будет играть разные роли.
Колесо это не нечто круглое вращающееся, это определенное колесо (деревянное, определенного диаметра и толщины  и.т.п). Могу на стену повесить, и тогда уже роль украшения будет играть. Гончарное колесо я могу заменить на колодезное или снять со стены. Это даже не наследники, это все объекты одного класса.



Re: внутренняя структура Ответ #9 : 18 Ноября 2010, 17:12:14
Эдуард, в
Колесо это не нечто круглое вращающееся, это определенное колесо (деревянное, определенного диаметра и толщины  и.т.п). Могу на стену повесить, и тогда уже роль украшения будет играть. Гончарное колесо я могу заменить на колодезное или снять со стены. Это даже не наследники, это все объекты одного класса.
Понимаете, вы как-то не от того идете. Типа у меня вот есть реализация, а тем я под нее хочу подстроить некую модель. Причем под реализацией у вас какое-то свое понимание, которое но нас не доходит.

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



Re: внутренняя структура Ответ #10 : 19 Ноября 2010, 09:41:25
А следовательно беря гончарный круг - мы подразумеваем что можем использовать его как колесо везде где такое колесо нужно. Правильная ли трактовка для вашего случая?

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



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



Re: внутренняя структура Ответ #12 : 19 Ноября 2010, 10:50:50
Эдуард, вы задаете тот же вопрос, что и greesha, на который я думал что ответил.
Может я не очень удачную аналогию привел, но у нас в действительности есть один класс который в зависимости от места установки будет играть разные роли.

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

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

Спасибо.



Re: внутренняя структура Ответ #13 : 19 Ноября 2010, 11:34:01
Давайте без аналогий. Ответьте на два простых вопроса:
1. Что это в действительности за объект?
2. Какую задачу вы собираетесь решать?
Спасибо.
В предыдущем посте я уже перешел от аналогий к реальной задачи.
Это Контроллер для управления технологическими объектами. В одном случае играет роль информационного обмена по полевой шине, в другой- обмен данными между сетями (разного уровня), в третьей исполняют прикладные пользовательские задачи , принимают и генерируют управляющие сигналы.

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



Re: внутренняя структура Ответ #14 : 19 Ноября 2010, 11:42:58
Как описать эту ситуацию?
Один и тот же класс в контексте устройства выполняет разные роли, в целом оставаясь тем же самым?
Возможно для этого следует сделать параметризированную кооперацию. Лучше всего ответит Денис Иванов.

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

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




 

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