121

Примеры / Re: ДВИ формирования претензий по заказу

« : 28 Марта 2020, 02:53:54 »

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

122

Примеры / Re: диаграмма последовательности процесса снятия денег в банкомате

« : 28 Марта 2020, 02:22:33 »

Тогда с учетом общей критики наверное так

Некро-коммент: дефект диаграммы в том, что клиент всегда получает налик и ему всегда возвращают карту. В жизни это не так. Некоторую странность  диаграммы можно усмотреть в том, что заканчивается она двумя возвратами на один и тот же call. Разумно было бы либо делать один возврат, либо вообще не моделировать взаимодействие с экземпляром действующего лица сообщениями типа call и reply. И финальная рекомендация. Ради Марса, не рисуйте экзекьюшн спецификации на диаграммах последовательности. Их отсутствие почти всегда ни на что не влияет, а присутствие, как правило, провоцирует нарушения стандарта.

123

UML SysML и пр. / Re: [Статистика использования UML]. Типы диаграмм

« : 12 Февраля 2020, 01:44:53 »

Не понял, что нужно сделать

Ничего не _нужно_. _Можно_, к примеру, потрындеть, сколько человек соберутся рисовать именно Information flow diagram, а не диаграмму классов (учитывая, что в реальной UML-среде можно средствами диаграммы классов создать что-то визуально не отличимое от UML-IFD). И почему, к примеру, UML-IFD -- поведенческая, хотя по конкретному синтаксису она вполне себе выглядит структурной.

124

UML SysML и пр. / Re: [Статистика использования UML]. Типы диаграмм

« : 06 Февраля 2020, 14:20:45 »

Ненормативные диаграммы не указаны явно в тексте стандарта UML в той его части, которая посвящена диаграммам -- аппендиксе A.
Можно, при желании, просто понекротредить про эти дополнения.

125

UML SysML и пр. / Re: [Статистика использования UML]. Типы диаграмм

« : 03 Февраля 2020, 20:51:04 »

На картинке ненормативные диаграммы, описанные by Kirill Fakhroutdinov, выделены цветом.

126

UML SysML и пр. / Re: [Статистика использования UML]. Типы диаграмм

« : 25 Января 2020, 11:25:21 »

Барахлит мой ксенолингвист и ксеночувство юмора. Уместного способа сообщить о том, что классификация uml-ьных диаграмм может быть пополнена на ~50% ненормативными типами, у меня не нашлось.

127

Реализация / Re: Реализация ассоциаций

« : 25 Января 2020, 01:20:47 »

Выше было дано разрешение.   
Если смотреть шире на uml-ьные стрелочки, то в сети есть шутка:

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

128

UML SysML и пр. / Re: [Статистика использования UML]. Типы диаграмм

« : 24 Января 2020, 10:17:42 »

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

129

Реализация / Re: Реализация ассоциаций

« : 24 Января 2020, 09:50:10 »

часть должна знать какому целому она принадлежит, но наоборот нет так актуально.

Некротредно несогласно! Если имеется составной объект с композируемыми в него объектами-частями, то, чтобы , отправляясь в мир иной, прибить свои части [как велит семантика стандартной uml-ьной композиции] такой объект должен их знать.

130

UML SysML и пр. / Re: Шутки и UML

« : 01 Января 2020, 20:31:31 »

Из-за межгалатических расстояний до меня лишь недавно дошло, что прибегание человека, ищущего помощь в UML-моделировании сказки, -- следствие "пользы". Кто-то репостнул с пометкой, мол, в обучении хорошо использовать, кто-то прочёл и стал использовать: выдавать студентам для самостоятельного решения задания про uml-журавля с uml-лисицей.

131

UML SysML и пр. / Re: Шутки и UML

« : 29 Декабря 2019, 18:22:11 »

Некротединга псто
==============
Сайт umljokes помер. Диаграммы разошлись на незакавыченные цитаты в блоги.

132

Sparx / Re: отразить на диаграмме свойства Generalization Set

« : 15 Декабря 2019, 02:24:27 »

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

133

Sparx / Re: отразить на диаграмме свойства Generalization Set

« : 09 Декабря 2019, 11:06:52 »

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

134

Sparx / Re: Кооперация

« : 09 Декабря 2019, 10:58:41 »

Хотя нет, нашел!

Спасибо, Galogen!

135

Sparx / Re: Кооперация

« : 04 Декабря 2019, 02:33:44 »

Можно решить, что кооперация -- плохой способ моделировать паттерн [весь]. Что же делать? Можно вспомнить что в UMLе есть штуковина, внутри которой классы чувствуют себя вполне нормально, внутри которой можно рисовать и ассоциации, и обобщения, и реализации, и зависимости. Это пакет:

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

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