md_to_gost/docs/archimate.md

ArchiMate 3.2: гайд по генерации схем (PlantUML + md2gost)

Учебный гайд по правильной генерации диаграмм ArchiMate® 3.2 в PlantUML для отчётов md2gost.
Язык — только 3.2 (документ C226). ArchiMate 4 не используется.

ArchiMate® — зарегистрированный товарный знак The Open Group. Текст гайда — учебный пересказ корпуса PDF и документации PlantUML, не копия спецификации.

Содержание

1. Как рисовать в md2gost
2. Каркас языка 3.2
3. Каталог элементов → макросы PlantUML
4. Связи
5. Что с чем связывать
6. Viewpoints
7. Синтаксис PlantUML
8. Чеклист для ИИ
9. Готовые шаблоны
10. Антипаттерны
11. Источники и границы корпуса

---

1. Как рисовать в md2gost

Оградка схемы: ```uml-archimate или ```archimate.

В теле пишите только макросы Archimate-PlantUML. Без @startuml, без @enduml, без !include — схема archimate добавит их сама.

%arch1 Слоистая архитектура портала +landscape

```uml-archimate
LAYOUT_TOP_DOWN()

Business_Actor(student, "Студент")
Business_Process(enroll, "Подача заявки")
Application_Service(portalSvc, "Портал заявок")
Application_Component(portal, "Web-портал")

Rel_Assignment(student, enroll)
Rel_Serving(portalSvc, enroll)
Rel_Realization(portal, portalSvc)
```

Флаг у %подписи	Смысл
+landscape	Альбомная страница под широкий рисунок
+listing	Рядом показать исходник диаграммы

Широкие Layered / Application Cooperation почти всегда с +landscape.

---

2. Каркас языка 3.2

2.1. Модель, концепт, элемент, связь

По sample C226 (§2–3):

• Model — набор концептов.
• Concept — либо element, либо relationship.
• Element — behavior, structure, motivation или composite (абстрактные классы; в модели не рисуются сами по себе).
• Relationship — связь source → target; класс: structural / dependency / dynamic / other.
• Relationship connector (Junction) — соединяет две или более связи одного типа.

Язык намеренно мал: «80 % практических случаев», без попытки покрыть всех пользователей сразу (§3.1).

2.2. Три core-слоя

Слой	Что показывает
Business	Бизнес-сервисы для клиентов; процессы и акторы, которые их реализуют
Application	Прикладные сервисы и приложения, поддерживающие бизнес
Technology	ИТ и OT: обработка, хранение, сети; также физика (сооружения, оборудование, материалы, распределительные сети)

Структура моделей на слоях похожа: те же виды элементов и связей, разная природа и гранулярность.

2.3. Аспекты (подлежащее — сказуемое — дополнение)

Аспект	Роль	Примеры
Active structure	Кто/что действует	Actor, Role, Component, Node, Device
Behavior	Что делается	Process, Function, Interaction, Service, Event
Passive structure	Над чем работают	Business Object, Data Object, Artifact, Material
Motivation	Зачем	Stakeholder, Driver, Goal, Requirement…
Composite	Группировка / место	Grouping, Location, Product

На листах Виерды (не стандарт Open Group): синий = активная структура, жёлтый = поведение, зелёный = пассивная. Официальный ArchiMate бесцветен; цвета — соглашение инструментов (в PlantUML — палитры слоёв #Business, #Application, …).

2.4. Full framework

К core добавляются (van den Berg §2.4 / full framework C226):

• слой Strategy;
• слой Implementation & Migration;
• аспект Motivation.

2.5. Два главных межслойных моста (§3.3)

1. Serving (раньше used by): сервис (или элемент) предоставляет функциональность другому. Сервис нижнего/соседнего слоя обслуживает потребителя. Сервис может обслуживать и элемент того же слоя.
2. Realization: более конкретное (часто ниже) реализует более абстрактное (часто выше): например приложение реализует прикладной сервис, сервис/процесс реализует требование или capability.

Каноническая цепочка внутри слоя:

Active structure  —Assignment→  internal behavior (Process/Function)
internal behavior —Realization→  Service (external behavior)
Service           —Serving→     consumer (Role / Process / Component …)
behavior          —Access→      passive structure

---

3. Каталог элементов → макросы PlantUML

Определения — N221 (Reference Cards). Макросы — Archimate-PlantUML 3.2.1.
Формат: Category_ElementName(alias, "Подпись").

Alias — латиница (student, crm). Не используйте end, start, group как alias.

3.1. Motivation

Элемент	Макрос	Определение (N221)
Stakeholder	Motivation_Stakeholder	Роль индивида, команды или организации, заинтересованной в эффектах архитектуры
Driver	Motivation_Driver	Внешнее/внутреннее условие, побуждающее задать цели и изменения
Assessment	Motivation_Assessment	Результат анализа положения дел относительно driver
Goal	Motivation_Goal	Высокоуровневое намерение / желаемое конечное состояние
Outcome	Motivation_Outcome	Конечный результат / эффект некоторого положения дел
Principle	Motivation_Principle	Общее свойство, применимое к любой системе в контексте
Requirement	Motivation_Requirement	Потребность: свойство конкретной системы в архитектуре
Constraint	Motivation_Constraint	Ограничение на архитектуру, реализацию или процесс внедрения
Meaning	Motivation_Meaning	Знание/интерпретация концепта в контексте
Value	Motivation_Value	Относительная ценность / полезность концепта

3.2. Strategy

Элемент	Макрос	Определение (N221)
Resource	Strategy_Resource	Актив, которым владеют или управляют
Capability	Strategy_Capability	Способность, которой обладает активная структура
Value Stream	Strategy_ValueStream	Последовательность активностей, создающая результат для клиента/стейкхолдера
Course of Action	Strategy_CourseOfAction	Подход/план настройки capabilities и resources для достижения цели

3.3. Business

Элемент	Макрос	Аспект	Определение (N221)
Business Actor	Business_Actor	Active	Сущность, способная выполнять поведение
Business Role	Business_Role	Active	Ответственность за поведение; роль актора
Business Collaboration	Business_Collaboration	Active	Агрегат ≥2 внутренних active structure для коллективного поведения
Business Interface	Business_Interface	Active	Точка доступа, где бизнес-сервис доступен среде
Business Process	Business_Process	Behavior	Последовательность бизнес-поведения к конкретному результату
Business Function	Business_Function	Behavior	Набор поведения по критериям (ресурсы/компетенции)
Business Interaction	Business_Interaction	Behavior	Коллективное поведение ≥2 акторов/ролей/коллабораций
Business Event	Business_Event	Behavior	Изменение состояния на бизнес-уровне
Business Service	Business_Service	Behavior	Явно определённое поведение, доступное среде
Business Object	Business_Object	Passive	Концепт предметной области
Contract	Business_Contract	Passive	Соглашение провайдер–потребитель (права/обязанности, параметры)
Representation	Business_Representation	Passive	Воспринимаемая форма информации бизнес-объекта
Product	Business_Product	Composite	Согласованный набор сервисов/пассивных элементов + contract

3.4. Application

Элемент	Макрос	Аспект	Определение (N221)
Application Component	Application_Component	Active	Инкапсуляция прикладной функциональности, модульная и заменяемая
Application Collaboration	Application_Collaboration	Active	Агрегат ≥2 application internal active structure
Application Interface	Application_Interface	Active	Точка доступа к application services
Application Function	Application_Function	Behavior	Автоматизированное поведение компонента
Application Interaction	Application_Interaction	Behavior	Коллективное поведение ≥2 компонентов
Application Process	Application_Process	Behavior	Последовательность прикладного поведения к результату
Application Event	Application_Event	Behavior	Изменение состояния приложения
Application Service	Application_Service	Behavior	Явно определённое внешнее прикладное поведение
Data Object	Application_DataObject	Passive	Данные, структурированные для обработки

3.5. Technology (+ Physical в гл. Technology 3.2)

Элемент	Макрос	Определение (N221)
Node	Technology_Node	Вычислительный/физический ресурс, хостящий другие ресурсы
Device	Technology_Device	Физический ИТ-ресурс для хранения/исполнения ПО и артефактов
System Software	Technology_SystemSoftware	ПО среды исполнения/хранения
Technology Collaboration	Technology_Collaboration	Агрегат ≥2 technology internal active structure
Technology Interface	Technology_Interface	Точка доступа к technology services
Path	Technology_Path	Связь между ≥2 technology internal active structure для обмена
Communication Network	Technology_CommunicationNetwork	Структуры/поведение для передачи данных
Technology Function	Technology_Function	Набор технологического поведения
Technology Process	Technology_Process	Последовательность технологического поведения
Technology Interaction	Technology_Interaction	Коллективное technology-поведение
Technology Event	Technology_Event	Изменение технологического состояния
Technology Service	Technology_Service	Явно определённое внешнее technology-поведение
Artifact	Technology_Artifact	Данные/файл, используемый или порождаемый разработкой/эксплуатацией
Equipment	Physical_Equipment	Физические машины/инструменты для материи
Facility	Physical_Facility	Физическая структура или окружение
Distribution Network	Physical_DistributionNetwork	Физическая сеть транспортировки материи/энергии
Material	Physical_Material	Осязаемая материя или энергия

В 3.2 Device / System Software / Facility / Equipment — не подтипы Node, а technology internal active structure с composition/aggregation к Node (changelog C226).

3.6. Implementation & Migration

Элемент	Макрос	Определение (N221)
Work Package	Implementation_WorkPackage	Серия действий с результатом в сроках и ресурсах
Deliverable	Implementation_Deliverable	Точно определённый результат work package
Implementation Event	Implementation_Event	Изменение состояния, связанное с внедрением/миграцией
Plateau	Implementation_Plateau	Относительно стабильное состояние архитектуры на период
Gap	Implementation_Gap	Различие между двумя plateaus

3.7. Composite и Junction

Элемент	Макрос	Определение (N221)
Grouping	Grouping / Other_Grouping / Group	Агрегирует/композирует концепты по общему признаку
Location	Other_Location / Business_Location	Место, где расположены или выполняются концепты
And Junction	Junction_And	Логическое И для связей одного типа
Or Junction	Junction_Or	Логическое ИЛИ для связей одного типа

Grouping и Junction допустимы в любом viewpoint (спецификация).

3.8. Когда какой элемент поведения

Нужно	Берите
Последовательность шагов к результату	*_Process
Группа поведения «изнутри» по компетенциям/ресурсам	*_Function
Поведение коллаборации (≥2 участников)	*_Interaction
Внешне видимое поведение (чёрный ящик)	*_Service
Момент / смена состояния	*_Event

Не смешивайте слои: Business_Process ≠ Application_Process ≠ Technology_Process. Слой задаётся типом элемента, не подписью.

---

4. Связи

4.1. Одиннадцать типов (N221) + PlantUML

Тип	Класс	Смысл (N221)	Макрос	Нотация PlantUML
Composition	Structural	Элемент состоит из других; часть не существует без целого	Rel_Composition	*--
Aggregation	Structural	Элемент объединяет другие; части могут жить отдельно	Rel_Aggregation	o--
Assignment	Structural	Ответственность / выполнение поведения / хранение / исполнение	Rel_Assignment	@-->>
Realization	Structural	Критическая роль в создании/достижении более абстрактного	Rel_Realization	`~~
Serving	Dependency	Предоставляет функциональность другому	Rel_Serving	-->
Access	Dependency	Поведение/active structure наблюдает или действует на passive	Rel_Access / _r / _w / _rw	~~ / <-~ / ~-> / <~~>
Influence	Dependency	Влияет на реализацию/достижение motivation-элемента (+/-)	Rel_Influence	..>
Triggering	Dynamic	Временная/причинная активация	Rel_Triggering	-->>
Flow	Dynamic	Передача чего-либо	Rel_Flow	..>>
Specialization	Other	Является разновидностью	Rel_Specialization	`--
Association	Other	Неспецифичная связь (или нет другого типа)	Rel_Association / _dir	-- / --\
Junction	Connector	Соединяет связи одного типа	Junction_And / Junction_Or	circle

Направление на схеме: Rel_Type_Up / _Down / _Left / _Right (например Rel_Serving_Up(svc, proc)).

4.2. Направления (частые ошибки)

Связь	Откуда → куда
Serving	Поставщик (часто Service) → потребитель
Realization	Более конкретное → более абстрактное
Composition / Aggregation	Целое → часть
Assignment	Active structure → behavior (или ресурс хранения → artifact)
Access	Behavior (или active) → passive; тип: read / write / read-write
Triggering	Предшественник → следующий
Flow	Источник передачи → приёмник
Influence	Влияющий → motivation-элемент (сила ++/+/0/-/-- в подписи)
Specialization	Специализация → общий тип

На листах: realization — «вверх» по абстракции; serving — к тому, кого обслуживают. Access всегда к объекту, независимо от отрисовки стрелки.

4.3. Правила с листов (метамодель ядра)

• Любой элемент может compose/aggregate элементы того же класса (на обзорных диаграммах часто не рисуют).
• Внутренние поведения одного слоя могут compose/aggregate друг друга (Function агрегирует Process).
• Association формально возможна между любыми классами — но на схеме используйте её только когда нет более точного типа.
• Collaboration ведёт себя как соответствующий internal active structure.
• Stakeholder — Association с любым элементом; элементы мотивации (кроме Stakeholder) — Influence друг на друга.

4.4. Чего нет в корпусе

Полная Appendix B (матрица всех допустимых пар и derivation) в sample PDF обрезана. Ниже — практические цепочки из §3.3, N221, листов и типичных viewpoint’ов. Не выдавайте их за полную нормативную матрицу B.

---

5. Что с чем связывать

5.1. Канонические цепочки

# Внутри слоя
Business_Actor/Role     Rel_Assignment     Business_Process/Function
Business_Process        Rel_Realization    Business_Service
Business_Process        Rel_Access_*       Business_Object
Business_Event          Rel_Triggering     Business_Process

Application_Component   Rel_Assignment     Application_Function/Process
Application_Function    Rel_Realization    Application_Service
Application_Service     Rel_Serving        Business_Process/Role
Application_Component   Rel_Access_*       Application_DataObject
Application_Component   Rel_Composition    Application_Component

Technology_Node         Rel_Composition    Technology_Device / SystemSoftware
Technology_*            Rel_Assignment     Technology_Function/Process
Technology_Function     Rel_Realization    Technology_Service
Technology_Service      Rel_Serving        Application_Component
Technology_Artifact     Rel_Realization    Application_DataObject
Application_DataObject  Rel_Realization    Business_Object

# Стратегия / мотивация
Business_Process / Application_Service  Rel_Realization  Strategy_Capability
Application_Service / Component         Rel_Realization  Motivation_Requirement
Motivation_Driver                       Rel_Association  Motivation_Stakeholder
Motivation_Assessment                   Rel_Association  Motivation_Driver
Motivation_Goal                         Rel_Realization  Motivation_Outcome
Motivation_Requirement                  Rel_Specialization Motivation_Constraint  # или наоборот по смыслу «ограничение как вид требования» — лучше Constraint отдельно + Influence/Association

# Миграция
Implementation_WorkPackage  Rel_Realization / Aggregation  Implementation_Deliverable
Implementation_Plateau      Rel_Aggregation               core elements
Implementation_Gap          Rel_Association               between plateaus

5.2. Запреты для генерации

1. Не Rel_Assignment от Data Object / Business Object к процессу.
2. Не Rel_Realization от Component сразу к Process — нужен Function/Process того же слоя, затем Realization к Service.
3. Не Rel_Serving «потребитель → сервис» (перевёрнуто).
4. Не подменять Access потоком Flow «потому что данные».
5. Не рисовать Business_Process вместо Application_Process, если исполнитель — компонент.
6. Не ставить Association на все рёбра «на всякий случай».
7. Не считать Device подтипом Node без composition/aggregation (3.2).

---

6. Viewpoints

Один рисунок = один viewpoint. Не сваливайте мотивацию, бизнес, приложения и ЦОД на один холст без нужды (Layered — исключение, но всё равно ограничивайте число элементов).

Имена — из оглавления sample C226, Appendix C:

6.1. Basic (C.1)

Viewpoint	Фокус	Типичные элементы
Organization	Структура орг. единиц	Actor, Role, Collaboration, Location, Interface
Application Structure	Внутренняя структура приложений	Component, Collaboration, Interface, Data Object
Information Structure	Данные/информация	Business Object, Representation, Data Object, Artifact, Meaning
Technology	Инфраструктура	Node, Device, System Software, Network, Path, Artifact…
Layered	Обзор слоёв	Набор из Business + Application + Technology + serving/realization
Physical	Физический мир	Equipment, Facility, Distribution Network, Material + tech
Product	Ценность продукта	Product, Contract, Services, Interfaces
Application Usage	Приложения в бизнес-контексте	Process/Function/Service бизнес + application
Technology Usage	Технологии для приложений	Application + Technology services/nodes
Business Process Cooperation	Связь процессов	Processes, Events, Services, Roles, supporting apps
Application Cooperation	Связь приложений	Components, Services, Interfaces, Data, Flow/Serving
Service Realization	Как сервисы реализованы	Service ← Process/Function ← Active structure
Implementation and Deployment	Развёртывание	Application + Artifact + Node/Device

6.2. Motivation (C.2)

Stakeholder · Goal Realization · Requirements Realization · Motivation — Driver/Assessment/Goal/Outcome/Principle/Requirement/Constraint/Value/Meaning и Realization/Influence к core.

6.3. Strategy (C.3)

Strategy · Capability Map · Value Stream · Outcome Realization · Resource Map.

6.4. Implementation & Migration (C.4)

Project · Migration · Implementation and Migration — Work Package, Deliverable, Plateau, Gap, Event.

6.5. Макет

• Организация / структура: LAYOUT_TOP_DOWN() или вложенность { }.
• Процессы слева направо: LAYOUT_LEFT_RIGHT() + Rel_*_Right.
• Layered: бизнес сверху, technology снизу; serving вверх (Rel_Serving_Up), realization вверх к абстракции.
• Широкие схемы: %id … +landscape.

Пример композиции (van den Berg): сначала Motivation viewpoint (риски/цели), затем отдельные схемы процессов с Junction на ветвлениях восстановления.

---

7. Синтаксис PlantUML

Документация: plantuml.com/archimate-diagram. Stdlib: Archimate-PlantUML 3.2.1.

7.1. Рекомендуемый путь (схема md2gost)

LAYOUT_TOP_DOWN()   ' или LAYOUT_LEFT_RIGHT()
Business_Actor(a, "Имя")
Application_Service(s, "Сервис")
Rel_Serving_Up(s, a)

Include и @startuml добавляет схема archimate.

7.2. Низкоуровневый keyword (без макросов)

Только в ```uml, если stdlib недоступен:

@startuml
archimate #Business "Подача заявки" as p <<business-process>>
archimate #Application "Портал" as c <<application-component>>
c --> p
@enduml

Sprites: <<$archimate/business-process>> или jar:archimate/....
Не смешивайте макросы и сырой archimate на одной схеме.

7.3. Темы

!theme archimate-standard from <archimate/themes>
' archimate-alternate | saturated | lowsaturation | handwriting

7.4. Nesting и special shapes

Business_Product(prod, "Тариф") {
  Business_Service(s1, "Подключение")
  Business_Contract(c1, "Оферта")
}

Для special shapes ($ARCH_SPECIAL_SHAPES) у Service/Actor/Value/ValueStream при вложении: $nest=%true().

7.5. Layout helpers

Lay_U / Lay_D / Lay_L / Lay_R — скрытые связи для выравнивания.
LAYOUT_AS_SKETCH() — черновик (не для финального ГОСТ-рисунка).

7.6. Sequence с ArchiMate

Только если явно просят sequence: !global $ARCH_SEQUENCE_SUPPORT = %true() до include. Это не замена viewpoint.

7.7. List sprites

@startuml
listsprite
@enduml

---

8. Чеклист для ИИ

1. Версия языка: ArchiMate 3.2; макросы слоя (Business_*, Application_*, …).
2. Оградка ```uml-archimate; без @startuml / !include.
3. Выбрать один viewpoint; 8–18 элементов на рисунок.
4. Сначала все элементы, потом все Rel_*.
5. Alias латиницей; подписи по-русски в кавычках; длинные имена с \n.
6. Serving от сервиса к потребителю; Realization от конкретного к абстрактному.
7. Поведение того же слоя, что и исполнитель (Assignment).
8. Не UML class/component, не C4 Person, не BPMN XOR, не mxgraph.
9. Не Association «по умолчанию».
10. Для отчёта: %id Название (+ +landscape если широко).

---

9. Готовые шаблоны

Тела для ```uml-archimate (без обёртки).

9.1. Organization

LAYOUT_TOP_DOWN()
Business_Actor(uni, "Университет") {
  Business_Actor(dean, "Деканат")
  Business_Actor(it, "Управление ИТ")
}
Business_Role(student, "Студент")
Business_Role(clerk, "Методист")
Rel_Assignment(dean, clerk)
Rel_Assignment(uni, student)

9.2. Service Realization

LAYOUT_TOP_DOWN()
Business_Role(applicant, "Абитуриент")
Business_Process(apply, "Подача заявления")
Business_Service(applySvc, "Приём заявлений")
Application_Service(webSvc, "Веб-приёмная")
Application_Component(lk, "Личный кабинет")
Application_Function(submitFn, "Отправка формы")

Rel_Assignment(applicant, apply)
Rel_Realization(apply, applySvc)
Rel_Serving(webSvc, apply)
Rel_Assignment(lk, submitFn)
Rel_Realization(submitFn, webSvc)

9.3. Application Cooperation

LAYOUT_LEFT_RIGHT()
Application_Component(crm, "CRM")
Application_Component(billing, "Биллинг")
Application_Service(crmApi, "API клиентов")
Application_DataObject(client, "Карточка клиента")

Rel_Realization(crm, crmApi)
Rel_Serving(crmApi, billing)
Rel_Access_rw(crm, client)
Rel_Access_r(billing, client)
Rel_Flow(crm, billing, "событие оплаты")

9.4. Layered

LAYOUT_TOP_DOWN()
Business_Process(sale, "Оформление заказа")
Business_Object(order, "Заказ")
Application_Service(shopSvc, "Интернет-магазин")
Application_Component(shop, "ShopApp")
Technology_Service(dbSvc, "СУБД")
Technology_Node(dbHost, "DB Host")
Technology_SystemSoftware(pg, "PostgreSQL")

Rel_Access_w(sale, order)
Rel_Serving_Up(shopSvc, sale)
Rel_Realization(shop, shopSvc)
Rel_Serving_Up(dbSvc, shop)
Rel_Assignment(dbHost, dbSvc)
Rel_Composition(dbHost, pg)

9.5. Motivation / Requirements Realization

LAYOUT_TOP_DOWN()
Motivation_Stakeholder(rector, "Ректор")
Motivation_Driver(comp, "Конкуренция вузов")
Motivation_Goal(digital, "Цифровизация приёма")
Motivation_Requirement(online, "Заявление онлайн 24/7")
Motivation_Constraint(152fz, "152-ФЗ")
Application_Service(portal, "Портал абитуриента")

Rel_Association(rector, comp)
Rel_Association(comp, digital)
Rel_Realization(online, digital)
Rel_Influence(152fz, online, "-")
Rel_Realization(portal, online)

9.6. Implementation & Migration

LAYOUT_LEFT_RIGHT()
Implementation_Plateau(asIs, "AS-IS 2025")
Implementation_Plateau(toBe, "TO-BE 2026")
Implementation_Gap(gap1, "Нет единого ЛК")
Implementation_WorkPackage(wp, "Проект Единый ЛК")
Implementation_Deliverable(d1, "Релиз 1.0")
Implementation_Event(goLive, "Go-Live")

Rel_Association(gap1, asIs)
Rel_Association(gap1, toBe)
Rel_Realization(wp, d1)
Rel_Triggering(d1, goLive)
Rel_Triggering(goLive, toBe)

9.7. Technology Usage

LAYOUT_TOP_DOWN()
Application_Component(api, "API Gateway")
Technology_Node(k8s, "Kubernetes")
Technology_Device(node1, "Worker x86")
Technology_SystemSoftware(os, "Linux")
Technology_CommunicationNetwork(net, "Cluster CNI")
Technology_Artifact(image, "api:1.2.img")

Rel_Serving_Up(k8s, api)
Rel_Composition(k8s, node1)
Rel_Composition(node1, os)
Rel_Association(node1, net)
Rel_Assignment(node1, image)

9.8. Process с Junction (в духе van den Berg)

LAYOUT_LEFT_RIGHT()
Business_Event(incident, "Инцидент")
Business_Process(triage, "Триаж")
Junction_Or(j1, "")
Business_Process(restore, "Восстановление КФ")
Business_Process(investigate, "Расследование")
Business_Process(close, "Закрытие")

Rel_Triggering(incident, triage)
Rel_Triggering(triage, j1)
Rel_Triggering(j1, restore)
Rel_Triggering(j1, investigate)
Rel_Triggering(restore, close)
Rel_Triggering(investigate, close)

---

10. Антипаттерны

Плохо	Почему	Как надо
Все связи Rel_Association	Теряется семантика	Serving / Realization / Assignment / Access
Application_Component вместо Business_Actor	Разные аспекты и слои	Actor/Role для людей/орг. единиц
Business Process «внутри» компонента без Assignment	Слои смешаны	Process на бизнес-слое; Serving от Application Service
Serving от Role к Service	Направление наоборот	Service → Role/Process
Realization Component → Process	Пропущен внутренний behavior	Component → Function → Service
Flow вместо Access к Data Object	Flow — передача, Access — работа с объектом	Rel_Access_r/w/rw
Один Layered на 40+ элементов	Нечитаемо	Несколько viewpoint’ов
C4 Person / UML class в archimate-блоке	Другой язык	Только макросы ArchiMate
Generic «Process» без слоя	В 3.2 слоя обязательны	Business_Process / Application_Process / …

---

11. Источники и границы корпуса

Норматив (при конфликте — сверху вниз)

1. n221p.pdf — ArchiMate 3.2 Reference Cards (N221): определения элементов и связей.
2. 978940180955C_SMPL.pdf (+ дубль SMPL-1) — sample C226: гл. 1–2, начало гл. 3, оглавление (в т.ч. список viewpoints Appendix C).
3. archimate-sheets-ru-20230805-s.pdf — листы метамодели 3.2 (Виерда / Ефремов): прямые связи, цвета аспектов на листах. Описания элементов на листах не от Open Group — для формулировок «что такое X» побеждает N221.

Синтаксис рисунка

• plantuml.com/archimate-diagram
• Stdlib Archimate-PlantUML 3.2.1 (!include <archimate/Archimate>)

Примеры композиции (не словарь языка)

• hospital ZiRA preview (inkijkexemplaar) — reference architecture / C226.
• vandenBerg_MA_EEMCS.pdf — §2.4 framework, motivational viewpoint, Junction в процессах BCM/DR.

Не правила ArchiMate

• Article_37 (FEM), paper_41 (OntoUML/COVO), FASD (UML атак), 419 (единое окно), 2659430 (Packt Practical Cybersecurity Architecture — процесс кибер-архитектуры, не спецификация 3.2).

Ограничения

• Полная Appendix B в sample отсутствует — матрица пар здесь практическая, не нормативная таблица B.5.
• PDF спецификации в git не хранятся.
• Старый PlantUML/Kroki без stdlib 3.2: fallback — ```uml + keyword archimate.
• Пользовательский md2gost.schemes.json: встроенные схемы с author: md2gost синхронизируются с бандлом; свои правки (другой author) не затираются.

---

См. также: schemes.md, меню Шаблоны UML, Справка → Промпт для ИИ (схема archimate).