Архитектурные стили
Архитектурный стиль определяет основные правила выделения компонентов и организации взаимодействия между ними в рамках системы или подсистемы в целом. Различные архитектурные стили подходят для решения различных задач в плане обеспечения нефункциональных требований — различных уровней производительности, удобства использования, переносимости и удобства сопровождения. Одну и ту же функциональность можно реализовать, используя разные стили.
Работа по выделению и классификации архитектурных стилей была проведена в середине 1990-х годов. Ее результаты представлены в работах [5,6]. Ниже приведена таблица некоторых архитектурных стилей, выделенных в этих работах.
| Конвейер обработки данных (data flow) | Система выдает четко определенные выходные данные в результате обработки четко определенных входных данных, при этом процесс обработки не зависит от времени, применяется многократно, одинаково к любым данным на входе. Обработка организуется в виде набора (необязательно последовательности) отдельных компонентов-обработчиков, передающих свои результаты на вход другим обработчикам или на выход всей системы.
Важными свойствами являются четко определенная структура данных и возможность интеграции с другими системами | ||||
| Пакетная обработка (batch sequential) | Один-единственный вывод производится на основе чтения некоторого одного набора данных на входе, промежуточные преобразования организуются в виде последовательности | Сборка программной системы: компиляция, сборка системы, сборка документации, выполнение тестов | |||
| Каналы и фильтры (pipe-and-filter) | Нужно обеспечить преобразование непрерывных потоков данных. При этом преобразования инкрементальны и следующее может быть начато до окончания предыдущего. Имеется, возможно, несколько входов и несколько выходов.
В дальнейшем возможно добавление дополнительных преобразований | Утилиты UNIX | |||
| Замкнутый цикл управления (closed-loop control) | Нужно обеспечить обработку постоянно поступающих событий в плохо предсказуемом окружении.
Используется общий диспетчер событий, который классифицирует событие и отдает его на асинхронную обработку обработчику событий такого типа, после чего диспетчер снова готов воспринимать события | Встроенные системы управления в автомобилях, авиации, спутниках.
Обработка запросов на сильно загруженных Web-серверах. Обработка действий пользователя в GUI | |||
| Вызов-возврат (call-return) | Порядок выполнения действий четко определен, отдельные компоненты не могут выполнять полезную работу, не получая обращения от других | ||||
| Процедурная декомпозиция | Данные неизменны, процедуры работы с ними могут немного меняться, могут возникать новые.
Выделяется набор процедур, схема передачи управления между которыми представляет собой дерево с основной процедурой в его корне | Основная схема построения программ для языков C, Pascal, Ada | |||
| Абстрактные типы данных (abstract data types) | В системе много данных, структура которых может меняться. Важны возможности внесения изменений и интеграции с другими системами.
Выделяется набор абстрактных типов данных, каждый из которых предоставляет набор операций для работы с данными такого типа. Внутреннее представление данных скрывается | Библиотеки классов и компонентов | |||
| Многоуровне-вая система (layers) | Имеется естественное расслоение задач системы на наборы задач, которые можно было бы решать последовательно — сначала задачи первого уровня, затем, используя полученные решения, — второго, и т.д. Важны переносимость и возможность многократного использования отдельных компонентов.
Компоненты разделяются на несколько уровней таким образом, что компоненты данного уровня могут использовать для своей работы только соседей или компоненты предыдущего уровня. Могут быть более слабые ограничения, например, компонентам верхних уровней разрешено использовать компоненты всех нижележащих уровней | Телекоммуникацион-ные протоколы в модели OSI (7 уровней), реальные протоколы сетей передачи данных (обычно 5 уровней или меньше).
Системы автоматизации предприятий (уровни интерфейса пользователя–обработки запросов–хранения данных) | |||
| Клиент-сервер | Решаемые задачи естественно распределяются между инициаторами и обработчиками запросов, возможно изменение внешнего представления данных и способов их обработки | Основная модель бизнес-приложений: клиентские приложения, воспринимающие запросы пользователей и сервера, выполняющие эти запросы | |||
| Интерактивные системы | Необходимость достаточно быстро реагировать на действия пользователя, изменчивость пользовательского интерфейса | ||||
| Данные–представление–обработка (model–view-controller, MVC) | Изменения во внешнем представлении достаточно вероятны, одна и та же информация представляется по-разному в нескольких местах, система должна быстро реагировать на изменения данных.
Выделяется набор компонентов, ответственных за хранение данных, компоненты, ответственные за их представления для пользователей, и компоненты, воспринимающие команды, преобразующие данные и обновляющие их представления | Наиболее часто используется при построении приложений с GUI.
Document-View в MFC (Microsoft Foundation Classes) — документ в этой схеме объединяет роли данных и обработчика | |||
| Представление–абстракция–управление (presentation–abstraction–control) | Интерактивная система на основе агентов, имеющих собственные состояния и пользовательский интерфейс, возможно добавление новых агентов.
Отличие от предыдущей схемы в том, что для каждого отдельного набора данных его модель, представление и управляющий компонент объединяются в агента, ответственного за всю работу именно с этим набором данных. Агенты взаимодействуют друг с другом только через четко определенную часть интерфейса управляющих компонентов | ||||
| Системы на основе хранилища данных | Основные функции системы связаны с хранением, обработкой и представлением больших количеств данных | ||||
| Репозиторий (repository) | Порядок работы определяется только потоком внешних событий.
Выделяется общее хранилище данных — репозиторий. Каждый обработчик запускается в ответ на соответствующее ему событие и как-то преобразует часть данных в репозитории | Среды разработки и CASE-системы | |||
| Классная доска (blackboard) | Способ решения задачи в целом неизвестен или слишком трудоемок, но известны методы, частично решающие задачу, композиция которых способна выдавать приемлемые результаты, возможно добавление новых потребителей данных или обработчиков.
Отдельные обработчики запускаются, только если данные репозитории для их работы подготовлены. Подготовленность данных определяется с помощью некоторой системы шаблонов. Если можно запустить несколько обработчиков, используется система их приоритетов | Системы распознавания текста | |||
Многие из представленных стилей носят достаточно общий характер и часто встречаются в разных системах. Кроме того, часто можно обнаружить, что в одной системе используются несколько архитектурных стилей — в одной части преобладает один, в другой — другой, или же один стиль используется для выделения крупных подсистем, а другой — для организации более мелких компонентов в подсистемах.
Более подробного рассмотрения заслуживают стили "Каналы и фильтры", "Многоуровневая система". Далее следуют их описания согласно [7].
