Введение

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

В книге An Introduction to Software Architecture Дейвид Гарлан (David Garlan) и Мэри Шоу (Mary Shaw) пишут, что архитектура - это особый уровень проекта: "Помимо создания алгоритмов и структур данных, необходимо решить еще одну принципиальную задачу - разработать общую структуру системы. Процесс разработки структуры включает в себя создание общей инфраструктуры организации системы и управления ею, выбор протоколов и методов синхронизации и доступа к данным, распределение функций системы между компонентами, физическое распределение, объединение элементов проекта, масштабирование, оптимизацию производительности и выбор оптимальных вариантов среди доступных альтернатив". [GAR93]

Однако архитектура не ограничивается рамками структуры программного продукта. Сотрудники группы разработчиков архитектур IEEE называют архитектуру "концепцией системы высочайшего уровня в своей среде" [IEP1471]. В этом определении архитектура охватывает такие аспекты, как целостность системы, экономическую целесообразность ее реализацию, эстетику программирования и стиль. В рамках архитектуры рассматриваются не только внутренние элементы системы, но и взаимодействие системы с внешней средой, включая пользовательскую среду и среду разработки.

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

Описание архитектуры

Для обсуждения структуры программы сначала следует определить архитектурное представление, способ описания важных аспектов архитектуры. В RUP это описание фиксируется в Документе по архитектуре программного обеспечения.

Архитектурные представления

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

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

Типичный набор архитектурных представлений

Архитектуру можно представить в виде совокупности архитектурных представлений, каждое из которых описывает "значимый для архитектуры" элемент модели. В RUP отправной точкой при разработке архитектуры служит типичный набор архитектурных представлений, который называется "моделью 4+1" [KRU95]. Модель содержит следующие компоненты:

• Представление вариантов использования, в состав которого входят сценарии и варианты использования, описывающие значимые для архитектуры технические риски, классы и поведение системы. Это подмножество модели вариантов использования.
• Логическое представление содержит важнейшие классы проекта, распределенные по пакетам и подсистемам, которые, в свою очередь, распределены по слоям. Кроме того, это представление содержит некоторые реализации вариантов использования. Данное представление представляет собой подмножество модели проекта.
• Представление реализации содержит общие сведения о модели реализации и ее структуре с точки зрения модулей, пакетов и слоев. В это представление также входит информация о распределении пакетов и классов логического представления по пакетам и модулям представления реализации. Это подмножество модели реализации.
• Представление процессов содержит описание задач (процессов и нитей), их взаимодействия и конфигурации, а также взаимосвязи между классами и объектами проекта и задачами. Это представление применяется только в системах, обладающих значительным параллелизмом. В RUP это подмножество модели проекта.
• Представление развертывания содержит описания физических узлов наиболее распространенных конфигураций платформ и информацию о распределении задач (из представления процессов) между физическими узлами. Это представление применяется только с распределенными системами. Оно представляет собой подмножество модели развертывания.

Подробную информацию об архитектурных представлениях можно найти в документе по архитектуре программного обеспечения. Можно создавать и другие представления, отражающие те или иные аспекты системы: представление интерфейса, представление защиты, представление данных и т.д. В простых системах можно обойтись без некоторых из представлений, входящих в модель 4+1.

Фокус архитектуры

Хотя перечисленные выше представления могут полностью охватывать проект системы, в состав архитектуры входят только вполне определенные аспекты:

• Структура модели - организационные шаблоны, например слои.
• Базовые элементы - важнейшие варианты использования, классы, общие механизмы и т.п. (в противоположность всем элементам модели).
• Несколько ключевых сценариев, на которых продемонстрированы основные потоки управления в системе.
• Службы, характеризующие модульность системы, необязательные компоненты и аспекты, относящиеся к линиям продукта.

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

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

Шаблоны архитектуры

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

Примеры шаблонов архитектуры

В [BUS96] шаблоны архитектуры сгруппированы по характеристикам систем, в которых они наиболее часто применяются, при этом одна категория отведена под шаблоны общей структуры. В следующей таблице показаны категории [BUS96] и содержащиеся в них шаблоны.

Две из этих категорий подробно описаны в данной главе в качестве иллюстрации идей. Подробное описание можно найти в книге [BUS96]. Шаблоны представлены в следующей широко распространенной форме:

• Имя шаблона
• Контекст
• Задача
  • Описание различных аспектов задачи, которые следует принять во внимание.
• Решение
  • Обоснование
  • Результирующий контекст
  • Примеры

Имя шаблона

Слои

Контекст

Большая система, нуждающаяся в декомпозиции

Задача

Система должна работать одновременно с несколькими уровнями абстракции.   Например, система должна принимать во внимание вопросы управления аппаратным обеспечением, вопросы, связанные с общими службами, и вопросы, относящиеся к конкретным предметным областям. Крайне нежелательно разрабатывать вертикальные компоненты, в которых придется иметь дело со сложностями на всех уровнях сразу. Такой подход потребует многократного решения одних и тех же задач (вероятно, различными способами) в разных компонентах.

Движущие силы

• Компоненты системы должны быть взаимозаменяемы.
• Изменение компонентов не должно нарушать стабильность системы в целом.
• Схожие функции должны быть сгруппированы.
• Сложные компоненты могут нуждаться в декомпозиции .

Решение

Структура системы должна представлять собой несколько слоев компонентов. Компоненты верхних слоев должны пользоваться компонентами нижних слоев (но ни в коем случае не наоборот). Не рекомендуется пользоваться компонентами "через слой" (единственный вариант, когда это оправданно - это ситуация, когда искусственно созданные промежуточные слои не несут полезной нагрузки).

Примеры:

1. Общие слои

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

2. Уровни бизнес-системы

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

Более подробная информация об этом шаблоне приведена в разделе Рекомендация: многослойные структуры.

Имя шаблона

Доска

Контекст

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

Задача

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

Движущие силы

• Последовательность, в которой агенты принимают участие в решении задачи, не фиксирована и может зависеть от стратегии решения задачи.

• Разные агенты могут поставлять входные данные (результаты или частичные решения) в разных форматах и представлениях.

• Агентам неизвестно о существовании других агентов напрямую, однако они могут оценивать вклад других агентов в решение задачи.

Решение

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

Пример:

На этой диаграмме показано структурное (или статическое) представление, смоделированное с помощью UML. Это часть параметризуемого кооперирования, для которого фактические параметры устанавливаются в момент создания экземпляра по шаблону.

Архитектурный стиль

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

Архитектурный эскиз

Графическое изображение архитектурного представления называется архитектурным эскизом. Эскизы представлений, описанных выше, составляются из следующих диаграмм языка UML [UML01]:

• Логическое представление. Диаграммы классов, конечные автоматы и диаграммы объектов.
• Представление процессов. Диаграммы классов и объектов (включая нити и процессы задач).
• Представление реализации. Диаграммы компонентов.
• Представление развертывания. Диаграммы развертывания.
• Представления вариантов использования. Диаграммы вариантов использования с вариантами использования, субъектами и обычными классами, а также последовательные диаграммы, иллюстрирующие взаимодействие объектов проекта.

Процесс разработки архитектуры

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