46

UML SysML и пр. / Re: UML Best Practice: "На диаграммах деятельности не рисуйте деятельности"

« : 19 Июля 2021, 04:25:01 »

Запуски могут быть синхронными и асинхронными.
На этой диаграмме это как-то отражается какими-нибудь специальными символами?

Графических средств для этого почти нет. Можно приклеить уродливый коммент с явным выписыванием isSynchronous=true или isSynchronous=false.
"Почти нет", т. к. есть один финт.

На фрагменте а) видим узел действия вызова деятельности. И у этого узла видим выходящий пин. По стандарту узлу с isSynchronous=false запрещено иметь такие пины. Значит, этот узел с  isSynchronous=true.
 

Можете показать пример такого "соединения" деятельностей?

На практике такое вряд ли кто нарисует. Это всё равно, что две диаграммы вместе слитно нарисовать.

Берём иллюстрацию из стандарта. Рядом справа рисуем деятельность разбирающую компы обратно на части. Заводим ей входной параметр Assembled Comps. Соединяем стрелкой-потоком один из выходных параметров первой деятельности со входным параметров второй.

И можете пожалуйста объяснить, чем по определению деятельность отличается от действия?

Деятельность -- это конструкция из кирпичиков, каждый из которых атомарен (элементарен, не раскладывается на части). Кирпичики принято называть узлами. Один из видов узлов -- узлы действия. Т. е. деятельность собирается из действий. А действие ни из чего не собирается. Оно целёхонькое и прочное -- его на куски не расколотить.

47

UML SysML и пр. / UML Best Practice: "На диаграммах деятельности не рисуйте деятельности"

« : 08 Июля 2021, 02:19:20 »

Наткнулось на заметку Geert Bellekens "UML Best Practice: There are no Activities on an Activity Diagram"
Подумало, как клёво, что в 2012-м людям в Бельгии всё уже было ясно.
Стало смотреть диаграммы [глазом из нынешнего 2021го]. Ротовые щупальца встали дыбом.
Чел из Бельгии рисует такое и пишет, что одноимённые узлы (он называет их "деятельностями") это ужас-ужас.

Но потом избавляет нас от ужаса, делая их узлами действия вызова одной и той же деятельности:


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

Воткнув вилки и добавив двоеточия бельгиец не избавился от дублирования (глазом это видно). Два раза нарисовано одно и то же. Изменилось лишь одно. Без вилок это были два OpaqueAction или два CallBehaviourAction, что говорило нам о невыразимости средствами UMLя сути хреновины по имени "Process Payment". С вилками мы утверждаем, что кто-то может нарисовать отдельную диаграмму деятельности, где будут видны внутренности "Process Payment".

Может ли на диаграмме деятельности присутствовать деятельность? Может, конечно. Обычно, при этом она выгладит как прямоугольная со скруглёнными углами рамка, внутри которой находится всё содержимое диаграммы. Если заморочиться, то можно нарисовать две такие "диаграммы в рамочках" рядом. Потом можно захотеть их соединить. Стандарт запрещает это делать напрямую. Каждая деятельность сначала должна будет вырастить на своей границе объектный узел специального вида -- параметр. И вот эти выращенные параметры (output с input) можно будет соединить стрелкой-потоком.

48

RUP EUP AUP OpenUP / Re: Практика использования RUP. Или бег на месте...

« : 19 Июня 2021, 14:37:24 »

"Приключения в ресторане" продолжаются.
Некто поместил в википедию свою версию диаграммы ВИ ресторана. Далее её стали использовать в куче мест. (К слову в самой вики пытаются эту диаграмму читать и как BUC, игноря предупреждения by Kirill Fakhroutdinov с красными человечками, приведённые выше). Например, её использовали создатели рисовалки, не умеющей пунктирные стрелки. Так появилась испорченная версия со сплошными экстендами.  Дальше больше. Испорченную версию ещё больше испортила авторка из Томска и поместила в придуманный ею тест на знание UML. Верхний сплошной экстенд стал сплошным инклюдом (отражая, по мнению авторки из Томска, "Неконсистентность связей между прецедентами с вином и едой: include указывает на то, что заказ вина возможен ТОЛЬКО при заказе еды"). Однозначно ошибочным является только нарушение нотации (непунктирные стрелки расширений и включения). Вероятно ошибочным -- направление инклюда. Замороченность тем, что с чем заказывать, выпивку к закуске или закуску к выпивке, ВИ-диаграмма не в силах прояснить, тут необходимо читать тексты сценариев.

49

Теория моделирования и нотации / Re: Самая удобная нотация и инструмент моделирования для проектирования БД

« : 17 Июня 2021, 20:54:06 »

А я имел ввиду, что у самой связи (то есть у линии, связывающей две сущности) нету информации о ключах (столбцах), по которым осуществляется эта связь.
Ну в общем, как-то мне не очень эта идея.

После уточнения прояснилось, в чём именно видится дефект. Чтобы отразить эти сведения, можно допилить профиль и переложить эти tagged values в стереотипы для связей.

В копилку "не очень идей": рисовать в Visual Paradigm и моделировать категоризацию тем способом, который предложен разрабами VP. Красивые картинки a la IDEF1X получать экспортируя диаграммы в "рисовалки" вроде Visio, где явно пририсовывать категоризацию. Не думаю, что стоит так мучиться, но ничего другого не могу предложить.

50

Теория моделирования и нотации / Re: Самая удобная нотация и инструмент моделирования для проектирования БД

« : 15 Июня 2021, 22:57:29 »

Здесь в отношениях нету информации о ключах и полях, с помощью которых "реализуется" эта связь.

[в продолжение трындежа]
У Амблера для этого предусмотрены метасвойства/tagged values у столбцов, помеченных как внешние ключи (<<FK>>).

51

Теория моделирования и нотации / Re: Самая удобная нотация и инструмент моделирования для проектирования БД

« : 15 Июня 2021, 15:49:53 »

[Вероятно, имеются в виду реляционные БД.]
[Далее следует порция трындежа, который худо-бедно связан с заданными вопросами, но не даёт на них ответа.]
Инструмент (программу) можно подбирать под задачу. Например, чтобы она из имеющихся DDLей сама рисовала что-то удобоваримое, а после перерисовывания генерила новые версии DDL, и чем, чёрт не шутит, помогала рефакторить содержимое БД. Как следствие, такие полезные свойства инструмента могут помочь смириться с несовершенством поддерживаемой нотации.
Можно ставить в вершину угла выразительные возможности нотации (и, как следствие, мириться с несовершенством инструмента, который её поддерживает).
У нотации полно других свойств, которые могут быть важны (и даже быть важнее выразительных возможностей). Например, если нотация привычна Вашим коллегам, то они с бОльшим энтузиазмом воспримут Ваши диаграммы.
[Тут трындёж как бы заканчивается.]
Мне привычен UML. К нему есть профиль, предложенный на сайте Скотта Амблера. С помощью этого профиля можно приспособить стандартную UML-диаграмму классов к моделированию схемы реляционной БД. Амблер не приводит пример с категоризацией, но в актуальной версии UML есть такие штуки как Generalization Set с Power Type-ами. Это позволяет наUMLылить что-то похожее на IDEF1X-ные categorization-отношения.
Недостатков такого решения прорва:
- инструмент для перевода с/в DDL в/с UML почти наверняка не существует;
- приспособленные UML-диаграммы классов не привычны разработчикам БД, они откажутся их читать;
- пляски с Generalization Set и Power Type-ами лишь отдалённо напоминают то, что было в IDFE1X.

52

Теория моделирования и нотации / Re: Неизвестная нотация структуры базы данных

« : 07 Июня 2021, 17:45:34 »

1) С Марсу кажется, что это IDEF1X.
2) Если не только кажется, то это часть ISO/IEC/IEEE 31320-2:2012. От которого не отказались.
3) Не знаю. В Visual Paradigm есть ERD. В них можно указать дискриминатор, но явно на диаграмме он не будет отражаться. Что-то схожее можно нарисовать на UML, но без вороньих/куриных лапок.
4) Не порекомендую.

53

Системный Анализ и Требования / Re: Диаграмма состояний

« : 03 Июня 2021, 00:15:56 »

Доступ, видимо, закрыт теперь.
Может быть тон моего коммента передался неверно.

54

Системный Анализ и Требования / Re: Диаграмма состояний

« : 30 Апреля 2021, 07:12:51 »

1. Как корректно отобразить для состояния «Сформировано», что Exit/заблокировать на редактирование произойдет только при переходе в статус «Отправлено»?

Не используйте действие по выходу, т. к. оно выполняется при любом выходе. Вы можете это действие приписать на те переходы, для которых оно актуально.
[В сторону] невполне ясно, как строится модель. Так как события "отредактировать" игнорятся вне "создать извещение", то независимо от того, заблокируете или нет, отредактировать в "Отправить" и проч. не выйдет.

2. При переходе из статуса «Отправлено» в статус «Возвращено» для переходов «[подтвердить формирование РПРО]» и «[отклонить формирование РПРО]» нужно ли каким-либо образом указывать, что такие переходы возможны только если уведомление №14. Если нужно, то как это возможно отобразить?

Можно указать сторожевое условие на части составного перехода, ведущей в верхний правый ромбик.

Неясно, зачем всюду "подвесочки" с финальными состояниями. Они обессмысливают, на мой взгляд, состояния "Не использовано", "Использовано" и др.. Но это если стандартно читать. Если у Вас в ходу свои правила чтения, то и славно.

Вообще говоря, на стандартных диаграммах состояний не бывает ромбиков в которые входят несколько переходов. Вместо них чёрные кружки (переходные псевдосостояния).

Если написать название в виде действия "Создать извещение", то это не означает, вообще говоря, что что-то будет делаться. Мысленно заменив такое называние на State0, получаем диаграмму с тем же смыслом (если стандартно читать).

Неясно, зачем событие и do-деятельность названы одинаково: "Отредактировать".  [Если у Вас в ходу свои правила чтения/составления UML-диаграмм состояний, то и славно.]

Неясно, зачем некоторые события взяты в прямоугольные скобочки: [получен ответ...]. [Если у Вас в ходу свои правила чтения/составления UML-диаграмм состояний, то и славно.]

55

Идеи и мозговой штурм / Re: Диаграммы Курта Воннегута

« : 18 Апреля 2021, 15:10:05 »

Интересно. Курт Воннегут несколько раз пытался защитить разные дипломные работы? Вроде в бакалавриате одна дипломная.

К. В. после войны учился в "специалитете" на антрополога -- уникальной программе сочетающей B.S.+M.S.. Кажется, было две попытки и темы были разные, но на общей ключевой идее. В итоге ему дали почётную степень за "Колыбель для кошки". Примечательно, что К. В. преподавал в вузах, при этом неясно, было ли это до или после присвоения степени.

Говорят UML уже не используется в it-разработке, пора начать активно внедрять его в другие области человеческой деятельности. Как я понимаю, для конструирования сюжета. Тут можно обсудить, какие диаграммы и как следует использовать, чтобы проектировать бестселлеры

Попадалось что-то про UML для сочинителей детективов, но это неточно, т. к. ссылка потерялась.

56

Идеи и мозговой штурм / Диаграммы Курта Воннегута

« : 06 Апреля 2021, 12:52:03 »

Предлагается продолжить наши междисциплинарные инопланетные штудии.

Недавно перевели книжку ученицы Курта Воннегута Сьюзен Макконелл "Курт Воннегут. Пожалейте читателя. Как писать хорошо". Объёмный томик для каждого, у кого 15-20-летие совпало с выпуском романов К. В. на русском. Из книги можно узнать про Kurt Vonnegut Story Chart -- диаграммы, положенные в основу дипломных работ, которые Курт Воннегут [безуспешно] пытался защитить в бакалавриате. Выглядят story chart-ы примерно так:

На ютьюбе нагугливается ролик с выступлением К. В., где видно, как он рисует story chart-ы, и поясняет, как визуализируется смена состояний главного героя в ходе изложения. Линия идёт выше -- главный герой счастливее, ниже -- несчастнее.
Можно заметить, что story chart -- это фрагмент UML-диаграммы синхронизации. Ещё бы чуть и К. В. изобрёл бы их. Ему стоило догадаться, что помимо протагониста есть антагонист и всякие дейтерагонисты с тритагонистами. И их состояния также меняются. И полный story chart должен включать не одну линию жизни, а несколько, на которых соотношение счастья/несчастья персонажей меняется синхронно.

57

Работа / Re: Почему аналитики не читают литературу по специальности?

« : 18 Марта 2021, 12:11:30 »

Удалось найти первоисточник - произведение самого Баркера (примерно 1989 года) или перевод на русский язык (видел примерно в 1993 году)?

https://archive.org/details/casemethod00rich
На всякий случай, ссылка на книжку "Case Method: Entity Relationship Modelling". Если зарегаться на archive.org, то можно читать.

58

UML SysML и пр. / Re: Бертран Мейер -- UML-ненавистник

« : 27 Января 2021, 22:39:43 »

Ксенолингвист барахлит при переводе bbcode с марсианского. Прошу прощения. Фиксануло.

59

UML SysML и пр. / Бертран Мейер -- UML-ненавистник

« : 17 Января 2021, 23:29:44 »

В 1997м Б. Мейер составил и опубликовал фельетон "UML: The Positive Spin" ("UML: Позитивная раскрутка") и выступил в роли одного из первых UML-хэйтеров. В фельетоне от лица студента как бы составлено письмо своему профу с требованием повысить оценку, заниженную якобы по политическим причинам.
Вывод в этом фельетоне вполне может быть в жилу тем, кто считает UML не годным, кто коллекционирует и сам зачастую рисует т. н. "смешные UML-диаграммы":
UML назван...

...замечательной само-подпитывающейся машиной, посвященной от А до Я созданию нового рынка, свободного от каких-либо трудностей, связанных с неприятным процессом разработки программного обеспечения: Книги по UML! Курсы UML! Курсы по книгам! Книги по курсам! Книги по книгам! Вводные курсы для подготовки к курсам повышения квалификации! Курсы для преподавателей! Редакции! Журналы по UML! Конференции! Мастер-классы! Учебники! Стандарты! Комитеты! Футболки!

Готовя очередное выступление на аналитическом слёте, посвящённое тому, почему UML не взлетел, можно обратить внимание на классические тезисы БМ и продолжить многолетнюю традицию, заложенную им.
Остальным читателям страничка даст путь к книге по "европейскому UML" -- BON (Business Object Notation). Книга называется "Seamless Object-Oriented Software Architecture — Analysis and Design of Reliable Systems". Она выложена одним из двух авторов (Kim Waldén) на его странице.

60

Идеи и мозговой штурм / Re: На пути к морфологии сценариев ВИ

« : 16 Января 2021, 18:25:35 »

Идея не претендует на новизну.
Идея не претендует на осуществимость.
В упомянутых книгах паттерны понимаются в другом ключе, насколько могу судить. Например, авторы "Patterns for Effective Use Cases" называют паттернами свои советы о том, как реализовать юзкейсописательство, и прочие придуманные ими юзкейсо-хаки. "Паттерны" Проппа другого сорта, это выявленные общие шаблоны, схемы. Понятно, что он их придумал/разглядел/выявил. Но делал это на материале, полученном извне. Мне не попадалось книг, в которых бы приводились советы и решения, составленные по итогам анализа сценариев ВИ, написанных не самими авторами этих книг. Тот же Коберн приводит сторонние тексты как иллюстрации своих положений, не как почву из которой эти положения выросли. К слову в "PfEUC" нет и мысли о расширении видов действующих лиц.