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

×


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

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


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

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

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

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

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

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

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

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

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

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

113
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-инги. То есть использование паттерна -- это не использование кооперации, которая его моделирует.

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

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

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

117
Цитировать
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 почему-то навело меня на мысль о том, что тут могут иметься в виду расширяющие или включённые ВИ.

118
Во многих источниках информации указано, что use case - это некая цель, которую желает достич пользователь с помощью системы.
Цитата: Kirill Fakhroutdinov
Use cases are no longer required to express some needs of actors and to be initiated by an actor.
Написанное относится к UML, начиная с версии 2.5.

119
Интересный сайт. Даты указаны в ноябре 2018. И крупными буквами: "событие отменено".
Наверное, так и надо.

120
Вроде того (с поправкой, что речь идёт о текстовых описаниях, которые могут предшествовать UML-диаграммам и/или дополнять их).
Есть статья 2002 года, не мейнстрим, но есть.

Страницы: « 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 »