Роль архитектурных решений

Построение и использование архитектурного подхода в разработке ПО может быть обобщенно представлено как последовательность обобщенных действий: понимание + анализ + коммуникация + конструирование 2.

Перечислим положительные факторы, получаемые от построения и использования архитектуры ПО. Архитектура:

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

Приведенный перечень получаемых от разработки архитектуры

выгод впечатляет. Разумеется, разработка архитектуры дорого стоит, но не дороже, чем негативы от ее отсутствия.

В понятии «архитектура» следует разделять концептуальные схемы, архитектурные стили и архитектурное описание модели.

1.4. Архитектурные концептуальные схемы.

Определение и ретроспектива

В практике архитектурных описаний ПО разного типа сложился специфический класс «Архитектурных концептуальных схем» (Architecture Frameworks), принадлежность к которому конкретной концептуальной схемы определяется по наличию у схемы вполне определенного набора признаков.

Концептуальные схемы являются обобщенными прагматически руководствами:

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

К числу особо важных составляющих концептуальной схемы относятся:

  • • «виды», как средства для понимания, взаимопонимания и коммуникативного взаимодействия лиц, заинтересованных в разработке ПО [ 16J;
  • • «методы», предоставляющие дисциплину, для того чтобы собирать и организовывать данные и конструкты «видов» способом, помогающим гарантировать целостность, точность и завершенность архитектурного представления ПО [17];
  • • «обучение/опыт», что обеспечивает разумное и конструктивное применение методов и обслуживающих их инструментов [18].

Архитектурная концептуальная схема Дж. Захмана

Особое место среди архитектурных концептуальных образцов занимает концептуальная схема Дж. Захмана [19] (1987 г.). Схема изначально нацеливалась на системное представление задач информатизации, в которых приходится учитывать специфику ПО.

С момента своего создания схема Дж. Захмана постоянно совершенствовалась, оставаясь определенного рода «вопросником» о существенных аспектах ПО. Схема построена в форме табличной структуры, для формирования и использования которой необходимо построить систему ответов, каждый из которых заполняет определенную позицию таблицы. Ответ может быть как простым, так и сложным. Одной из наиболее распространенных форм ответов является визуализируемая концептуальная модель (рис. 3).

Архитектурная концептуальная схема Дж. Захмана

Рис. 3. Архитектурная концептуальная схема Дж. Захмана

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

Данные

ЧТО

Функции

КАК

Дислокация, сеть

ГДЕ

Люди

КТО

Время Мотивация

КОГДА ПОЧЕМУ

Плани

ровщик

Список

важных

понятий и объектов

Список

основных

бизнес-

процессов

Территори

альное

располо

жение

Ключевые

организации

Важнейшие

события

Бизнес-цели и стратегии

Сфера

действия

(контекст)

Владелец,

менеджер

Концепту

альная

модель

данных

Модель

бизнес-

процессов

Схема

логистики

Модель

потока

работ

(workflow)

Мастер-

план

реализации

Бизнес-

план

Модель

предприятия

Конструктор, архитектор

Логические

модели

данных

Архитектура

приложений

Модель распределенной архитектуры

Архитектура

интерфейса

пользователя

Структура

процессов

Роли и модели бизнес-правил

Модель

системы

Технологи

ческая

(физическая)

модель

Проекти

ровщик

Физическая

модель

данных

Системный

проект

Технологич.

архитектура

Архитектура

презентации

Структура

управления

Описания

бизнес-прави;

Разра

ботчик

Описание

структуры

данных

Программный код

Сетевая

архитектура

Архитектура

безопас

ности

Определе

ние

временных

привязок

Реализация

бизнес-

логики

Детали

реализации

Данные

Работаю

щие

программы

Сеть

Реальные

люди,

организации

Бизнес-

события

Работающие бизнес-стратегии

Работающее

предприятие

Данные

Функции,

процессы

Сеть,

располо

жение

систем

Люди, Время, Мотивация

органи- расписа-зации ния

Рис. 4. Пример реализации схемы Дж. Захмана

Пример конкретной реализации схемы Захмана приведен на рис. 4.

То содержание, которое вкладывается в каждый ряд и каждый столбец схемы, представлено в табл. 1 и 2.

Здесь и далее используется термин «ВИД» (View). Понимать этот термин следует по аналогии с чертежами и конструкторской документацией: вид на деталь справа, слева, сверху, оксонометрия детали, описание применяемого материала... Для программирования, например, вид с точки зрения пользователя — внешние интерфейсы, вид с точки зрения программиста — структуры данных и алгоритмы работы программы и т. п. [ 201.

Таблица 1. Описание назначения строк схемы

Ряд схемы

Содержание

1. Цели и границы (Вид планировщиков)

Определяет основные цели и границы, в рамках которых должны приниматься архитектурные решения

2. Модель предприятия, системы (Вид владельцев, ответственных за систему)

Определяет сущность предприятия (системы), включая структуры, процессы и организационные структуры

3. Модель базового понимания (информационного представления, Вид архитектора)

Определяет в более строгих терминах содержание ряда 2

4. Технологическая модель (Вид проектировщиков)

Определяет, как и какая технология должна быть использована для того, чтобы запросы третьего ряда были удовлетворены

5. Детализированное представление (Вид разработчика)

Определяет детали проектирования, применяемые языковые средства, структуры данных и

другие средства

6. Функциональности системы (Вид пользователей)

Определяет, как должны работать системы в рамках предприятия ( в контексте окружения)

Таблица 2. Описание назначения столбцов схемы

Столбец

Содержание

1. Данные (Структура, Что?)

Фокусирует внимание на сущностях, объектах, компонентах и отношениях между ними

2. Функции (Активность, Как?)

Фокусирует внимание на той деятельности, которая осуществляется организацией и поддерживается автоматизированными системами

3. Сеть работ (Месторасположение, Где?)

Фокусирует внимание на географическом (физическом) распределении активностей

4. Люди (Кто?)

Фокусирует внимание на тех лицах, которые вовлечены в бизнес-процессы

5. Время (Когда?)

Фокусирует внимание на эффектах, связанных со временем ( планирование, события)

6. Мотивации (Почему?)

Фокусирует внимание на целях, стратегиях и ограничениях, специфических для реализации системы

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

Развитие концептуальной схемы Дж. Захмана до трех измерений за счет перехода к многослойной структуре системы моделей показано на рис. 5.

В трехмерную структуру введены следующие дополнения, детализирующие содержание артефактов, которые приписываются «клеткам схемы Дж. Захмана»:

  • • слой разработки, раскрывающий «Что?» должно быть сделано для каждого артефакта, приписанного к «клетке» схемы Дж. Захмана;
  • • слой метаданных, включающий описание информации, которая должна быть собрана и «Как?» она должна быть организована;
  • • слой документирования, раскрывающий типовые формы документов, в которых «Где?» будет зафиксирована информация;
  • • слой ответственности, фиксирующий, «Кто?» из команды разработчиков будет исполнять требуемые работы;
  • • слой жизненного цикла, показывающий, «Где?» в процессе разработки будет создан соответствующий артефакт;
  • • слой целей, описывающий, «Почему?» следует включать артефакт в состав архитектурного описания.

Для предлагаемого расширения автором трехслойной модели разработаны детали для каждого слоя (и для каждой клетки слоя).

Архитектурная концептуальная схема DoDAF

DoDAF (Department of Defense Architecture Framework) создана по заказу Департамента обороны США.

Архитектурное описание ПО в DoDAF строится на базе модели данных ядра архитектуры (Core Architecture Data Model, CADM). CADM представляет собой стандартизованную систему понятий для определения видов и их составляющих в базе данных [21].

Вид понимается традиционно и представляет определенный объем операций, систем и технических стандартов. Каждый вид является хорошо определенным множеством элементов данных в составе CADM. Архитектурные артефакты документируются с использованием языка UML.

Виды объединены в четыре группы. Первая группа называется «Все виды» (All Views) и содержит обзор, обобщения и интегрированный словарь по архитектуре DoDAF. Остальные группы — это «Операционные виды» (Operational Views), «Системные виды» (System Views) и «Технические виды» (Technical Views). Обобщенная картина видов представлена на рис. 6.

Активности/задачи

- Операционный

вид

Информационные потоки

Операционные

элементы

Раскрывает, что необходимо делать и кто будет действовать

Системы и их связность

Предписывает стандарты и соглашения

Рис. 6. Архитектурная концептуальная схема DoDAF

Операционные виды описывают специфику деятельности и операции, узлы операций, узлы соединений, информационный обмен, организационные отношения, правила операций, последовательности событий и логическую модель данных. Описания, содержащиеся в этой группе, распределены по 24 подвидам (каждый подвид является видом по определению IEEE-1471).

Системные виды описывают систему и ее компоненты, системные интерфейсы, коммуникативное взаимодействие, матрицу отношений на множестве систем и подсистем, функциональности, матрицу связности (traceability), эволюцию, использование и технологические предсказания. Группа состоит из подвидов.

Технические виды (группа из 12 подвидов) описывают текущий стандартный профиль и предсказания по его изменениям.

Архитектурная концептуальная схема DoDAF разработана для военных нужд, и в этом плане она является предметно-зависимой. Следует отметить, что DoDAF предоставляет ограниченные возможности по моделированию конфигурации ПО и моделированию нефункциональных требований.

Данные

Функции

Среда

| Люди

Время

Мотивы

List of Things

О

List of Proc-

О

List of Locations

Last of Organizations

Inmuciuojto

a • * • *

List of Events Significant to

Ъе:

Time= Business

Г* a

List of Business ^4Nzie

e.g., Entity Relationship Diagrai"

п

Func^^

О

О

e.g.. Processing

e.g.. Knowledge Archf?y turc

Г» . • . •

О

4 )

c

1

/

e.g.. Knowledge

s

Ent=Fields

e.g., Program

о

о

e.g.. Know ledge

=

--

Time=lntcrrupt

Операционный вид Системный Технический

Рис. 7. Проекция системы DoDAF на схему Дж. Захмана

Ближайшим родственником архитектурной схемы DoDAF является схема MoDAF, разработанная европейскими союзниками США. В число основных потребностей, приводящих к отличиям схемы MoDAF от схемы DoDAF, входят следующие потребности.

  • 1. Потребность решать и моделировать задачи приобретения разного рода комплектующих аппаратного и программного типов.
  • 2. Потребность моделировать трансформационные программы и их взаимозависимости.
  • 3. Потребность моделировать компетентность и другие виды способностей лиц, вовлеченных в разработку и использование АС.
  • 4. Потребность моделировать необходимые для разработки АС кадровые ресурсы, подобно моделированию технических ресурсов.
  • 5. Потребность объединять информационные представления в традиционные модели архитектуры, чтобы обеспечить необходимой информацией работу архитекторов предприятия.

Средства DoDAF согласованы с концептуальной схемой Захмана. Объем пересечений между схемами (отмеченный овалами) отражен на рис. 7. В версиях DoDAF указывается, что они согласованы со стандартом IEEE-1471.

Архитектурная концептуальная схема TOGAF (1995 г.)

С момента ее первого опубликования в 1995 г. архитектурная концептуальная схема TOGAF (The Open Group Architecture Framework) развивается и используется. TOGAF позиционируется ее авторами не как некоторая эталонная модель, а как «средство для разработки архитектур информационных систем». Основное назначение — ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития. В декабре 2003 г. была опубликована версия 8.1 этой модели.

Основным полем для применения TOGAF является, прежде всего, программная инфраструктура информационной системы (в противоположность таким типам архитектур, как бизнес-архитектура, архитектура данных и приложений). Таким образом, она в наилучшей мере подходит для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего критичных для бизнеса (mission-critical). Поскольку эта интеграционная архитектура сильно зависит от принимаемых решений в остальных областях, то в рамках TOGAF в необходимой степени рассматриваются и эти смежные области.

В состав модели TOGAF входят две основные компоненты — методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и базовая архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Заметим, что в описании TOGAF добавлен специальный документ, поясняющий соответствие между понятиями TOGAF и моделью Захмана.

Общая структура TOGAF |22] показана на рис. 8.

Методика разработки архитектуры ADM

со

Техническая

эталонная

База

модель

База

элемен-

TRM

стандартов

тарных

блоков

Таксономия

сервисов

о.

>4

  • ?
  • 0

fc LJ_ X <

CL О

со о

5 Ь

со

со

о

го

со

LO

База ресурсов, в том числе язык АОМ1_, принципы, представления, примеры реализации

Рис. 8. Общая структура TOGAF

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

В соответствии с методикой ADM процесс разработки архитектуры включает следующие фазы:

  • • подготовка: уточнение модели под особенности организации, определение принципов реализации проекта;
  • • фаза А: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством;
  • • фаза В: разработка бизнес-архитектуры предприятия;
  • • фаза С: разработка архитектуры данных и архитектуры приложений;
  • • фаза D: разработка технологической архитектуры;
  • • фаза Е: проверка возможности реализации предложенных решений;
  • • фаза F: планирование перехода к новой системе;
  • • фаза G: формирование системы управления преобразованиями;
  • • фаза Н: управление изменением архитектуры.

Каждая фаза, в свою очередь, разбивается на подпроцессы (этапы), отдельные работы и т. д. Например, фаза D включает следующие основные подпроцессы:

  • • описание существующей технологической архитектуры;
  • • обзор бизнес-архитектуры, архитектуры данных и приложений для определения начальных данных и необходимой степени детализации;
  • • описание существующей системы с необходимой степенью детализации, которая выбирается для того, чтобы можно было выявить необходимые изменения при формировании целевой архитектуры. Формирование реестра используемых платформ программного и аппаратного обеспечения;
  • • выявление и описание элементарных архитектурных блоков — кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах;
  • • разработка черновика технического отчета, резюмирующего основные результаты изучения существующего состояния и возможности использования типовых блоков;
  • • направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок;
  • • формирование целевой технологической архитектуры;
  • • описание существующей системы в терминах TOGAF;
  • • определение перспектив (представлений) архитектуры;
  • • формирование модели целевой архитектуры;
  • • определение ИТ-служб (сервисов);
  • • подтверждение учета бизнес-требований;
  • • определение архитектуры и используемых блоков (шаблонов);
  • • проведение анализа расхождений (gap analysis).

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

Процесс разработки не заканчивается после выбора оптимальной архитектуры и разработки плана миграции. Необходимыми элементами являются задачи, выполняемые на фазах G и Н. В частности, для обеспечения практического принятия архитектуры в организации и успеха проекта обязательным является формирование системы управления реализацией архитектуры (Implementation Governance).

Применение TOGAF осуществляется как итеративный процесс. Итерации TOGAF (которые в руководствах называются циклами) обычно объединяют несколько фаз реализации и обслуживания архитектуры предприятия (рис. 9).

Жизненный цикл TOGAF

Рис. 9. Жизненный цикл TOGAF

Архитектурная схема РЕАР (1998 г.)

Ее специфика (рис. 10) связана с разработкой ПО в рамках системы задач государственного масштаба для США.

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

Федеральная архитектура определяет функции государственных организаций, информацию и технологии, необходимые для их реализации, а также процессы преобразований, необходимые для внедрения новых информационных технологий. Отдельные государственные организации должны использовать эту общую модель для описания своих собственных архитектур [23].

Архитектурная схема РЕАР

Рис. 10. Архитектурная схема РЕАР

Контрольные вопросы

  • 1. Дайте определение понятия «архитектура программного обеспечения».
  • 2. Как согласуются модели жизненного цикла разработки ПО и вопросы разработки архитектуры?
  • 3. Как и кто определяет грань между архитектурой программного обеспечения и детальным проектированием ПО?
  • 4. Перечислите выгоды, получаемые от построения и использования архитектуры.
  • 5. Что такое архитектурные концептуальные схемы?
  • 6. Какие составляющие архитектурных концептуальных схем наиболее важны?
  • 7. Как построена архитектурная концептуальная схема Дж. Захмана?
  • 8. Приведите определение понятия «вид».
  • 9. Каким образом объединяются «виды» в архитектуре ОоОАГ?
  • 10. Какова связь между концептуальной схемой Дж. Захмана и архитектурой

ОоОАГ?

  • 11. Каковы основные компоненты модели Т06АГ?
  • 12. Перечислите основные фазы процесса разработки архитектуры в соответствии с моделью Т06АЕ.
  • 13. Какова основная специфика и назначение архитектурной схемы ГЕАГ?
 
< Пред   СОДЕРЖАНИЕ     След >