3 Структура языка

В данной главе описывается структура языка моделирования архитектуры предприятия ArchiMate. Подробное определение и примеры стандартного набора элементов и отношений приведены в главах 4–1

3.1 Рассмотрение вопросов проектирования языка

Ключевой вызов при разработке общей метамодели для архитектуры предприятия заключается в достижении баланса между специфичностью языков для отдельных областей архитектуры и очень общей совокупностью концепций архитектуры, отражающей взгляд на системы как на простой набор взаимосвязанных сущностей.

Проектирование языка ArchiMate началось с набора относительно общих концепций. Эти концепции были адаптированы для применения на различных архитектурных уровнях, как объясняется в последующих разделах. Наиболее важным ограничением проектирования языка является то, что он явно разработан для минимального размера, но при этом остаётся пригодным для большинства задач моделирования архитектуры предприятия. Многие другие языки стремятся удовлетворить потребности всех возможных пользователей. В интересах простоты обучения и использования язык ArchiMate ограничен концепциями, достаточными для моделирования знаменитых 80% практических случаев.

В настоящем стандарте не описывается подробное обоснование проектирования языка ArchiMate. Заинтересованным читателям рекомендуется обратиться к источникам [1], [2] и [3], в которых приведено подробное описание построения языка и вопросов проектирования.

3.2 Структура языка на высшем уровне

На рисунке 1 показана иерархическая структура языка на высшем уровне:

• Модель — это совокупностьконцепций— концепция представляет собой либоэлементлибоотношение
• Элемент — это либо элемент поведения, либо элемент структуры, либо элемент мотивации, либо составной элемент

Обратите внимание, что этиабстрактныеконцепции; они не предназначены для прямого использования в моделях. Для обозначения этого они изображены белым цветом с названиями курсивом. См. главу 4 для пояснения обозначений, используемых на рисунке 1.

Рисунок 1: Иерархия концепций ArchiMate на высшем уровне

3.3 Уровневая структура языка ArchiMate

Ядро языка ArchiMate определяет структуру общих элементов и их отношений, которые могут быть специализированы на различных уровнях. В ядре языка ArchiMate определены три уровня следующим образом:

1. УровеньБизнесотображает бизнес-услуги, предоставляемые клиентам, которые реализуются в организации посредством бизнес-процессов, выполняемых бизнес-акторами.
2. УровеньПриложенияотображает сервисы приложений, поддерживающие бизнес, и приложения, реализующие их.
3. УровеньТехнологиивключает в себя как информационные, так и операционные технологии. Вы можете моделировать, например, обработку, хранение и коммуникационные технологии в поддержку прикладного мира и бизнес-слоев, а также моделировать операционные или физические технологии с использованием объектов, физического оборудования, материалов и сетей распределения.

Общая структура моделей в различных слоях схожа. Используются одни и те же типы элементов и отношений, хотя их точная природа и степень детализации различаются. В следующей главе представлена структура генерического метамодели. В главах 8, 9 и 10 эти элементы специализируются для получения элементов, специфичных для определенного слоя.

В соответствии с принципами ориентации на сервисы, наиболее важным отношением между слоями является отношение «обслуживания»[1]отношения, которые показывают, как элементы одного слоя обслуживаются сервисами других слоев. (Обратите внимание, однако, что сервисы могут обслуживать не только элементы в другом слое, но и элементы в том же слое.) Второй тип связи образуется с помощью отношений реализации: элементы нижних слоев могут реализовывать сопоставимые элементы верхних слоев; например, объект

«объект данных» (прикладной слой) может реализовывать «бизнес-объект» (бизнес-слой); или объект

«артефакт» (технологический слой) может реализовывать либо «объект данных», либо «компонент приложения» (прикладной слой).

3.4 Ядро архитектурной модели ArchiMate

Ядро архитектурной модели ArchiMate — это система из девяти ячеек, используемых для классификации элементов языка ArchiMate. Оно состоит из трех аспектов и трех слоев, как показано на рисунке 2. Это известно как ядро архитектурной модели ArchiMate.

Важно понимать, что классификация элементов на основе аспектов и слоев является лишь общей. Элементы реальной архитектуры не обязательно строго ограничиваются одним аспектом или слоем, поскольку элементы, связывающие различные аспекты и слои, играют центральную роль в согласованном описании архитектуры. Например, опережая последующие концептуальные обсуждения, бизнес-роли выступают в качестве промежуточных элементов между «чисто поведенческими» элементами и «чисто структурными» элементами, и зависит от контекста, считается ли определенный программный продукт частью прикладного слоя или технологического слоя.

Рисунок 2: Ядро архитектурной модели ArchiMate

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

Размерности модели следующие:

• Слои — три уровня, на которых предприятие может быть смоделировано в ArchiMate — бизнес, приложение и технология (как описано в разделе 3.3)
• Аспекты:

—Аспект активной структуры, который представляет структурные элементы (бизнес-актеры, компоненты приложения и устройства, демонстрирующие реальное поведение; то есть

«субъекты» деятельности)

—Аспект поведения, который представляет поведение (процессы, функции, события и сервисы), выполняемые актерами; структурные элементы назначаются поведенческим элементам, чтобы показать, кто или что демонстрирует поведение

—Аспект пассивной структуры, который представляет объекты, на которых выполняется поведение; это обычно информационные объекты в бизнес-слое и объекты данных в прикладном слое, но они также могут использоваться для представления физических объектов

Эти три аспекта вдохновлены естественным языком, в котором предложение имеет подлежащее (активная структура), сказуемое (поведение) и дополнение (пассивная структура). Используя те же конструкции, к которым люди привыкли в собственных языках, язык ArchiMate становится проще для изучения и понимания.

Поскольку нотация ArchiMate являетсяграфическойязыком, в котором элементы организованы пространственно, этот порядок не имеет значения при моделировании.

Составной элемент, как показано на рисунке 1, — это элемент, который не обязательно должен соответствовать одному аспекту (столбцу) модели, но может объединять два или более аспекта.

Обратите внимание, что язык ArchiMate не требует от моделиста использовать какую-либо конкретную компоновку, например, структуру данного фреймворка; он представляет собой просто классификацию элементов языка.

3.5 Полный фреймворк ArchiMate

Полный фреймворк ArchiMate, как описано в данной версии стандарта, добавляет несколько уровней и аспект к базовому фреймворку. Физические элементы включены в технологический уровень для моделирования физических объектов, оборудования, распределительных сетей и материалов. Таким образом, они также являются основными элементами. Элементы стратегии вводятся для моделирования стратегического направления и выбора. Они описаны в главе 7. Аспект мотивации вводится на общем уровне в следующей главе и подробно описан в главе 6. Элементы реализации и миграции описаны в главе 12. Результатом является полный фреймворк ArchiMate, показанный на рисунке 3.

Рисунок 3: Полный фреймворк ArchiMate

Язык ArchiMate не определяет специальный уровень для информации; однако элементы аспекта пассивной структуры, такие как бизнес-объекты, данные и артефакты, используются для представления сущностей информации. Моделирование информации поддерживается на всех уровнях ArchiMate.

3.6 Абстракция в языке ArchiMate

Структура языка ArchiMate предусматривает несколько знакомых форм абстракции и уточнения. Прежде всего, различие между внешним (черный ящик, абстрагирование от содержимого ящика) и внутренним (белый ящик) взглядом широко используется в проектировании систем. Внешний взгляд показывает, что система должна делать для своей среды, а внутренний — как она это делает.

Во-вторых, различие между поведением и активной структурой часто используется для разделения того, что система должна делать, и того, как она это делает, от составных частей системы (людей, приложений и инфраструктуры), которые это выполняют. При моделировании новых систем часто полезно начинать с поведения, которое система должна выполнять, а при моделировании существующих систем — начинать с людей, приложений и инфраструктуры, составляющих систему, а затем подробно анализировать поведение, выполняемое этими активными структурами.

В-третьих, различие между концептуальным, логическим и физическим уровнями абстракции. Это имеет свои корни в моделировании данных: концептуальные элементы представляют информацию, которая имеет значение для бизнеса; логические элементы обеспечивают логическую структуру этой информации для ее обработки информационными системами; физические элементы описывают хранение этой информации, например, в виде файлов или таблиц базы данных. В языке ArchiMate это соответствует бизнес-объектам, объектам данных и артефактам, а также отношениям реализации между ними.

Различие между логическими и физическими элементами также перенесено на описание приложений. Метамодель предприятия TOGAF [4] включает набор сущностей, описывающих бизнес-компоненты, компоненты данных, приложения и технологии, а также услуги, для описания концепций архитектуры. Логические компоненты — это независимые от реализации или продукта оболочки данных или функциональности, тогда как физические компоненты — это осязаемые программные компоненты, устройства и т.д. Это различие зафиксировано в рамках TOGAF в виде архитектурных блоков (ABB) и блоков решений (SBB). Это различие снова полезно при переходе от высокого уровня абстрактных описаний к конкретным проектным решениям. Обратите внимание, что блоки могут содержать несколько элементов, которые обычно моделируются с использованием концепции группировки в языке ArchiMate.

Язык ArchiMate имеет три способа моделирования таких абстракций. Во-первых, как описано в [6], элементы поведения, такие как функции приложений и технологий, могут использоваться для моделирования логических компонентов, поскольку они представляют собой независимые от реализации оболочки функциональности. Соответствующие физические компоненты затем могут быть смоделированы с использованием элементов активной структуры, таких как компоненты приложений и узлы, привязанные к элементам поведения. Во-вторых, язык ArchiMate поддерживает концепцию реализации. Это лучше всего описать, работая с технологическим уровнем вверх. Технологический уровень определяет физические артефакты и программное обеспечение, реализующие компонент приложения. Он также предоставляет сопоставление с другими физическими понятиями, такими как устройства, сети и т.д., необходимыми для реализации информационной системы. Отношение реализации также используется для моделирования более абстрактных форм реализации, например, между (более конкретным) требованием и (более общим) принципом, при котором выполнение требования подразумевает соблюдение принципа. Реализация также разрешена между компонентами приложений и между узлами. Таким образом, можно смоделировать физический компонент приложения или технологии, реализующий логический компонент приложения или технологии соответственно. В-третьих, логические и физические компоненты приложений могут быть определены как специализации элемента компонента приложения на уровне метамодели, как описано в главе 14 (см. также примеры в разделе 14.2.2). То же самое относится к логическим и физическим компонентам технологии метамодели содержимого TOGAF, которые могут быть определены как специализации элемента узла (см. раздел 14.2.3).

Язык ArchiMate сознательно не поддерживает различие между типами и экземплярами. На уровне абстракции корпоративной архитектуры чаще моделируются типы и/или образцы, а не экземпляры. Аналогично, бизнес-процесс в языке ArchiMate не описывает отдельный экземпляр (то есть один запуск этого процесса). В большинстве случаев бизнес-объект используется для моделирования типа объекта (см. класс UML®), экземпляры которого могут существовать в организации. Например, каждый запуск процесса обработки страхового заявления может привести к конкретному экземпляру бизнес-объекта страхового полиса, но это не моделируется в корпоративной архитектуре.

3.7 Понятия и их нотация

Язык ArchiMate разделяет понятия языка (то есть составные части метамодели) от их нотации. Разные группы заинтересованных сторон могут требовать различных нотаций для понимания модели или представления архитектуры. В этом отношении язык ArchiMate отличается от языков, таких как UML или BPMN™, которые имеют только одну стандартизированную нотацию. Механизм точек зрения, описанный в главе 13, предоставляет средства для определения таких визуализаций, ориентированных на заинтересованные стороны.

Хотя нотация понятий ArchiMate может (и должна) быть специфичной для заинтересованных сторон, стандарт предоставляет одну общую графическую нотацию, которую могут использовать архитекторы и другие, разрабатывающие модели ArchiMate. Эта нотация ориентирована на аудиторию, знакомую с существующими техническими методами моделирования, такими как диаграммы отношений сущностей (ERD), UML или BPMN, и поэтому похожа на них. В остальной части данного документа, если не указано иное, символы, используемые для изображения понятий языка, представляют стандартную нотацию ArchiMate. Стандартная нотация для большинства элементов состоит из прямоугольника с иконкой в правом верхнем углу. В некоторых случаях эта иконка сама по себе может использоваться в качестве альтернативной нотации. Эту стандартную иконографию следует предпочитать whenever possible, чтобы любой, знающий язык ArchiMate, мог читать диаграммы, созданные на этом языке.

3.8 Использование вложенности

Вложенность элементов внутри других элементов может использоваться в качестве альтернативной графической нотации для выражения некоторых отношений. Это подробно объясняется в главе 5 и в определении каждого из этих отношений.

3.9 Использование цветов и нотационных подсказок

На рисунках метамодели в данном стандарте используются оттенки серого для различения элементов, относящихся к различным аспектам фреймворка ArchiMate, следующим образом:

• Белый — для абстрактных (то есть неприменимых) понятий
• Светло-серый — для пассивных структур
• Серый — для поведения
• Темно-серый — для активных структур

В моделях ArchiMate формальные семантики не присваиваются цветам, а использование цвета остается на усмотрение моделиста. Однако они могут свободно использоваться для акцентирования определенных аспектов в моделях. Например, во многих примерах моделей, представленных в данном стандарте, цвета используются для различения уровней базового фреймворка ArchiMate, следующим образом:

• Желтый — для бизнес-уровня
• Синий — для прикладного уровня
• Зеленый — для технологического уровня

Они также могут использоваться для визуального акцентирования. Рекомендуемый текст с руководствами — глава 6 [1]. Помимо цветов, могут использоваться и другие нотационные подсказки для различения уровней фреймворка. Буква M, S, B, A, T, P или I в левом верхнем углу элемента может использоваться для обозначения элемента мотивации, стратегии, бизнеса, приложения, технологии, физического уровня или реализации и миграции соответственно. Пример такой нотации показан в примере 34.

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

• Углы с квадратной формой используются для обозначения элементов структуры
• Углы с круглой формой используются для обозначения элементов поведения
• Углы с диагональной формой используются для обозначения элементов мотивации

[1]Обратите внимание, что в предыдущих версиях стандарта это называлось «используется»; для ясности это название было изменено на «обслуживает».