51

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

« Последний ответ от [прилетело НЛО и...] 17 Марта 2023, 15:47:24 »

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

52

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

« Последний ответ от [прилетело НЛО и...] 17 Марта 2023, 15:42:01 »

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

53

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

« Последний ответ от [прилетело НЛО и...] 18 Декабря 2022, 03:55:59 »

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

54

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

« Последний ответ от konung2112 28 Ноября 2022, 11:56:33 »

Добрый день. Я знакомлюсь со стандартом BPMN, и прошу подсказать правильно ли я понимаю границы (масштабы) в которых может быть определен Definition

Definition - это корневой элемент модели. Как я выяснил, изучая стандарт, особенностью BPMN является модель может входить множество процессов (Process). Вообще Definition может содержать множество RootElement-во, в число которых могут входить процессы (Process), Взаймодействия (Collaboration), Диаграммы (BPMNDiagram).
Как понять в каких масштабах нужно использовать Definition и его содержимое:
У меня 2 альтернативных варианта понимания/использования Definition :
 - в нем должны содержаться все процессы процессы (Process) компании, которых могут быть десятки или сотни процессов и сопоставимое количество диаграмм, взаимодействий (Collaboration), участников (Participant) - то есть Definition - это база данных процессов одной компании или подразделения.
 - в нем должны содержаться один процесс или несколько связанных процессов, участвующих в одном Взаимодействии (Collaboration), которые можно представить на одной диаграмме.

Обобщение вопроса: Как правильнее использовать Definitions - складывать все модели в один Definitions или использовать множество Definitions импортирующий и вызывающих друг друга?

55

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

« Последний ответ от [прилетело НЛО и...] 18 Августа 2022, 13:00:11 »

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

56

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

« Последний ответ от [прилетело НЛО и...] 06 Июля 2022, 01:07:36 »

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

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

57

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

« Последний ответ от Vadim 27 Июня 2022, 11:02:39 »

По ссылке https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-composite-structure-diagram/ смотрел "Deriving Composite Structure Diagram from Class Diagram" и так и не понял, что предлагается:
   1. использовать диаграмму составной структуры вместо диаграммы классов
   2. использовать диаграмму составной структуры вместе с диаграммой классов
И в одном, и в другом варианте вижу проблемные места:
   если 1., то не всё выражено
   если 2., то есть нестыковки

58

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

« Последний ответ от [прилетело НЛО и...] 25 Июня 2022, 20:47:17 »

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

59

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

« Последний ответ от [прилетело НЛО и...] 25 Июня 2022, 20:21:19 »

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

60

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

« Последний ответ от [прилетело НЛО и...] 23 Июня 2022, 02:01:47 »

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

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

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

См. здесь.