30. Миграция из Sparx / RSM / UML
Большинство читателей этой книги не пользовались Sparx EA, IBM Rational Software Modeler, ArchiMate или другими инструментами корпоративной архитектуры. Если вы не пользовались, пропустите эту главу; это руководство по переводу, а не учебник.
Если же вы ими пользовались — и особенно если пытаетесь мигрировать существующую модель — эта глава отображает ваш словарь на словарь Archlang. Соответствия не всегда один-к-одному. У нескольких концепций EA нет эквивалента в Archlang, потому что язык намеренно их отверг. У нескольких концепций Archlang нет чистого эквивалента в EA, потому что язык их сознательно добавил.
Почему соответствия не чисты
Традиционные инструменты 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 | actor (вид модуля из стандартной библиотеки) |
| Business process | process |
| Technology component | service, database; брокеры/очереди моделируются как external_system (встроенного вида queue нет) |
| Technology service | interface |
| Data object / artifact | Поле модуля, который его производит или владеет (не отдельный примитив) |
| Capability | facet на модуле или пользовательский вид фасета |
| Stereotype | Декларация type (type service payment_service { ... }) |
| Archetype | То же, что и стереотип, — декларация type |
| Template | То же, что и стереотип, — декларация type |
Первое наблюдение: три колонки ArchiMate (Business / Application / Technology) сворачиваются в одно дерево Archlang. Слои в ArchiMate становятся метками в Archlang (labels.layer: business, labels.layer: application, …), а проекции режут по слою, когда нужно.
Связи
| Связь EA | Archlang |
|---|---|
| Composition (whole-part) | Вложенность (service X { component Y { ... } }) или клауза in |
| Aggregation | Реже; обычно достаточно вложенности |
| Realization | Интерфейс ЕСТЬ реализация. Не моделируйте отдельно. |
| Assignment (actor to process) | Шаг процесса, где актор — вызывающий |
| Used-by | Шаг процесса (caller > callee.interface) |
| Triggering | Шаг процесса или subscribes: для асинхронного |
| 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. То же, что выше. Движок диффа выводит их, сравнивая два снапшота модели.
Несколько параллельных «видов» одного и того же элемента. В Sparx один и тот же физический сервис может появляться на пяти разных диаграммах, на каждой с разными нарисованными связями. В Archlang модель одна; проекции — это её срезы. У сервиса может быть пять проекций; все они читают из одной канонической записи.
Свободнотекстовые «стереотипы», навешенные на элементы. Sparx позволяет помечать любой элемент произвольными строками-стереотипами. Archlang требует, чтобы стереотип был объявленным типом. Выгода: правила уровня типа (обязательные пустые слоты, поведение каскада) привязываются к стереотипу. Цена: нельзя просто шлёпнуть метку и идти дальше.
При миграции: разберитесь, что на самом деле означают ваши стереотипы, и запишите их как декларации type.
Аннотации ограничений в свободном тексте. Sparx позволяет писать OCL-ограничения в заметках, которые читают люди, а инструменты игнорируют. Archlang требует, чтобы ограничения были проверяемыми — обязательные пустые слоты (глава 17) и правила валидации (глава 28). Модель кодирует только то, что валидатор может проверить.
Что нового
У нескольких идей Archlang нет эквивалента в EA. Они стоят отдельной кривой обучения.
Стабильные идентификаторы. Инструменты EA используют имена как идентичность. Archlang использует непрозрачные идентификаторы (глава 13), так что переименования не ломают ссылки. В Sparx эквивалента нет — переименование там молча ломает каждую диаграмму, ссылавшуюся на старое имя.
Модель типов как форма-шаблон. Инструменты EA имеют стереотипы; Archlang имеет шаблоны-формы, которые штампуют содержимое. Разница: стереотипы — это метки. Шаблоны-формы — это требования, которые распространяются. Стереотип, говорящий экземплярам «вы обязаны заполнить team», проверяется на этапе разбора. Ближайший аналог в Sparx — «tagged value с mandatory=true», но распространения там нет.
Два сочетаемых механизма распространения. Штамповка шаблоном (механизм A) плюс структурный каскад (механизм B) — вместе они позволяют одной метке или полю, заданному на родительском модуле, дотянуться до каждого вложенного элемента. У инструментов EA эквивалента нет; они требуют выставлять значение на каждом элементе явно. См. главу 18.
Git как система записи. Sparx хранит модели в проприетарных файлах .eapx (или в бэкенде Oracle/SQL Server). Archlang хранит файлы .arch в вашем репозитории, рядом с кодом, который они описывают. Модель можно ревьюить в pull-запросах, ветвить, мерджить. Никакого импорта/экспорта при миграции — как только всё в файлах .arch, инструмент — git.
Подход к миграции
Для существующей модели Sparx с ~500 элементами:
Фаза 0 — Решите, что оставить. Большинство моделей Sparx накапливают мусор за годы. Определите ключевые 50-100 элементов, отражающие реальную текущую архитектуру. Остальное отложите.
Фаза 1 — Сначала определите свои виды. Посмотрите на используемые стереотипы. Решите, какие из них отображаются на существующие виды стандартной библиотеки (service, database, external_system, actor, frontend), а какие требуют пользовательских типов (глава 29). Напишите kinds.arch первым.
Фаза 2 — Мигрируйте модули в порядке зависимостей. Начинайте с листьев — сервисов, которые никого не вызывают. Объявите их в файлах .arch с их видом, именем, командой и ключевыми метками. Добавьте интерфейсы. Процессы пока не рисуйте.
Фаза 3 — Добавьте процессы. Пройдитесь по диаграммам последовательностей и активностей в Sparx. Каждая становится process в Archlang. Стрелки на ваших диаграммах становятся шагами процесса.
Фаза 4 — Добавьте проекции. Воссоздайте сохранённые проекции Sparx как декларации view, используя focus, group by и layout.
Фаза 5 — Добавьте валидацию. Определите правила, принудительной проверки которых вам не хватало в Sparx, — обязательные URL runbook, обязательные метки соответствия, обязательные команды. Закодируйте их как required пустые слоты на ваших видах.
К концу у вас будет ~половина того исходника, что был в Sparx (Archlang компактнее), ноль сломанных диаграмм и впервые — возможность ревьюить архитектуру в pull-запросах.
К чему стоит реалистично готовиться
- Первые диаграммы будут выглядеть иначе. Раскладки Archlang (ELK, Dagre) — авторазмещение; вы не можете расставлять узлы попиксельно. Когда вы впервые сгенерируете диаграмму из мигрированной модели, она будет выглядеть непривычно. Через неделю большинство людей предпочитают авторазмещение из-за консистентности.
- Вы потеряете часть функций Sparx. Календарное прогнозирование, инструменты gap-анализа, специфичные для ArchiMate viewpoint-фреймворки — этого в Archlang нет. Если это критично для вашей организации, оцените, стоит ли держать их параллельно (Sparx для этих отчётов, Archlang для архитектуры).
- Кастомные скрипты Sparx не перенесутся. Они написаны против Sparx COM API. Эквивалент в Archlang —
@archlang/core(глава 24) — писать легче, но цена переписывания реальная. - Словарь устаканивается неделями. Команды, привыкшие к «Application Service» + «Business Process» + «Information Object», поначалу будут неуклюже выражаться в словаре Archlang. Главы книги ускоряют переход; сопротивляйтесь желанию буквально воссоздать словарь EA в виде пользовательских видов.
Итоги
- Большинство концепций EA отображается на модуль / интерфейс / процесс / проекцию, стереотипы становятся типами.
- Слои ArchiMate становятся метками; проекции режут по слою.
- Маркеры TO-BE / AS-IS заменены ветками git.
- Стабильные идентификаторы решают проблему «переименование ломает всё», которую Sparx так и не решил.
- Шаблоны-формы плюс структурный каскад заменяют стереотипы-с-tagged-values плюс ручную конфигурацию каждого элемента.
- Подход к миграции: сначала виды, затем модули от листьев, затем процессы, затем проекции, затем валидация.
Конец части VI
Это вся книга — двадцать девять глав от трёх обязательств предисловия через шесть разобранных примеров. Приложения (Грамматика, Ключевые слова, Виды стандартной библиотеки, Шпаргалка) — плотный справочник, когда вы знаете, что ищете.
Если вы прочитали каждую главу по порядку, теперь у вас есть язык, метамодель, инструменты и ощущение того, как моделируются реальные системы. Следующий шаг — ваш собственный файл .arch и тот цикл, который дают расширения редактора: вы сохраняете — и диаграмма обновляется. Именно в этом цикле язык окупает себя.