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](#1-как-рисовать-в-md2gost)
2. [Каркас языка 3.2](#2-каркас-языка-32)
3. [Каталог элементов → макросы PlantUML](#3-каталог-элементов--макросы-plantuml)
4. [Связи](#4-связи)
5. [Что с чем связывать](#5-что-с-чем-связывать)
6. [Viewpoints](#6-viewpoints)
7. [Синтаксис PlantUML](#7-синтаксис-plantuml)
8. [Чеклист для ИИ](#8-чеклист-для-ии)
9. [Готовые шаблоны](#9-готовые-шаблоны)
10. [Антипаттерны](#10-антипаттерны)
11. [Источники и границы корпуса](#11-источники-и-границы-корпуса)

---

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

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

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

````markdown
%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.

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

```text
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. Канонические цепочки

```text
# Внутри слоя
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](https://plantuml.com/archimate-diagram). Stdlib: Archimate-PlantUML **3.2.1**.

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

```text
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 недоступен:

```plantuml
@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. Темы

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

### 7.4. Nesting и special shapes

```plantuml
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

```plantuml
@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

```plantuml
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

```plantuml
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

```plantuml
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

```plantuml
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

```plantuml
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

```plantuml
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

```plantuml
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)

```plantuml
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](https://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](schemes.md), меню **Шаблоны UML**, **Справка → Промпт для ИИ** (схема `archimate`).