Comments 20
Смотрю схему https://habrastorage.org/r/w1560/getpro/habr/upload_files/042/d66/a5f/042d66a5f34e041acdf9d9d7d65749b4.jpg
Допустим у нас есть неактивные депозиты.
В таком случае мы должны их подсветить.
Вопрос: где мы их подсвечиваем, если список депозитов выводится только в случае отсутствия неактивных депозитов?
Как понять блок не показывать виджет?
Именно "не показывать", а не "убрать"
Ничего не делать? зачем тогда этот блок нужен?
Да, стоит переименовать действие "В списке подсветить неактивные депозиты" на "Показать список депозитов активных и подсвеченными неактивными", а действие " Показать список" Заменить на "Показать список активных депозитов".
Не показывать и убрать в данном случае синонимы, это значит информации по депозитам не должно быть на сайте
Просто представьте, что помимо «активный/неактивный» у вас завтра появится ещё 4 категории депозитов и 4 разновидности их подсветок. Сколько ветвлений вам придётся сделать? 2 в пятой степени, для каждой возможной комбинации (это в лучшем случае, если все категории — бинарные)?
Более понятным подходом было бы оставить один блок «Послать проверенный список в виджет», безо всяких ветвлений, а к нему прилинковать отдельную спецификацию для отображения виджета и его элементов, вроде
Если список депозитов пуст, скрыть виджет.
Список депозитов отсортировать по [времени|активности|...].
Для каждого элемента списка депозитов:
Если депозит неактивный, то подсветить.
...
P.S. Кроме того, блок «Получить список депозитов» должен именоваться как «Запросить список депозитов», потому что событием, передающим управление от сайта к сервису, является «запрос», а «получение» — это событие-ответ, следущее за запросом, и там могут быть варианты, включающие «нет ответа».
Насчёт переименования, здесь именно показать список, потому что в сервисе есть сформиоовать. Нужно в сервисе показать отправить, но для упрощения схемы это действие пропустила.
Про ветвления: в моём кейсе именно два, поэтому их можно вот так отобразить и наглядность схемы не пострадает. В вашем примере да, согласна, что ветвлений станет много и схема станет нечитаемой.
По моему опыту не стоит усложнять варианты ветвления: как только появляются коллекции "крестов" внутри ромбов - заказчик "плывет". Я ставлю ромб, внутри условие, например "депозиты есть?" и два выхода: да/нет. Наглядно.
Bpmn, как и любая другая блок-схема, не работает, если участники не знают контекст и не погружены в значение значков, при этом считается, что bpmn отличается от блок-схем как раз одинаковым пониманием. На самом деле это не так, что и показал ваш опыт. По схеме нельзя создать код, нельзя описать идею, это просто некая отрисовка основных моментов и возможно каких-то опорных точек в процессе. Даже если все и все понимают и уже тысячу раз проговорили детали, технология и схемотехника не заменит подход человека к этим задачам. Ну и bpmn нужно уметь знать и понимать не хуже, чем уметь сопоставлять разные трактовки святого писания, а это умеет делать не так много людей.
Не уверен, что bpmn это нотация для системных аналитиков, она скорее нужно бизнес-аналитикам. Системные аналитики по моему наблюдению используют flowchart, idef0, uml диаграммы. Если bpmn диаграмма нужна для команды разработки, то скорее для общего понимания бизнес-процесса, но для технического задания лучше использовать uml, idef0, flowchart.
Я бы аналитиков заставлял рисовать схемы для себя(для начала) - если получился осьминог, то задачу точно надо упрощать до щупальца. А потом уже презентовал там команде....Да и команде оно не надо...разрабу нужно щупальце, а оно укладывается в понятие сценарий, для которого сложные инструменты обычно только вредят.
У вас в схеме 2 (uml) не используются варианты, что искусственно ухудшает uml в пользу bpmn
Есть еще вот такой инструмент: https://www.websequencediagrams.com Меня в нем подкупила возможность вносить изменения в исходный код диаграммы в текстовом виде. Иногда это удобнее, чем двигать и подписывать элементы мышкой.
Спасибо! Очень похоже на plantuml, а для bpmn такого же не встречали?
К сожалению, только такой у меня в закладках есть.
Разве мы можем на схеме отображать клиента - пользователя и рисовать ему какое-то действие? На сколько я понимаю, мы не можем принимать за клиента никаких решений, поэтому верно бы было изобразить его в свёрнутом пуле.
Что касается Activity, то действий всего 4: Task, Call Activity, Transaction, Event Sub-Process. Всё остальное это типы задач и маркеры действий. ИМХО - может чутка запутать народ.
Дорожки могут служить не только для участников процесса, но и для категоризации / упорядочивания действий.
А вообще, я с Вами согласен, моделирование процессов открывает массу возможностей. У нас в компании до моего появления не использовалась ни одна нотация для моделирования, однако сейчас про моделирование процессов знают в каждом подразделении и сотрудники успешно читают модели. Я уверен, что вскоре мы будем рисовать модели все вместе)). Главное в таком деле не отступать).
Желаю Вам удачи.
А будут ли статьи с рассмотрением других аннотаций, кроме BPMN?
Спасибо за идею, подумаем. Пока есть статья по plantuml sequence и activity https://habr.com/ru/post/661931/
BPMN не в теории, а на практике