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

Общий раздел => Примеры => Тема начата: Vadim от 04 Июля 2016, 18:42:23

Название: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: Vadim от 04 Июля 2016, 18:42:23
В процессе проработки http://www.uml2.ru/forum/index.php?topic=6532.msg40739#msg40739 (http://www.uml2.ru/forum/index.php?topic=6532.msg40739#msg40739)всплыл вопрос о лучшем диаграммировании ситуации из вложения.
Все SetGeneralization полные (complete) и непересекающиеся (disjoint).
Недостаток: Transition обобщает IncomingTransition и OutgoingTransition, а на диаграмме этого явно не видно.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: Galogen от 04 Июля 2016, 21:45:00
Ссылка у вас ведет почему-то на ftp. Может быть Вы тезисно повторить исходную проблему?
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: Vadim от 05 Июля 2016, 08:34:45
Ссылку поправил, но по ней можно не ходить - это не принципиально.
Принципиально - уменьшить недостатки диаграммы.
Например диаграмма во вложении частично преодолевает указанный в исходном топике недостаток (явно видно, что Transition обобщает IncomingTransition), но вносит новый недостаток - теряется симметричность диаграммы, хотя исходная проблема явно симметрична. По-прежнему все SetGeneralization полные (complete) и непересекающиеся (disjoint).
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: Galogen от 05 Июля 2016, 16:32:19
Если не ходить по ссылке:
почему outgoingtransition - это не transition?
begintransaction - что это за понятие? и не кажется ли вам, что оно выпадает из общей сравнительной классификации:
начальный переход
внешний переход
внутренний переход

и разве начальный переход не подвид внешнего перехода?
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: Vadim от 05 Июля 2016, 20:10:18
почему outgoingtransition - это не transition?
outgoingtransition - это transition, но на диаграмме этого сразу не видно, а хотелось бы!
begintransaction - что это за понятие? и не кажется ли вам, что оно выпадает из общей сравнительной классификации:
начальный переход
внешний переход
внутренний переход

и разве начальный переход не подвид внешнего перехода?
По UML-стандарту начальный переход это подвид внешнего перехода, хотя некоторые UML-инструменты имеют визуальный элемент, который объединяет и начальное состояние, и переход из него. Но в данной теме хотелось обсуждать не это, а диаграммирование конкретной ситуации, а названия классов могли быть просто a, b, c, d, e, f.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: [прилетело НЛО и...] от 21 Июля 2016, 17:27:34
Если отвлечься от надписей, то почему бы не так:
A родитель перекрывающихся B и C, В родитель не перекрывающихся D и E, С родитель не перекрывающихся E и F.
Если принять во внимание надписи, то можно подумать над набором классов -- все ли нужны.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: Vadim от 21 Июля 2016, 18:22:26
A родитель перекрывающихся B и C, В родитель не перекрывающихся D и E, С родитель не перекрывающихся E и F.
Допустимыми должны быть только конфигурации: (ABD), (ABCE), (ACF). А так получается, что допустимой является и конфигурация ABCDF.
Если принять во внимание надписи, то можно подумать над набором классов -- все ли нужны.
Все нужны - на диаграмме этого нет, но каждый имеет особенность: или атрибут, или участие в ассоциации, или ограничение, или ещё что-нибудь.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: [прилетело НЛО и...] от 22 Июля 2016, 11:18:03
Допустимыми должны быть только конфигурации: (ABD), (ABCE), (ACF). А так получается, что допустимой является и конфигурация ABCDF.
Раз так, то просто провести явно неявные стрелочки на 1й диаграмме.
Все нужны - на диаграмме этого нет, но каждый имеет особенность: или атрибут, или участие в ассоциации, или ограничение, или ещё что-нибудь.
Авторы стандарта просто завели атрибут, чтобы хранить вид перехода. Почему бы не последовать их дурному примеру?)
Кстати про ABCDF. См. Figure 14.35. Ах, да. Про это писали выше.
P. S. Рисунок гармонирует с ограничением state_is_external из 14.5.11.8. Как тут не вспомнить Джеймса Рамбо с его сакраментальным: "В ставке Гитлера все малахольные!"
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: Vadim от 22 Июля 2016, 16:43:07
Раз так, то просто провести явно неявные стрелочки на 1й диаграмме.
Тогда на диаграмме будут обозначены и базовые факты, например "D подкласс B" и "B подкласс A", что хорошо, и производный факт "D подкласс A", что обычно не делается. Начиная тему, я предполагал, что  идеального варианта может и не быть, хотелось совместно выбрать лучший.
Авторы стандарта просто завели атрибут, чтобы хранить вид перехода. Почему бы не последовать их дурному примеру?)
Диаграмма, как её рисует стандарт (без constraint'ов) упрощается (правда появляется кратность 0..1 вместо 1..1 для атрибутов и ассоциаций), но модель в целом - усложняется (где-то constraint'ы надо указать).
Кстати про ABCDF. См. Figure 14.35.
Не уловил.
Ах, да. Про это писали выше.
Не уловил.
P. S. Рисунок гармонирует с ограничением state_is_external из 14.5.11.8.
Не уловил.

Как тут не вспомнить Джеймса Рамбо с его сакраментальным: "В ставке Гитлера все малахольные!"
Не уловил (откуда цитата знаю, наверное с чувством юмора проблемы).
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: [прилетело НЛО и...] от 22 Июля 2016, 17:59:37
Не уловил.
Стандарт говорит, что initial transition является external transition. Буковки E и F у меня попутались. Указанное ограничение странно написано, но опять таки скобки у меня попутались. Рамбо в книжке интервью резко отзывался об IBM.
Приношу всем свои извинения.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: Vadim от 16 Августа 2016, 11:17:20
Лучший (по-моему) вариант.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: [прилетело НЛО и...] от 16 Августа 2016, 17:00:24
Интересно. Не припомню примеров derived классов.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: Vadim от 16 Августа 2016, 17:36:10
http://infocat.ucpel.tche.br/disc/mc/cmis.pdf глава "8 Derived Types".
Пункт "8.3.2 Derived by Specialization" на стр.170 содержит аналогичную ситуацию:
 context Square::allInstances():Set(Square)
 body: Rectangle.allInstances()->
 intersection(Rhombus.allInstances())

И в целом книга интересна, и другие произведения автора.

EnterpriseArchitect (не знаю с какой версии, но в 12 есть) даёт возможность в свойствах класса указать, что derived.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: [прилетело НЛО и...] от 17 Августа 2016, 01:51:45
Клевая ссылка, спасибо.
В стандартной метамодели UML нет места, чтобы запомнить isDerived у класса. Можно без экзотики написать инвариант, запрещающий плохие комбинации наследования.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: Vadim от 17 Августа 2016, 13:30:35
В стандартной метамодели UML нет места, чтобы запомнить isDerived у класса.
Я тоже не нашёл. Но:
В книге есть попытка решить исходную проблему топика, но неудачная (рис.4.16.) - Vehicle может быть Car и Boat одновременно.
Можно без экзотики написать инвариант, запрещающий плохие комбинации наследования.
Такой инвариант может быть в контексте любого из остальных 5 (кроме ExternalTransition) классов и только в классе Transition сохранит симметричность модели (но не простоту написания).

Попутно замечу, что производность класса не означает производность его атрибутов и ассоциаций - производным является состав объектов, но не значения свойств.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: [прилетело НЛО и...] от 17 Августа 2016, 15:52:14
В книге Рамбо и Блаха в 4.10. прямо сказано: "Производными могут быть классы, ассоциации и атрибуты" и пример есть (правда не очень хороший)
Спасибо за ссылку на пример.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: [прилетело НЛО и...] от 20 Августа 2016, 12:44:50
Перечёл у Рамбо обсуждение обобщений. Выглядит странно на фоне стандарта 2.5.  Стандарт говорит о том, что классификаторы могут расшаривать экземпляры при {overlapping}, но не уточняет, что для этого надо.   Ну, то есть, как на диаграмме объектов нарисовать этот самый расшаренный экземпляр? Стандартная метамодель UML разобраться нисколько не помогает. По ней -- связывай экземпляр с любыми классификаторами и всё. Никаких тебе ограничений.
По [моему пониманию] Рамбо ограничения {overlapping/disjoint} говорят о том, какие обобщения можно проводить между подклассами и их наследниками. Если мы хотим запретить "склеивать" ветки в поддереве наследования, то пишем {disjoint}, иначе ничего не пишем и получаем по умоланию {overlapping}. Разница между написанным в стандарте и этой трактовкой в том, что экземпляры не могут просто так шариться. Сначала придётся завести класс-наследник у двух подклассов, а затем только экземпляры этого класса (его наследников и других, таких же как он) могут быть расшарены. Пока такого класса нет, нет и реальной возможности использовать расшаренный экземпляр, а декларируемая стандартном возможность  остаётся только теоретической.
Неясно как в свете UML 2.5 выглядят примеры Рамбо в параграфе 4.6.3. Он словно ломится в открытую дверь усложняя модель.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: Vadim от 22 Августа 2016, 10:06:20
Ну, то есть, как на диаграмме объектов нарисовать этот самый расшаренный экземпляр?
Поискал, не нашёл. Единственный класс, к которому относится объект указывается после двоеточия после имени объекта. Можно предложить если классов несколько, то можно их там же перечислить через запятую.
По ней -- связывай экземпляр с любыми классификаторами и всё. Никаких тебе ограничений.
Ограничения есть, конфигурация классов должна быть допустимой, но это на совести автора диаграммы объектов - как определять допустимые конфигурации по модели классов даже у Оливе нет.
Разница между написанным в стандарте и этой трактовкой в том, что экземпляры не могут просто так шариться. Сначала придётся завести класс-наследник у двух подклассов, а затем только экземпляры этого класса (его наследников и других, таких же как он) могут быть расшарены. Пока такого класса нет, нет и реальной возможности использовать расшаренный экземпляр, а декларируемая стандартном возможность  остаётся только теоретической.
Путь с обязательным заведением класса-наследника неприемлем. Кстати у Рамбо-Блаха рис.4.15. неточен - нет гарантии, что все Employee, которые одновременно FullTimeEmployee и IndividualContributor попадут в FullTimeIndividualContributor.
Неясно как в свете UML 2.5 выглядят примеры Рамбо в параграфе 4.6.3. Он словно ломится в открытую дверь усложняя модель.
В параграфе 4.6.3. "Обходные маневры" делается попытка обойтись без множественного наследования и множественной классификации. По мне это даже вредно - модель должна соответствовать предметной области, а не используемому инструменту (язык программирования).
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: [прилетело НЛО и...] от 22 Августа 2016, 11:53:06
Ограничения есть, конфигурация классов должна быть допустимой, но это на совести автора диаграммы объектов - как определять допустимые конфигурации по модели классов даже у Оливе нет.
Эти ограничения настолько слабы (после overlapping'а по умолчанию), что их как бы и нет. Единственное, что явно сказано про недопустимые конфигурации в стандарте -- disjoint'ы. Нет их, нет и ограничений.
Путь с обязательным заведением класса-наследника неприемлем.
Это путь от кода. Но ему есть хоть какое-то объяснение. Что например мешает двум никак не связанным классам расшарить экземпляр? По [молчащему на этот счёт] стандарту -- ничто. По этому пути -- хотите шарить -- заводите общий подкласс, т. е. сначала свяжите классы хотя бы опосредованно.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: [прилетело НЛО и...] от 22 Августа 2016, 12:10:53
Ограничения есть
P. S. В метамодели UML ассоциация между классификатором и экземпляром ничем не ограничена. Вообще. Нет даже сакраментального "Cannot be expressed in OCL".
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: Vadim от 22 Августа 2016, 12:47:47
Эти ограничения настолько слабы (после overlapping'а по умолчанию), что их как бы и нет. Единственное, что явно сказано про недопустимые конфигурации в стандарте -- disjoint'ы. Нет их, нет и ограничений.
Кроме overlapping/disjoint есть ещё complete/uncomplete, а также абстрактность класса. Абстрактность требует(?), чтобы все/хоть одна(?) SetGeneralization этого класса была complete.
P. S. В метамодели UML ассоциация между классификатором и экземпляром ничем не ограничена. Вообще. Нет даже сакраментального "Cannot be expressed in OCL".
В стандарте "9.8.3 Semantics" есть абзац "It is important to keep in mind that InstanceSpecification is a model element and should not be confused with the
instance that it is modeling. As an InstanceSpecification may only partially determine the properties of an instance,
there may actually be multiple instances in the modeled system that satisfy the requirements of the
InstanceSpecification. On the other hand, an InstanceSpecification may model a situation which is not actually
supposed to occur in the modeled system, in which case no instance meeting the requirements of the
InstanceSpecification may ever actually occur in the system."
Я понял это так: идёт речь не об экземпляре, а об элементе диаграммы, который, строго говоря, может и не быть полноценным экземпляром.
Ну, то есть, как на диаграмме объектов нарисовать этот самый расшаренный экземпляр?
9.8.4. в первом абзаце говорит о нескольких классификаторах через запятую.
Название: Re: Структура обобщений более сложна, чем иерархия - как диаграммировать
Отправлено: [прилетело НЛО и...] от 22 Августа 2016, 14:03:44
Я лишь пытаюсь уточнить свою мысль. Переходить от "ограничений на связанные с экземпляром классификаторы" на другие ограничения в мои планы пока не входит.
Ещё в стандарте есть параграф 9.9.9.6. Именно к нему относится сказанное мной об отсутствии ограничений в стандартной метамодели UML.
Подход "запишем через запятую и всё" не плох, что и говорить.)