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

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

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

Сочетание архитектурных стилей крайне полезно при построении УеЬ-приложений, где можно достичь эффективного разделения функциональности за счет применения многослойного архитектурного стиля. Таким образом, можно отделить логику представления от бизнес-логики и логики доступа к данным. Требования безопасности организации могут обусловливать либо 3-уровневое развертывание приложения, либо развертывание более чем с тремя уровнями. Уровень представления может развертываться в пограничной сети, располагающейся между внутренней сетью организации и внешней сетью. В качестве модели взаимодействия на уровне представления может применяться шаблон представления с отделением (разновидность многослойного стиля), такой как Мос1е1-йеу-Соп1:го11ег (МУС). Также можно выбрать архитектурный стиль 80А и реализовать связь между УеЬ-сервером и сервером приложений посредством обмена сообщениями.

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

Клиент-серверная архитектура. Вычислительная (сетевая) клиент-серверная архитектура предполагает, что задания или сетевая нагрузка распределены между поставщиками услуг (сервисов) — серверами и заказчиками услуг — клиентами (рис. 5.3). Нередко клиенты и серверы взаимодействуют через компьютерную сеть и могут быть как различными физическими устройствами, так и различным ПО.

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

Архитектурный стиль (парадигма)

Описание

Клиент-серверная

архитектура

Система разделяется на клиентскую и серверную части, где клиент посылает запросы к серверу. Во многих случаях в роли сервера выступает сервер БД, а логика приложения представлена процедурами

хранения

Компонентная архитектура

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

Проблемно-ориентированное проектирование (дизайн на основе предметной области)

Объектно-ориентированный стиль, ориентированный на моделирование сферы деловой активности и определяющий бизнес-объекты на основании сущностей данной предметной области

Многослойная архитектура

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

Архитектура на основе канала сообщений

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

/У-уровневая/З-уровневая

архитектура

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

Объектно-ориентированная

архитектура

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

Сервисно-ориентированная архитектура (БОА)

Описывает приложения, предоставляющие и потребляющие функциональность в виде сервисов с помощью контрактов и сообщений

Архитектурный стиль «Клиент—сервер»

Рис. 5.3. Архитектурный стиль «Клиент—сервер»

Типичным упрощенным примером реализации архитектуры «Клиент—сервер» можно назвать различные Web-сайты, которые содержат страницы с данными, а также логику их отображения. Клиенты передают на сайты запросы на предоставление информации, а в ответ получают содержимое запрошенных страниц.

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

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

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

Компонентная архитектура используется при проектировании и разработке систем, когда программные компоненты являются независимыми единицами, обладающими однозначно определенными (well-defined) интерфейсами и зависимостями (связями) и могут собираться и развертываться независимо друг от друга. Данный подход

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

Пример использования компонентов в интерфейсе пользователя

Рис. 5.4. Пример использования компонентов в интерфейсе пользователя

Данный архитектурный стиль обладает следующими преимуществами:

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

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

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

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

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

Преимущества данного архитектурного стиля состоят в следующем:

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

Модель предметной области «Финансовые документы»

Рис. 5.5. Модель предметной области «Финансовые документы»

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

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

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

При строгом разделении на слои компоненты одного слоя могут взаимодействовать только с компонентами этого же слоя или компонентами слоя, расположенного «ниже». Более свободное разделение на слои позволяет компонентам взаимодействовать с компонентами того же слоя и всех «нижележащих» слоев.

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

На рис. 5.6 представлен пример трехслойной архитектуры приложения, где в качестве слоя данных (хранения информации) может выступать БД, модуль по хранению и чтению данных с диска. Этот слой может располагаться и на отдельном сервере (выделенный файл-сервер, сервер БД), и совместно с другим слоем (например, простое УеЬ-приложение, где сервер и БД располагаются на одном компьютере). Для УеЬ-приложений под слой логики (обработки информации) можно выделить УеЬ-сервер либо, для более сложных проектов, сервер приложений, а в качестве слоя представления (отображения информации) выступает браузер, где пользователь просматривает информацию.

Слой представления (отображения информации)

^

Слой логики (обработки информации)

Xх_X

V_Xх

Слой данных (хранения информации)

Рис. 5.6. Пример трехслойной архитектуры

К преимуществам данного архитектурного стиля можно отнести следующие его характеристики:

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

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

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

На рис. 5.7 приведен пример работы с шиной данных, где часть клиентов работает через УеЬ-сервер с корпоративными сервисами (каждый из которых установлен на отдельный сервер): получение данных из базы данных, работа с почтой, работа с файлами. Доступ к сервисам напрямую имеют клиенты, которые, например, подключены к корпоративной сети компании. Весь обмен информации производится через шину данных. Программы отсылают в ней запросы, шина данных определяет получателя (сервер/сервис), к которому адресован запрос, и направляет его к нему, а затем возвращает результат отправителю. Следует отметить, что в настоящее время существует

Архитектурный стиль с использованием шины данных

Рис. 5.7. Архитектурный стиль с использованием шины данных

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

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

А-уровневая/З-уровневая архитектура. При использовании этой архитектуры предполагается разделение функциональности на сегменты, во многом аналогично многослойной архитектуре, но в данном случае эти сегменты (их называют уровнями) могут физически размещаться на разных компьютерах. Данный архитектурный стиль был создан на базе компонентно-ориентированного подхода, где для связи используют методы определенной платформы (DCOM, CORBA и др.), а не сообщения.

Характеристиками /V-уровневой архитектуры являются функциональная декомпозиция приложения, сервисные компоненты и их распределенное развертывание, что обеспечивает высокую масштабируемость, доступность, управляемость и эффективность использования ресурсов. Каждый уровень абсолютно независим от всех остальных, кроме тех, с которыми он непосредственно соседствует: п-му уровню требуется лишь знать, как обрабатывать запрос от (п + 1 )-го уровня, как передавать этот запрос на (п - 1)-й уровень (если таковой имеется) и как обрабатывать результаты запроса. Связь между уровнями, как правило, асинхронная для обеспечения более высокой масштабируемости.

TV-уровневая архитектура обычно имеет не менее трех отдельных логических уровней, которые физически размещаются на разных серверах. Каждый уровень отвечает за определенную функциональность. При использовании многослойного подхода слой развертывается на уровне, если предоставляемая этим слоем функциональность используется более чем одним сервисом или приложением уровня. Примером трехуровневого архитектурного стиля может служить типовое финансовое Web-приложение с высокими требованиями к безопасности. Бизнес-слой в этом случае должен быть развернут за межсетевым экраном, из-за чего приходится развертывать слой представления на отдельном сервере в пограничной сети (рис. 5.8).

Данный архитектурный стиль обладает рядом преимуществ:

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

Рис. 5.8. Пример трехуровневой архитектуры

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

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

Основными принципами объектно-ориентированного архитектурного стиля являются: абстракция, композиция, наследование, инкапсуляция, полиморфизм, отделение.

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

Композиция. Объекты могут быть образованы другими объектами и по желанию могут скрывать эти внутренние объекты от других классов или предоставлять их как простые интерфейсы.

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

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

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

Отделение. Объекты могут быть отделены от потребителя путем определения абстрактного интерфейса, реализуемого объектом и понятного потребителю. Это позволяет обеспечивать альтернативные реализации без влияния на потребителей интерфейса.

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

Обычно объектная модель представляется в виде диаграммы классов. На рис. 5.9 приведен упрощенный пример такой диаграммы, где изображены три класса, причем классы «Teacher» и «Student» наследуют свое поведение и данные от класса «Persona».

К преимуществам данного архитектурного стиля относят:

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

Рис. 5.9. Пример диаграммы классов

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

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

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

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

Основные принципы данного архитектурного стиля:

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

Типовые сервисно-ориентированные приложения обеспечивают совместное использование информации, выполнение многоэтапных процессов (системы резервирования и онлайн-магазины), предоставление организациям специальных отраслевых данных или сервисов, создание составных приложений, которые объединяют данные из многих источников. В настоящее время практически все современные языки программирования поддерживают формат SOAP (Simple Object Access Protocol) сервисов, которые позволяют различным системам обмениваться информацией вне зависимости от языка программирования, на котором она была написана.

На рис. 5.10 изображен пример предоставления некоторой финансовой системой открытого сервиса для получения информации о курсах валют. К данному сервису могут обращаться любые программные продукты, в которых реализован программный код по получению этих данных. В рассматриваемом примере информацию получают: другой Web-сервер (возможно, для отображения курсов валют на своих страницах); сервер по работе с мобильными устройствами (возможно, для предоставления курсов на мобильные устройства по запросу клиентов); программа на персональном компьютере (ПК); программа на карманном ПК.

Преимущества данного архитектурного стиля:

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

Рис. 5.10. Пример обмена информацией для сервис-ориентированных систем

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

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

 
< Пред   СОДЕРЖАНИЕ     След >