Согласно предложенному принципу классификации,архитектурные паттерны проектирования объединены в группы в соответствии со специализированными задачами, решение которых они позволяют реализовать.
Архитектурные шаблоны позволяют сформировать "скелет" информационной системы, на который в дальнейшем будет наращиваться актуальный и востребованный функционал. Шаблоны этой категории определяют ключевой фактор каждой информационной системы – структуру, коренное изменение которой может стать достаточно ресурсоемкой процедурой для компании и пользователей программного продукта.
Для построения востребованной архитектуры программного обеспечения, отвечающей принципам программной инженерии, системную структуру организуют на основе классов или объектов, использующих структурные архитектурные шаблоны проектирования.
С другой стороны, для обеспечения требуемой гибкости функционала основное значение имеет адекватная организация взаимодействия отдельных системных элементов.Для этой цели служит другой вид архитектурных паттернов –шаблоны управления. Они же, в свою очередь, разделены на шаблоны централизованного и децентрализованного управления:
Следует упомянуть, что проектирование информационных систем затрагивает не только описание логики взаимодействие компонентов, но и описание логики взаимодействия с базой данных, которое может являться значимым аспектом в обеспечении нефункциональных характеристик.
Именно поэтому среди паттернов управления выделена большая группа шаблонов, описывающих организацию связи с базой данных.
Архитектурные структурные шаблоны представляют класс паттернов, описывающих подходы к организации структуры создаваемого приложения, вариативность которой может диктоваться условиями эксплуатации конкретного программного продукта.
Данный способ организации информационных систем целесообразно использовать в ситуациях, когда системе необходимо обработать большой массив сторонних данных. Оптимальная организация способов обработки включает в себя хранение обрабатываемых данных в центральной базе данных, которая доступна всем использующим ее подсистемам.
"Репозиторий" – пассивный модуль, управление которым возложено на использующие его компоненты или подсистемы.
Централизованное расположение данных позволяет отказаться от их "пересылки" и уменьшает степень связности между разнородными компонентами. Подсистеме не нужно понимать, как используются данные в других подсистемах.
С другой стороны, все компоненты должны иметь унифицированный интерфейс для взаимодействия с моделью данных "Репозитория". Также за счет единой структуры данных все подсистемы должны поддерживать схожую политику безопасности (восстановление, резервирование и пр.).
В качестве практических примеров использования данного шаблона могут служить системы классовBI иBW, основной обязанностью которых является оперативная обработка информации и формирование на ее основе оперативной отчетности.
Этот архитектурный шаблон предполагает распределение функционирования программы между тремя основными компонентами:
Клиенты должны знать имена серверов и сервисов.Серверам не надо знать имена клиентов и их количество. Клиенты получают доступ к сервисам, предоставляемым серверами с помощью удаленного вызова процедур.
Этот подход используется при реализации систем, основанных на шаблоне "Репозиторий", который поддерживается как сервер. Подсистемы, имеющие доступ к "Репозиторию", являются "клиентами".
Шаблон "Клиент-сервер" лежит в основе распределенных архитектур большинства современных информационных систем, использующих сетевые системы с множеством распределенных процессоров.
Неоспоримым преимуществом администрирования и сопровождения архитектуры, построенной на шаблоне "Клиент-сервер", является простота расширения (добавление, изменение серверов, выполняющих обработку информации и их интеграцию с остальной частью системы).
В процессе функционирования "сервер" и "клиент" обмениваются данными, но при большом объеме передаваемых данных могут возникнуть проблемы с пропускной способностью сети, что является неоспоримым недостатком данного шаблона.
Предпосылки к созданию этого шаблона возникли после появления концепции разработки DDD (Domen Driven Design).
Шаблон "Модель предметной области" целесообразно применять в случаях, когда бизнес-логика реализуемого приложения очень сложна, имеется множество правил и условий, обосновывающих множество вариантов функционирования создаваемой системы.
Информационная система в этом случае состоит из совокупности комплексно связанных компонентов, которые должны соответствовать сущностям предметной области, автоматизированным в программном продукте. Различные сущности (или объекты) создаются во время выполнения функций программы и предоставляют "соседним" объектам в пользование методы, определенные на основе собственных классов.
При таком определении системы упрощается ее последующая модификация. Изменение реализации того или иного объекта не оказывает глобального влияния на связанные с ним объекты, при условии сохранения результата выполнения функционирования связывающих объекты методов.При использовании шаблона "Модель предметной области" компания-разработчик получает следующие преимущества:
Однако при использовании сервисов использующие их объекты должны явно ссылаться на имена других объектов и однозначно "понимать" их интерфейс.Это факт необходимо учитывать при изменении системы.
Шаблон "Модель предметной области" является достаточно сложным, как для полноценной реализации, так и для понимания, поэтому есть множество "подшаблонов", которые являются его упрощенной моделью для конкретных условий эксплуатации, – к примеру, "Модуль таблицы".
В отличие от шаблона "Модель предметной области",этот шаблон содержит только по одному объекту. "Модуль таблицы" используется совместно с множеством сервисов. Сначала создается объект, а затем его дочерние "подобъекты", которым передаются аргументы.
С помощью шаблона "Многоуровневая архитектура" различные структурные элементы организуются по отдельным уровням, взаимосвязывающимся между собой таким образом, чтобы на более низких уровнях располагались:
На более высоких уровнях располагаются сервисы уровня логики приложения, которые подвергаются постоянным изменениям и реализуют необходимую функциональность информационных систем.
Очень важной характеристикой, которую следует соблюдать при реализации слоев, является то, что связывание уровней должно выполняться сверху вниз, а не наоборот.
Одним из слоев верхнего уровня, отвечающим за взаимодействие между программой и пользователем и несущим в себе часть реализации бизнес-логики, является слой представления.
К главным функциям этого слоя относится отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в соответствии с автоматизированной бизнес-логикой и содержанием источника данных.
Источник данных – подмножество функций, обеспечивающих взаимодействие со сторонними системами.
Главным отличием шаблона "Многоуровневая архитектура" от шаблона "Клиент-сервер", которые на первый взгляд очень похожи, является то, что слои располагаются совместно в одном месте, а не на разных машинах (серверах).
Наиболее известным примером данного шаблона служит модель взаимодействия открытых систем (OSI), в которой механизм обмена данными между компьютерными системами реализован на основе семиуровневой модели протоколов передачи данных.
Одно из современных веяний менеджмента – переход к функционально-ориентированной (построенной методом "функциональных колодцев") модели управления – ознаменовал появление соответствующего архитектурного шаблона.
Этот паттерн воплотил в себе принцип разделения функциональности информационных систем в соответствии с потребностями автоматизации отдельных объектов.
Различные функциональные модели имеют набор уникальных классов и методов, на основе которых выполняется их автоматизация.
С одной стороны, это приводит к независимости реализации отдельных моделей и повышению гибкости информационной системы в целом, но, как следствие, грозит появлением дублирующей функциональности, созданных для разных моделей.
Каждый функциональный колодец представляет собой миниатюру шаблона "Модель предметной области". Основные трудности возникают в тот момент, когда требуется выполнить интеграцию разнородных моделей в единое определение объекта.
Каждая система состоит из функциональных модулей.Они получают на входе данные и преобразуют их (конвейерный подход). Каждый шаг обработки реализован в виде преобразования. Преобразования могут выполняться последовательно или параллельно, а обработка данных может быть пакетной или поэлементной.
Шаблон "Потоки данных" представляет собой алгоритмы, основанные на возможности повторного использования преобразований и возможности модификации существующей системы посредством добавления новых преобразований.
Данный паттерн прост в реализации как для систем, поддерживающих последовательный, так и параллельный способы обработки данных.
Основной недостаток данного шаблона заключается в необходимости использования общего формата данных, который должен распознаваться всеми преобразованиями. Каждое преобразование либо следует согласовывать со смежными преобразованиями относительно формата преобразовываемых данных, либо необходимо использовать стандартный формат для всех обрабатываемых данных.
Взаимодействующие подсистемы со сложными форматами ввода-вывода и большим количеством разнообразных событий достаточно сложно проектировать с использованием этого паттерна, поскольку трудно прогнозировать и обеспечить равномерный и единый по формату поток обрабатываемых данных.
Архитектурные шаблоны централизованного управления относятся к типам шаблонов, которые предлагают централизованный способ организации логики выполняемых программных продуктов.
Паттерны этой категории содержат описание механизмов единого унифицированного управления, основанного на структурных особенностях поэтапного выполнения программ. Эти шаблоны выполняют роль "мозгового центра" проектируемого программного продукта.
Современные корпоративные информационные системы обладают большим количеством компонентов и громоздкой иерархической структурой их взаимосвязей.
Вызов процедур, как правило, осуществляется "сверху вниз". Управление начинается на вершине иерархии и через вызовы передается на нижние уровни.Подобный способ управления хорошо зарекомендовал себя в программных продуктах, в которых процессы запускаются и выполняются последовательно, в соответствии с условиями их функционирования.
Применение шаблона "Сценарий транзакций" способствует сохранению целостности, прозрачности, предсказуемости создаваемого программного обеспечения."Сценарий транзакции"целесообразно рассматривать как механизм организации бизнес-логики ("Модель предметной области").
"Сценарий транзакций"– процедура, которая получает на вход информацию от слоя представления, обрабатывает ее, производя необходимые проверки и вычисления, сохраняет в базе данных и активизирует операции других слоев.
В качестве основных недостатков можно выделить сложность выявления и обработки исключительных ситуаций. Сценарий транзакции не годится для организации "запутанной"бизнес-логики.
Этот шаблон организации систем предусматривает создание системного компонента, который назначается диспетчером, то есть отвечает за управление и координацию выполнения процессов, исполняемых в программном продукте. При этом нет ограничений на способы выполнения процессов ("последовательно", "параллельно" и пр.).
Паттерн, как правило, применяется в системах, для которых необходимо повысить их общую производительность за счет "запараллеливания" процессов, но может использоваться и для последовательной обработки (управляющая программа или диспетчер вызывает отдельные подсистемы в зависимости от значений некоторых переменных состояния).
Одним из главных недостатков применения шаблона "Диспетчер" является рекомендация по использованию в так называемых "мягких" системах реального времени (нет строгих временных ограничений).
Применение "Диспетчера" целесообразно в тех случаях, когда группа разработки полностью понимает и имеет различные способы воздействия на все программные компоненты (система представляет собой "прозрачный" ящик).
Управление по событиям является способом координации потока(ов) информации и ее последующей обработки в зависимости от факторов и условий, значимых для достижений конечного результата деятельности программного приложения.
Шаблоны управления по событиям помогают в разработке логики, автоматизирующей значимые функции, возникающие при наступлении или отсутствии определенных бизнес-сигналов.
Данный шаблон проектирования транслирует каждое обрабатываемое событие в виде передачи сообщений всем заинтересованным подсистемам, которые обрабатывают событие и при необходимости отвечают на него. Шаблон "Передача сообщений" получил особую популярность при реализации систем, обрабатывающих сложную и разрозненную бизнес-логику.
Логика исполнения основана на сетевом взаимодействии различных участников автоматизируемого процесса.Сферы ответственности участников достаточно независимы друг от друга. Конечный результат обработки определяется вкладом каждого из участников.
Шаблон "Управление прерываниями" применяется в основном в системах реального времени со строгими временными требованиями на обработку поступающих извне сообщений, когда необходима быстрая реакция системы на зафиксированное событие.
Использование данного шаблона предусматривает регистрацию возникающих прерываний специализированным обработчиком. После чего наступает стадия непосредственной обработки, которая должна выполняться другим системным компонентом.
Шаблон "Управление прерываниями" очень часто используют вместе с шаблоном "Диспетчер". В случае штатного функционирования система управляется посредством "Диспетчера", а в критических ситуациях используется управление, основанное на прерываниях. Основной недостаток подобного комбинирования шаблонов состоит в том, что система сложна в программировании и последующем тестировании. Если уделить внимание основным сложностям, то они состоят в имитации всех возможных прерываний, которые должны быть известны априори.
Взаимодействие с базой данных – неотъемлемая часть современных информационных систем. То, насколько оптимально организована связь между слоем логики и слоем данных, во многом предопределяет нефункциональные характеристики программных продуктов.
Шаблоны, описывающие данный способ взаимодействия, позволяют избежать многих проблем, которые возникают в работе над созданием программного обеспечения.
В случаях, когда предметная область несложная, то логично каждому классу делегировать и ответственность за конкретные объекты бизнес-логики.При использовании этого паттерна объект класса должен "понимать", как взаимодействовать с данными.
Для этого шаблона характерны следующие характеристики:
При выполнении операций (создание, чтение, изменение, удаление) над объектами базы данных система должна гарантировать, что данные останутся согласованными (консистентными).
Эта задача решается за счет специализированного объекта, который должен отслеживать вносимые изменения. Подобное решение позволит контролировать различное состояние объектов и соответствующим образом обслужить операции обновления содержимого базы данных. Не будет необходимости явно вызывать методы сохранения – достаточно сообщить объекту о необходимости фиксации результатов работы отдельных методов в базе данных.Вся сложная логика фиксации сосредоточена в одном месте.
Если требуется загрузить данные из базы в оперативную память так, чтобы при загрузке требуемого объекта автоматически загружались и другие связанные с ним объекты (при этом объем загружаемых данных не должен быть чрезмерным), используется шаблон "Загрузка по требованию".
При загрузке связанных объектов процесс прерывается при достижении первоначально необходимого объема данных,но остается метка о важности загрузки последующих данных. Это позволит загрузить данные только тогда, когда они действительно потребуются.
Когда требуется гарантировать, что каждый объект будет загружен из базы данных только один раз, применяется шаблон "Количество объектов". Паттерн реализуется за счет создания специальной коллекции объектов, загруженных из базы данных в пределах одной транзакции.
При получении очередного запроса можно просмотреть эту коллекцию в поисках нужного объекта.Предотвращение повторных загрузок позволяет избежать ошибок и повышает производительность системы.
Шаблон "Множество записей" относится к одной из основополагающих "динамических" структур данных.Он имитирует табличную форму представления содержимого базы данных. "Множество записей" не приходится конструировать – как правило, существуют стандартные классы, реализующие этот шаблон данных.
Они удобны, поскольку предоставляют структуру данных, которая хранится в оперативной памяти и соответствует результату выполнения запроса к базе данных.В то же время эта структура данных может быть сгенерирована и использована другими частями системы.
В продолжение обсуждения "низкоуровневых" шаблонов, которые катализируют процесс разработки программного обеспечения за счет экономии ресурсов на повторном использовании наиболее эффективных программных элементов, следует затронуть следующий паттерн–"Шлюз записи данных".
Этот шаблон обеспечивает взаимодействие компонентов слоев бизнес-представления со слоями базы данных. Для его создания следует инкапсулировать код реализации компонента от кода бизнес-логики. Реализация этого шаблона заключается в копировании структуры записей в отдельном программном классе. Для каждой записи, возвращаемой запросом к базе данных, создается экземпляр шлюза.
Бизнес-алгоритмы, автоматизируемые в современных корпоративных информационных системах, с технической точки зрения представляют собой достаточно высокоуровневую логику исполнения и принятия решений. Это приводит к тому, что "бизнес-транзакции" содержат в себе ряд системных транзакций.
Несоответствие понятий бизнес- и системных транзакций влечет за собой необходимость привлечения на каждом из уровней декомпозиции дополнительных объектов. Цель новых элементов – обеспечить согласованный переход к требуемому уровню представления или автоматизации бизнес-процесса.
Шаблон "Оптимистическая автономная блокировка" позволяет минимизировать негативное влияние несогласованности записей при использовании базы данных в автоматизируемых бизнес-процессах.
Попытка доступа нескольких обращений базы данных к одним и тем же записям грозит нарушением целостности данных и, кроме того, может привести к утрате внесенных изменений.
Проверка изменений, проведенных одним сеансом,конфликтует с изменениями, проведенными другим сеансом.Например, сверяется номер версии записи, сохраненной вместе с состоянием сеанса и с текущим номером версии этой же записи в базе данных. Если проверка прошла успешно, то изменяемые записи блокируются и изменения фиксируются в базе данных. Проверка и фиксация осуществляются в рамках одной системной транзакции, данные останутся согласованными. Срок действия "Оптимистической автономной блокировки" ограничивается системной транзакцией, в процессе которого она была установлена.
Шаблон "Оптимистическая автономная блокировка"решает задачу фиксации результатов, выполненной одним пользователем за период жизнедеятельности конкретной бизнес- или системной транзакции.
Ее использование не оправдано в случаях, когда необходимо поддержать многопользовательскую работу над одним участком данных.
Для предотвращения описанного конфликта применяется шаблон "Пессимистическая автономная блокировка", которая "накладывается" на данные прежде, чем бизнес-транзакция начинает с ними работать.Это обеспечивает завершение транзакции без негативных последствий из-за множества параллельных сеансов.
"Пессимистическая автономная блокировка" должна применяться в том случае, когда велика вероятность конфликта.
Этот способ организации блокировок не подходит для системных компонентов, в которых необходима возможность одновременной работы с данными из нескольких подключений.
При переходе от результатов выполнения загрузки данных к переменным программы приходится выполнять определенные преобразования, которые приводят к усложнению и разрастанию программных объектов.
Задачу изолирования модели предметной области от данных, с возложением на промежуточный слой всей полноты ответственности за отображение объектов домена в таблицы базы данных, выполняет шаблон "Преобразователь данных". Он обслуживает все операции загрузки и сохранения информации, инициируемые бизнес-логикой, и позволяет независимо модернизировать как программные компоненты, так и сущности базы данных.
Этот шаблон позволяет полностью изолировать бизнес-логику от операций преобразования данных.
При реализации логики взаимодействия между пользователем и программой есть несколько системных шаблонов, применение которых позволит избежать ряда проблем, связанных с сохранением данных, в процессе работы пользователя.
Первый вариант –шаблон "Сохранение данных на стороне клиента". Данная реализация предусматривает передачу всех сведений о завершаемом сеансе от сервера к клиенту вместе с каждым запросом. Никаких данных о состоянии сеанса на сервере храниться не должно. Если есть необходимость хранения числового идентификатора сеанса, то альтернативы данному паттерну не существует.
Можно использовать серверные объекты без состояний, что обеспечивает большую степень отказоустойчивости.Возникают проблемы безопасности при передаче данных от клиента серверу –их приходится шифровать. Затруднительно использовать данный паттерн при большом объеме информации о сеансе.
В противоположность шаблону "Сохранение данных сеанса на стороне клиента" используется паттерн "Сохранение сеанса на стороне сервера".
В этом случае реализации на "клиенте" хранится только идентификатор сеанса, а все данные о сеансе хранятся сервером. Для реализации данного шаблона требуются значительные ресурсы сервера, масштабируемые по числу пользователей информационной системы.
В этой главе мы рассмотрели основной, но наиболее сложный вид паттернов – архитектурные шаблоны проектирования.
Этот вид шаблонов несет на себе обязанность предопределения логики выполнения реализованных на их основе программных приложений и управление их последующим выполнением.
Некоторые из рассмотренных шаблонов (структурные шаблоны) достаточно абстрактны, не имеют ясных и понятных признаков, которые могут однозначно их характеризовать, предписывая концептуальные принципы реализации информационных систем.
Другие (шаблоны управления) должны иметь в виде воплощения специализированные компоненты. Шаблоны взаимодействия, в противовес структурным и управленческим паттернам, предписывают обязательные правила реализации специализированных компонентов.
В заключение необходимо отметить, что успешное изучение предложенных типов шаблонов позволит свободно ориентироваться при проектировании информационных приложений, отталкиваясь от определенных условий и требований к их реализации.
Согласно предложенному принципу классификации,архитектурные паттерны проектирования объединены в группы в соответствии со специализированными задачами, решение которых они позволяют реализовать.
Архитектурные шаблоны позволяют сформировать "скелет" информационной системы, на который в дальнейшем будет наращиваться актуальный и востребованный функционал. Шаблоны этой категории определяют ключевой фактор каждой информационной системы – структуру, коренное изменение которой может стать достаточно ресурсоемкой процедурой для компании и пользователей программного продукта.
Для построения востребованной архитектуры программного обеспечения, отвечающей принципам программной инженерии, системную структуру организуют на основе классов или объектов, использующих структурные архитектурные шаблоны проектирования.
С другой стороны, для обеспечения требуемой гибкости функционала основное значение имеет адекватная организация взаимодействия отдельных системных элементов.Для этой цели служит другой вид архитектурных паттернов –шаблоны управления. Они же, в свою очередь, разделены на шаблоны централизованного и децентрализованного управления:
Следует упомянуть, что проектирование информационных систем затрагивает не только описание логики взаимодействие компонентов, но и описание логики взаимодействия с базой данных, которое может являться значимым аспектом в обеспечении нефункциональных характеристик.
Именно поэтому среди паттернов управления выделена большая группа шаблонов, описывающих организацию связи с базой данных.
Архитектурные структурные шаблоны представляют класс паттернов, описывающих подходы к организации структуры создаваемого приложения, вариативность которой может диктоваться условиями эксплуатации конкретного программного продукта.
Данный способ организации информационных систем целесообразно использовать в ситуациях, когда системе необходимо обработать большой массив сторонних данных. Оптимальная организация способов обработки включает в себя хранение обрабатываемых данных в центральной базе данных, которая доступна всем использующим ее подсистемам.
"Репозиторий" – пассивный модуль, управление которым возложено на использующие его компоненты или подсистемы.
Централизованное расположение данных позволяет отказаться от их "пересылки" и уменьшает степень связности между разнородными компонентами. Подсистеме не нужно понимать, как используются данные в других подсистемах.
С другой стороны, все компоненты должны иметь унифицированный интерфейс для взаимодействия с моделью данных "Репозитория". Также за счет единой структуры данных все подсистемы должны поддерживать схожую политику безопасности (восстановление, резервирование и пр.).
В качестве практических примеров использования данного шаблона могут служить системы классовBI иBW, основной обязанностью которых является оперативная обработка информации и формирование на ее основе оперативной отчетности.
Этот архитектурный шаблон предполагает распределение функционирования программы между тремя основными компонентами:
Клиенты должны знать имена серверов и сервисов.Серверам не надо знать имена клиентов и их количество. Клиенты получают доступ к сервисам, предоставляемым серверами с помощью удаленного вызова процедур.
Этот подход используется при реализации систем, основанных на шаблоне "Репозиторий", который поддерживается как сервер. Подсистемы, имеющие доступ к "Репозиторию", являются "клиентами".
Шаблон "Клиент-сервер" лежит в основе распределенных архитектур большинства современных информационных систем, использующих сетевые системы с множеством распределенных процессоров.
Неоспоримым преимуществом администрирования и сопровождения архитектуры, построенной на шаблоне "Клиент-сервер", является простота расширения (добавление, изменение серверов, выполняющих обработку информации и их интеграцию с остальной частью системы).
В процессе функционирования "сервер" и "клиент" обмениваются данными, но при большом объеме передаваемых данных могут возникнуть проблемы с пропускной способностью сети, что является неоспоримым недостатком данного шаблона.
Предпосылки к созданию этого шаблона возникли после появления концепции разработки DDD (Domen Driven Design).
Шаблон "Модель предметной области" целесообразно применять в случаях, когда бизнес-логика реализуемого приложения очень сложна, имеется множество правил и условий, обосновывающих множество вариантов функционирования создаваемой системы.
Информационная система в этом случае состоит из совокупности комплексно связанных компонентов, которые должны соответствовать сущностям предметной области, автоматизированным в программном продукте. Различные сущности (или объекты) создаются во время выполнения функций программы и предоставляют "соседним" объектам в пользование методы, определенные на основе собственных классов.
При таком определении системы упрощается ее последующая модификация. Изменение реализации того или иного объекта не оказывает глобального влияния на связанные с ним объекты, при условии сохранения результата выполнения функционирования связывающих объекты методов.При использовании шаблона "Модель предметной области" компания-разработчик получает следующие преимущества:
Однако при использовании сервисов использующие их объекты должны явно ссылаться на имена других объектов и однозначно "понимать" их интерфейс.Это факт необходимо учитывать при изменении системы.
Шаблон "Модель предметной области" является достаточно сложным, как для полноценной реализации, так и для понимания, поэтому есть множество "подшаблонов", которые являются его упрощенной моделью для конкретных условий эксплуатации, – к примеру, "Модуль таблицы".
В отличие от шаблона "Модель предметной области",этот шаблон содержит только по одному объекту. "Модуль таблицы" используется совместно с множеством сервисов. Сначала создается объект, а затем его дочерние "подобъекты", которым передаются аргументы.
С помощью шаблона "Многоуровневая архитектура" различные структурные элементы организуются по отдельным уровням, взаимосвязывающимся между собой таким образом, чтобы на более низких уровнях располагались:
На более высоких уровнях располагаются сервисы уровня логики приложения, которые подвергаются постоянным изменениям и реализуют необходимую функциональность информационных систем.
Очень важной характеристикой, которую следует соблюдать при реализации слоев, является то, что связывание уровней должно выполняться сверху вниз, а не наоборот.
Одним из слоев верхнего уровня, отвечающим за взаимодействие между программой и пользователем и несущим в себе часть реализации бизнес-логики, является слой представления.
К главным функциям этого слоя относится отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в соответствии с автоматизированной бизнес-логикой и содержанием источника данных.
Источник данных – подмножество функций, обеспечивающих взаимодействие со сторонними системами.
Главным отличием шаблона "Многоуровневая архитектура" от шаблона "Клиент-сервер", которые на первый взгляд очень похожи, является то, что слои располагаются совместно в одном месте, а не на разных машинах (серверах).
Наиболее известным примером данного шаблона служит модель взаимодействия открытых систем (OSI), в которой механизм обмена данными между компьютерными системами реализован на основе семиуровневой модели протоколов передачи данных.
Одно из современных веяний менеджмента – переход к функционально-ориентированной (построенной методом "функциональных колодцев") модели управления – ознаменовал появление соответствующего архитектурного шаблона.
Этот паттерн воплотил в себе принцип разделения функциональности информационных систем в соответствии с потребностями автоматизации отдельных объектов.
Различные функциональные модели имеют набор уникальных классов и методов, на основе которых выполняется их автоматизация.
С одной стороны, это приводит к независимости реализации отдельных моделей и повышению гибкости информационной системы в целом, но, как следствие, грозит появлением дублирующей функциональности, созданных для разных моделей.
Каждый функциональный колодец представляет собой миниатюру шаблона "Модель предметной области". Основные трудности возникают в тот момент, когда требуется выполнить интеграцию разнородных моделей в единое определение объекта.
Каждая система состоит из функциональных модулей.Они получают на входе данные и преобразуют их (конвейерный подход). Каждый шаг обработки реализован в виде преобразования. Преобразования могут выполняться последовательно или параллельно, а обработка данных может быть пакетной или поэлементной.
Шаблон "Потоки данных" представляет собой алгоритмы, основанные на возможности повторного использования преобразований и возможности модификации существующей системы посредством добавления новых преобразований.
Данный паттерн прост в реализации как для систем, поддерживающих последовательный, так и параллельный способы обработки данных.
Основной недостаток данного шаблона заключается в необходимости использования общего формата данных, который должен распознаваться всеми преобразованиями. Каждое преобразование либо следует согласовывать со смежными преобразованиями относительно формата преобразовываемых данных, либо необходимо использовать стандартный формат для всех обрабатываемых данных.
Взаимодействующие подсистемы со сложными форматами ввода-вывода и большим количеством разнообразных событий достаточно сложно проектировать с использованием этого паттерна, поскольку трудно прогнозировать и обеспечить равномерный и единый по формату поток обрабатываемых данных.
Архитектурные шаблоны централизованного управления относятся к типам шаблонов, которые предлагают централизованный способ организации логики выполняемых программных продуктов.
Паттерны этой категории содержат описание механизмов единого унифицированного управления, основанного на структурных особенностях поэтапного выполнения программ. Эти шаблоны выполняют роль "мозгового центра" проектируемого программного продукта.
Современные корпоративные информационные системы обладают большим количеством компонентов и громоздкой иерархической структурой их взаимосвязей.
Вызов процедур, как правило, осуществляется "сверху вниз". Управление начинается на вершине иерархии и через вызовы передается на нижние уровни.Подобный способ управления хорошо зарекомендовал себя в программных продуктах, в которых процессы запускаются и выполняются последовательно, в соответствии с условиями их функционирования.
Применение шаблона "Сценарий транзакций" способствует сохранению целостности, прозрачности, предсказуемости создаваемого программного обеспечения."Сценарий транзакции"целесообразно рассматривать как механизм организации бизнес-логики ("Модель предметной области").
"Сценарий транзакций"– процедура, которая получает на вход информацию от слоя представления, обрабатывает ее, производя необходимые проверки и вычисления, сохраняет в базе данных и активизирует операции других слоев.
В качестве основных недостатков можно выделить сложность выявления и обработки исключительных ситуаций. Сценарий транзакции не годится для организации "запутанной"бизнес-логики.
Этот шаблон организации систем предусматривает создание системного компонента, который назначается диспетчером, то есть отвечает за управление и координацию выполнения процессов, исполняемых в программном продукте. При этом нет ограничений на способы выполнения процессов ("последовательно", "параллельно" и пр.).
Паттерн, как правило, применяется в системах, для которых необходимо повысить их общую производительность за счет "запараллеливания" процессов, но может использоваться и для последовательной обработки (управляющая программа или диспетчер вызывает отдельные подсистемы в зависимости от значений некоторых переменных состояния).
Одним из главных недостатков применения шаблона "Диспетчер" является рекомендация по использованию в так называемых "мягких" системах реального времени (нет строгих временных ограничений).
Применение "Диспетчера" целесообразно в тех случаях, когда группа разработки полностью понимает и имеет различные способы воздействия на все программные компоненты (система представляет собой "прозрачный" ящик).
Управление по событиям является способом координации потока(ов) информации и ее последующей обработки в зависимости от факторов и условий, значимых для достижений конечного результата деятельности программного приложения.
Шаблоны управления по событиям помогают в разработке логики, автоматизирующей значимые функции, возникающие при наступлении или отсутствии определенных бизнес-сигналов.
Данный шаблон проектирования транслирует каждое обрабатываемое событие в виде передачи сообщений всем заинтересованным подсистемам, которые обрабатывают событие и при необходимости отвечают на него. Шаблон "Передача сообщений" получил особую популярность при реализации систем, обрабатывающих сложную и разрозненную бизнес-логику.
Логика исполнения основана на сетевом взаимодействии различных участников автоматизируемого процесса.Сферы ответственности участников достаточно независимы друг от друга. Конечный результат обработки определяется вкладом каждого из участников.
Шаблон "Управление прерываниями" применяется в основном в системах реального времени со строгими временными требованиями на обработку поступающих извне сообщений, когда необходима быстрая реакция системы на зафиксированное событие.
Использование данного шаблона предусматривает регистрацию возникающих прерываний специализированным обработчиком. После чего наступает стадия непосредственной обработки, которая должна выполняться другим системным компонентом.
Шаблон "Управление прерываниями" очень часто используют вместе с шаблоном "Диспетчер". В случае штатного функционирования система управляется посредством "Диспетчера", а в критических ситуациях используется управление, основанное на прерываниях. Основной недостаток подобного комбинирования шаблонов состоит в том, что система сложна в программировании и последующем тестировании. Если уделить внимание основным сложностям, то они состоят в имитации всех возможных прерываний, которые должны быть известны априори.
Взаимодействие с базой данных – неотъемлемая часть современных информационных систем. То, насколько оптимально организована связь между слоем логики и слоем данных, во многом предопределяет нефункциональные характеристики программных продуктов.
Шаблоны, описывающие данный способ взаимодействия, позволяют избежать многих проблем, которые возникают в работе над созданием программного обеспечения.
В случаях, когда предметная область несложная, то логично каждому классу делегировать и ответственность за конкретные объекты бизнес-логики.При использовании этого паттерна объект класса должен "понимать", как взаимодействовать с данными.
Для этого шаблона характерны следующие характеристики:
При выполнении операций (создание, чтение, изменение, удаление) над объектами базы данных система должна гарантировать, что данные останутся согласованными (консистентными).
Эта задача решается за счет специализированного объекта, который должен отслеживать вносимые изменения. Подобное решение позволит контролировать различное состояние объектов и соответствующим образом обслужить операции обновления содержимого базы данных. Не будет необходимости явно вызывать методы сохранения – достаточно сообщить объекту о необходимости фиксации результатов работы отдельных методов в базе данных.Вся сложная логика фиксации сосредоточена в одном месте.
Если требуется загрузить данные из базы в оперативную память так, чтобы при загрузке требуемого объекта автоматически загружались и другие связанные с ним объекты (при этом объем загружаемых данных не должен быть чрезмерным), используется шаблон "Загрузка по требованию".
При загрузке связанных объектов процесс прерывается при достижении первоначально необходимого объема данных,но остается метка о важности загрузки последующих данных. Это позволит загрузить данные только тогда, когда они действительно потребуются.
Когда требуется гарантировать, что каждый объект будет загружен из базы данных только один раз, применяется шаблон "Количество объектов". Паттерн реализуется за счет создания специальной коллекции объектов, загруженных из базы данных в пределах одной транзакции.
При получении очередного запроса можно просмотреть эту коллекцию в поисках нужного объекта.Предотвращение повторных загрузок позволяет избежать ошибок и повышает производительность системы.
Шаблон "Множество записей" относится к одной из основополагающих "динамических" структур данных.Он имитирует табличную форму представления содержимого базы данных. "Множество записей" не приходится конструировать – как правило, существуют стандартные классы, реализующие этот шаблон данных.
Они удобны, поскольку предоставляют структуру данных, которая хранится в оперативной памяти и соответствует результату выполнения запроса к базе данных.В то же время эта структура данных может быть сгенерирована и использована другими частями системы.
В продолжение обсуждения "низкоуровневых" шаблонов, которые катализируют процесс разработки программного обеспечения за счет экономии ресурсов на повторном использовании наиболее эффективных программных элементов, следует затронуть следующий паттерн–"Шлюз записи данных".
Этот шаблон обеспечивает взаимодействие компонентов слоев бизнес-представления со слоями базы данных. Для его создания следует инкапсулировать код реализации компонента от кода бизнес-логики. Реализация этого шаблона заключается в копировании структуры записей в отдельном программном классе. Для каждой записи, возвращаемой запросом к базе данных, создается экземпляр шлюза.
Бизнес-алгоритмы, автоматизируемые в современных корпоративных информационных системах, с технической точки зрения представляют собой достаточно высокоуровневую логику исполнения и принятия решений. Это приводит к тому, что "бизнес-транзакции" содержат в себе ряд системных транзакций.
Несоответствие понятий бизнес- и системных транзакций влечет за собой необходимость привлечения на каждом из уровней декомпозиции дополнительных объектов. Цель новых элементов – обеспечить согласованный переход к требуемому уровню представления или автоматизации бизнес-процесса.
Шаблон "Оптимистическая автономная блокировка" позволяет минимизировать негативное влияние несогласованности записей при использовании базы данных в автоматизируемых бизнес-процессах.
Попытка доступа нескольких обращений базы данных к одним и тем же записям грозит нарушением целостности данных и, кроме того, может привести к утрате внесенных изменений.
Проверка изменений, проведенных одним сеансом,конфликтует с изменениями, проведенными другим сеансом.Например, сверяется номер версии записи, сохраненной вместе с состоянием сеанса и с текущим номером версии этой же записи в базе данных. Если проверка прошла успешно, то изменяемые записи блокируются и изменения фиксируются в базе данных. Проверка и фиксация осуществляются в рамках одной системной транзакции, данные останутся согласованными. Срок действия "Оптимистической автономной блокировки" ограничивается системной транзакцией, в процессе которого она была установлена.
Шаблон "Оптимистическая автономная блокировка"решает задачу фиксации результатов, выполненной одним пользователем за период жизнедеятельности конкретной бизнес- или системной транзакции.
Ее использование не оправдано в случаях, когда необходимо поддержать многопользовательскую работу над одним участком данных.
Для предотвращения описанного конфликта применяется шаблон "Пессимистическая автономная блокировка", которая "накладывается" на данные прежде, чем бизнес-транзакция начинает с ними работать.Это обеспечивает завершение транзакции без негативных последствий из-за множества параллельных сеансов.
"Пессимистическая автономная блокировка" должна применяться в том случае, когда велика вероятность конфликта.
Этот способ организации блокировок не подходит для системных компонентов, в которых необходима возможность одновременной работы с данными из нескольких подключений.
При переходе от результатов выполнения загрузки данных к переменным программы приходится выполнять определенные преобразования, которые приводят к усложнению и разрастанию программных объектов.
Задачу изолирования модели предметной области от данных, с возложением на промежуточный слой всей полноты ответственности за отображение объектов домена в таблицы базы данных, выполняет шаблон "Преобразователь данных". Он обслуживает все операции загрузки и сохранения информации, инициируемые бизнес-логикой, и позволяет независимо модернизировать как программные компоненты, так и сущности базы данных.
Этот шаблон позволяет полностью изолировать бизнес-логику от операций преобразования данных.
При реализации логики взаимодействия между пользователем и программой есть несколько системных шаблонов, применение которых позволит избежать ряда проблем, связанных с сохранением данных, в процессе работы пользователя.
Первый вариант –шаблон "Сохранение данных на стороне клиента". Данная реализация предусматривает передачу всех сведений о завершаемом сеансе от сервера к клиенту вместе с каждым запросом. Никаких данных о состоянии сеанса на сервере храниться не должно. Если есть необходимость хранения числового идентификатора сеанса, то альтернативы данному паттерну не существует.
Можно использовать серверные объекты без состояний, что обеспечивает большую степень отказоустойчивости.Возникают проблемы безопасности при передаче данных от клиента серверу –их приходится шифровать. Затруднительно использовать данный паттерн при большом объеме информации о сеансе.
В противоположность шаблону "Сохранение данных сеанса на стороне клиента" используется паттерн "Сохранение сеанса на стороне сервера".
В этом случае реализации на "клиенте" хранится только идентификатор сеанса, а все данные о сеансе хранятся сервером. Для реализации данного шаблона требуются значительные ресурсы сервера, масштабируемые по числу пользователей информационной системы.
В этой главе мы рассмотрели основной, но наиболее сложный вид паттернов – архитектурные шаблоны проектирования.
Этот вид шаблонов несет на себе обязанность предопределения логики выполнения реализованных на их основе программных приложений и управление их последующим выполнением.
Некоторые из рассмотренных шаблонов (структурные шаблоны) достаточно абстрактны, не имеют ясных и понятных признаков, которые могут однозначно их характеризовать, предписывая концептуальные принципы реализации информационных систем.
Другие (шаблоны управления) должны иметь в виде воплощения специализированные компоненты. Шаблоны взаимодействия, в противовес структурным и управленческим паттернам, предписывают обязательные правила реализации специализированных компонентов.
В заключение необходимо отметить, что успешное изучение предложенных типов шаблонов позволит свободно ориентироваться при проектировании информационных приложений, отталкиваясь от определенных условий и требований к их реализации.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.