30. Миграция из UML- и ArchiMate-инструментов

Большинство читателей этой книги не пользовались UML, ArchiMate или другими средствами моделирования корпоративной архитектуры. Если вы не пользовались, пропустите эту главу; это руководство по переводу, а не учебник.

Если же вы ими пользовались — и особенно если пытаетесь мигрировать существующую модель — эта глава отображает ваш словарь на словарь ArchLang. Соответствия не всегда один-к-одному. У нескольких концепций EA нет эквивалента в ArchLang, потому что язык намеренно их отверг. У нескольких концепций ArchLang нет чистого эквивалента в EA, потому что язык их сознательно добавил.

Кнопки импорта нет

Сразу зададим ожидание, потому что именно его чаще всего понимают неправильно: ArchLang не может импортировать ваши диаграммы EA. Нет конвертера для проприетарных файлов моделей, нет импортёра Structurizr DSL, нет читателя ArchiMate XML, нет парсера диаграмм C4. Это не отсутствующая функция в дорожной карте — это структурно.

Причина — ключевая инверсия (глава 7): рёбра ArchLang выводятся из процессов, а не рисуются. В вашем инструменте EA вы поставили две коробки и протянули между ними стрелку с подписью «Used-By». Эта стрелка — рисунок. ArchLang некуда её поместить — зависимость существует только потому, что какой-то шаг процесса говорит Caller > Callee.Interface. Нет ничего, во что можно механически перевести нарисованную стрелку, потому что стрелка никогда не была источником истины; она была её картинкой.

Поэтому миграция — это ручное ремоделирование, а не конвертация. Вы заново выражаете смысл старой модели в терминах ArchLang — а смысл, в части рёбер, живёт в ваших диаграммах последовательностей и активностей, а не в диаграммах компонентов. Попытка механически перенести коробки-и-линии порождает модель, которая выглядит как старая и ничего не значит: груда модулей со стрелками, за которыми не стоит ни один процесс.

Правило. Не воспроизводите нарисованные рёбра. Ремоделируйте по предметным областям в два прохода — сначала модули (актёрский состав), затем процессы (сюжет) — и пусть стрелки зависимостей выпадают из шагов процессов. Архитектура — это описание, которое вы пишете, а не рисунок, который вы переносите. Если за стрелкой на старой диаграмме не стоит процесс, она не переживает переезд, и это правильно.

Почему соответствия не чисты

Традиционные инструменты EA строились на нескольких посылках, которые ArchLang не разделяет:

• Диаграммы — основной артефакт. Моделеры рисуют коробки и стрелки; модель — это картинка. ArchLang переворачивает это: модель — это текст, а диаграммы — производные проекции (глава 14).
• Онтология большая и фиксированная. Только в ArchiMate 50+ типов концепций (Business Actor, Business Service, Application Function, Technology Process, …). У ArchLang четыре примитива (модуль, интерфейс, процесс, проекция) плюс пользовательские типы. Онтология маленькая и расширяемая.
• TO-BE vs AS-IS явные. Моделеры носят флаги или дублируют элементы, чтобы отличать текущее состояние от предлагаемого. В ArchLang такого нет — будущее состояние это ветки Git (глава 14 снова).
• Стереотипы / архетипы / шаблоны как отдельный механизм. Множественные параллельные механизмы для «эта штука — разновидность чего-то». ArchLang сводит их в один: шаблоны типов-форм (глава 15).

Дальше — как выразить ваши существующие концепции, что отбросить и что нового.

Сопоставление базовых элементов

Концепция EA	ArchLang
Application component	service (или любой пользовательский подтип)
Application service	interface на сервисе
Business component	module (часто system для группировки верхнего уровня)
Business service	interface на модуле бизнес-компонента
Business actor / role	user (тип модуля из стандартной библиотеки)
Business process	process
Technology component	service, database, gateway. Брокер/очередь обычно транспорт, а не узел — моделируйте логический вызов и прикрепляйте брокер как аспект (глава 26). Делайте его модулем message_broker, только если ваши сервисы вызывают его административный API.
Technology service	interface
Data object / artifact	Поле модуля, который его производит или владеет (не отдельный примитив)
Capability	surface на модуле или пользовательский тип поверхности
Stereotype	Декларация type (type service payment_service { ... })
Archetype	То же, что и стереотип, — декларация type
Template	То же, что и стереотип, — декларация type

Первое наблюдение: три колонки ArchiMate (Business / Application / Technology) сворачиваются в одно дерево ArchLang. Слои в ArchiMate становятся аспектами в ArchLang (aspect layer: business, aspect layer: application, …), а проекции режут по слою, когда нужно.

Связи

Связь EA	ArchLang
Composition (whole-part)	Вложенность (service X { component Y { ... } }) или клауза in
Aggregation	Реже; обычно достаточно вложенности
Realization	Интерфейс ЕСТЬ реализация. Не моделируйте отдельно.
Assignment (actor to process)	Шаг процесса, где актор — вызывающий
Used-by	Шаг процесса (caller > callee.interface)
Triggering	Шаг процесса (синхронный или асинхронный — решает тип интерфейса на вызываемой стороне)
Flow	Шаг процесса
Specialization	Подтип в системе типов
Association	Если не одно из перечисленного, скорее всего, оно вам не нужно

Самый большой скачок: большинство типов связей EA сворачивается в «шаг процесса» или «вложенность». Причина: шаги процессов фиксируют причинность; вложенность фиксирует владение; остальное — детали.

Сдвиг мышления. Инструменты EA побуждают сначала рисовать связи. Вы проводите стрелку между двумя компонентами и подписываете «Used-By» или «Triggers». ArchLang переворачивает это — вы сначала пишете шаги процесса, а стрелки выводятся. Если вам хочется добавить связь, которая не является шагом процесса или вложенностью, спросите, является ли нижележащий факт причинностью (используйте процесс), владением (используйте вложенность) или классификацией (используйте аспект или тип). Почти всё сводится к этой тройке.

Что не переносится

У нескольких концепций EA нет эквивалента в ArchLang. Это не упущение — они были намеренно исключены.

Маркеры TO-BE / AS-IS. В ArchLang нет поля статуса на декларациях. Эту роль играют ветки git. Ваша модель «текущего состояния» живёт на main; ваша модель «предлагаемого состояния» живёт в ветке функции. Структурный дифф (глава 14) показывает дельту.

При миграции: если в вашей модели EA есть артефакты TO-BE, отбросьте их. Используйте ветки.

Флаги new / changed / existing. То же, что выше. Движок диффа выводит их, сравнивая два снапшота модели.

Несколько параллельных «видов» одного и того же элемента. В инструменте, где первична диаграмма, один и тот же физический сервис может появляться на пяти разных диаграммах, на каждой с разными нарисованными связями. В ArchLang модель одна; проекции — это её срезы. У сервиса может быть пять проекций; все они читают из одной канонической записи.

Свободнотекстовые «стереотипы», навешенные на элементы. Инструменты EA позволяют помечать любой элемент произвольными строками-стереотипами. ArchLang требует, чтобы стереотип был объявленным типом. Выгода: правила уровня типа (обязательные пустые слоты, поведение каскада) привязываются к стереотипу. Цена: нельзя просто шлёпнуть аспект и идти дальше.

При миграции: разберитесь, что на самом деле означают ваши стереотипы, и запишите их как декларации type.

Аннотации ограничений в свободном тексте. Инструменты EA позволяют писать OCL-ограничения в заметках, которые читают люди, а инструменты игнорируют. ArchLang требует, чтобы ограничения были проверяемыми — обязательные пустые слоты (глава 17) и правила валидации (глава 28). Модель кодирует только то, что валидатор может проверить.

Что нового

У нескольких идей ArchLang нет эквивалента в EA. Они стоят отдельной кривой обучения.

Стабильные идентификаторы. Инструменты EA используют имена как идентичность. ArchLang использует непрозрачные идентификаторы (глава 13), так что переименования не ломают ссылки. У инструментов, где первична диаграмма, эквивалента нет — переименование там молча ломает каждую диаграмму, ссылавшуюся на старое имя.

Модель типов как форма-шаблон. Инструменты EA имеют стереотипы; ArchLang имеет шаблоны-формы, которые штампуют содержимое. Разница: стереотипы — это аспекты. Шаблоны-формы — это требования, которые распространяются. Стереотип, говорящий экземплярам «вы обязаны заполнить team», проверяется на этапе разбора. Ближайший аналог в инструментах EA — «tagged value с mandatory=true», но распространения там нет.

Два сочетаемых механизма распространения. Штамповка шаблоном (механизм A) плюс структурный каскад (механизм B) — вместе они позволяют одному аспекту или полю, заданному на родительском модуле, дотянуться до каждого вложенного элемента. У инструментов EA эквивалента нет; они требуют выставлять значение на каждом элементе явно. См. главу 18.

Git как система записи. Инструменты EA хранят модели в проприетарных файлах (или в бэкенде Oracle/SQL Server). ArchLang хранит файлы .arch в вашем репозитории, рядом с кодом, который они описывают. Модель можно ревьюить в pull-запросах, ветвить, мерджить. Никакого импорта/экспорта при миграции — как только всё в файлах .arch, инструмент — git.

Подход к миграции

Для существующей модели EA с ~500 элементами:

Фаза 0 — Решите, что оставить. Большинство моделей EA накапливают мусор за годы. Определите ключевые 50-100 элементов, отражающие реальную текущую архитектуру. Остальное отложите.

Фаза 1 — Сначала определите свои типы. Посмотрите на используемые стереотипы. Решите, какие из них отображаются на существующие типы стандартной библиотеки (service, database, external_system, user, frontend), а какие требуют пользовательских типов (глава 29). Напишите types.arch первым.

Фаза 2 — Ремоделируйте модули в изоляции (первый проход). Идите модуль за модулем. Объявите каждый в файлах .arch с его типом, именем, командой и ключевыми аспектами и добавьте его интерфейсы — но пока не думайте о связях. Не переносите ни единой стрелки. Это первый из двухпроходного потока (лучшие практики): опишите актёрский состав до сюжета. Голые модули — это нормально; вы фиксируете то, чем каждая вещь является, а не то, как она связывается.

Фаза 3 — Ремоделируйте процессы (второй проход). Теперь связи. Пройдитесь по старым диаграммам последовательностей и активностей — тем, что кодируют реальную причинность и порядок — и заново выразите каждую как process. Стрелки зависимостей возникают из шагов процессов; вы никогда их не рисуете. Что важно, ваши диаграммы компонентов (картинки коробок-и-линий) здесь не входные данные — стрелка там, за которой нет поведения, не во что превратиться и не должна пережить переезд.

Фаза 4 — Добавьте проекции. Воссоздайте сохранённые диаграммы как декларации view, используя show/hide и group by @@…, style для акцентов/цвета и представление table/matrix/flow там, где старая проекция была таблицей или диаграммой последовательности/потока.

Фаза 5 — Добавьте валидацию. Определите правила, принудительной проверки которых вам не хватало в старом инструменте, — обязательные URL runbook, обязательные аспекты соответствия, обязательные команды. Закодируйте их как required пустые слоты на ваших типах.

К концу у вас будет ~половина того исходника, что был раньше (ArchLang компактнее), ноль сломанных диаграмм и впервые — возможность ревьюить архитектуру в pull-запросах.

К чему стоит реалистично готовиться

• Первые диаграммы будут выглядеть иначе. Раскладки ArchLang (ELK, Dagre) — авторазмещение; вы не можете расставлять узлы попиксельно. Когда вы впервые сгенерируете диаграмму из мигрированной модели, она будет выглядеть непривычно. Через неделю большинство людей предпочитают авторазмещение из-за консистентности.
• Вы потеряете часть функций EA-пакета. Календарное прогнозирование, инструменты gap-анализа, специфичные для ArchiMate viewpoint-фреймворки — этого в ArchLang нет. Если это критично для вашей организации, оцените, стоит ли держать их параллельно (старый пакет для этих отчётов, ArchLang для архитектуры).
• Кастомные скрипты не перенесутся. Они написаны против скриптового API вашего EA-пакета. Эквивалент в ArchLang — @archlang/engine (глава 24) — писать легче, но цена переписывания реальная.
• Словарь устаканивается неделями. Команды, привыкшие к «Application Service» + «Business Process» + «Information Object», поначалу будут неуклюже выражаться в словаре ArchLang. Главы книги ускоряют переход; сопротивляйтесь желанию буквально воссоздать словарь EA в виде пользовательских типов.

Итоги

• Кнопки импорта нет — нет конвертера проприетарных моделей / Structurizr / ArchiMate / C4. Миграция — это ручное ремоделирование, потому что рёбра выводятся из процессов, а не из рисунков.
• Не воспроизводите нарисованные рёбра; ремоделируйте по предметным областям в два прохода (модули, затем процессы) и пусть стрелки выпадают из шагов процессов. Архитектура — это описание, а не инструмент рисования.
• Большинство концепций EA отображается на модуль / интерфейс / процесс / проекцию, стереотипы становятся типами.
• Слои ArchiMate становятся аспектами; проекции режут по слою. Брокер — это транспорт (аспект), а не узел.
• Маркеры TO-BE / AS-IS заменены ветками git.
• Стабильные идентификаторы решают проблему «переименование ломает всё», которую инструменты, где первична диаграмма, так и не решили.
• Шаблоны-формы плюс структурный каскад заменяют стереотипы-с-tagged-values плюс ручную конфигурацию каждого элемента.
• Подход к миграции: сначала типы, затем модули в изоляции, затем процессы, затем проекции, затем валидация.

Конец части VI

Это вся книга — двадцать девять глав от трёх обязательств предисловия через шесть разобранных примеров. Приложения (Грамматика, Ключевые слова, Типы стандартной библиотеки, Шпаргалка) — плотный справочник, когда вы знаете, что ищете.

Если вы прочитали каждую главу по порядку, теперь у вас есть язык, метамодель, инструменты и ощущение того, как моделируются реальные системы. Следующий шаг — ваш собственный файл .arch и тот цикл, который дают расширения редактора: вы сохраняете — и диаграмма обновляется. Именно в этом цикле язык окупает себя.