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

×


Последние сообщения

Страницы: « 1 2 3 4 5 6 7 8 9 10 »
41
Мне кажется, что Ваш вопрос относится не к языку, а к технологии. Язык, упрощённо говоря, даёт систему обозначений. Как эту систему обозначений применить для решения конкретной задачи, -- это определяется процессом. Т. е. в стандарте языка Вы не найдёте ответа на Ваш вопрос. En-wiki упоминает такую книгу как "The Process: Business Process Modeling using BPMN". Ну или что-то переводное. Сами видите, старожилы форума безмолвствуют, марсиане правят бал.(
42
Теория моделирования и нотации / 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 импортирующий и вызывающих друг друга?
43
ПО Аналитика / Re: Новости от Visual Paradigm
« Последний ответ от [прилетело НЛО и...] 18 Августа 2022, 13:00:11 »
Выпущен VP 17.0
https://www.visual-paradigm.com/whats-new/
Что-то добавили в SysML/UML.
Будем посмотреть.
44
UML SysML и пр. / Re: Ассоциация внутри класса
« Последний ответ от [прилетело НЛО и...] 06 Июля 2022, 01:07:36 »
Мне понравилась последняя диаграмма.

Нижний коннектор, соединяющий модули памяти с материнкой, имеет мультиплисити. Части BasicPC, соединяемые им, имеют мультиплисити. И порты на концах коннектора имеют мультиплисити. Чтобы убедиться в том, что 1 модуль памяти втыкается в 1 разъём и при этом всё сходится, необходимо сверить 5 явных цифирь и одну неявную.
45
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., то есть нестыковки
46
В современной версии UML есть подвид зависимости называемый <<derive>>. Им связывают элементы модели, такие что, один вычисляется из второго. Положение дел до вызова операции -- это базовый элемент, на основе которого вычисляется / <<derive>>-ится второй -- положение дел после вызова. В приведённом примере можно считать, что есть две спецификации экземпляра Class1, соединённые <<derive>>. По смыслу это один и тот же экземпляр, "снятый" в разные моменты времени. В кооперации, описывающей реализацию операции setFS(C,B), можно завести для этого 2 элемента.
47
UML SysML и пр. / Re: Diagram: Activity vs Sequence
« Последний ответ от [прилетело НЛО и...] 25 Июня 2022, 20:21:19 »
Одно и то же поведение может быть описано разными диаграммами. В зависимости от используемой диаграммы будут визуализированы разные аспекты этого поведения. Диаграмма последовательности визуализирует взаимодействие в рамках описываемого поведения, при чём выражает его в виде обменов сообщениями. Диаграмма деятельности визуализирует потоки управления и/или данных в рамках описываемого поведения, выражая их в виде действий и управления. Получается что два типа диаграмм дают два вида проекций. Разные проекции одного и того же поведения могут быть схожи до такой степени, что по потокам управления можно догадаться и/или "прочесть между строк" о том, каким будет взаимодействие. В другую сторону это тоже может быть справедливо. Но это не всегда так. Проекции могут существенно расходится.
Алгоритм, реализация операции могут быть описаны в обеих проекциях.
Выбор типа диаграммы определяется задачей, но это не задача, сформулированная так: "смоделировать алгоритм / операцию / что-то ещё". Это задача в формулировке которой указано, какой аспект важен: передача управления и/или данных между отдельными шагами или обмен сообщениями между объектами.
48
UML SysML и пр. / Re: Ассоциация внутри класса
« Последний ответ от [прилетело НЛО и...] 23 Июня 2022, 02:01:47 »
В современном прочтении, то, что соединяет такая связь, является частями (Part). Ассоциация не может соединять Part в нынешней версии стандарта. В другой теме мы обсудили, что вложенные классы и части композитной структуры рисуются сейчас разными. Части соединяет коннектор. Авторы стандарта избегают примеров диаграмм, где бы коннектор выходил за пределы объемлющего класса. И пишут про коннектор так, как-будто у коннектора (и соединяемых им частей) есть общий владелец-классификатор. Абстрактный синтаксис допускает, что у коннектора нет владельца, но примера в стандарте (как и пояснения к внутренней структуре чего относится такой коннектор) нет. Диаграмма из URM может быть допилена, чтобы потрафить стандарту, добавлением объемлющего классификатора и превращением кластера в part. И всё же, понравившийся пример был и останется уколом в дефекты UML, где конкретный синтаксис норовит войти в клинч с абстрактным.

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

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

См. здесь.
49
Трактовка ассоциации, соединяющей актора и ВИ, как пути доступа -- это огрубление и переделывание стандартного смысла.
Если ДВИ рисуется при взгляде на систему как на "чёрный ящик", то о каких "конкретных модулях системы" может идти речь.
Чудесатое обсуждение.
50
UML SysML и пр. / Re: Диаграмма прецедентов /Актеры/
« Последний ответ от [прилетело НЛО и...] 23 Июня 2022, 01:06:42 »
Кручу-верчу, запутать хочу.

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

Стандарт лишь запрещает рисовать акторов в виде глазастых пней.)
Страницы: « 1 2 3 4 5 6 7 8 9 10 »