Предпосылка 3: Структуры ограничены пространством
Предпосылка: Все действия в системе выполняются действующими лицами или компонентами, которые занимают пространство и должны быть адресуемыми.
Интерфейсы, роли и функции не определяют поведение, они только идентифицируют варианты поведения. Они называют модели поведения, за которые отвечают адресуемые компоненты, человеческие субъекты и организационные подразделения.
Принцип 3.1: Тип поведенческого элемента описывает схожие начальные характеристики.
*Софистика — мастерство, умение, хитрая выдумка, уловка) — формально кажущееся правильным, но ложное по существу умозаключение, основанное на преднамеренно неправильном подборе исходных положений.
Процессы ArchiMate являются начальными или циклическими, но его функции — нет. Поскольку функции больше похожи на роли, классификация их как поведенческих сбивает с толку. ArchiMate пытается провести различие, говоря, что роли представляют собой ответственность за поведение, тогда как функции описывают это поведение, но последующее обсуждение предполагает, что это софистика.
Принцип 3.2: Роли и функции определяют, а не выполняют модели поведения
Что делает вещь (субъект или объект) структурной? Что она адресуема. Если вы не можете определить местоположение объекта в пространстве, вы не можете попросить его выполнить работу. Если вы не можете определить местоположение объекта в пространстве, вы не можете с ним работать. Далее, что делает структурный элемент активным? Что он выполняет одно или несколько действий (каждое из которых имеет чисто логическую структуру с течением времени) или идентифицирует или называет действия, которые необходимо выполнить.
Компоненты, организационные единицы и действующие лица демонстрируют поведение. Интерфейсы, роли и функции этого не делают; они только идентифицируют / называют поведение.
- Разделение интерфейсов (которые определяют поведение) и компонентов (ответственных за выполнение поведения) отделяет то, что должно быть сделано, от того, как это назначено компонентам в структуре системы.
- Разделение функций (которые определяют поведение) и организационных единиц (ответственных за выполнение поведения) отделяет то, что должно быть сделано, от того, как это распределено между организационными единицами.
- Разделение ролей (которые определяют поведение) между действующими лицами (ответственными за выполнение поведения) отделяет то, что должно быть сделано, от того, как это возложено на людей.
Обратите внимание, что ArchiMate использует термин actor как для отдельного подразделения организации, так и для отдельного человека.
То, что система может делать, определяется в определениях ее активных структурных элементов. Бизнес-функции определяют, что делают подразделения организации, а роли определяют, что делают действующие лица. Функции и роли являются структурными элементами, а не поведенческими. Метамодель ArchiMate можно легко модифицировать, чтобы более четко отличать процессы (поведение от начала до конца) от функций и ролей (логические компоненты). В этой таблице показано, как элементы можно переименовывать и перемещать.
Уровни архитектуры Поведение с течением времени Адресуемые структуры Бизнес-уровень Бизнес-сервис Бизнес-интерфейс Бизнес -процесс Функция / Роль / Действующее лицо Уровень приложений Служба приложений Интерфейс приложения Процесс подачи заявки Приложение, функция / Компонент Уровень инфраструктуры Инфраструктурные услуги Интерфейс инфраструктуры Инфраструктурный процесс Инфраструктура, функция / Узел
Принцип 3.3: Кластеризация отдельных сервисов создает структурную функцию, а не более крупную услугу
В дополнение к разновидностям абстракции, упомянутым выше, простое удаление деталей из описания является простейшим видом абстракции. Один из способов стереть детали — объединить несколько связанных объектов в группу, а затем назвать группу объектов или тип объекта. Таким образом, отдельные личности становятся набором, вещи становятся типом, уникальное становится коллекцией.
Объединение различных типов поведения в группу — это способ проектирования логических структурных элементов, которые мы называем интерфейсами, функциями и ролями.
Логическая структура типы поведения кластеров, которые подробнее о физических структурах несут ответственность за Внешний интерфейс типы поведения кластеров, которые Компоненты несут ответственность за Бизнес -функция типы поведения кластеров, которые действующие лица организационных подразделений несут ответственность за Роль типы поведения кластеров, которые действующие лица несут ответственность за
Детализация здесь неуместна. Поведенческий элемент (услуга или процесс) может быть мелкозернистым или крупнозернистым, в зависимости от степени детализации и характера системы, которая его предоставляет или выполняет. Единая бизнес-услуга может представлять собой проект, который проходит от запроса проекта до доставки в течение многих лет. Но множественность имеет значение. Но объединение различных единиц поведения в совокупность с использованием какого-либо другого критерия — это то, как мы проектируем логический структурный элемент. Агрегат отличается от внутреннего поведения и очень похож на роль или функцию, или на то, что TOGAF называет логическим компонентом (корневой объект “возможности” для выполнения этой функции с использованием физических ресурсов).
Короче говоря, если вы объединяете отдельные сервисы в именованную группу, вы должны представлять ее с помощью символа функции или интерфейса.
Принцип 3.4: однозначные отношения и блоки синонимов
На практике некоторые диаграммы архитектуры загромождены избыточными соотношениями 1 к 1 и блоками синонимов. Если блок под названием gardening связан 1 к 1 с блоком под названием gardener , то наличие двух блоков излишне. Поле с глагольным названием просто прикрепляет альтернативный ярлык к блоку с именем существительным. Определяя услугу как все, что делает компонент, мы видим диаграммы, загроможденные соотношениями 1 к 1, такими как: обработка транзакций <это услуга, реализуемая> обработчиком транзакций; посредничество в передаче сообщений <это услуга, реализуемая> посредником сообщений; и управление взаимоотношениями с клиентами — это <это услуга, реализуемая> системой управления взаимоотношениями с клиентами.
Аналогично, если один компонент имеет один интерфейс, находящийся по одному адресу, нет необходимости отделять интерфейс от компонента. Если два компонента сотрудничают для поддержки одного интерфейса, то этот интерфейс представляет собой совместную работу, поэтому нет необходимости также рисовать окно совместной работы. Если один процесс предоставляет одну услугу, разделение службы и процесса может не помочь. И так далее.
Предпосылка 4: Данные передают смысл
Предпосылка: Объект данных содержит структуру данных или элемент, который имеет смысл или ценность для его создателей и пользователей. Разработчикам бизнес-систем необходимо знать, какие данные передаются между участниками или компонентами, какие данные хранятся в каких контейнерах. Архитекторы предприятия моделируют ”информационно насыщенные» бизнес-системы, в которых важными элементами являются потоки данных и хранилища данных.
ArchiMate плохо разбирается в архитектуре данных. Является ли его “объектом данных” сообщение или поток данных? область памяти или хранилище данных? или отдельный фрагмент информации, передаваемый внутри сообщения или сохраняемый в памяти? Предпосылкой здесь является то, что каждый объект данных представляет собой элемент данных или более крупную структуру данных, которая имеет смысл или ценность для ее создателей и пользователей.
В ArchiMate не говорится о структурах данных, содержащихся в объектах данных, но они там есть. Объект данных может быть маленьким или большим. Это может быть отдельный элемент данных или объект клиента с несколькими атрибутами. Это может быть совокупная сущность, такая как клиент, с заказами и номенклатурами заказов. Или большая и сложная структура данных, содержащая клиентов, заказы, номенклатуры заказов и типы продуктов. Каким бы маленьким или большим ни было содержимое объекта данных, оно может быть определено в модели данных.
Принцип 4.1: сообщение или поток данных передает объект данных от источника к цели.
Дискретное сообщение или поток данных (или интерфейс в TOGAF) передает объект данных от источника к цели. Сообщения занимают пространство и принимают физическую форму (например, цифровую или бумажную). Вы можете нарисовать стрелку потока, чтобы показать перемещение данных / информации / ценности между исходным и целевым элементами. Вы можете разработать каждую взаимосвязь потоков данных, используя две стрелки и объект данных, таким образом [исходный элемент —> объект данных —> целевой элемент].
Обратите внимание, что любая отдельная служба может использовать и / или возвращать поток данных, даже если это не показано на диаграмме.
Принцип 4.2: В памяти или хранилище данных сохраняется объект данных для использования субъектами или компонентами, выполняющими определенные действия.
Дискретная память или хранилище данных (или компонент данных в TOGAF) сохраняет объект данных для использования действующими лицами или компонентами, выполняющими определенные действия. Память занимает пространство и принимает физическую форму (например, цифровую или бумажную). Цель отображения хранилищ данных в модели системы — определить независимо поддерживаемые области памяти. Особенно те, которые содержат большие и сложные структуры данных, состоящие из множества структур данных и элементов меньшего размера.
Как представить хранилище данных? В ArchiMate нет символа хранилища данных, но есть различные символы, которые могут быть использованы.
- Объект данных – может представлять структуру данных любого масштаба, от атомарного элемента данных до большой и сложной структуры данных.
- Артефакт – может представлять развертываемое определение структуры данных (например, схему сообщений или схему базы данных).
- Системное программное обеспечение – может представлять систему управления данными (например, СУБД).
- Компонент приложения – может представлять уровень сервера данных, который инкапсулирует хранилище данных или другой источник данных.
Не очевидно, какой символ лучше. Вы можете сказать, что хранилище данных — это пассивная структура, которая не выполняет никаких действий. Таким образом, хранилище данных можно смоделировать как объект данных – возможно, большой и сложный. Во время выполнения хранилище данных создает экземпляры концепций, определенных в любой связанной логической модели данных; оно содержит фактические данные (например, строки в таблицах базы данных). Для того, чтобы это было полезно, оно должно быть каким-то образом инкапсулировано службами ввода / получения. Это означает, что его можно смоделировать как компонент приложения. Итак, должны ли мы нарисовать объект данных или компонент приложения? ArchiMate не позволяет вам рисовать потоки данных к объектам данных или из них, поэтому, если вы хотите это сделать, вам придется представить хранилище данных в виде компонента приложения.
Принцип 4.3: Количество ассоциаций – это Важно!
В ArchiMate нет способа показать количество элементов ассоциативного отношения. В результате люди используют композицию для обозначения ассоциации из 1-N, а агрегацию — для обозначения ассоциации из N-N. Точно так же, как нам нужны символы AND и OR для соединения взаимосвязей, нам нужен символ мощности, чтобы показать, где системный элемент на одном конце взаимосвязи может отображаться в нескольких экземплярах в операционной системе.
Предпосылка 5: модели — это абстракции
Предпосылка: Все системные описания абстрагируются от существующих или планируемых операционных систем. Опущение деталей, пожалуй, является наиболее базовым и универсальным методом абстракции. Например:
- После абстракции с помощью делегирования в описании клиента отсутствует поведение, делегированное серверам.
- После абстрагирования с помощью композиции описание целого скрывает детали его частей.
- После абстрагирования с помощью обобщения в описании обобщения опускаются детали любых специализаций.
- После абстракции с помощью идеализации в описании логической вещи опускаются детали более физических усовершенствований или конкретизации.
*Абстра́кция — процесс отвлечения (абстрагирования) от тех или иных характеристик объекта для их избирательного анализа; при этом наблюдаемый объект замещается его идеализированным теоретическим образом — абстрактным объектом.
В этой таблице представлен каждый из этих четырех видов абстракции в виде четырехуровневой иерархии.
Делегирование полномочий Состав Обобщение Идеализация ПриложенияСистемное программное обеспечениеАппаратное обеспечение Среднезернистый композитДетализированный композитЭлементарная часть Довольно общийДовольно специфичныйУникальная конфигурация Логическая модельФизическая модельФизические материалы Серверы Декомпозиция Специализация Реализация
Примечание: Соответствия вдоль ряда не подразумеваются.
Принцип 5.1: Декомпозиция представлений активной структуры и поведения определяет одни и те же элементарные действия
*Декомпозиция — операция мышления, состоящая в разделении целого на части. Также декомпозицией называется общий приём, применяемый при решении проблем, состоящий в разделении проблемы на множество частных проблем, а также задач, не превосходящих суммарно по сложности исходную проблему, с помощью объединения решений которых, можно сформировать решение исходной проблемы в целом.
В UML фундаментальная или элементарная единица поведения – наиболее детализированное поведение в модели системы – называется “действием”. Объединение действий в последовательный поток — это то, как мы определяем более длительное поведение (процесс, документооборот, конечный автомат или взаимодействие). Кластеризация действий по какому-то другому критерию сплоченности — это то, как мы проектируем структурные элементы (функции, компоненты, интерфейсы и т.д.). В ArchiMate следует рассмотреть принцип, согласно которому представления активной структуры и поведения можно разложить на одни и те же элементарные действия, и способы представления этого сочетания с помощью символов на диаграммах.
Принцип 5.2: архитекторы как обобщают, так и идеализируют типы элементов системы
Корпоративные архитекторы обычно стремятся обобщить компоненты, сервисы и интерфейсы для повторного использования на предприятии. В этой таблице показано, как схема TOGAF для артефактов описания архитектуры (континуум предприятия) сопоставляет уровни обобщения (столбцы) с уровнями идеализации (строки).
Идеализация (Универсальный) (Довольно общий) (Довольно специфично) (Уникальная настройка) Требования и контекст Архитектурный континуум (логические модели) Архитектура фундамента Общая системная архитектура Отраслевая архитектура Архитектура организации Континуум решений (физические модели) Фундаментальные решения Общие системные решения Отраслевые решения Организационные решения Развернутые решения
Принцип 5.3: Делегирование лучше всего отличать от реализации
Обычно сложную систему описывают или проектируют, разделяя ее на иерархические уровни клиент-сервер. Это упрощает проектирование более высоких систем, которые делегируют полномочия более низким системам, которые зависят от более низких систем и т.д. Делегирование позволяет описать систему более высокого уровня без каких-либо ссылок на то, как работает система более низкого уровня.
ArchiMate говорит о реализации, где делегирование кажется более подходящим термином. Клиент использует сервер или делегирует его серверу; не идеализирует его. Приложение делегирует полномочия устройствам; не идеализирует эти устройства. Приложение для выставления счетов делегирует полномочия программному узлу базы данных или функции; не идеализирует это. И наоборот, сервер обслуживает клиента; не осознает этого. Устройство обслуживает системное программное обеспечение; оно этого не осознает. Программный узел системы баз данных обслуживает биллинговое приложение; не реализует его.
UML может отображать делегирование полномочий от клиентов к серверам с помощью стрелки зависимости. С этой целью ArchiMate использует отношение “используется» в обратном направлении (что означает “обслуживает”).
Принцип 5.4: Корпоративные архитекторы моделируют лишь часть реальности
Корпоративные архитекторы не описывают всю суету, гул, неразбериху реальности; удивительное разнообразие действующих лиц и видов деятельности при ведении бизнес-операций. Они не описывают биохимию человека, человеческое познание или социальную коммуникацию человека. Они не описывают здания, лифты, двери, транспортные средства, кабели и компьютерные процессорные чипы. Они не описывают, возможно, 99% биологического, физического или материального мира, на который опирается бизнес.
TOGAF в своем методе разработки и “континууме предприятия” использует четыре различных вида абстракции для классификации и разделения описаний архитектуры. В этой таблице каждый вид абстракции представлен в виде четырехуровневой иерархии; соответствия вдоль ряда не подразумеваются.
Метод разработки архитектуры Континуум предприятия Делегирование полномочий Состав Обобщение Идеализация Клиенты Составлено Общие сведения Идеальный вариант Роли Предприятие / Стратегия Основа Требования Приложения Сегменты Общая система Строительные блоки архитектуры Системное программное обеспечение расширенные возможности Отрасль Строительные блоки решений Аппаратное обеспечение Организация Развернутые решения Разделы Разложено по полочкам Специфика Реальный
Даже нижняя строка (развернутые решения) enterprise continuum от TOGAF представляет собой огромную абстракцию от реальности операционных систем.
Принцип 5.5: Опущение деталей
Опущение деталей — это, пожалуй, самый базовый и универсальный метод абстракции. TOGAF подразумевает опущение промежуточных объектов, которые часто отображаются на архиматных диаграммах.
Предпосылка 6: Все типизировано
Предпосылка: Архитекторы обычно моделируют типы, а не экземпляры. Операционная система содержит отдельные элементы (элементы структуры и характеристики поведения), которые являются полными, точными и конкретными. Архитекторы, напротив, создают весьма абстрактные модели. В моделях представлены типы объектов; типы абстрактны, неполны и могут быть нечеткими.
Различие между типом и экземпляром обычно интерпретируется как различие между описанием и реальностью. Экземпляр — это все, что воплощает или демонстрирует свойства типа. Создание экземпляра поведенческого типа отличается. Симфоническое исполнение — это пример симфонии. Производство автомобиля — это пример процесса производства автомобиля. Вычисление площади прямоугольника — это пример вычисления площади прямоугольника.
Как правило, системы состоят из действующих лиц (адресуемых структур), которые выполняют действия (поведение с ограничениями по времени). И действующие лица, и действия представлены в виде описательных типов и операционных экземпляров.
Системы Поведение с ограничениями по времени Адресуемые структуры Типы Типы действий описывают единицы поведения, которые являются переходными. Например. Контракт на обслуживание, технологическая схема процесса или диаграмма взаимодействия / последовательности. Типы действующих лиц описывают типы атрибутов, которые должны быть у действующего лица, и типы действий, которые оно может выполнять. Например. роль. Функция. Определение интерфейса. Примеры Действия – это временные характеристики, которые выполняются с течением времени от начала до конца. Например. Любой процесс, который реализует логику в сервисном контракте, блок-схеме или диаграмме взаимодействия / последовательности. Действующие лица адресуемы в пространстве, выполняют действия, имеют поток контроля и текущее состояние. Например. Действующие лица, которые играют роли. Организационные единицы, реализующие функции. Экземпляры компонентов, реализующие интерфейсы.
Например, в UML класс определяет типы поведения, которые могут выполняться объектами, создающими экземпляр класса.
UML Поведение с ограничениями по времени Адресуемые структуры Типы Типы операций Классы Примеры Примеры операций Активные объекты
Естественный язык часто стирает различие между типами и экземплярами системных элементов. Для их разграничения можно использовать терминологию UML и ArchiMate. Таким образом:
- Тип активного структурного элемента описывает (каждый элемент в наборе) похожих действующих лиц, компоненты или узлы.
- Тип поведенческого элемента описывает (каждый элемент в наборе) схожие характеристики
- Тип события описывает (каждый элемент в наборе) похожие события.
- Тип данных описывает (каждый элемент в наборе) похожие структуры данных или элементы.
В этой таблице типы и экземпляры, приведенные выше, соотносятся с системными аспектами ArchiMate.
Аспект ArchiMate Введите модель Человек в операционной системе Активная структура Роль Субъект: имеет состояние и отношения с другими субъектами Поведение Процесс Производительность: выполняется от начала до конца в соответствии с бизнес-правилами Поведение Мероприятие Возникновение: запускает производительность процесса Пассивная структура Объект данных Структура данных / элемент: кодирует конкретную значимую информацию (может быть создана, перемещена, изменена или уничтожена).
В основном архитекторы моделируют типы объектов. Архитекторы почти никогда не ссылаются на отдельные события или характеристики процессов, но иногда они называют отдельных действующих лиц или компоненты и, возможно, даже значения отдельных структур данных / элементов (инвариантов).
Принцип 6.1: Тип действующего лица или компонента описывает похожих действующих лиц или компонентов.
Действующие лица распределяются по ролям. Строго говоря, то, что создает экземпляр роли, — это назначение действующего лица на эту роль. Однако создание этого экземпляра обычно рассматривается с точки зрения роли (а не с точки зрения человека). Таким образом, менеджеры организационных подразделений и корпоративные архитекторы рассматривают актеров как создающих экземпляры ролей. То, чем являются действующие лица и что они делают за пределами выполнения ролей в системе, не отражено в наших моделях бизнес-систем.
В таблице ниже показаны подразделения организации , создающие экземпляры функций способом, аналогичным исполнителям , создающим экземпляры ролей
Бизнес Люди Организация Типы Роли Функции Примеры Действующие лица Организационные единицы
ArchiMate явно не отличает типы от экземпляров, но обычно моделирует типы. Вы не будете моделировать производство одного отдельного автомобиля, но можете смоделировать общий процесс производства автомобилей. Однако вы можете смоделировать одного отдельного субъекта, которому назначена определенная роль. Эта таблица расширяет двумерную сетку, чтобы показать различия между типами и экземплярами, которые можно нарисовать в ArchiMate.
Вид Модели поведения Структуры Логические типы Примеры во времени Примеры в пространстве Логические типы Внешний Бизнес -услуги Случаи предоставления услуг Бизнес-интерфейсы? Соглашения об уровне обслуживания Внутренний Бизнес -процессы Эффективность процессов Люди — действующие лица Роли
Любопытно, что ArchiMate позиционирует функции как элементы поведения. В этой таблице бизнес-функция наконец-то оказывается там, где ей, по-видимому, место. Но теперь позиция бизнес-интерфейса вызывает сомнения.
Принцип 6.2: Реализация имеет множество возможных значений
Системные модели скрывают бесконечно подробные физические характеристики реальных действующих систем. ArchiMate говорит, что “реализация связывает логическую сущность с более конкретной сущностью, которая ее реализует”. Определять термин с использованием самого термина — плохая практика, поскольку это не помогает читателю. Это оставляет реализацию открытой по крайней мере для четырех возможных значений, проиллюстрированных здесь в терминах концепций объектно-ориентированного программного обеспечения.
Эти более логичные вещи Вы могли бы сказать Эти более конкретные вещи Классы реализуются путем создания экземпляра в Объекты Методы (услуги) реализуются путем внедрения в Тела методов (процессы) Абстрактные классы (интерфейсы) реализуются путем внедрения в Конкретные классы (компоненты) Классы UML разработаны для Классы Java
Но в примерах ArchiMate стрелка реализации используется для особого выбора этих значений.
Возможно, вы услышите, что «реализация» означает создание экземпляра типа в реальных условиях, как показано в этой таблице.
Логические типы Вы могли бы сказать Физические экземпляры Типы данных реализуются путем создания экземпляра в Структуры данных / элементы Мероприятия реализуются путем создания экземпляра в Примеры Процессы реализуются путем создания экземпляра в Результаты Роли реализуются путем создания экземпляра в Действующие лица
Но ArchiMate, похоже, не использует реализацию в этом смысле создания экземпляра.
Можно сказать, что внешняя служба или интерфейс реализуются путем внедрения в один или несколько внутренних процессов или компонентов.
Внешние элементы Вы могли бы сказать Внутренние элементы Услуги реализуются путем внедрения в Процессы Интерфейсы реализуются путем внедрения в Компоненты
Любопытно, что ArchiMate говорит о первом, но не о втором (вместо этого говорится, что интерфейс является частью компонента.
Вы могли заметить, что TOGAF уделяет большое внимание определению строительных блоков логической архитектуры (ABB) выше и предшествует строительным блокам физических решений (SBB). Логические описания ABB заранее спроектированы в SBB, которые по-прежнему являются только описаниями и “сильно абстрагированы” от материальных компонентов или компонентов выполнения.
Logical ABBs Вы могли бы сказать Physical ABBs Бизнес -функции разработаны для Описания организационных подразделений Компоненты логических приложений разработаны для Физические компоненты приложения Компоненты логических технологий разработаны для Компоненты физических технологий
ArchiMate использует этот усовершенствованный подход, но только в области архитектуры данных.
Logical ABBs Вы могли бы сказать Physical ABBs Бизнес -объекты разработаны для Объекты данных в модели данных Объекты данных разработаны для Таблицы базы данных в схеме базы данных или артефакте
ArchiMate не предлагает иерархии идеализации-реализации активных структурных элементов. Однако приведенная ниже таблица (с использованием сочетания терминов TOGAF и ArchiMate) показывает, где стрелка реализации может использоваться для привязки логических элементов к более физическим / реальным элементам.
домены Этот логический тип относится к и реализации Приложения TOGAF: Логический компонент приложения реализуется Физические компоненты приложения ArchiMate: прикладная функция / интерфейс / сервис реализуется Компоненты приложения ТЕХНОЛОГИЯ TOGAF: Логический технологический компонент реализуется Компоненты физических технологий ArchiMate: Инфраструктурная функция / интерфейс / сервис реализуется Узлы инфраструктуры
Разработка трех принципов
Принцип 5.1: Декомпозиция представлений активной структуры и поведения определяет одни и те же элементарные действия
Физики считают, что наш мир встроен в четырехмерный пространственно-временной континуум. Это называется “континуумом”, потому что предполагается, что пространство и время могут быть разделены без каких-либо ограничений по размеру или продолжительности. Описания бизнес-систем могут быть иерархически разделены по пространству / структуре и по времени / поведению.
Структурный состав / декомпозиция
Структурный вид определяет, из чего состоит система. Он определяет действующих лиц и компоненты, которые выполняют поведение (наряду с интерфейсами и структурами данных). Структурная декомпозиция последовательно разделяет пространство на более мелкие области. Биологи описывают организм в терминах органов, затем тканей, затем клеток, и т.д.. Архитекторы разбивают большую систему на крупные компоненты, которые подразделяются на более мелкие и так далее. Система более высокого уровня может быть описана только в терминах самых крупных компонентов, скрывающих внутренние детали более мелких компонентов.
Поведенческая композиция / декомпозиция
Поведенческий взгляд на систему определяет, что делает система, как она работает. Он определяет обычные службы и процессы, которые выполняются от начала до конца, неоднократно. Поведенческая декомпозиция последовательно делит время на более короткие промежутки. Мы можем разделить длительный процесс на короткие этапы, разделить эти этапы на более короткие этапы и так далее. Процесс более высокого уровня может быть описан только в терминах следующих самых крупных этапов процесса, скрывающих внутренние детали более мелких этапов.
Функции можно рассматривать как логические компоненты. Бизнес-функции можно рассматривать как логические организационные единицы. Иерархия функциональной декомпозиции группирует действия в структурном представлении. Напротив, иерархия декомпозиции процессов группирует действия в поведенческом представлении. Итак, если обе иерархии разложены на один и тот же уровень, они должны сводиться к одним и тем же элементарным действиям. Этот принцип очевиден в методах структурированного анализа, используемых в фреймворках EA, таких как Avancier Methods, EA3 и TOGAF. Элементарная деятельность может быть названа элементарной бизнес-функцией и/ или элементарным бизнес-процессом.
Декомпозиция представлений поведения и активной структуры на один и тот же уровень
В UML фундаментальная или элементарная единица поведения – наиболее детализированное поведение в модели системы – называется “действием”. Объединение действий в последовательный поток — это то, как мы определяем более длительное поведение (процесс, документооборот, конечный автомат или взаимодействие). Кластеризация действий по какому-то другому критерию сплоченности — это то, как мы проектируем структурные элементы (функции, компоненты, интерфейсы и т.д. В ArchiMate следует рассмотреть принцип, согласно которому представления активной структуры и поведения можно разложить на одни и те же элементарные действия, и способы представления этого сочетания с помощью символов на диаграммах.
Принцип 5.5: Опущение деталей
Опущение деталей — это, пожалуй, самый базовый и универсальный метод абстракции. TOGAF подразумевает опущение промежуточных объектов, которые часто отображаются на архиматных диаграммах.
Например, эта модель в стиле ArchiMate.
Элемент Отношение Элемент Отношение Элемент Обслуживание Присвоено из Интерфейс Часть Компонент Реализовано Процесс Для
Обычно в TOGAF это сводится к этой модели.
Элемент Отношение Элемент Обслуживание Реализовано Компонент
С другой стороны, не всегда возможно или полезно выводить прямую взаимосвязь из прямых. Иногда потому, что существует несколько возможных путей взаимосвязи. Иногда из-за того, что блоки представляют большие и сложные типы, состоящие из множества более мелких и простых элементов, а строки, связывающие экземпляры исходного и целевого типов, часто соединяют элементы внутри исходного и целевого экземпляров. А иногда потому, что взаимосвязи могут быть необязательными.
Например, ArchiMate утверждает, что если A-связано-с B-связано-с-C, то A-связано-с-C. Обязательно ли это верно? Что, если A запускает поведение внутри B, которое не имеет отношения к C? Или запускает поведение, которое выбирает, запускать C или нет? Если стратегия запускает Маркетинг и продажи, запускает жалобы и компенсацию, уместно ли говорить, что стратегия запускает жалобы и компенсацию?
Например, ArchiMate утверждает, что если A-связано-с B-связано-с-C, то A-связано-с-C. Что, если A связан только с частью B, которая не связана с C? Если ассоциации Клиент-Показ фильма-Актер фильма, уместно ли говорить, что Клиенты связаны с актерами?
В каком-то смысле каждая часть системы связана с любой другой частью, прямо или косвенно, иначе были бы отдельные системы. Но с архитектурной точки зрения связывать каждую часть с любой другой не имеет смысла или пользы.
Принцип 1.4: бизнес-интерфейсы не являются каналами связи платформы
Социальная, деловая или программная система инкапсулируется логически, а не физически. Интерфейсы «от субъекта к субъекту» или «от бизнеса к бизнесу» могут быть определены в документе соглашения об уровне обслуживания, в котором перечислены вызываемые бизнес-службы. Поскольку действующие лица и компоненты распределены, они должны обмениваться отдельными коммуникационными событиями, чтобы вызывать поведение и отвечать на вызовы, и должен существовать физический канал связи, по которому могут передаваться коммуникационные события. В примерах ArchiMate наблюдается путаница между концепцией логического бизнес-интерфейса (указывающего, какие службы могут быть вызваны) и каналами физической инфраструктуры, через которые могут быть вызваны службы.
В этой таблице бизнес-функция представлена там, где ей, по-видимому, место, но освещается вопрос о том, где место бизнес-интерфейсу.
Вид Модели поведения Структуры Логические типы Примеры во времени Примеры в пространстве Логические типы Внешний Бизнес -услуги Случаи предоставления услуг Бизнес-интерфейсы? Соглашения об уровне обслуживания Внутренний Бизнес -процессы Эффективность процессов Люди действующие лица Роли
Поскольку ArchiMate предполагает, что интерфейс является точкой доступа к сервисам, он приведен в качестве примера выше. Но диаграммы бизнес-архитектуры, показывающие бизнес-интерфейсы, называемые “телефон” или “веб”, вызывают большие сомнения. Это общие инфраструктурные устройства или пути связи. Они не привязаны (как настаивает ArchiMate, интерфейс должен быть) к одной-единственной бизнес-роли или действующему лицу.
Коммуникации B2B и B2C зависят, например, от общей коммуникационной инфраструктуры:
- Речь лицом к лицу — из уст в ухо через физическую среду звуковых волн.
- Телефонная речь – говори на ухо через глубокий коммуникационный стек телекоммуникационной сети.
- Электронная почта Snail – от записи к чтению с использованием бумаги по коммуникационному стеку почтовой службы.
- Электронная почта – от записи к чтению с клавиатуры и экрана через SMTP / IMAP через TCP через IP через Ethernet через физические ИТ-носители.
Мы рассматриваем бизнес-области, приложения и инфраструктуру как уровни клиент-сервер. А в “открытой” (а не закрытой) архитектуре клиент-сервер уровни можно пропустить. Таким образом, выполняя бизнес-роль, человек-исполнитель может напрямую вызывать инфраструктурную службу. Но общие инфраструктурные устройства и каналы связи не являются системными интерфейсами, специфичными для бизнеса.
Итак, что такое специфичный для бизнеса интерфейс? Своего рода соглашение об уровне обслуживания определяет (логически), какие услуги требуются или предоставляются бизнесу. Затем этот логический интерфейс может быть реализован в интерфейсе приложения, с помощью которого клиенты могут вызывать отдельные службы. Или в телефонной автоответчике, который предоставляет клиентам услуги, зависящие от домена (нажмите 1 для этого, 2 для того). Часто это реализуется в официальных запросах на работу и менее формальном общении между людьми.
Вот некоторые концепции, связанные с идеей интерфейса, которые следует распутать.
- Соглашение об уровне обслуживания: контракт или другая форма определения интерфейса, который объявляет, какие службы могут вызывать клиенты, но не является механизмом доступа во время выполнения.
- Элементы управления: механизмы (включая пользовательские интерфейсы), которые предоставляют клиентам инструменты для прямого вызова служб, специфичных для домена.
- Справочник: «прямой брокер” или агент по внедрению, который объявляет услуги и предоставляет их адреса клиентам.
- Facade: компонент “косвенного посредника”, который принимает события и запросы на обслуживание и передает их серверным компонентам.
- Коммуникационный стек: платформенные технологии, используемые в каналах связи между участниками или компонентами.
Выводы и рекомендации
Очень сложно (неестественно) использовать слова дисциплинированным образом. Но профессионал обязан понимать, какие слова для конкретной предметной области являются двусмысленными, где могут возникнуть недоразумения, и четко указывать решения. Стандартные языки моделирования — это только часть ответа.
Широко распространено незнание предпосылок теории систем. Это затрудняет обучение людей концепциям архитектуры и приводит к непоследовательному использованию языков моделирования. Использование тех же символов, что и у кого-либо другого, не означает, что вы используете тот же язык. И довольно часто читатель диаграмм не уверен, что имел в виду автор диаграммы.
Такие слова, как функция и сервис, используются в естественном языке по-разному и расплывчато. Если попросить комитет определить их значения на языке моделирования, он может попытаться угодить всем, ослабив определения до степени двусмысленности. Таким образом, становится невозможным передать ценные и необходимые концепции с какой-либо определенностью. Компрометация определений символов для удовлетворения всех желающих и всех практик приводит к непоследовательности и непоследовательности и затрудняет обучение архитекторов.
Конечно, многие используют инструменты системного моделирования так же, как они использовали бы PowerPoint. Налицо сочетание лени, сомнительных примеров и низкого качества обучения. Но проблемы, поднятые в этой статье, могут быть решены достаточно легко, и, безусловно, их следует решать, а не замалчивать. Мы должны стиснуть зубы и использовать “контролируемую лексику” – скорее то, что кажется наиболее естественным или распространенным языком сегодня. Здесь предпринята попытка определить основные термины в TOGAF.
ArchiMate может оставаться намеренно нестрогим, определяемым местами неоднозначно и местами независимо от более широкой теории систем. В этой статье предлагается использовать символы ArchiMate таким образом, чтобы они были более совместимы с предпосылками теории систем, лежащими в основе UML и TOGAF. Варианты включают:
- Объясните, что различие между структурой и поведением ArchiMate отличается от различий в других стандартах, и измените определения “сервиса” и “интерфейса” в стандарте, чтобы они напоминали то, что часто показывают примеры диаграмм (хотя это еще больше запутает структуру с поведением и абстрактное с конкретным).
- Приведите предпосылки ArchiMate в соответствие с принципами теории систем, рассмотрите все принципы в этой статье и пересмотрите примеры диаграмм, чтобы они соответствовали им.
- Добавьте этот документ к стандарту в качестве приложения по настройке ArchiMate для соответствия UML и TOFAF (текущее руководство по этому вопросу наивно и неадекватно).