Форум Сообщества Аналитиков
Общий раздел => Примеры => Задачи студентов => Тема начата: 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)
-
не знаю, что автор пытался изобразить. но он допустил грубейшую ошибку.
композиция - связь несимметричная, это означает, что част одного не может быть для него и целым.
у автора ровно это и сказано.
согласно принципу Лисков - каждый экземпляр класса В и С - есть класс AbstractBase, который является частью класса Concretedata, который почему-то является часть классов В и С
кстати AbstractBase - это абстрактный класс? Если да, то не понятно экземпляр какого класса будет содержаться в атрибуте Data класса Concretedata
-
класс ConecreteData является шаблоном. Как это изобразить
В UML существует несколько разновидностей класса: интерфейс, шаблон, утилита и др.
Для указания вида класса в UML введено понятие стереотипа (stereotype). Стереотип как бы определяет подтип некого глобального типа Класс. Соответственно, классы-интерфейсы имеют стереотип "interface", а классы-утилиты - "utility". Существует стандартный набор стереотипов, который, при необходимости, можно расширять.
-
Соглашусь по всем разве кроме шаблонов. Тут следует понять, что автор под этим понимает. Возможно он понимает template/ UML имеет средства выражения для этого отличные от стереотипов. т.к. они совершенно иную задачу выполняют
-
Добрый день.
С шаблонами я разобрался. Под шаблонами я подразумевал параметризованный класс.
Вот еще одна версия того что я хочу изобразить, но опять же с ошибкой.
Ошибка в том что шаблоны не могут наследоваться, но я не знаю как изобразить эту схему без наследования шаблонов.(http://www.kolobok.us/smiles/madhouse/dash2.gif)
(http://imglink.ru/pictures/25-04-12/a75acbbc3a21c0ff3eb7803adbae969e.jpg) (http://imglink.ru)
-
В общем кому интересно. Для такого отношения используется слово "bind".
Всем спасибо.
-
композиция - связь несимметричная, это означает...
... это означает, что нельзя нарисовать ромбики на обоих концах одной композиции.
В общем случае, ошибки, на которую указано, нет. Экземпляр B может быть целым для экземпляра ConcreteData. Этот экземпляр ConcreteData может быть целым для другого экземпляра В. В общем случае между классами A и B можно нарисовать две композиции: у одной ромб рядом с A, у другой -- рядом с B.
-
... это означает, что нельзя нарисовать ромбики на обоих концах одной композиции.
В общем случае, ошибки, на которую указано, нет. Экземпляр B может быть целым для экземпляра ConcreteData. Этот экземпляр ConcreteData может быть целым для другого экземпляра В. В общем случае между классами A и B можно нарисовать две композиции: у одной ромб рядом с A, у другой -- рядом с B.
Хорошо.
Есть объект типа Металл - в смысле химэлемент (медь) и есть объект типа Сплав (Мельхиор)
т.е. объект типа Сплав (Мельхиор) может стать частью объекта типа Металл???
Лучше рисовать, чем писать ;) Наверняка в вашей галактике это понимают как ни в какой иной.
-
Композиция не тождественна связям металлов в составе сплава.
Можно представить, что Группа -- это часть Рисунка, а частью Группы является (другой) Рисунок. Композиция/агрегация не накладывает ограничения на сами классы и связи между ними. Накладываются ограничения на соединения между экземплярами классов, связанных композицией/агрегацией. Правда, мощности всё же надо указывать верно, чтобы не возникало противоречий.
-
Композиция не тождественна связям металлов в составе сплава.
Кто это утверждает?
-
Я утверждаю, что нетождественная, т. е. обращаю внимание на то, что композицией могут быть промоделированы более "слабые" связи, чем связи внутри сплава. Пример был приведён.
-
Я утверждаю, что нетождественная, т. е. обращаю внимание на то, что композицией могут быть промоделированы более "слабые" связи, чем связи внутри сплава. Пример был приведён.
Правильно ли я понимаю, что композиция мало отличается от агрегации? Композиция в ООП - это не композит в реальном мире, а агрегация - это вовсе не про агрегат?
-
По UML-ному стандарту есть два отличия (указанные мною в другой ветке).
UMLьная агрегация говорит о том, что объект-целое группирует объекты-части. Объектам-частям можно входить в несколько групп (если позволяет мощность полюса). Существование объектов-частей не [очень] зависит от существования объектов-групп.
Полисемия зашумляет обсуждение. Мои извинения за то, что не разобрало в каком ключе тут разбирают композиции и агрегации.
-
По UML-ному стандарту есть два отличия (указанные мною в другой ветке).
UMLьная агрегация говорит о том, что объект-целое группирует объекты-части. Объектам-частям можно входить в несколько групп (если позволяет мощность полюса). Существование объектов-частей не [очень] зависит от существования объектов-групп.
Полисемия зашумляет обсуждение. Мои извинения за то, что не разобрало в каком ключе тут разбирают композиции и агрегации.
Полисемия?? Настройте уже свой прибор на порядочный русский :)
UML вообще претендует на то, что с его использованием можно производить и описания предметных областей, а не только программные концепции.
В концепции реального мира, часть всегда (одновременно) принадлежит одной части целого, кроме вопросов классификации, ну например при описании систем автомобиля можно предположить, что зажигание является часть системы электроснабжения, системы топливной, двигательной и т.п. Это что тогда, агрегация, композиция или и то и другое?
Ну, мы на форуме аналитиков, я сюда вас клоню :)
-
Сиамские близнецы могут разделять общую часть тела.)
Модель лишь с некоторой достаточной степенью точности описывает реальное положение дел. Если модель формальна, то в ней используются термины, которые в некоторой степени идеальны, вроде математических терминов.
Я понимаю, что есть разные аспекты:
1) смысл, вкладываемый в термины, которые используются при моделировании;
2) адекватность моделей реальному положению дел.
Готово обсуждать первый. Со вторым сложнее.
В моей тарелке и зажигания-то нет, летаю на чистой возобновляемой энергии. И как там с колёсами дело обстоит, тоже затрудняюсь. Есть не-бок-овские примеры, где колёса к авто крепят агрегацией. Но это, мне кажется, мало говорит о том, как правильнее крепить, а скорее указывает на то, что для одних задач (где важно сжигать авто вместе с его колёсами) одна модель подойдёт лучше другой.
-
а скорее указывает на то, что для одних задач (где важно сжигать авто вместе с его колёсами) одна модель подойдёт лучше другой.
Т.е. без контекста не обойтись. Однако в нашем случае мы все-таки говорим не о конкртеной машине и ее конкретных колесах, а об данных (или как тут некто Марк Мельник любит повторят) объектах учета.
В такой концепции возможно, колеса должны просто идентифицироваться тем автомобилем, с которым они были собраны при комплектации. Т.е. до сборки, колеса шли как отдельные, после сборки стали идентифицироваться иначе. Хотя наверняка у колеса есть свой ID, иначе что-то криминалисты распутывали.
-
Колёса и машины были приведены как иллюстрация -- пример, подкреплённый авторитетом, и выдержавший[?] проверку в редакции Journal of Object Technology. Если пример не годится, то можно подобрать более наглядную и понятную иллюстрацию вместо того, чтобы закапываться в учёт колёс и авто.
Вопрос идентификации решается в UML другими средствами. У атрибутов, входящих в состав идентификатора, ставится пометка {id}. UMLьная композиция (и агрегация) не указывает на то, как именно идентифицируются объекты-части.
Заявка на другой пример: Составное3ДТело◆-0..1---2..*-Простое3ДТело. Тут из двух или более кубов можно создать композит. Кубы до создания композита могли существовать сами по себе как простые тела. Перед уничтожением композита все его кубы, кроме обязательных двух могут сбежать. Двум, как древнеегипетским рабам, придётся сопроводить композита-фараона в долину мертвых.
-
Или вот другая история.
Сначала на нашей планете думали, что: Человек◆-1---1..2-Почка.
Потом прилетели пришельцы и научили трансплантологии. Выяснилось, что: Человек◆-0..1---0..2-Почка (с двумя почкам рождается, с 1-2 живёт, из трупа можно вырезать все и пересадить, до пересадки не более чем 72 часа почка живет сама по себе в холодильнике). Трансплантологи подзуживают, что на самом деле Человек◆-0..1---0..3-Почка, так как можно вшить доп. почку к имеющимся двум, и такое было. На нашей планете.
-
А чего композиция? Уж тогда агрегация :)
-
Агрегацию нарисуем, когда почка станет искусственной, т. е. "имплантируемым в организм гемодиализным аппаратом".
Сейчас композиция показывает, что, например, при кремации невырезанные почки сгорают вместе с трупом.
[Б-р-р. Улетаю. Тема зашла куда-то не туда.]
-
Да, оставим почки человеку.