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

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - [прилетело НЛО и...]

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »
106
Барахлит мой ксенолингвист и ксеночувство юмора. Уместного способа сообщить о том, что классификация uml-ьных диаграмм может быть пополнена на ~50% ненормативными типами, у меня не нашлось.

107
Реализация / Re: Реализация ассоциаций
« : 25 Января 2020, 01:20:47 »
Выше было дано разрешение.   :)
Если смотреть шире на uml-ьные стрелочки, то в сети есть шутка:

В шутке, как полагается, есть доля шутки.
Кажется, что комбинаторный анализ uml-стрелочек как со стороны конкретного синтаксиса, так и со стороны абстрактного, может выявить, что не все сочетания [допускаемые стандартом] имеют такой смысл, что их можно использовать в модели.

108
На моей планете любят и используют диаграммы профиля.
Глядя из сегодняшнего дня, можно добавить в список ещё 8 типов UML-диаграмм, о которых знает Фархутдинов. Из них я однажды рисовало одну.

109
Реализация / Re: Реализация ассоциаций
« : 24 Января 2020, 09:50:10 »
Цитировать
часть должна знать какому целому она принадлежит, но наоборот нет так актуально.
Некротредно несогласно! Если имеется составной объект с композируемыми в него объектами-частями, то, чтобы , отправляясь в мир иной, прибить свои части [как велит семантика стандартной uml-ьной композиции] такой объект должен их знать.

110
UML SysML и пр. / Re: Шутки и UML
« : 01 Января 2020, 20:31:31 »
Из-за межгалатических расстояний до меня лишь недавно дошло, что прибегание человека, ищущего помощь в UML-моделировании сказки, -- следствие "пользы". Кто-то репостнул с пометкой, мол, в обучении хорошо использовать, кто-то прочёл и стал использовать: выдавать студентам для самостоятельного решения задания про uml-журавля с uml-лисицей.

111
UML SysML и пр. / Re: Шутки и UML
« : 29 Декабря 2019, 18:22:11 »
Некротединга псто
==============
Сайт umljokes помер. Диаграммы разошлись на незакавыченные цитаты в блоги.

112
Про стандарт, хоть тема про EA. В VP та же ботва (из-за стандарта).(

113
Можно подметить особенность нынешнего стандарта UML: на диаграмме свойство Generalization Set, названное в метамодели UML isCovering, отображается как {complete}/{incomplete}. Зачем-то введена синонимия причём раздельная: для абстрактного синтаксиса один термин, для конкретного синтаксиса -- другой. А то бы всё было слишком просто, такова логика авторов стандарта?

114
Sparx / Re: Кооперация
« : 09 Декабря 2019, 10:58:41 »
Хотя нет, нашел!
Спасибо, Galogen!

115
Sparx / Re: Кооперация
« : 04 Декабря 2019, 02:33:44 »
Можно решить, что кооперация -- плохой способ моделировать паттерн [весь]. Что же делать? Можно вспомнить что в UMLе есть штуковина, внутри которой классы чувствуют себя вполне нормально, внутри которой можно рисовать и ассоциации, и обобщения, и реализации, и зависимости. Это пакет:

И есть в UMLе изобретение авторов языка Ада (того самого) -- параметризованный пакет:

Только вот зависимость связывания, согласно последним веяниям, должна рисоваться как зависимость, не как реализация.
Итак, паттерн можно моделировать  пакетом. Участники паттерна и связи между ними становятся элементами пакета. Структура описывается диаграммой, вроде той, что выше. Для описания поведения в состав пакета можно включить кооперацию и внутри неё смоделировать взаимодействие экземпляров участников. Использование паттерна описывается как конкретизация пакета [см. на диаграмме выше].
P. S. У предложенного способа есть недостаток. Связи между классами, соединёнными по рецепту паттерна оказываются отдельно от этих классов. Они лежат в пакете -- конкретизации параметризованного пакета. Где лежат сами эти классы [мне] неясно.

116
Sparx / Re: Кооперация
« : 03 Декабря 2019, 22:01:52 »
Если жирно некротредить, то можно сказать следующее.
Текущий стандарт UML (который возможно отличается от стандарта из 2010 года) говорит, что кооперация -- это пачка взаимодействующих экземпляров. Если рисуется диаграмма составной структуры, показывающая "кишки" кооперации вроде:

, то роли там можно соединять только коннекторами (но не ассоциациями/агрегациями/композициями, не обобщениями, не реализациями). Так что некоторые картинки, нарисованные по ссылке, которая протухла, невозможны по текущему стандарту. Надо сказать, что и диаграмма с www.uml-diagrams.org, которую я использую, тоже нарушает стандарт. Т. к. внутренности ролей на ней не ролевые, как положено по стандарту, а интерфейсные как по стандарту не положено. Стандартные внутренности ролей -- это вложенные в роли части (parts) и/или свойства (properties). Так что по стандарту кооперация Observer должна рисоваться иначе (тут другая одноимённая кооперация, но смысл тот, что ни атрибутов, ни операций у ролей не должно быть):

Между тем, в стандарте делается некоторый финт. Говорится, что якобы есть альтернативная нотация:

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

Далее...
Если используется кооперация, т. е. создаётся CollaborationUse, то с экземплярами, подставляемыми на роли, она по стандарту соединяется зависимостями. Важное слово тут -- экземпляры. Стандарт не позволяет подставлять классы на роли.

Моделирование паттернов проектирования как параметризованных коопераций в связи со сказанным сопряжено такими моментами:
1) Параметрами (а не ролями!) кооперации, моделирующей паттерн, должны быть участники (participants) паттерна. У Observer это Subject, Observer и ConcreteObserver.
2) Роли в кооперации задают имена, с которыми экземпляры участников паттерна будут фигурировать на диаграммах взаимодействия.
3) Использование паттерна (т. е. увязка классов друг с другом по его рецепту) -- это конкретизация параметризованной кооперации. По параметризованной кооперации, моделирующей паттерн, создаётся другая кооперация -- её конкретизация. Они соединяются зависимостью связывания, в которой прописываются bind-инги. То есть использование паттерна -- это не использование кооперации, которая его моделирует.

117
Не знаю и не берусь предсказать. Если будет технология и инструменты, соответствующие этим (пока чрезмерным, на мой взгляд) выразительным возможностям UML 2.5.1, то прогресс пойдёт.

118
Написанное мною, не соответствует стандарту UML 1.4. В первом UML описание стандарта языка строилось вокруг диаграмм, т. е. вокруг ранее независимых нотаций, брошенных в плавильный котёл UML. Поэтому в стандарте UML 1.4 есть определение диаграммы объектов. С переходом ко второй версии точка зрения авторов стандарта сместилась. Софтина, работающая с UML-моделью -- трансформатор, кодогенератор, анализатор -- не интересуется диаграммами, видит общую кучу элементов модели и связей между ними, вычленяя то, что её интересует по типам элементов и связей, а не по факту принадлежности элементов одной и той же диаграмме или разным. В подобном виде переписан стандарт UML. В стандарте UML 2.4.1 нет определения не только для диаграммы объектов, но и для диаграммы классов. Также в стандарте UML 2.4.1  приводится иллюстрация, являющаяся смешением диаграммы деятельности с диаграммой классов. Видимо, авторов стандарта увлекала идея сплавления подъязыков UML в единое целое. В последней версии стандарта постулируется зыбкость границ между разными типами диаграмм (контрастирующая с привычным ходом составления самих диаграмм в какой-либо UML-среде).

119
Мне представляется, что когда-то местом для описания диаграмм сделали UML Reference Manual и т. п. руководства. Стандарт не так уж много внимания уделял диаграммам в прошлом. В этом плане последняя версия в приложениях сравнительно много говорит о диаграммах. Появился кусок метамодели UML, посвящённый диаграммам. На UmlObjectDiagram даже одно ограничение навесили.

120
Цитировать
Use cases are no longer required to express some needs of actors...
Тут стандарт всего лишь соглашается с Коберном и проч., считающими, что помимо ВИ уровня моря, могут быть ВИ других уровней.
Цитировать
Use cases are no longer required to... be initiated by an actor.
Чтение перечня багов стандарта UML почему-то навело меня на мысль о том, что тут могут иметься в виду расширяющие или включённые ВИ.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »