38 KiB
2x-aC
Комент к Architecture As Code (AaC): от рисунка на салфетке к инструменту анализа
1 term
Много всякого "ХХ as Code": Архитектура (программная, корпоративная и другая), BP (business process, бизнес-процесс), инфраструктура, документация и т.п. И все это - "КАК КОД".
1.1 DaC
Наиболее понятное - Диаграмма как код (DaC, diagram as code) - это типа написал скрипт на dot, plantUML, mermaid (github) и т.п., нажал кнопку показать и у тебя "сама нарисовалась схема". Собственно мои проекты - это про это же:
- знания как код, RDF - grapher как on-line сервис: вместо https://www.ldf.fi/service/rdf-grapher см. https://github.com/bpmbpm/rdf-grapher/tree/main/ver1
- graphviz-online см. https://github.com/bpmbpm/graphviz-online/tree/main/ver1 - удивительно, в оригинальном graphviz-online не было поддержки тега image
- родословная как код https://github.com/bpmbpm/family-tree/tree/main/ver6 например, см. export
Собственно все эти DaC - это и есть 1х-aC, т.е. кодирование чего-либо (архитектуры, процессов, предков и т.п.) скриптом для последующего отображения в виде схемы.
Формула: скрипт - схема, построенная автоматически по коду \ скрипту.
Более того, совсем не важно скрипт это или таблица. Технология Smart Design строит ровно такие же схемы по таблице, см. [ВРМ. Смарт-инструменты «Таблица -> Схема» для формализации бизнес-процессов. Рестайлинг ARIS SmartDesign(https://habr.com/ru/articles/810851/).
Более того, есть разные автопостроители, которые делают ровно тоже самое, но без таблиц и без кода, например, автопостроитель в visio (авторазмещение фигур, layout), но не мастер типа org-structure (этот мастер построитель по таблице excel).
Это к тому, что код (скрипт) - таблица или иной формализм для построения схемы - все это DaC \ 1х-aC. Также, часто вместо схемы достаточно построить граф, и это будет "Граф как код".
1.2 Mining
Как было сказано Проблемы EA и BPM - схожие
Та же самая проблема, когда «as is» отличается от «as-really-is», см. Инструментальный Цифровой двойник
Одно дело, когда мы (процессники, архитекторы и т.п.) смотрим на "потолок" (процесс), на программный код или еще куда-то и Сами рисуем схему или пишем dot\mermaid (неважно рисуем сразу или вначале скрипт). Никакой гарантии нет, что это действительно адекватно реальности. Ошибки, фантазии, воображения и т.п. категории "человеческий фактор".
Поэтому, мы включаем "Инструментальный подход", например, process mining в случае с BPM. Тогда мы получаем «as-really-is». Тоже самое с архитектурой (включая solution) и инфраструктурой (включая network infrastructure, например, раскрытие сети).
Одно из хороших было бы решений - это Autodiscover для автопостроения формы № 0409072, см. «Архитектура в Графе». Графическая визуализация формата CSV/| формы «Операционной надежности и ИТ» (№ 0409072)
В итоге:
2х-aC = 1х-aC + Autodiscover,
т.е. классический DaC + какая-либо технология класса «as-really-is».
Если mining - это как бы "обратная разработка", то варинат "прямой разработки" класса 2х-aC, это когда по схеме генерится код, например, как в исполняемом BPMN (BPMN-engine, Camunda, Activiti, jBPM, Runa). Да, и там по схеме генерится только часть кода (нет пока реального "no-code"), поэтому для "архитктура как код" класса 2х-aC вполне достаточно генерации скелета кода, классов и т.п. Кстати это в 2000 году делал ARIS из нотации EPC (генерировал скелет кода на С), а "звездный час" Rational Rose - он поддерживает генерацию кода и обратное проектирование казалось "перевернет" перевернет мир программирования, как это сейчас происходит с vibe coding.
Полагаю, что 2х-aC в связке с LLM создадут отдельное направление в vibe coding. Хотелось что-бы все-же это было "на троих", где третий - онтология \ linked data, см. на примере Semantic BPM.
Таким образом, 2х-aC в версии "прямая разработка" - это MBSD, где модель процесса (архитектуры) является активным реальным артефактом, управляющим поведением программы, а не просто красивой картинкой в спецификации (картинкой на салфетке или на экране ARIS - не принципиально). В случае 2х-aC в версии "обратная разработка" - это mining \ Autodiscover. В обоих случаях - это "графика" с промежуточным скриптовым представлением (dot\plantUML или даже RDF\OWL) или таблицей.
1.3 link (DaC&AaC)
В папке https://github.com/bpmbpm/doc/tree/main/visualization/diagramascode собирал по DaC\AaC, задавал вопросы, например,
Архитектура как код - это не про визуализацию нарисованной модели,
не диаграмма, как код, то есть рисуем из головы скрипт, который отображается в графике.
А это же именно когда автоматические данные берутся из конфига систем, скриптуются и отображаются в виде диаграмм.
Видимо, нужно какой-то термин уточняющий дать. Например, архитектура как код - это извлечение архитектурных артефактов, а диаграмма
как код - это, ну, рисование архитектурных артефактов. Термин есть такой, он называется Autodiscover.