Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Обучение от Mail.Ru Group.
Онлайн-университет
для программистов с
гарантией трудоустройства.
Набор открыт!
2005 г.

Обзор паттернов проектирования

Ольга Дубина



Назад Оглавление Вперед



4 АРХИТЕКТУРНЫЕ СИСТЕМНЫЕ ПАТТЕРНЫ

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

В свою очередь, паттерны управления разделены на паттерны централизованного управления, 4.2.1 (то есть паттерны, в которых одна из подсистем полностью отвечает за управление, запускает и завершает работу остальных подсистем) и паттерны управления, подразумевающие децентрализованное реагирование на события, 4.2.2, (согласно этим паттернам на внешние события, определённые в разделе 7.3, отвечает соответствующая подсистема.). Также следует упомянуть, что поскольку проектирование взаимодействия той или иной подсистемы с реляционной базой данных (определенной в разделе 7.3) является неотъемлемой частью разработки корпоративных информационных систем, среди паттернов управления выделена большая группа паттернов, описывающих организацию связи с базой данных, см. раздел 4.2.3.

4.1 Структурные паттерны

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

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

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

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

4.1.2 Клиент/сервер
Описание Данные и процессы системы распределены между несколькими процессорами. Паттерн имеет три основных компонента: набор автономных серверов, (предоставляют сервисы другим подсистемам), набор подсистем - клиентов (которые вызывают сервисы, предоставляемые серверами) и сеть (служит для доступа клиентов к сервисам). Клиенты должны знать имена серверов и сервисов, в то время как серверам не надо знать имена клиентов и их количество. Клиенты получают доступ к сервисам, предоставляемым серверами посредством удаленного вызова процедур.
Рекомендации Данный подход можно использовать при реализации систем, основанных на репозитории, который поддерживается как сервер системы. Подсистемы, имеющие доступ к репозиторию, являются клиентами.
Преимущества Данный паттерн формирует распределенную архитектуру, ее эффективно использовать в сетевых системах с множеством распределенных процессоров В систему легко добавить новый сервер и интегрировать его с остальной частью системы или же обновить сервисы, не воздействуя на другие части системы.
Недостатки При работе серверы и клиенты обмениваются данными, но при большом объеме передаваемых между серверами и клиентами данных могут возникнуть проблемы с пропускной способностью сети.
4.1.3 Обьектно - ориентированный, Модель предметной области (Domain Model), модуль таблицы (Data Mapper)
Задача Бизнес - логика крайне сложна, имеется множество правил и условий, оговаривающих различные варианты поведения системы.
Решение Система представляется состоящей из совокупности связанных между собой обьектов. Объекты представляют сервисы (методы) другим объектам и создаются во время исполнения программы на основе определения классов обьектов. Объекты скрывают информацию о представлении состояний и, следовательно, ограничивают к ним доступ.
Преимущества Упрощается процесс модификации системы: можно изменять реализацию того или иного объекта, не воздействуя на другие объекты. Обьектно - ориентированная система проще в понимании и модернизации. Данная система удобна для групповой разработки: работу по реализации системы легко разделить между разработчиками. Потенциально все объекты являются повторно используемыми компонентами, так как они независимо инкапсулируют данные о состоянии и операции. Архитектуру системы можно разрабатывать на базе обьектов (структур обьектов) уже созданных в предыдущих проектах.
Недостатки При использовании сервисов объекты должны явно ссылаться на имена других обьектов и знать их интерфейс (это необходимо учесть если при изменении системы требуется изменить интерфейс).

Пример 1.

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

Пример 2.

Модуль таблицы также является частным случаем данного паттерна. В отличие от модели предметной области Модуль таблицы содержит по одному объекту Контракт для каждого контракта, а Модуль таблицы является единственным объектом. Модуль таблицы используется совместно с множеством записей (Record Set). Сначала создается объект "Контракт", затем - "Продукт", множество записей передается ему в качестве аргумента.. Для совершения операций над отдельным контрактом, следует сообщить объекту соответствующий идентификатор (Id).

Модуль таблицы представляет собой промежуточный вариант между "Сценарием транзакции" 4.2.1.1 и "Моделью предметной области" (Пример1).

4.1.4 Многоуровневая система (Layers) или абстрактная машина
Описание В соответствии с паттерном "Многоуровневая система" структурные элементы системы организуются в отдельные уровни со взаимосвязанными обязанностями таким образом, чтобы на нижнем уровне располагались низкоуровневые службы и службы общего назначения, а на более высоких - объекты уровня логики приложения. При этом взаимодействие и связывание уровней происходит сверху вниз. Связывания обьектов снизу вверх следует избегать.

На рисунке показаны типичные уровни логической архитектуры системы [ 5].

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

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

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

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

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

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

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

4.2 Паттерны управления

4.2.1 Паттерны централизованного управления
4.2.1.1 Вызов - возврат (сценарий транзакции - частный случай).
Описание Вызов программных процедур осуществляется "сверху - вниз", то есть управление начинается на вершине иерархии процедур и через вызовы передается на нижние уровни иерархии.
Рекомендации Применима только в последовательных системах, то есть в таких системах, в которых процессы должны происходить последовательно.
Преимущества Простой анализ потоков управления. Последовательные системы легче проектировать и тестировать.
Недостатки Сложно обрабатывать исключительные ситуации.
Пример Сценарий транзакции можно считать частным случаем паттерна. Сценарий транзакции может быть рассмотрен как способ организации бизнес - логики ("Модель предметной области", см. 4.1.3.) Сценарий транзакции - процедура, которая получает на вход информацию от слоя представления, обрабатывает ее, производя необходимые проверки и вычисления, сохраняет в базе данных и активизирует операции других систем.

Сценарий транзакции не годится для сложной бизнес - логики.

4.2.1.2 Диспетчер
Описание Один системный компонент назначается диспетчером и управляет запуском и завершением других процессов системы и координирует эти процессы. Процессы могут протекать параллельно.
Рекомендации Применяется в системах, в которых необходимо организовать параллельные процессы, но может использоваться также и для последовательных систем, в которых- управляющая программа вызывает отдельные подсистемы в зависимости от значений некоторых переменных состояния.
Пример Можно использовать в системах реального времени, где нет чересчур строгих временных ограничений (в так называемых "мягких" системах реального времени).
4.2.2 Паттерны управления, основанные на событиях
4.2.2.1 Передача сообщений
Описание В рамках данного паттерна событие представляет собой передачу сообщения всем подсистемам. Любая подсистема, которая обрабатывает данное событие, отвечает на него.
Рекомендации Данный подход эффективен при интеграции подсистем, распределенных на разных компьютерах, которые объединены в сеть.
4.2.2.2 Управляемый прерываниями
Описание При использовании данного паттерна внешние прерывания регистрируются обработчиком прерываний, а обрабатываются другим системным компонентом.
Рекомендации Используются в системах реального времени со строгими временными требованиями. Данный паттерн может быть скомбинирован с паттерном Диспетчер, см. п. 4.2.1.2: центральный диспетчер управляет нормальной работой системы, а в критических ситуациях используется управление, основанное на прерываниях.
Преимущества Достаточно быстрая реакция системы на происходящие события.
Недостатки При использовании данного подхода система сложна в программировании. При тестировании системы затруднительно имитировать все прерывания. Число прерываний ограничено используемой аппаратурой (после достижения предела, связанного с аппаратными ограничениями, никакие другие прерывания не обрабатываются).
4.2.3 Паттерны, обеспечивающие взаимодействие с базой данных
4.2.3.1 Активная запись (Active Record)
Описание Если предметная область несложная, то логично возложить на каждый класс порцию бизнес - логики.

При использовании этого паттерна объект класса "осведомлен" о том, как взаимодействовать с таблицами базы данных.

4.2.3.2 Единица работы (Unit Of Work)
Задача При выполнении операций считывания или изменения обьектов система должна гарантировать, что состояние базы данных останется согласованным. Например, на результат загрузки данных не должны влиять изменения, вносимые другими процессами.
Решение Создается специальный объект, "отслеживающий" изменения, вносимые в базу данных. Данное типовое решение позволяет проконтролировать, какие объекты считываются и какие модифицируются и обслужить операции обновления содержимого базы данных.

Преимущества Нет необходимости явно вызывать методы сохранения, достаточно сообщить объекту Единица работы о необходимости фиксации (commit) результатов в базе данных. Вся сложная логика фиксации сосредоточена в одном месте, таким образом, координируется запись в базу данных.
4.2.3.3 Загрузка по требованию (Lazy Load)
Задача Требуется загрузить данные из базы данных в оперативную память так, чтобы при загрузке требуемого объекта автоматически загружались и другие связанные с ним объекты, при этом, обьем загружаемых данных не должен быть чрезмерным.
Решение Прерывать процесс загрузки связанных обьектов из базы данных, оставляя при этом соответствующую метку. Это позволит загрузить данные только тогда, когда они действительно потребуются.
4.2.3.4 Коллекция обьектов (Identity Map)
Задача Требуется гарантировать, что каждый объект будет загружен из базы данных только один раз.
Решение Создать специальную коллекцию обьектов, загруженных из базы данных в пределах одной бизнес - транзакции. Таким образом, при получении запроса можно просмотреть эту коллекцию в поисках нужного объекта.
Преимущества Предотвращение повторных загрузок позволяет избежать ошибок и повышает производительность системы.
4.2.3.5 Множество записей (Record Set)
Описание Одна из основополагающих структур данных, имитирующая табличную форму представления содержимого базы данных. Как правило, Множество записей не приходится конструировать самому разработчику, поскольку, как правило, существуют стандартные классы.
Преимущества Удобно для разработчиков, поскольку предоставляет структуру данных, которая хранится в оперативной памяти и соответствует результату выполнения SQL - запроса, в то же время, эта структура данных может быть сгенерирована и использована другими частями системы.
4.2.3.6 Наследование с одной таблицей (Single Table Inheritance)
Задача Поскольку SQL не предоставляет стандартных инструментов поддержки наследования, требуется создать специальный аппарат отображения в базе данных иерархии наследования.
Решение Все поля всех классов наследования отображаются в одной и той же таблице. Например, требуется отобразить структуру

При использовании паттерна "Наследование с одной таблицей" формируется следующая таблица

Преимущества Данный метод прост в реализации и устойчив к модификациям.
Недостатки При работе пользователей с одной большой таблицей будет вводиться много блокировок.
4.2.3.7 Наследование с таблицами для каждого класса (Class Table Inheritance)
Описание Каждой таблице соответствует отдельный класс. Данное отображение является самым простым и прямолинейным вариантом организации наследования (связи между классами и таблицами). При использовании паттерна "Наследование с таблицами для каждого класса" для примера паттерна 4.2.3.7 формируются две таблицы

Недостатки Для загрузки информации об отдельном объекте приходится осуществлять несколько операций соединения (join), что обычно снижает производительность системы.
4.2.3.8 Оптимистическая автономная блокировка (Optimistic Offline Lock)
Задача Бизнес - транзакция содержит несколько системных транзакций, см. п. 7.3 в этом случае СУБД не может гарантировать согласованность записей базы данных. Любая попытка доступа нескольких сеансов к одним и тем же записям грозит нарушением целостности данных и, кроме того, может привести к утрате внесенных изменений.
Решение Провести проверку, не вступят ли изменения, проведенные одним сеансом в конфликт с изменениями, проведенными другим сеансом (например, сверяется номер версии отдельной записи, сохраненной вместе с состоянием сеанса, с текущим номером версии этой же записи в базе данных). Если проверка прошла успешно, то изменяемые записи блокируются и изменения фиксируются в базе данных. Проверка и фиксация осуществляются в рамках одной системной транзакции, данные останутся согласованными. Срок действия "Оптимистической автономной блокировки" ограничивается той системной транзакцией, в процессе которого она была установлена.
4.2.3.9 Отображение с помощью внешних ключей
Описание Требуется организовать в реляционной базе данных отображение связи "один - ко -многим" (в отличие от базы данных для объекта легко реализовать многозначный атрибут - достаточно просто сделать коллекцией значение данного аттрибута).

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

4.2.3.10 Отображение с помощью таблицы ассоциаций (Association Table Mapping)
Описание Требуется организовать в реляционной базе данных отображение связи "многие - ко -многим".

Решение Создать специальную таблицу отношений для хранения ассоциаций. При этом каждой паре взаимосвязанных обьектов будет соответствовать только одна строка таблицы отношений.

Недостатки Обновление данных занимает значительное время.
4.2.3.11 Пессимистическая автономная блокировка (Pessimistic Offline Lock)
Задача При использовании оптимистической блокировки один пользователь может зафиксировать результаты транзакции, а остальным пользователям будет в этом отказано. Требуется предотвратить подобный конфликт.
Решение Блокировка накладывается на данные прежде, чем бизнес - транзакция начинает с ними работать, таким образом, гарантируется завершение транзакции без негативных последствий из-за параллельных сеансов.
Рекомендации Пессимистическая блокировка должна применяться в том случае, когда велика вероятность конфликта.
Примечание Альтернативой применению "Пессимистической блокировки" может быть использование длинных системных транзакций.
4.2.3.12 Поле идентификации (Identity Field)
Описание Связи обьектов и таблиц реализуются по разному. Обьекты манипулируют связями, отображая ссылки в виде адресов памяти. В реляционных базе данных связь одной таблицы с другой задается путем формирования соответствующего внешнего ключа. Кроме того, объект способен сохранить множество ссылок с помощью коллекции, в то время как правила нормализации таблиц базы данных допускают применение только однозначных ссылок. Требуется организовать отображение связей.
Решение Сохранять в составе объекта идентификаторы связанных с ним обьектов - записей и обращаться к этим значениям, когда требуется прямое и обратное отображение обьектов и ключей таблиц базы данных.

Недостатки Невозможно организовать ссылку на коллекцию обьектов.
4.2.3.13 Преобразователь данных (Data Mapper)
Описание При переходе от полей "Шлюза таблицы данных", 4.2.3.17, к полям обьектов "Модели предметной области", 4.1.3, приходится выполнять определенные преобразования, которые приводят к усложнению обьектов домена.
Решение Изолировать "Модель предметной области" от базы данных, возложив на промежуточный слой всю полноту ответственности за отображение обьектов домена в таблицы базы данных. Преобразователь данных обслуживает все операции загрузки и сохранения информации, инициируемые бизнес - логикой и позволяет независимо модернизировать как "Модель предметной области" так и схему базы данных.
Преимущества Полная изоляция бизнес - логики от базы данных.
4.2.3.14 Cохранение сеанса на стороне клиента (Client Session State)
Задача Сохранить сведения о сеансе, определение - см. п. 7.3.
Решение Данные о состоянии сеанса можно сохранять на стороне клиента. При этом клиент передает серверу все сведения о сеансе вместе с каждым запросом. Никаких данных о состоянии сеанса на сервере не хранится. Если есть необходимость хранения числового идентификатора сеанса, то альтернативы данному паттерну не существует.
Преимущества Можно использовать серверные объекты без состояний, что обеспечивает большую степень отказоустойчивости.
Недостатки Возникают проблемы безопасности при передаче данных от клиента серверу - передаваемые данные приходится шифровать. Затруднительно использовать данный паттерн при большом объеме информации о сеансе. Часто возникает проблема преобразования формата данных.
4.2.3.15 Cохранение сеанса на стороне сервера (Server Session State)
Задача Сохранять сведения о сеансе.
Решение На клиенте хранится только идентификатор сеанса, а все данные о сеансе хранятся сервером. Для хранения обьектов сеансов на сервере формируется специальная коллекция.
Преимущества Передается только идентификатор сеанса, а не весь обьем данных о сеансе.
Недостатки Требуются значительные ресурсы сервера.
4.2.3.16 Шлюз записи данных (Row Data Gateway)
Задача Обеспечить взаимодействие бизнес - логики с базой данных, при этом требуется обособить SQL код от бизнес - логики.
Решение Копировать структуру записи в отдельном классе. Для каждой записи, возвращаемой запросом к базе данных, создается экземпляр шлюза.

4.2.3.17 Шлюз таблицы данных (Table Data Gateway)
Задача Обеспечить взаимодействие бизнес - логики с базой данных, при этом требуется обособить SQL код от бизнес - логики.
Решение Копировать структуру таблицы базы данных в отдельном классе, который содержит методы активизации запросов, возвращающих множество записей.




Назад Оглавление Вперед

Новости мира IT:

Архив новостей

Последние комментарии:

Релиз ядра Linux 4.14  (9)
Среда 22.11, 19:04
Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...