АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
|
Глава 2. АРХИТЕКТУРНЫЕ СТИЛИ 2.1. Понятие архитектурного стиля. Классификация архитектурных стилей Архитектура может соответствовать некоторому архитектурному стилю. Большинство архитектур построены на основе систем, которые используют похожие решения. Сходство может быть определено как архитектурный стиль, который, в свою очередь, можно рассматривать как особый вид паттерна (шаблона). Архитектурный стиль представляет собой кодификацию опыта проектирования ИТ систем. Примеры архитектурных стилей включают распределенный стиль, стиль "каналы и фильтры", стиль с централизованной обработкой данных, стиль, построенный на правилах, и так далее. Конкретная система может демонстрировать более одного архитектурного стиля. Архитектурный стиль можно определить как семейство систем в терминах шаблона организации структуры. Точнее, архитектурный стиль определяет номенклатуру компонентов и типов соединительных звеньев, а также набор условий, в соответствии с которыми они могут соединяться. Архитектурный стиль определяется набором типов компонентов, во время счета выполняющих некоторую функцию, топологической раскладкой компонентов с указанием их взаимосвязей во время выполнения, набором семантических ограничений, набором соединителей, служащих средой сообщения, координации и сотрудничества между компонентами. В последние годы чаще вместо термина архитектурный стиль используется термин архитектурный паттерн (шаблон). Однако следует отметить наличие принципиальных различий между архитектурными стилями и паттернами. Паттерн – это, по существу, фрагмент кода на конкретном языке программирования, а архитектурный стиль – это подход к проектированию. Несмотря на многочисленные попытки до сих пор отсутствуют стандартные языки описания архитектур. Принято выделять 12 базовых архитектурных стилей, которые делятся на 5 групп (рис.2.1): потоки данных (Data Flow Systems); вызов с возвратом (Call-and-Return Systems); независимые компоненты (Independent Component Systems); централизованные данные (Data-Centric Systems); виртуальные машины (Virtual Machines). К системам, работающим по принципу потоков данных, относят два архитектурных стиля: системы пакетно-последовательной обработки (Batch Sequential Systems) и системы типа конвейеры и фильтры (Pipe and Filter Architecture). К системам, работающим по принципу вызова с возвратом, относят четыре архитектурных стиля: программа-сопрограммы (Main Program and Subroutines), объектно-ориентированные системы (Object-Oriented Systems), клиент-серверные системы (Client–Server Systems), иерархические многоуровневые системы (Hierarchically Layered Systems). К системам, работающим по принципу независимых компонентов, относят два стиля: система взаимодействующих процессов (Communicating Sequential Processes), системы, управляемые событиями (Event-Based Systems). К системам, использующие централизованные репозитария данных, относят два стиля: системы, основанные на использовании централизованной базы данных (Database Systems) и системы, использующие принцип классной доски (Blackboard Systems). К системам, работающим по принципу виртуальной машины, относят два стиля: интерпретаторы (Interpreters), системы, основанные на правилах (Rule-Based Systems).  Рис. 2.1. Классификация архитектурных стилей 2.2. Потоки данных К системам, работающим по принципу потоков данных, относят системы пакетно-последовательной обработки и системы типа конвейеры и фильтры. Системы пакетно-последовательной обработки представляют собой набор связанных программных модулей, которые образует линейную структуру. Задача делится на отдельные подзадачи, при этом выходные данные, сформированные одной подзадачей, используются в качестве входных данных для другой подзадачи. Обычно подзадачи выполняются последовательно. Данные могут передаваться либо через системную память, либо через внешние файлы. Для управления вычислительным процессом обычно используются скриптовые языки. Типичным примером такого подхода являются программы, написанные на языке Unix shell. Архитектурный стиль конвейеры и фильтры близок к системам пакетно-последовательной обработки и может рассматриваться как обобщение пакетно-последовательной обработки. Система, построенная с использованием стиля конвейеры и фильтры, представляет собой множество модулей, каждому из которых ставится в соответствие один или несколько процессов. Модули могут быть как одинаковыми, так и разными и могут выполняться как на одном, так и различных хостах. Данные с выходов одного модуля могут поступать на входы одного или нескольких других модулей. Система работает по принципу конвейера. Данные между отдельными ступенями конвейера могут передаваться через файлы или системные файлы, например, посредством использования механизмов межпроцессорного взаимодействиями, такими как pipe в Unix. Обработка носит преимущественно линейный характер, хотя конвейеры могут иметь обратные связи. Примером данного подхода может служить компилятор. На вход компилятора поступает исходный код компилируемой программы. В качестве первого фильтра выступает лексический анализатор. В качестве второй ступени выступает семантический анализатор. В качестве третьей ступени выступает оптимизатор. В качестве четвертой ступени выступает генератор кода. Системы типа конвейеры и фильтры находят также достаточно широкое применение при построении систем обработки сигналов и изображений. 2.3. Вызов с возвратом К системам, работающим по принципу вызова с возвратом, обычно относят системы, построенные по принципу программа-сопрограммы, объектно-ориентированные системы, клиент-серверные системы и иерархические многоуровневые системы. Отличительной особенностью систем, относящихся к данной группе, является то, что это синхронные программные архитектуры, в которых клиентская программа приостанавливает свое функционирование на то время пока поставщик сервиса обслуживает запрос, по завершению обработки запроса сервер возвращает результат вычислений клиенту. Архитектуры, работающие по принципу вызова с возвратом, могут иметь произвольное число уровней вложенности. Самым старым архитектурным стилем, относящимся к данной группе, является архитектурный стиль типа «Основная программа – сопрограммы». Основная программа выполняет функции контроллера, который управляет вычислительным процессом, в то время как функциональность реализуется в сопрограммах. Сопрограммы могут выполняться как на локальном, так и на удаленном хосте. В последнем случае речь идет о вызове удаленных процедур. Отличительной особенностью данного стиля является то, что программа имеет только одну нить управления. Данный стиль является, по существу реализацией идей структурного программирования. В качестве разновидности стиля основная программа-сопрограммы можно выделить архитектуры типа Ведущий-ведомый (Master–Slave Architecture). Обычно такие архитектуры не выделяют в отдельный стиль и рассматривают как параллельную версию стиля «Основная программа – сопрограммы». Отличительной особенностью данных архитектур является то, что основная программа и сопрограммы работают одновременно (параллельно). В данном случае на основную программу (Ведущий) возлагаются функции диспетчеризации процесса вычислений. Сопрограмм (Ведомый) получает задание, выполняет его, а по завершению задания запрашивает Ведомого о новом задании. Данная архитектура может реализовываться как в рамках многопроцессорных систем, так и в сетевой среде с произвольной топологией. Клиент-серверные системы можно рассматривать как специальный случай стиля «Основная программа-сопрограммы». Основное отличие состоит в том, что клиент и сервер находятся на разных хостах, хотя, в принципе, клиент и сервер могут работать на одном хосте. Клиент – это процесс, который формирует запрос на обслуживание. Сервер – это процесс, который реализует сервис. В простейшем случае клиент посылает серверу команды, ожидает окончания выполнения запроса. Результатом выполнения запроса могут быть либо данные, либо подтверждение выполнения команды. Большинство серверов работает с множеством клиентов. Широко используемая разновидность клиент-серверных систем – транзакционные системы, к которым могут быть отнесены, например, системы продажи билетов. В системах, ориентированных на выполнение транзакций, число и типы транзакций фиксировано. Серверы в клиент-серверных системах при увеличении числа запросов серверы могут масштабироваться. Принято выделять два типа клиент-серверных систем: системы с толстым и тонким клиентом. Толстым называют клиентское приложение, которое содержит наряду с кодом, отвечающим за представление данных, достаточно большой объем кода, реализующего бизнес-логику. Тонкий клиент содержит код, который реализует исключительно функции, связанные с представлением информации. Обычно тонкий клиент – это Веб броузер. Каждый из этих подходов имеет собственные достоинства и недостатки. Например, при использовании тонкого клиента достаточно просто модифицировать код приложения, поскольку нет необходимости обновлять код на многочисленных клиентских хостах. Код сервера обычно организуется по принципу супервизор-рабочие процессы. Супервизор обслуживает единую точку доступа к сервисам. Рабочие процессы обрабатывают каждый конкретный запрос. Обычно реализуется следующий алгоритм. 1. Сервер открывает «хорошо известный порт». 2. Сервер принимает запросы к открытому порту. 3. При поступлении запроса сервер передает его одному из рабочих процессов и ожидает следующего запроса. Клиент-серверные архитектуры имеют несколько разновидностей. Большинство ранних версий клиент-серверных приложений имели двухслойную организацию, в которой на сервере размещался репозитарий данных (рис. 2.2). Бизнес-логика размещалась в клиентском приложении, на сервере или была разделена между клиентом и сервере.  Рис. 2.2. Двухслойная организации клиент-серверной архитектуры Трехслойная архитектура отличается от двухслойной тем, что бизнес-логика размещается на отдельном сервере. Процессы становятся более устойчивыми, поскольку процессы работают независимо как от клиентов, так и от серверов (рис. 2.3).  Рис. 2.3. Трехслойная организации клиент-серверной архитектуры Иногда используется и четырехслойная архитектура, которая может включать, например, следующие слои: контроллер домена, веб-сервер, сервер приложений, сервер баз данных. Сервер может общаться с клиентом как с установлением соединения, например, по протоколу TCP/IP, так и без установления соединения, например, по протоколу UDP. Сервер может либо сохранять, либо не сохранять информацию об обслуживаемом клиенте. Информацию о клиенте в этом случае называют состоянием. Информация о состоянии может быть полезна, если сеанс работы с клиентом включает обмен несколькими сообщениями. Объектно-ориентированные системы можно также в определенном смысле рассматривать как частный случай систем типа «Основная программа-сопрограммы», при этом объекты могут находиться как на одном, так и на разных хостах. Отличительной особенностью объектов является то, что объекты полностью инкапсулируют код и данные и общение между объектами происходит либо посредством вызова процедур, либо посредством механизма сообщений. Объектно-ориентированные системы также поддерживают механизмы наследования и/или делегирования, которые требуют динамического связывания в процессе выполнения. Пример простейшей объектно-ориентированной системы показан на рис. 2.4.  Рис. 2.4. Простейшая объектно-ориентированная система Одной из проблем, возникающих в процессе функционирования объектно-ориентированных систем, состоит в том, что объект должен знать, где находится объект, с которым он хочет взаимодействовать и какими интерфейсами он обладает. Привязка к объекту может осуществляться либо в статике, либо в динамике. Основным достоинством объектно-ориентированных систем является возможность сокрытия данных от пользователя. Это позволяет изменять внутреннее представление объекта, не уведомляя об этом клиента. Другим достоинством объектно-ориентированных систем является то, что они естественным образом поддерживают процесс распараллеливания вычислений. Объектно-ориентированная система может рассматриваться как коллекция взаимодействующих агентов. Каждый объект при этом может быть как клиентом, так и сервером. Объекты могут располагаться в одном процессе, храниться в библиотеках, находиться в разных процессах, работающих на одном хосте и, наконец, располагаться на разных хостах. Важной разновидностью объектов являются компоненты, которые являются объектами, обладающими специальными свойствами. Широко известны такие компонентные системы как COM, CORBA, EJB. Типовая структура распределенной объектной системы показана на рис.2.5.  Рис. 2.5. Типовая структура распределенной объектной системы Иерархические многоуровневые системы используются преимущественно для построения крупномасштабных приложений. Система представляет собой несколько слоев. Каждый слой можно рассматривать как виртуальную машину для вышележащего слоя. Каждый из слоев можно рассматривать также как набор сервисов для вышележащего слоя, таким образом, вышележащий слой работает в режиме клиента, а нижележащий – сервера. Обычно каждый из слоев взаимодействует с соседними слоями через четко определенные интерфейсы. Данный стиль повсеместно используется для построения стеков протоколов, в частности, коммуникационных протоколов. Другим возможным применением данного стиля являются операционные системы. На рис. 2.6 показана структура операционной системы, имеющей 3-х уровневую организацию. Система включает 3 уровня: уровень ядра системы, уровень системных утилит и уровень на котором работает прочее программное обеспечение. Данный подход был настолько популярен, что в процессорах фирмы Intel, начиная с модели Intel 286, заложена аппаратная поддержка работы 4-х уровневой системой. Следует отметить, что современные ОС, такие как Unix и все ОС фирмы Microsoft используют ОС, работающие только на 2-х уровнях, однако для построения стеков протоколов данный стиль продолжает широко использоваться. Основной недостаток состоит в том, что не все алгоритмы можно реализовать в виде многослойной архитектуры.  Рис. 2.6. Операционная система с 3-х уровневой организацией Основное достоинство данного стиля состоит в том, что он позволяет вести разработку кода для каждого из слоев независимо и иметь несколько вариантов реализации кода, кроме того, имеется возможность безболезненно модифицировать код послойно. 2.4. Независимые компоненты К системам, работающим по принципу независимых компонентов, обычно относят системы взаимодействующих процессов и системы, управляемые событиями. Взаимодействующие процессы и системы, управляемые событиями, объединяет, то, что в обоих случаях используется механизм неявного вызова оператора. Другими словами, вызывающий и вызываемый оператор могут существовать независимо и могут быть распределены по разным хостам. В системах, управляемых событиями, компоненты могут не знать о существовании друг друга. Активация оператора происходит по получению информации о наступлении события. Системы, управляемые событиями, могут основываться на использовании механизма «публикация-подписка». В самом общем виде идея взаимодействующих процессов состоит в том, что имеется множество независимых процессов, которые обмениваются сообщениями. Эта модель была предложена и разработана еще в семидесятых годах прошлого века Хоаром и имеет множество вариантов реализаций, наиболее популярными из которых являются микроядерные архитектуры, параллельные системы, основанные на обмене сообщениями, а также мультиагентные системы. Отличительной особенностью систем, управляемых событиями, является то, что процесс обработки запускается только тогда, когда происходит соответствующее событие. Можно привести следующие примеры событий: срабатывает таймер, пользователь перемещает мышь, пользователь щелкает мышью на иконке или графическом объекте. Основное отличие систем, управляемых событиями от систем взаимодействующих процессов состоит в том, что в системах, управляемых событиями, получатель сообщения о событии не знает ничего об отправителе, а отправитель может ничего не знать о получателе или получателях информации о событии. Другими словами, системы, управляемые событиями можно рассматривать как слабосвязанные системы. Системы, управляемые событиями, имеют много общего с программами, работающими от прерываний, поскольку прерывания и события по своей суть очень похожи тем, что им соответствует некоторое асинхронное событие, на которое система должна реагировать. Обобщенная структура системы, управляемой событиями, показана на рис. 2.7. Основными компонентами системы являются: источники событий, обработчики событий, коннекторы (диспетчер). Источники событий являются генераторами событий. Источник «генерирует» событие, в случае, если хочет сообщить другим компонентам о том, что произошло некоторое событие, которое может их заинтересовать. В типовом варианте получатель должен зафиксировать свою заинтересованность в информации о конкретном событии. Диспетчер отвечает за три момента: сохранение сообщения о событии, если приемник не готов принять данное сообщение, маршрутизацию сообщений, запоминает информацию о том, в какой информации заинтересован тот или иной компонент. Обычно источник и приемник не знают о существовании диспетчера. Обработчики событий – это программы, которые запускаются по приходу событий. Отличительной особенностью систем, управляемых событиями, состоит в том, что для них обычно невозможно указать поток управления. Можно выделить, по крайней мере, три подстиля в рамках систем, управляемых событиями: централизованные системы, системы, используемые в промежуточном ПО, системы очередей сообщений. Примером централизованных систем могут служить активные базы данных (поддерживающие работу с триггерами), системы разработки графических пользовательских интерфейсов.  Рис. 2.7. Структура системы, управляемой событиямиВ системах промежуточного ПО системы обработки событий используются достаточно активно. В частности, в CORBA имеется CORBA Event Service. Однако во многих реализациях она построена по централизованному принципу. В качестве одного из важнейших аспектов применения рассматриваемого архитектурного стиля являются очереди сообщений. 2.5. Централизованные данные К системам, работающим по принципу централизованных данных (репозитария), относят системы, основанные на использовании централизованной базы данных и системы, использующие принцип классной доски. Репозитарии иногда называют также системами с централизованным хранением данных (Data-centric systems). Отличительной особенностью архитектурных стилей, принадлежащих рассматриваемой группе, является наличие централизованного хранилища информации, содержимое которого общедоступно. Централизованное хранилище используется как для хранения данных, так и метаданных (знаний о данных). Централизованное хранилище обеспечивает удобный доступ к данным и метаданным. На рис. 2.8 показана обобщенная структура системы, работающей по принципу репозитария.  Рис. 2.8. Структура системы, работающей по принципу репозитария Можно выделить следующие основные достоинства данного подхода: данные вводятся в систему однократно, что уменьшает затраты, исключает дублирование и уменьшает вероятность ошибки при вводе данных, пользователь может получить доступ к данным из множества разных приложений, репозитарий можно использовать как инструмент для обмена данными между приложениями, по мере необходимости, репозитарий можно масштабировать. Одним из наиболее часто используемых стилей является стиль, который известен как «Базы данных и базы знаний». Для организации разного рода систем хранения информации, которые можно использовать в качестве репозитариев применяются разные подходы: информацию можно хранить в файлах, которые могут храниться в файловой системе; можно организовать централизованное хранилище, например, для хранения сериализованных объектов, можно хранить информацию в реляционных базах данных. Практически повсеместно используется последний подход. Можно выделить 2 основных типа баз данных: реляционные и объектно-ориентированные. Подавляющее большинство используемых на практике баз данных относятся к реляционным. Информация, касающаяся баз данных, имеется в широко доступной литературе и более подробно рассматриваться не будет. Что касается баз знаний, в последние годы намечается устойчивая тенденция к использованию реляционных баз данных для хранения знаний. Системы, использующие принцип классной доски, реализуют метафору классной доски, на которой можно писать мелом, при этом написанное доступно всем участникам обсуждения. В основе своей классная доска представляет собой базу данных, в которую процессы могут записывать, читать и удалять данные. Системы, построенные с использованием данного архитектурного стиля, находят применение, в первую очередь, в системах искусственного интеллекта, в качестве репозитария для хранения системных знаний. Обобщенная структуры системы, работающей по принципу классной доски, показана на рис. 2.9. В данной системе источники знаний представлены независимыми процессами, которые обладают определенными знаниями о внешнем мире и о ходе решения текущей задачи. Процессы могут изменять данные, находящиеся на доске.  Рис. 2.9. Структура системы, работающей по принципу классной доски Доска представляет собой разделяемую память, в которой хранятся данные и знания о ходе решения задачи. Каждый процесс, выполнив свою часть работы по решению задачи, помещает результат на доску, где он становится доступен другим процессам. Каждый процесс может пользоваться услугами подсистемы информирования об изменении конкретной информации, помещенной на доску. Таким образом, если, один процесс изменил данные, находящиеся на доске, то все процессы, которые заинтересованы в использовании этих данных, немедленно информируются о факте изменения данных. Уведомления процессам об изменении данных поступают процессам в форме сообщений. В системах, работающих по принципу классной доски, для решения прикладных задач широко используются системы логического вывода, при этом используются три подхода: прямой логический вывод, обратный логический вывод, смешанные стратегии. Данный архитектурный стиль появился еще в 70-х годах прошлого века и первоначально использовался в системах распознавания речь. В настоящее время данный стиль широко применяется в мультиагентных системах для обеспечения взаимодействия агентов. 2.6. Виртуальные машины К системам, работающим по принципу виртуальной машины, относят интерпретаторы и системы, основанные на правилах. Виртуальная машина представляет собой эмулятор, который работает поверх аппаратной и (или) программной настройки, и обеспечивает программный интерфейс, в общем случае, отличный от программного интерфейса той платформы, на которой он работает. Если рассматривать ИТ систему как многослойную структуру, то виртуальная машина образует внешний слой, который отвечает за взаимодействие с клиентскими приложениями. Можно выделить следующие типовые варианты использования интерпретаторов: отладка программного обеспечения, предназначенного для работы на других, например, контроллерных платформах, запуск программ, написанных для одной операционной системы (ОС), под управлением другой ОС, например, для запуска приложений для Linux на платформе Windows, интерпретаторы команд, интерпретация некоторого языка, в качестве которого может выступать либо скриптовый язык, либо язык высокого уровня, либо некоторый специальный (доменно-ориентированный) язык. Использование интерпретаторов в составе систем разработки используется, прежде всего, для разработки ПО встроенных систем. В этом случае интерпретатор представляет собой программную модель целевой системы. Этот подход повсеместно используется при разработке и отладке программного обеспечения, прежде всего, для встроенных систем. Использование интерпретатора в качестве средства переноса (портирования) приложений на другие платформы – достаточно популярный подход. В этой связи можно упомянуть такой повсеместно используемый продукт как VMWare, который обеспечивает перенос приложений, в частности, между Windows и Linux. Интерпретаторы команд используются давно и повсеместно, например, используемая в DOS command.com и утилита Norton Commander. В Unix используются программы типа shell. В MS Windows интерпретатор команд встроен в Window Manager и управляется посредством мыши, а не вводом команды в виде строки. Широко используются такие интерпретаторы языков Basic, Perl, Python, а интерпретатор javascript встроен во все броузеры. Однако наибольшее практическое применение имеет виртуальная java машина (The Java Virtual Machine). В системах, основанных на правилах, знания и логика представлены в виде множества правил - это отличает их от системы, основанных на использовании традиционных языков программирования. Структура типовой системы, ориентированной на работу с правилами показана на рис. 2.10, включает в себя множество правил, базу данных фактов и подсистему логического вывода (движок), используемый для обработки правил.  Рис. 2.10. Типовой системы, ориентированной на работу с правилами Обычно пользователь полуучает доступ к системе через тот или иной пользовательский интерфейс. Запросы к системе выполняются с помощью специального языка. Подсистема логического вывода выполняет анализ запроса пользователя и определяет логический вывод. В процессе выполнения вывода подсистема логического вывода по мере надобности выбирает их базы знаний правила и данные. В базе знаний хранится два типа данных: факты, относящиеся к домену задач и набор правил также относящихся к домену задач. Подсистема логического вывода применяет правила к данным до тех пор, пока не будет получен результат. Рабочая память используется для хранения промежуточных результатов. Более сложные системы, основанные на правилах, могут содержать кроме перечисленных выше подсистем, подсистему объяснения, которая представляет пользователю кроме конечного результата информацию о тех правилах, которые использовались в процессе логического вывода. В системах, основанных на правилах, используется два типа логического вывода: прямой и обратный. Прямой логический вывод инициируется появлением нового факта, а в результате применения правил формируется некоторое заключение или выполняется некоторое действие. При использовании обратного вывода в качестве исходных данных выступает некоторое утверждение (цель), процесс логического вывода посредством применения правил подтверждает истинности исходного высказывания или его ложность. Возможно совместное применение прямого и обратного логического вывода. Что касается практического применения систем, основанных на правилах, то можно выделить три основных варианта их использования: оболочка экспертной системы, которая может наполняться фактами и правилами, например, система CLIPS, библиотека компонентов, которая позволяет встраивать механизмы работы с правилами в пользовательские приложения, например, система Jess, использование правил для управления бизнес процессами, например система Jrules. 2.7. Использование архитектурных стилей В табл. 2.1 приведены условия, при которых целесообразно использовать те или иные архитектурные стили Таблица 2.1 Условия использования архитектурных стилей
Рассмотренные выше архитектуры можно отнести к «чистым» архитектурам. «Чистые» архитектуры рассматривались, в основном, с целью объяснения природы каждого из стилей. Большинство реальных архитектур являются комбинацией нескольких стилей. Архитектурные стили в рамках конкретной архитектуры могут комбинироваться разными способами, основными из которых являются следующие: иерархии стилей, использование нескольких стилей на одном уровне иерархии, конкретное архитектурное решение может быть описано в терминах двух или более архитектурных стилей. Кроме того, конкретная архитектура может представлять собой комбинацию перечисленных выше подходов. Первый подход предполагает, что компонент системы, построенной с использованием одного архитектурного стиля, внутри может быть организован с использованием другого стиля. Например, при использовании механизма Unix pipes каждый из программных модулей, работающих в составе конвейера, может реализовывать любой другой архитектурный стиль. Второй подход разрешает использовать в рамках одного компонента несколько архитектурных стилей. Например, некоторый компонент может работать с репозитарием, используя одну часть своего интерфейса и использовать другую часть своего интерфейса для взаимодействия с другими компонентами, используя стиль pipes&filters. Другим примером могут служить «активные» базы данных, которые, с одной стороны, реализуют архитектурный стиль типа репозитарий, а, с другой стороны, реализуют неявный вызов. В системах, построенных по принципу классной доски, также часто реализуется такая комбинация стилей. В ряде случаев одну и ту же архитектуру можно описать в терминах нескольких архитектурных стилей, например, систему Линда можно рассматривать как систему взаимодействующих процессов, так и как систему, использующую централизованный репозитарий. На практике для достаточно сложных программных систем чаще всего используется некоторая комбинация перечисленных выше подходов. Следует заметить, что для решения одной и той же задачи может использоваться несколько разных архитектурных стилей. То же самое можно сказать и о семействах архитектур [ 21, 22]. |