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

↑

▷ Содержание

⇐ ПредыдущаяСтр 4 из 4

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

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

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

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

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

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

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

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

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

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

Таблица 2

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

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

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

Архитектурный стиль «клиент-сервер» (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-х звеньевой архитектуры.

Познавательные статьи:



Коммуникативные барьеры и пути их преодоления

Рынок недвижимости. Сущность недвижимости

Решение задач с использованием генеалогического метода

История происхождения и развития детской игры