Architectural Blueprints — The “4+1” View Model of Software Architecture

Оригинал: November 1995, Philippe Kruchten
https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf

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

Архитектура ПО = {Элементы, Формы, Обоснование/Ограничения}
Чтобы описывать большие и сложные архитектуры, мы предлагаем использовать 5 “взглядов”:

• Logical view: использует объектно-ориентированный метод конструирования
• Process view: охватывает параллелизм и синхронизацию аспектов проектирования
• Physical view: описывает отображение ПО на электронные устройства и отображает распределенные стороны
• Development view: описывает статическую организацию ПО в среде разработки
• Scenarios: наглядно показывает устройство архитектуры

Logical архитектура использует объектно-ориентированный подход, в основном поддерживает функциональные требования(какие сервисы система должная предоставлять пользователям). Для представления логической архитектуры используются обозначения диаграммы классов, шаблонов классов. Диаграмма классов показывает набор классов(Class) и их взаимосвязей: ассоциация(Association), использование(Usage), композиция, наследование(Inheritance), и т.д. Наборы связанных классов группируются по категориям класса(Class category). Схожие механизмы или сервисы определены в утилиты класса(Class utility).

Process архитектура рассматривает некоторые нефункциональные требования, такие как производительность и доступность. Process архитектура может быть описана несколькими уровнями абстракции.

• Сети(networks): соединяют различные части программы. Могут существовать несколько одновременно, разделяя одни и те же ресурсы.
• Процесс(process): представляет уровень, на котором архитектура может быть тактически контролируема. Также процессы реплицируются для увеличения распределения нагрузки при обработке или для улучшения доступности.
• Задания(tasks): отдельные потоки управления, которые могут быть запланированы в индивидуальном порядке на одном узле обработки.

Development архитектура сосредотачивается на фактической организации программного модуля в среде разработки архитектуры ПО. ПО упаковано в небольшие библиотеки или подсистемы, которые могут быть разработаны с помощью одного или нескольких разработчиков. Development архитектура системы представлена ​​диаграммами модулей и подсистем. Правила, которые регулируют development архитектуру: разделение, группировка, видимость. Development архитектура учитывает внутренние требования, связанные с простотой разработки, управлением ПО, повторным использованием ПО, а также ограничениями, которые накладываются на набор инструментов или на язык программирования.

Рекомендуется использовать слоевую структуру для представления development архитектуры.
Пример слоевой структуры для Hughes Air Traffic Systems(HATS)

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

Предыдущие 4 системы работают вместе при помощи сценариев. Сценарии выполняют 2 основные функции:

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

• Inside-out: Начиная с logical архитектуры: определить задачи агента, которые являются сложными для одного потока управления; объекты, чья жизнь подчинена активному объекту, также выполняются на том же агенте; несколько взаимоисключающих классов обрабатываются одним агентом.
• Outside-in: Начиная с physical архитектуры: определить внешние запросы к системе, определить клиентские процессы, которые только предоставляют услуги; использовать ограничения целостности данных, чтобы определить правильный набор серверов, а также разделить объекты на клиентских агентов и серверы.

Класс обычно реализуется в виде модуля. Дополнительные ограничения накладываются на определения подсистем, таких как организация команды, ожидаемая величина кода, степень ожидаемого повторного использования. Logical и development взгляды очень близки, но решают разные проблемы. Чем больше проект, тем больше расстояние между этими видами.

Процессы и группы процессов отображаются на доступных аппаратных средствах в различных конфигурациях для тестирования или развертывания.

Модель “4 + 1” была с успехом использована на нескольких крупных проектов с использованием(или без) некоторой локальной настройки и регулировки в терминологии.