Методы и модели проектирования бизнес-приложений в архитектуре "клиент-сервер" (объектно-ориентированный подход)

* абстрагирование (abstraction);

* инкапсуляция (encapsulation);

* модульность (modularity);

* иерархия (hierarchy).

Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:

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

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

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

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

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

В третьей главе. В первой главе было показано, что при решении проблем интеграции автоматизированных систем управления (АСУ) обладающих свойством развития, адаптации к изменениям внешней и внутренней производственной обстановки, для расшивки жесткости пакетов прикладных программ (ППП) была предложена концепция и базирующаяся на ней архитектура организации функциональных ресурсов АСУ, названная банком формализованных задач БФЗ. Если ППП строились по схеме <Функциональная задача - Алгоритм (процедура) решения>,то БФЗ - по схеме <Типовая задача - метод решения - алгоритм, реализующий метол>. На множествах «типовая задача», «математический метод» и «реализующий алгоритм» определяются соответствия (взаимосвязи) {Типовая задача - метод решения}и {метод решения - реализующий алгоритм}. В данной архитектуре типовая задача рассматривается как задача, всегда имеющая решение (математический метод и алгоритм) и определяет «семейство типовой задачи » - множество функциональных задач, решение которых может быть получено на основе решения данной типовой задачи. Таким образом, полная формальная запись БФЗ может быть представлена следующим образом:

<{ФЗ}, {ТЗ}, {М}, {А}, r{ФЗ-ТЗ}, r{ТЗ-М}, r {М-А}>,

а схема решения конкретной функциональной задачи с использование БФЗ:

Рис. 1. схема решения конкретной функциональной задачи

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

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

Рис. 2. Схема решения задачи

Перейдем к рассмотрению решения данной задачи с применением паттернов проектирования.

Применение паттерна посредник (mediator)

Назначение

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

Мотивация

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

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

Применимость

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

поведение, распределенное между несколькими классами, должно поддаваться настройке без порождения множества подклассов.

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

Структура

Рис. 3. Решение с применением шаблона Посредник

Участники

- класс посредник это абстрактный класс - определяет интерфейс для обмена информацией с объектами типовой задачи;

- конкретные классы типовая задача 1, типовая задача 2, …

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

Применение паттерна Фасад (Facade)

Назначение

Шаблона фасад (facade) определяется следующим образом. Предоставление единого интерфейса для набора различных интерфейсов в системе. Шаблон Фасад определяет интерфейс более высокого уровня, что упрощает работу с системой.

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

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

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

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

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

Применение шаблона Фасад к проблеме БФЗ

Контекст

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

Проблема

В архитектуре БФЗ возникают непосредственные многочисленные взаимосвязи и взаимодействия между множеством типовых задач и методами их решения, вызывающие следующие проблемы:

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

* Слишком большое количество вызовов методов между клиентом (задачами) и алгоритмом.

При предоставлении методов клиенту, он должен понимать и нести ответственность за объектные взаимосвязи методов и должен быть способен контролировать последовательность алгоритмов.

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

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

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

Ограничения

* Обеспечить более простой интерфейс для клиентов посредством сокрытия всех сложных взаимодействий между методами.

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

* Обеспечить унифицированный уровень служб для отделения реализации типовой задачи от методов.

Решение: применение паттерна Фасад абстрагирует взаимодействия методов и обеспечивает уровень служб, предоставляющий только необходимые интерфейсы. Таким образом, он скрывает со стороны клиента сложные взаимодействия между участниками этих взаимодействий.

Структура

Рис. 4: Решение с применением шаблон Фасад

Участники

класс фасад это абстрактный класс:

- «знает», каким классам подсистемы адресовать запрос;

- делегирует запросы клиентов подходящим объектам внутри подсистем.

конкретные классы типовая метод 1, метод 2, метод 3:

- реализуют функциональность подсистемы;

- выполняют работу, порученную объектом Фасад.

Перейдем к анализу возможностей применения Паттерна Стратегия (strategy)

Данный паттерн определяет семейство алгоритмов, инкапсулирует каждый из них и делает их взаимозаменяемыми. Стратегия позволяет изменять алгоритмы независимо от клиентов, которые ими пользуются. Известен также под именем Policy (политика).

Применимость

Паттерн стратегия используется, когда:

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

- необходимо иметь несколько разных вариантов алгоритма. Например, можно определить два варианта алгоритма, один из которых требует больше времени, а другой - больше памяти. Стратегии разрешается применять, когда варианты алгоритмов реализованы в виде иерархии классов;

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

- в классе определено много поведений, что представлено разветвленными условными операторами. В этом случае проще перенести код из ветвей в отдельные классы стратегий.

Применение шаблона Стратегия к проблеме БФЗ

При обычном объектно-ориентированном подходе к организации БФЗ могут возникать все выше рассмотренные проблемы при организации связей между методами и реализующими их алгоритмами.

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

Структура

Рис. 5: Решение с применением шаблон Стратегии

Участники

- стратегия алгоритм: объявляет общий для всех поддерживаемых алгоритмов интерфейс.

- алгортм1, алгоритм2, алгоритм3 - конкретная стратегия: реализует алгоритм, использующий интерфейс, объявленный в классе стратегии;

После применения паттернов проектирования, мы получим результат показано на рис. 6.

Рис. 6. Схема решения с применением шаблоны

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

Рис. 7. Схема расчет себестоимости основной продукции

Применение шаблонов проектирования для моделирования БФЗ

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

Применение паттерн Посредник (Меdiator).

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

Структура

Рис. 8. Схема решения с применением шаблоны Посредник

На рис. 8. представлены:

- класс посредник это абстрактный класс - определяет интерфейс для обмена информацией с объектами типовой задачи;

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

Применение шаблона Фасад

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

На рисунке показана диаграмма классов, представляющих применение паттерна метод фасад (Method Faсade).

Рис. 9. Схема решения с применением шаблоны Фасад

- класс Фасад это абстрактный класс - определяет интерфейс для обмена информацией с объектами типовой задачи;

- конкретные классы метод1, метод2, метод3, метод4, методРС, методНИ, методСС, методУО, метод коденсат. - конкретные класс.

Применение шаблон Стратегия

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

Рис. 10. Решение с применением шаблоны Стратегии

Рис. 11. Общая схема решения с применением шаблоны

Заключение

В результате проведенных исследований в диссертационной работе получены следующие результаты:

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

2. Предложена модель интеграции ГИАРМ-УР в архитектуру «клиент - сервер», отличающаяся тем, что проблемно-независимый АРМ размещается в ПО промежуточного слоя как специализированный сервер проблемной ориентации и развития

3. Предложена модель организации БФЗ с паттернами проектирования, отличающаяся как номенклатерой паттернов, так и их взаимосвязями с компонентами БФЗ.

Таким образом на защиту выносятся следующие положения:

1. Выделение и реализацию проблемно - независимого АРМ в виде специализированного сервера приложений в многозвенной архитектуре «клиент - сервер».

2. Организацию функциональных ресурсов этого сервера на основе БФЗ строить с применением паттернов проектирования в объектно - ориентированной технологии.

Публикации по теме диссертации

1. Нгуен Хоанг Шинь. Применение шаблонов проектирования в АРМ РАО (Расчет амортизация оборудования) [Текст]/ Нгуен Хоанг Шинь, О.И. Шеховцов // Изв. СПб ГЭТУ “ЛЭТИ” (Известия Государственного электротехнического университета). Сер. Информатика, управление и компьютерные технологии 2007. Вып. 3. С.72-76.

2. Нгуен Хоанг Шинь. Применение шаблонов проектирования в АРМ ОГЭ [Текст]/ Нгуен Хоанг Шинь, О.И. Шеховцов// Журнал Техника и Технология № 4 2006 г. - ISSN 1811-3532- С.45-51.

Размещено на Allbest.ru