Методологические антипаттерны.

■ Программирование методом копирования-вставки (Copy and paste programming) – копирование (и лёгкая модификация) существующего кода вместо создания общих решений. Симптом этого антипаттерна: после внесения изменений программа в некоторых случаях ведёт себя также, как и раньше. Для устранения антипаттерна требуется выделить повторяющийся код в отдельный метод.

■ Дефакторинг (De-Factoring) – процесс уничтожения функциональности и замены её документацией.

■ Золотой молоток (Golden hammer) – сильная уверенность в том, что любимое решение универсально применимо. Название происходит от английской поговорки «когда в руках молоток, все проблемы кажутся гвоздями».

■ Фактор невероятности (Improbability factor) – предположение о невозможности того, что сработает известная ошибка.

■ Преждевременная оптимизация (Premature optimization) – оптимизация на основе недостаточной информации.

■ Изобретение колеса (Reinventing the wheel) – ошибка адаптации существующего решения.

■ Изобретение квадратного колеса (Reinventing the square wheel) – создание плохого решения, когда существует хорошее.

3.14. АРХИТЕКТУРА ПРОГРаммного Обеспечения

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

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

Таблица 2

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

Архитектурный стиль	Описание
Клиент-сервер	Разделение системы на два приложения – клиент и сервер. При работе клиент посылает запросы на обслуживание серверу
Архитектура, основанная на использовании компонентов	Разделение системы на компоненты, которые могут быть повторно использованы и не зависят друг от друга. Каждый компонент снабжается известным интерфейсом для коммуникаций
Многоуровневая архитектура	Разделение функций приложения на группы (уровни), которые организованы в виде стекового набора.
Шина сообщений	Система, которая может посылать и передавать информационные сообщения в определенном формате по общему коммуникационному каналу. Благодаря этому организуется взаимодействие систем без указаний конкретных получателей сообщений
N-звеньевая/3-звеньевая архитектура	Разделение функций подобно архитектуре, основанной на уровнях. Однако группировка происходит не только на логическом, но и на физическом уровне – отдельным группам соответствует отдельный компьютер (сервер, кластер)
Объектно-ориентированная архитектура	Представление системы в виде набора взаимодействующих объектов
Выделенное представление	Выделение в системе отдельных групп функций для взаимодействия с пользователями и обработки данных
Архитектура, ориентированная на сервисы	Каждый компонент системы представлен в виде независимого сервиса, предоставляющего свои функции по стандартному протоколу

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

«Клиент-сервер»

Архитектурный стиль «клиент-сервер» (client/server) описывает отношение между двумя компьютерными программами, в котором одна программа – клиент – выполняет запросы к другой программе – серверу. Этот стиль решает, в основном, задачу развёртывания приложения. На модели «клиент-сервер» созданы приложения для работы с базами данных, электронной почтой и для доступа к веб-ресурсам.

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

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

● В определенный момент времени клиент подключен к одному серверу для обработки запросов (реже – к небольшой группе серверов).

● Клиент работает с пользователем напрямую, обычно используя графический интерфейс.

● Сервер не инициирует запросов.

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

Главными преимуществами стиля «клиент-сервер» являются:

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

■ Централизованный доступ к данным. Так как данные хранятся только на сервере, ими легко управлять (например, обеспечить обновление).

■ Легкость сопровождения. Роль сервера могут выполнять несколько физических компьютеров, объединенных в сеть. Благодаря этому клиент не замечает сбоев или замены отдельного серверного компьютера.

Отметим некоторые вариации стиля «клиент-сервер». В системах клиент-очередь-клиент сервер исполняет роль очереди для данных клиентов. То есть, клиенты использую сервер для обмена данными между собой. Пиринговые приложения (peer-to-peer) – это вариант системы «клиент-очередь-клиент», в котором любой клиент может играть роль сервера. Сервера приложений служат для размещения и выполнения программ, которыми управляет клиент.

Архитектура, основанная на использовании компонентов

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

● Компонент допускает повторное использование в различных системах.

● Компонент не хранит информации, специфичной для конкретного ПО, в котором он используется.

● Допускается создание новых компонент на основе существующих.

● Компонент имеет известный интерфейс для взаимодействия, но скрывает детали своей внутренней реализации.

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

Типичным примером компонент являются компоненты пользовательского интерфейса (элементы управления).

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

■ Легкость развертывания. Когда для компонента доступна новая версия, старая версия заменяется без влияния на остальные компоненты.

■ Уменьшение стоимости. При разработке можно применять готовые компоненты сторонних производителей.

■ Повторное использование. Одни и те же компоненты могут использоваться в нескольких приложениях.

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

Многоуровневая архитектура

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

Принципы многоуровневой архитектуры:

● Проектирование четко устанавливает разграничение функций между уровнями.

● Нижние уровни не зависимы от верхних уровней. Это позволяет использовать компоненты одного уровня в разных приложениях.

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

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

■ Изоляция. Разработка и обновление ПО могут быть изолированы рамками одного уровня.

■ Производительность. Распределение уровней на отдельные физические компьютеры повышает производительность и отказоустойчивость.

■ Тестируемость. Уровни допускаю независимое тестирование.

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

1. Уровень представления (presentation layer) – ответственен за взаимодействие с пользователем, ввод и вывод информации.

2. Бизнес уровень или уровень бизнес-логики (business logic layer) – обрабатывает информацию, реализуя конкретные бизнес-правила.

3. Уровень доступа к данным (data access layer) – обеспечивает загрузку и сохранение информации, используя источник данных (файл, база данных) или внешний сервис.

 

Рис. 24. Уровни бизнес-приложения.

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

 

Рис. 25. Компоненты отдельных уровней.

1. Компоненты пользовательского интерфейса. Они предназначены для вывода информации и для ввода данных пользователем. Эти компоненты могут быть элементами Windows-интерфейса или элементами веб-интерфейса.

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

3. Рабочие потоки (workflows). После получения данных от пользователя они должны быть использованы при выполнении бизнес-процессов (рабочих потоков). Бизнес-процессы состоят из шагов, которые должны быть выполнены в определенном порядке. Например, система должна подсчитать общую сумму заказа, проверить данные кредитной карты и организовать доставку товара. При этом заранее неизвестно, сколько времени потребуется на выполнение этих шагов. Поэтому нужен механизм управления этими операциями.

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

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

6. Интерфейсы сервисов. Чтобы сервисы могли воспользоваться функциональностью друг друга, а приложения – функциональностью сервисов, должен быть определен протокол обмена данными и сообщениями между сервисами и приложениями-потребителями. Этот протокол объявляется как интерфейс сервиса. Часто эти интерфейсы называют бизнес-фасадом.

7. Компоненты, отвечающие за доступ к данным. Программам нужно где-то хранить данные и в какой-то момент выполнения бизнес-процесса к ним обращаться. Имеет смысл абстрагироваться от конкретного вида данных конкретного приложения в пользу универсальных компонентов, представляющих данные. Эти компоненты размещаются в слое доступа к данным. Например, чтобы показать данные о товаре пользователю, приложению понадобится получить данные о товаре из БД. Для этого будет задействованы слой доступа к данным и сама БД.

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

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

Шина сообщений

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

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

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

● Сообщения имеют стандартный формат. Это позволяет интегрировать компоненты, разработанные на разных платформах.

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

● Как правило, коммуникация происходит в асинхронном режиме.

Преимущества шины сообщений:

■ Расширяемость. Компоненты, подключённые к шине, добавляются и удаляются без воздействия на другие подключённые компоненты.

■ Уменьшение сложности. Для взаимодействий с системой компонент должен реализовать только логику работы с общей шиной.

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

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

Выделенное представление

Выделенное представление – это стиль обработки запросов или действий пользователя, а также манипулирования элементами интерфейса и данными. Стиль подразумевает отделение элементов интерфейса от логики приложения.

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

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

● Для интеграции отдельных компонентов может использоваться событийная модель.

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

В качестве примера использования выделенного представления рассмотрим шаблон модель-представление-контроллер (Model-View-Controller, MVC). Этот шаблон имеет три основных компонента (рис. 26):

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

2. Представление обеспечивает способ отображение данных модели.

3. Контроллер обрабатывает внешние запросы и координирует изменение модели и актуальность представления.

 

Рис. 26. Модель-представление-контроллер.

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

N-звеньевая архитектура

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

N-звеньевая архитектура характеризуется следующими принципами:

● Это архитектурный стиль для развертывания уровней многоуровневой архитектуры.

● Звенья зависят только от своих непосредственных соседей. Звено n знает, как обрабатывать запросы от звена n+1, передавать запросы к звену n-1 и интерпретировать полученные результаты.

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

Преимущества N-звеньевой архитектуры:

■ Сопровождаемость. Физическая изоляция уровней облегчает замену оборудования.

■ Масштабируемость. При увеличении нагрузки на одно из звеньев возможно легкое увеличение количества оборудования в звене.

■ Увеличение работоспособности и доступность. Этот показатель возрастает благодаря физической изолированности и независимости оборудования.

В качестве примера использования данного архитектурного стиля приведем типичное веб-приложение с повышенными требования к безопасности обрабатываемых данных. В таком веб-приложении компоненты бизнес-логики можно разместить на отдельном физическом сервере, который связан с веб-сервером по интранет-сети. Веб-сервер принимает запросы пользователей из внешней сети, перенаправляет их на обработку серверу с бизнес-логикой, обработанные данные представляет в виде веб-страниц. Если слой доступа к данным также размещается на отдельном компьютере, то мы получим достаточно распространённый вариант – 3-х звеньевую архитектуру (рис. 27).

 

Рис. 27. Пример 3-х звеньевой архитектуры.