1

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

« : 17 Марта 2023, 15:47:24 »

Издательство "Лори" "шутит".
Так диаграммы ВИ давно не рисуют. Но простым смертным об этом знать не обязательно. На оригинальном издании "Uml for Mere Mortals" обложка в порядке. Традиции российской переводческой школы, видимо, заложены персонажами из книг Ф. К. Дика.

2

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

« : 17 Марта 2023, 15:42:01 »

Подсказали, когда уместно нарисовать деятельность на диаграмме деятельности.
Если в описываемой диаграммой деятельности есть кусок, для моделирования которого прибегаем к рекурсии, то этот самый кусок можно изобразить как деятельность. И внутри этой деятельности будут узлы действия, из которых хотя бы 1 -- узел действия вызова деятельности, той самой которая изображает кусок.

3

Теория моделирования и нотации / Re: BPMN: 2.0 Границы Definition

« : 18 Декабря 2022, 03:55:59 »

Мне кажется, что Ваш вопрос относится не к языку, а к технологии. Язык, упрощённо говоря, даёт систему обозначений. Как эту систему обозначений применить для решения конкретной задачи, -- это определяется процессом. Т. е. в стандарте языка Вы не найдёте ответа на Ваш вопрос. En-wiki упоминает такую книгу как "The Process: Business Process Modeling using BPMN". Ну или что-то переводное. Сами видите, старожилы форума безмолвствуют, марсиане правят бал.(

4

ПО Аналитика / Re: Новости от Visual Paradigm

« : 18 Августа 2022, 13:00:11 »

Выпущен VP 17.0
https://www.visual-paradigm.com/whats-new/
Что-то добавили в SysML/UML.
Будем посмотреть.

5

UML SysML и пр. / Re: Ассоциация внутри класса

« : 06 Июля 2022, 01:07:36 »

Мне понравилась последняя диаграмма.

Нижний коннектор, соединяющий модули памяти с материнкой, имеет мультиплисити. Части BasicPC, соединяемые им, имеют мультиплисити. И порты на концах коннектора имеют мультиплисити. Чтобы убедиться в том, что 1 модуль памяти втыкается в 1 разъём и при этом всё сходится, необходимо сверить 5 явных цифирь и одну неявную.

6

UML SysML и пр. / Re: Вопрос по моделированию эффекта операции

« : 25 Июня 2022, 20:47:17 »

В современной версии UML есть подвид зависимости называемый <<derive>>. Им связывают элементы модели, такие что, один вычисляется из второго. Положение дел до вызова операции -- это базовый элемент, на основе которого вычисляется / <<derive>>-ится второй -- положение дел после вызова. В приведённом примере можно считать, что есть две спецификации экземпляра Class1, соединённые <<derive>>. По смыслу это один и тот же экземпляр, "снятый" в разные моменты времени. В кооперации, описывающей реализацию операции setFS(C,B), можно завести для этого 2 элемента.

7

UML SysML и пр. / Re: Diagram: Activity vs Sequence

« : 25 Июня 2022, 20:21:19 »

Одно и то же поведение может быть описано разными диаграммами. В зависимости от используемой диаграммы будут визуализированы разные аспекты этого поведения. Диаграмма последовательности визуализирует взаимодействие в рамках описываемого поведения, при чём выражает его в виде обменов сообщениями. Диаграмма деятельности визуализирует потоки управления и/или данных в рамках описываемого поведения, выражая их в виде действий и управления. Получается что два типа диаграмм дают два вида проекций. Разные проекции одного и того же поведения могут быть схожи до такой степени, что по потокам управления можно догадаться и/или "прочесть между строк" о том, каким будет взаимодействие. В другую сторону это тоже может быть справедливо. Но это не всегда так. Проекции могут существенно расходится.
Алгоритм, реализация операции могут быть описаны в обеих проекциях.
Выбор типа диаграммы определяется задачей, но это не задача, сформулированная так: "смоделировать алгоритм / операцию / что-то ещё". Это задача в формулировке которой указано, какой аспект важен: передача управления и/или данных между отдельными шагами или обмен сообщениями между объектами.

8

UML SysML и пр. / Re: Ассоциация внутри класса

« : 23 Июня 2022, 02:01:47 »

В современном прочтении, то, что соединяет такая связь, является частями (Part). Ассоциация не может соединять Part в нынешней версии стандарта. В другой теме мы обсудили, что вложенные классы и части композитной структуры рисуются сейчас разными. Части соединяет коннектор. Авторы стандарта избегают примеров диаграмм, где бы коннектор выходил за пределы объемлющего класса. И пишут про коннектор так, как-будто у коннектора (и соединяемых им частей) есть общий владелец-классификатор. Абстрактный синтаксис допускает, что у коннектора нет владельца, но примера в стандарте (как и пояснения к внутренней структуре чего относится такой коннектор) нет. Диаграмма из URM может быть допилена, чтобы потрафить стандарту, добавлением объемлющего классификатора и превращением кластера в part. И всё же, понравившийся пример был и останется уколом в дефекты UML, где конкретный синтаксис норовит войти в клинч с абстрактным.

P. S. Банкет от создателей Visual Paradigm:

В их голове это рифмуется с этим:

См. здесь.

9

UML SysML и пр. / Re: По каким критериям стоит разбивать 1 большую use case диаграмму на несколько

« : 23 Июня 2022, 01:24:59 »

Трактовка ассоциации, соединяющей актора и ВИ, как пути доступа -- это огрубление и переделывание стандартного смысла.
Если ДВИ рисуется при взгляде на систему как на "чёрный ящик", то о каких "конкретных модулях системы" может идти речь.
Чудесатое обсуждение.

10

UML SysML и пр. / Re: Диаграмма прецедентов /Актеры/

« : 23 Июня 2022, 01:06:42 »

Кручу-верчу, запутать хочу.

Средний "пень с глазами" -- это внутренний актор. Если верить, Алистеру Коберну. Т. к. у него SuD (System under Design) -- это актор. Т. к. это он в своей книге "WEUC" делит акторов на внутренних и внешних.
Учитывая подфорум, где задан вопрос, можно попытаться трактовать ситуацию с точки зрения стандарта языка. В стандарте нет следов коберновского деления. В стандарте нет примеров ДВИ с более чем 1 subject-ом. Абстрактный синтаксис не запрещает вкладывать классификаторы друг в друга, что, теоретически, даёт возможность рисовать ДВИ в коберновском стиле, когда система и актор оказываются внутри более крупной объемлющей их системы-сабджекта.

Стандарт лишь запрещает рисовать акторов в виде глазастых пней.)

11

UML SysML и пр. / Re: Вопрос по диаграмме деятельности

« : 16 Июня 2022, 00:36:59 »

Изначальная постановка вопроса указывает, что речь идёт о взаимодействии. Значит, используя диаграмму деятельности, аспекты взаимодействия изобразить не удастся. Что и подтвердилось в ходе обсуждения.

12

UML SysML и пр. / Re: Абстрактный вариант использования

« : 16 Июня 2022, 00:32:02 »

Продолжение тут: https://www.uml-diagrams.org/use-case.html#abstract-use-case
Тема, видимо, неисчерпаемая.

13

UML SysML и пр. / Re: Ортогональное составное состояние

« : 16 Июня 2022, 00:11:31 »

Арлоу и Нейштадт тут просто напутали. Выше на стр. 495 написано (тоже с некоторой путаницей), что нет синхронизации параллельных регионов в смысле, что второй не выходит, пытаясь догнать вышедший первый, и что мы не ждём когда выйдут оба. Остальные "просто прерывают выполнение". Т. е. в них жёсткий останов без совершения действий во выходу и т. п..
Путаницу можно усилить, слив два exit point-а в один. Тогда слитный exit point будет работать как join. Т. е. будет синхронизация. Чудеса, да и только.
IBMшики взяли себе за правило рисовать лишь один переход, ведущий в exit point.

14

UML SysML и пр. / Re: Количество потоков примера

« : 15 Июня 2022, 22:25:03 »

Вопрошающему стоило указать, реальные решения:
- продублировать decision-ы для потока документов и для потока резолюций;
- укрупнить объектные токены, чтобы в 1 токен влезала пара документ+резолюция;
- забыть про datastore как про страшный сон.

15

UML SysML и пр. / Re: UML 2 Profiles Package: Как расширить Operation?

« : 15 Июня 2022, 20:01:15 »

Ну как тут мимо пройти...

Infrastructure::Core::Constructs::Operation -- это имя конкретного экземпляра метакласса, взятого из метамодели UML.
Infrastructure::Core::Constructs::Class -- это тип, к которому принадлежит любой экземпляр метакласса.
Нет нужды подставлять имя экземпляра вместо его типа.
В современной версии стандарта есть рис. 12.26, поясняющий это. Если заменить имя (значение слота name) экземпляра метакласса с "Class" на "Operation", то всё встанет на свои места.