Аксиома: Любое архитектурное понятие TOGAF может быть с достаточной степенью точности описано с использованием UML или профиля UML[1].

В предыдущем выпуске цикла был рассмотрен пример моделирования заинтересованных лиц архитектуры. Это моделирование помогает собирать и систематизировать информацию об интересах заинтересованных лиц и использовать эту информацию в архитектурной работе (в том числе – для "управления" заинтересованными лицами). Куда положить эту весьма полезную информацию?

Архитекторы, выполняющие Метод разработки архитектуры (ADM), производят множество продуктов, таких , как описания потоков бизнес-процессов, архитектурные требования, проектные планы, проектные оценки и т.д. Классифицированию и сохранению рабочих продуктов посвящены две части Спецификации TOGAF: часть IV: Каркас содержания архитектуры и часть V: Континуум предприятия и инструментальные средства. Те, кто использует или собирается использовать TOGAF, безусловно, должны ознакомиться с содержащейся в них информацией. Автор публикации не собирается подменять официальный текст спецификации. Ниже будут рассмотрены общие принципы организации информации с учетом расширенного использования моделирования на UML (профиль UPIA). И здесь уж точно потребуется привлечение здравого смысла!

Каркас информационного наполнения TOGAF

Каркас использует три категории для описания типа продукта архитектурной работы в контексте его использования:

·         Поставка (Deliverable) – это продукт работы, который определен в контракте и который формально согласовывается и принимается заинтересованными лицами.
Поставки представляются в форме документов и, после завершении проекта, обычно передаются в архитектурный репозиторий как справочная модель, стандарт или снимок состояния области архитектуры в определенное время.

·         Артефакт (Artifact) – это минимальный продукт работы, который описывает архитектуру с определенной точки зрения. Примеры: сетевой график, спецификация сервера, спецификация прецедента, матрица бизнес-взаимодействий.
Артефакты представляются в виде каталогов (списков вещей), матриц (показывающих отношения между вещами) и диаграмм (изображающих вещи и их отношения).
Архитектурная поставка может содержать множество артефактов.

·         Компоновочный блок (Building block) представляет (потенциально многократного используемый) компонент бизнеса, IT или архитектурной возможности, который может быть объединен с другими компоновочными блоками, чтобы поставить архитектуру и решение.
Компоновочные блоки могут быть определены на различных уровнях детализации в зависимости от стадии разработки. Например, на ранних стадиях компоновочный блок может состоять только из названия или описания схемы. Позже, компоновочный блок может декомпозироваться во множество поддерживающих компоновочных блоков или сопровождаться полной спецификацией.
Спецификация TOGAF определяет:

• Архитектурные компоновочные блоки (ABB), обычно описывающие требуемую возможность
• Компоновочные блоки решений (SBB), представляющие компоненты, которые будут использоваться при реализации необходимых возможностей

На следующем рисунке показаны отношения между поставками, артефактами и компоновочными блоками (Спецификация TOGAF, рисунок 33-1).

Рисунок 1. Отношения между поставками, артефактами и компоновочными блоками

Модифицированное представление отношений продуктов архитектурной работы

Информационное наполнение TOGAF включает 22 поставки, 50 артефактов и (в ядре TOGAF) 17 архитектурных сущностей.

Странно, что на рисунке выше не представлены атомарные элементы архитектурного содержания (архитектурные сущности), такие, как процесс, роль, технологический компонент (см. рисунок 34-6 Спецификации TOGAF). Собственно, архитектурные сущности – это и есть те "вещи", которые упоминаются в определении артефакта как продукта работы.

На следующей диаграмме классов показано формальное представление отношений продуктов архитектурной работы, базирующейся на использовании моделирования на UML как фундаментальной технологии архитектурного моделирования[2].

Рисунок 2. Отношения между продуктами архитектурной работы при расширении моделирования в TOGAF.

Примечание: Обратите внимание, что на диаграмме выше отсутствует элемент "Архитектурная сущность". Его замещает "Модельный элемент UPIA". Между архитектурными сущностями TOGAF и элементами UML (UPIA) нет взаимно-однозначного соответствия. Однако, мне не удалось обнаружить ни одной архитектурной сущности, которую нельзя было бы представить элементом или набором элементов UML. По-видимому, для регулярного моделирования TOGAF с использованием UML должна быть составлена карта отображения элементов, подобная той, которая составлена IBM для моделирования DoDAF с использованием UPIA[3]. Такая работа запланирована в рамках работы над этим циклом публикаций.

Как отделить мух от котлет?

Хотите иметь хорошо документированную и всегда актуальную документацию архитектуры TOGAF?

Отделите процесс (и хранилище) моделирования от процесса создания артефактов и поставок TOGAF. У них разная логика и разные приемы:

• Моделирование – это творческий процесс, работа с заинтересованными лицами и документальными источниками, поиск возможных решений, реализация этих решений (с использованием инструментальных средств поддержки). Результат этой работы – набор модельных элементов и отношений между ними, в совокупности отражающий с установленной адекватностью настоящее или будущее состояние реальности (в нашем случае – архитектуру предприятия).
• Создание артефактов и поставок – это формальный процесс преобразования модельной информации по правилам (по шаблонам), установленным каркасом содержания. Хороший инструмент моделирования, интегрированный с хорошим инструментом генерации отчетов позволяет без существенных затрат создавать самодокументирующиеся модели[4].

Шаблон проекта UPIA Template for TOGAF

Предлагаемый подход реализуется в шаблоне проекта UPIA Template for TOGAF для IBM Rational Software Architect Standard (RSA).

Шаблон содержит два пакета UML верхнего уровня:

• Архитектурные модели
• Представления TOGAF

и папку Представления TOGAF

Рисунок 3. Фрагмент структуры шаблона UPIA Template for TOGAF.

Пакет Архитектурные модели

Структура пакета представлена на диаграмме ниже:

Рисунок 4. Структура пакета моделирования.

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

Примечание: В этом пакете использована возможность RSA преобразовывать пакеты UML в модели, т.е. в отдельные файлы файловой системы. Такая декомпозиция сделана для поддержки групповой работы над моделями.

Пакет Представления TOGAF

Хотя каркас содержания, наряду с процессом ADM, представляет основной материал Спецификации TOGAF, в его изложении, увы, содержится много неясностей и противоречий. А поскольку TOGAF фактически стал широко используемым стандартом моделирования архитектуры предприятия, а бренд TOGAF вошел в моду, пользователям приходится разрешать эти неясности и противоречия в меру своего умения. Наиболее обширные материалы на эту тему представлены на сайте http://avancier.co.uk.

В шаблоне UPIA Template for TOGAF структура пакета Представления TOGAF не устоялась и достаточно часто корректируется, поэтому в этом выпуске не приводится. Основная идея состоит в следующем:

Структура представляет иерархию пакетов, соответствующую метамодели содержания TOGAF. Листок этой иерархии представляет артефакт или поставку TOGAF. Соответствующий пакет содержит единственный элемент UML – URL к шаблону продукта работы (SoDA или BIRT). Запуск шаблона обеспечивает генерацию актуального документа, представляющего продукт работы в текущем состоянии.

Бесплатныq сыр бывает только в мышеловке:

• Для каждого типа производимого артефакта или поставки должен быть приобретен (разработан) шаблон
• Шаблоны проще разрабатывать для установленной структуры модели: хотите самодокументирующуюся модель – соблюдайте свои установленные правила структурирования модели

Папка Представления TOGAF

Эта папка повторяет структуру одноименного пакета в модели. Она предназначена для содержания файлов шаблонов отчетов.