Comments 15
Спасибо за информацию. О такой нотации не слышал. Покапаюсь. Уверен, что будет полезно. Можно в двух-трех словах описать, чем это нотация будет лучше для использования, чем например BPMN? Например для последней есть куча реализаций например и с симуляцией, что очень помогает прогонять процесс перед тем, как они будут реализованы.
Привет, у них разная задача:
С4 - описать статичную архитектуру;
BPMN - описать процесс, последовательность.
Мы на четвертом уровне описываем интеграционные процессы с помощью UML sequence, это аналог BPMN.
Почему мы выбрали UML sequence, а не BPMN? Просто наши пользователи больше с этой нотацией знакомы=)
Вопрос и к Дмитрию и к комментатору: а зачем системные взаимодействия описывать в BPMN? Напомню, что BPMN - это Business Process Model and Notation. То есть сразу в названии, что это бизнес процессы, а не системные. Соответственно системный взаимодействия из С4 абсолютно правильно описывать в сиквенсе
Абсолютно правильно говорите. Это еще одна причина по которой мы выбрали sequence для описания системных взаимодействий.
Но на моей практике(Другая работа) иногда приходилось описывать системные взаимодействия в BPMN, просто потому что потребитель не знал sequence и не готов был в нем разбираться.
А что, разрабатываемая система потом будет существовать в вакууме? Вот в примерах в статье у нас по два пользователя - конечный пользователь и пользователь-администратор. Когда пытаешься понять, как именно различные пользователи (особенно когда их > 3 категорий) будут участвовать в общем процессе, удобнее описывать это BPMN. Как отметил комментатор ниже, в виде Sequence Diagram такая схема будет нечитаема.
Вообще, странен переход от C4 к Sequence, т.к. последний вид диаграмм описывает процессы, (причём требует очень точного описания, иначе читать невозможно) тогда как C4, судя по его описанию, описывает систему в виде статичных её классов - просто в разном уровне детализации. Например, допустимую последовательность деплоя сервисов (контейнеров) из неё не почерпнуть.
Тогда как Sequence Diagram - это "микроописание" деталей поведения кусков системы. И в случае большого количества акторов, BPMN будет намного понятнее - это будет своего рода Sequence Diagram, "вид сверху" (лишённый, разумеется, визуализации хронологической одновременности параллельных процессов).
Я бы не был так категоричен в отождествлении BPMN и UML sequence. В диаграммах последовательности всё очень сложно с условным ветвлением. По сути надо декомпозировать все процессы до компонентов без ветвления или с одним простым ветвлением. Иначе сиквенс превращается в нечитабельный буллшит
BPMN в этом отношении гораздо богаче и гибче.
каждый козел придумывает свой способ обхода огорода
каждый козел придумывает свой способ обхода огорода
Конечно это так, и изобретаются мноие вещи вновь и вновь. Но ведь это нас больше движет вперёд, чем тормозит. Вы ведь тоже не под DOS 1.0 работать хотите?
Иногда есть нотации, которые держаться столетиями.Например музыкальные ноты, дорожные знаки, или например электрические схемы. Но и у тех и у других изменения хоть и приходят, но они гармонично вливается в уже существующие правила. С процессами и с Софтом всё немного динамичнее. Хотя и там есть желание всё сделать стандартным, найти общий знаменательный всегда легко.
Какой макрос в Confluence используете для построения диаграмм?
Вы используете какой-нибудь архитектурный репозиторий для моделей, или рисуете каждую из них "на коленке" и потом в confluence связываете url-ами?
А кто рисует такие диаграммы и из кого он достаёт всю нужную информацию?
Как описать большую систему в нотации С4