Программная инженерия.Часть II. Учебное пособие

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

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

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

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

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

II Часть | пособие Учебное

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

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

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

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

–небольшой стоимостью – использование компонентов сторонних производителей позволяет уменьшить затраты на разработку и обслуживание;

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

–возможностью повторного использования компонентов и, как следствие, возможностью распределения затрат на разработку и обслуживание между несколькими приложениями или системами;

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

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

11.4. Проблемно ориентированное проектирование

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

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

II Часть | пособие Учебное

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

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

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

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

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

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

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

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

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

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

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

II Часть | пособие Учебное

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

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

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

–абстракция – обеспечивается возможность внесения изменений на абстрактном уровне; используемый уровень абстракции каждого слоя может быть повышен или понижен;

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

–управляемость – разделение основных функций помогает идентифицировать зависимости и структурировать код программы в секции, что повышает управляемость ПП;

–производительность – распределение слоев по нескольким физическим уровням может улучшить масштабируемость, отказоустойчивость и производительность;

–возможность повторного использования – роли повышают возможность повторного использования;

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

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

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

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

тель сообщения не дожидается результата его обработки получателем

через «общую шину». Шины данных используются для реализации слож-

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

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

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

–расширяемость – возможность добавлять или удалять приложения

сшины без влияния на существующие приложения;

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

II Часть | пособие Учебное

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

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

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

–масштабируемость – возможность подключения к шине множества экземпляров одного приложения для обеспечения одновременной обработки множества запросов;

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

11.7. N-уровневая/3-уровневая архитектура

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

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

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

не, если предоставляемая этим слоем функциональность используется

более чем одним сервисом или приложением уровня. Примером треху-

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

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

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

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

–масштабируемость – уровни организовываются на основании развертывания слоев, поэтому масштабировать приложение довольно просто;

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

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

11.8. Объектно ориентированная архитектура

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

II Часть | пособие Учебное

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

ны. Обмен данными между ними происходит через интерфейсы путем вызова методов (свойств) других объектов и отправки (приема сообщений).

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

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

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

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

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

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

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

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

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