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

На правах рукописи

003177БЙЬ

Нгуен Хоанг Шинь

МЕТОДЫ И МОДЕЛИ ПРОЕКТИРОВАНИЯ БИЗНЕС-ПРИЛОЖЕНИЙ В АРХИТЕКТУРЕ «КЛИЕНТ-СЕРВЕР» (ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД)

Специальность 05 13 06- Автоматизация и управление технологическими процессами и производствами (промышленность)

АВТОРЕФЕРАТ

Диссертации на соискание ученой степени кандидата технических наук

2 7 ДЕК 2007

Санкт-Петербург - 2007

003177658

Работа выполнена в Санкт-Петербургском государственном электротехническом университете «ЛЭТИ» им В И Ульянова (Ленина)

Научный руководитель -

кандидат технических наук, доцент Щеховцов О И

Официальные оппоненты -

доктор технических наук, профессор Водяхо А И кандидат технических наук, доцент Шифрин Б М

Ведущая организация - Северо-Западный Государственный Заочный

Технический Университет, г Санкт-Петербург

дании диссертационного совета д ¿¡ггзхи/ ианкт-петероургского государственного электротехнического университета «ЛЭТИ» им В И Ульянова (Ленина) по адресу 197376, Санкт-Петербург, ул Проф Попова, 5

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

Защита диссертации состоится

часов на засе-

Автореферат разослан «

с2007 г

Ученый секретарь диссертационного совета

Цехановский В В

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ Актуальность исследований

В работах научно-исследовательской группы (Научные руководители проф Советов Ь Я и Шеховцов О И ) была предложена концептуальная схема банка формализованных задач БФЗ организации ресурсов АСУ, обеспечивающая реализацию свойства гибкости, адаптивности к изменяющимся условиям внешней экономической и внутренней производственной обстановки

Актуальность темы диссертационного исследования связана с развитием АРМовой технологии построения АСУ В данной технологии автоматизированное рабочее место управленческих работников АРМ рассматривалось как «толстый» клиент в двухуровневой архитектуре «клиент - сервер», модельным представлением которого является композиция двух компонентов модели проблемно-независимого АРМ и модели проблемно-зависимого АРМ с организацией ресурсов в виде банка формализованных задач

Цель диссертационнои работы

Целью настоящего исследования является анализ и разработка моделей и методов развития и реализации БФЗ в объектно-ориентированной технологии в трех или многозвенной архитектуре «клиент - сервер»

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

Методы исследовании

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

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

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

1 Подход к представлению конкретных управленческих задач в виде совокупности простых, рассматриваемых как типовые задач Для этих задач в соответствии с концепцией БФЗ известны методы их решения особенность данного подхода состоит в том, что при декомпозиции управленческих задач возникают точки принятия решений, что не предусмотрено классическим подходом

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

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

отвечает условиям развития системы и простоты ее сопровождения

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

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

Апробация работы Предлагаемые решения и результаты диссертационной работы докладывались и обсуждались на научно-технических конференциях Санкт-Петербургского государственного электротехнического университета, Санкт-Петербург, 2006-2007 г

Научные положения, выносимые на защиту

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

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

Публикации. По теме диссертации опубликованы 2 научные статьи (одна статья опубликована в ведущих рецензируемых научных журналах и изданиях, определенных ВАК)

Структура и объем диссертации Диссертационная работа состоит из введения, четырех глав с выводами, заключения, списка литературы, включающего 108 наименований Основная часть работы изложена на 103 страницах машинописного текста Работа содержит 44 рисунка и 2 таблицы

ОСНОВНОЕ СОДЕРЖАНИЕ РАБОТЫ

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

В первой главе представлен организация ГИАРМ_УР (Гибких Автоматизированных Рабочих Мест), модель двухуровневый АРМ -УР, и типовая задача

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

entensive) к приложениям, работающим по запросу (event driven), или приложениям, ориентированным на обработку процессов (process oriented) Исходя из изложенного дается такое определение приложению программный модуль, адаптированный к работе в распределенной среде, имеющий четко оределенные потребтельские свойства и интерфейсы с другими модулями

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

• Задачи проблемной ориентации ПЗ РАМ при разработке информационно-управляющей системы,

• Задачи развития ПЗ АРМ, его адаптации к изменению производственной обстановки под действием внешних и внутренних факторов экономического, технологического и др характера

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

В соответствии с требованиями динамичной внешней экономической и внутренней производственной среды предприятия АРМ-УР также должны обладать возможностью отслеживать возникающие изменения и оперативно настраиваться на эти изменения Мы будем рассматривать его как гибкий АРМ

Свойство АРМ УР оперативно и адекватно изменяющимся производственным условиям обеспечивать настройку АРМ па эти изменяющиеся условия, включая и изменения самого УР назовем гибкостью Для реализации свойства гибкости в (Ш) предложена следующая модель ГИАРМ

МГИАРМ =< 2 - х уровневая организация ГИАРМ, банк формализованных задач (БФЗ) > 2-х уровневая организация ГИАРМ представпена следующей структурой

ГИ АРМ - УР

где

КП-ПЗ - конечный пользователь - проектирование задач, КАИР - контур автоматизированного проектирования ,

ИСПЗ - инструментальная система проектирования задач (инструментальная среда разработки),

ИСРЗ - инструментальная среда решения функциональных (прикладных) задач пользователя,

КРФЗ - контур решения функциональных (управленческих), задач МВ - модуль взаимодействия,

КП-УР - конечный пользователь - управленческий работник

В такой структуре ресурсы, с помощью которых управленческий работник реализует свои функции, организуются в виде Банка формализованных задач (БФЗ)

Формально БФЗ описывается следующей структурой

БФЗ => < {СТЗ}, {ММ}, {А}, П(КЗ-ТЗ), П(ТЗ-ММ), П(ММ-А) > Где

СТЗ - семейство типовых задач

ММ - множество математических методов решения задач А - множество алгоритмов, реализующих математические методы П(КЗ-ТЗ) - соответствие между конкретной задачей и типовой

СТЗ все множество задач, которые могут решаться в рамках АРМ, объединенных в независимые семейства типовых задач

Типовая задача (ТЗ): Представляет собой содержательно сформулированную проблему, отличается тем, что все ограничения, имеющиеся в задаче, соответствуют требованиям конкретного алгоритма Одной типовой задаче могут соответствовать несколько методов и, наоборот (гомоморфизм)

Интеграция ГИАРМ в многозвенную архитектуру «клиент-сервер»

Более рациональной является организация АИС с выделением Проблемно-независимой компоненты в специализированное приложение - одну из разновидностей ПО промежуточного слоя в трех или многозвенной архитектуре «клиент - сервер» , назначение которого состоит в обеспечении ресурсами решение двух задач

• Задачи проблемной ориентации ПЗ РАМ при разработке информационно-управляющей системы,

• Задачи развития ПЗ АРМ, его адаптации к изменению производственной обстановки под действием внешних и внутренних факторов экономического, технологического и др характера

При таком представлении архитектуры КИС каждый АРМ-УР рассматривается как «тотстый» клиент, на котором размещается логика представления и прикладная логика, ориентированная на решение задач из конкретной предметной области финансовой, планово-экономической или, например, бухгалтерской деятельности

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

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

Во второй главе рассмотрены сущность объектно-ориентированного подхода, унифицированный язык моделирования (ЦМЬ), шаблоны (паттерны) проектирования,

значение паттернов проектирования для организации и развития ГИАРМ-УР

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

Концептуальной основой объектно-ориентированного подхода является объектная модель Основными все элементами являются

• абстрагирование (abstraction),

• инкапсуляция (encapsulation),

• модульность (modularity),

• иерархия (hierarchy)

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

• типизация (typing),

• параллелизм (concurrency),

• устойчивость (persistence)

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

L Название шаблона — это то, что мы можем использовать для описания проектной задачи, ее решений и последствий в одном двух словах Именование шаблона сразу же увеличивает наш проектный словарь Оно позволяет нам проектировать на более высоком уровне абстракции Наличие словаря для шаблонов позволяет говорить о них с коллегами, в проектной документации и даже с самими собой Это облегчает обдумывание проектов и сообщение другим о них и их оптимальных вариантах

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

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

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

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

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

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

В третьей главе

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

<{ФЗ}, {ТЗ}, {М}, {А}, г{ФЗ-ТЗ}, г{ТЗ-М}, г {М-А}>, а схема решения конкретной функциональной задачи с использование БФЗ г(ТЗ-М) г(ТЗ-М) г {М-А>

1 1 ;

ФЗ-► ТЗ —► М —Т-»А —► Решение

1

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

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

решения задачи с использованием классического объектно - ориентированного подхода

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

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

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

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

Мотивация

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

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

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

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

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

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

Клиент Посредник ManagerQ типовая задача

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

Участники

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

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

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

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

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

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

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

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

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

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

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

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

Проблема

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

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

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

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

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

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

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

Ограничения

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

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

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

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

Клиент типовая задача 0 фасад

Метод 1

Метод 2

Метод 3

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

Участники

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Структура

Клиент 0 -^

+Методинтерфеис()

Алгоритм 1

+АлгоритмИнтерфеис О

>- Стратеги алгоритм

*

+АлгоритмИнтерфеис 0

£

Алгоритм 2

♦АлгоритмИнтерфеис О

Алгоритм 3

+АпгоритмИнтерфейс ()

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

Участники

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

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

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

рис 6

Клиент ----> Посредник Мападег() типовая задача

Стратеги йлеоритм

♦АлгоритмИитерфеис (]

>АлгоритмИктерфеие ()

Алгоритм 2

+АлгоритмИкгерфеис ()

+АлгоришИнтерфеис ()

Рис 6 Схема решения с применением шаблоны В четвертой главе представлены применение шаблонов проектирования для

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

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

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

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

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

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

Структура

Учет сырья

^Алгоритм Интерфейс ()

Учет сырья с ВО

^Алгоритм Интерфейс ()

Учет ПП в тепле

+АлгоритмИнтерфеис ()

в электроэнергии

* А пгпр итм Интерфейс ()

в конденсата

+АлгоритмИитерфеис ()

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

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

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

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

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

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

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

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

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

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

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

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

Посредник Manag ег() типовая задача

+АлгоритмИнтерфеис ()

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

ПУБЛИКАЦИИ ПО ТЕМЕ ДИССЕРТАЦИИ

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

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

Подписано в печать 22 И 07 Формат 60*84 1/16 Бумага офсетная Печать офсетная Печ л 1,0 Тираж 100 экз Заказ 134

Отпечатано с готового оригинал-макета в типографии Издательства СПбГЭТУ "ЛЭТИ"

Издательство СПбГЭТУ "ЛЭТИ" 197376, С -Петербург, ул Проф Попова, 5

СПИСОК СОКРАЩЕНИЙ.

ВВЕДЕНИЕ.

Глава 1.

ИССЛЕДОВАНИЕ ПРИНЦИПОВ ОРГАНИЗАЦИИ АВТОМАТИЗИРОВАННЫХ РАБОЧИХ МЕСТ (АРМ) В ТЕХНОЛОГИИ МНОГОУРОВНЕВЫХ КЛИЕНТ-СЕРВЕР СИСТЕМ.

1.1 Обзор организации АРМ (Автоматизированное Рабочее Место).

1.1.1 Сущность АРМ.'.

1.1.2 Организация ГИАРМУР (Гибких Автоматизированных Рабочих Мест).

1.2 Проблема типизации и направления ее решения.

1.3 Структура автоматизированного рабочего места управленческого работника (АРМ-УР).

1.3.1 Модели деятельности управленческих работников.

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

1.3.3 Автоматизация управленческой деятельности.

1.4 Архитектура АРМ-УР.

1.5 Архитектура клиент-сервер.

1.6. Модель двухуровневый АРМ -УР.

1.6.1 Модель MDA.

1.6.2. Создание виртуальной машины.

1.7 АРМ-УР как «толстый клиент» в двухуровневой архитектуре «Клиент-Сервер».

1.8 Интеграция ГИАРМ в многозвенную архитектуру «клиент-сервер».30 Выводы по первой главе.

Глава 2.

ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ С ПРИМЕНЕНИЕМ ПАТТЕРНОВ ПРОЕКТИРОВАНИЯ.

2.1 Сущность объектно-ориентированного подхода.

2.2 Объектно-ориентированный анализ и проектирование.

2.2.1 Что такое анализ и проектирование?.

2.2.2 Объектно-ориентированный анализ.

2.2.3 Процесс объектно-ориентированного проектирования.

2.4 Унифицированный язык моделирования - UML.

2.5 Шаблоны ( паттерны) проектирования.

2.5.1 Описание Проектных Шаблонов.

2.5.2 Классификация шаблонов проектирования.

2.5.3 Как проектные шаблоны решают проектные задачи.

2.5.4 Механизм повторного использования.

2.5.5 Соотношение структур времени компиляции и времени выполнения

2.5.6 Применение паттернов при разработке приложений.

2.5.7 Значение паттернов проектирования для организации и развития ГИАРМ-УР.

Выводы по второй главе.

Глава 3.

КОМПОНЕНТЫ БФЗ И ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ.

3.1 Применение объектно-ориентированного подхода к организации функциональных ресурсов в виде БФЗ.

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

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

3.3.2 Паттерн Фасад (Facade).

3.2.3 Паттерн Стратегия (strategy).

Выводы по третьей главе.

Глава 4.

ПРИМЕНЕНИЕ ШАБЛОНОВ ПРОЕКТИРОВАНИЯ ДЛЯ КОНКРЕТНОГО

В работах научно-исследовательской группы (Научные руководители проф. Советов Б .Я. и позднее Шеховцов О.И.) была предложена концептуальная схема Банка формализованных задач БФЗ организации ресурсов АСУ, обеспечивающая реализацию свойства гибкости, настраиваете на изменяющиеся условия внешней экономической и внутренней производственной обстановки. Развитие АРМовой технологии построения автоматизированных систем позволило рассматривать АРМ-автоматизированное рабочее место управленческих работников как толстый клиент в двухуровневой архитектуре «клиент - сервер», модельное представление которого рассматривается как композиция двух компонентов: модели проблемно-независимого АРМ и модели проблемно-зависимого АРМ.

Целью настоящего исследования является анализ и разработка моделей и методов развития и реализации БФЗ в объектно -ориентированной технологии в трех или многозвенной архитектуре «клиент - сервер».

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

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

В четвертой глава рассматривается приложением разработанных методов и моделей для решения конкретной задачи планирования себестоимости продукции для непрерывного химического производства

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

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

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

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

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

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

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

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

ВЫВОДЫ ПО ГЛАВЕ

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

1. Алан Шаллоуей, Джеймс Тротт. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию"/ Алан Шаллоуей, Джеймс Трот //Публикована Питер 2003.

2. Архитектура клиент-сервер: определение, предпосылки для применения, плюсы и минусы. http://belani.narod.ru/l/Lklser2.htm.

3. Аппак, М.А. Автоматизированные рабочие места на основе персональных ЭВМ/ М.А. Аппак М// 'Радио и связь', 1989 г.

4. Автоматизированное рабочее место в системе управления предприятием. Сборник научных трудов, //Ленинград, 1989г.

5. Артемьев, В.И. Обзор способов и средств построения информационных приложений/ В.И. Артемьев // http://lib.csu.ru/dl/bases/prg/dbms/1996/05/source/52.html.

6. Артем Кондратьев Своими силами: управление процессом разработки ПО небольшой командой специалистов/ Артем Кондратьев // www.citforum.ru/SE/project/selfmade/.

7. Александра Гнатуш. CASE-технологии: что, когда, как? http://www.citforum.ru/programming/case/gnatush/case/.

8. Буздин К.В. Исполнение моделей при помощи виртуальной машины. Труды Института Системного Программирования РАН, 2004 г. http://ooad.asf.ru/standarts/uml/UMLMDA/ListO 1 .asp.

9. Н.Гради Буч. Объектно-ориентированный анализ и проектирование: с примерами приложений на С++. "Издательство Бином", "Невский диалект", 1998, 560 е., ил.

10. Горин С.В., Тандоев А.Ю. Применение CASE-средства ERWin 2.0 для информационного моделирования в системах обработки данных // СУБД. 1995. - № 3.

11. Дэвид С. Линтикам. Разгадка архитектуры клиент-сервер. PC Magazine, March 26, 1996, p. NE1. (С) CK Пресс 7/96.

12. Индриков В.А. Объектно-ориентированный подход и современные мониторы транзакций, http://www.citforum.ru/database/kbd97/14.shtml.

13. Иан Грэхем. Объектно-ориентированные методы принципы и практика. Третье издание-Публикована Вильяме - Москва Санкт-Петербург Киев -2004.

14. Кузнецов М.Б. Трансформация UML-моделей и ее применение в технологии MDA. Института Системного Программирования РАН.

15. Крег Ларман. Применение UML и шаблонов проектирования введение в объектно-ориентированный анализ, проектирование и унифицированный процесс UP. Второе здание - Публикована Вильяме - Москва Санкт-Петербург Киев -2004 .

16. Казанцев Ю.Б. Автоматизированное рабочее место и перспективы его развития. Реферат- Московский Государственный Авиационный Институт- г Москва 1995 г.

17. Кантарь И.Л. "Автоматизированные рабочие места управленческого аппарата", Москва 1990г.

18. Калянов Г.Н. Case-Технологии: Консалтинг в автоматизации бизнес-процессов. 3-е издание. Горячая линия-Телеком Москва 2002.

19. Кондраков Н.П. Бухгалтерский учет. Учебное пособие. М.:ИНФРА-М, 1999.

20. Луговой В.А. Учет основных средств, нематериальных активов, долгосрочных инвестиций. М.: Финансы и статистика, 1995.

21. Леоненков А.В. Самоучитель UML СПБ-Петербург, 2002 -304 с.

22. Мартин Фаулер. Рефакторинг улучшение существующего кода. Публикована Питер 2003.

23. Мартин Фаулер и Кендалл Скотт . UML основы Второе здание. Публикована Вильяме - Москва Санкт-Петербург Киев -2004.

24. М.Б. Кузнецов Трансформация UML-моделей и ее применение в технологии MDA. http://www.citforum.ru/SE/project/umlmda/.

25. Нидлз Б., Андерсон X., Кондуэлл Д. Принципы бухгалтерского учета. М.: Финансы и статистика, 1994.

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

27. Орлик С. В. Многоуровневые модели в архитектуре клиент-сервер. http://ods.com.ua/win/rus/db/kbd97/22.htm

28. Стелтинг, Маасен. Применение шаблонов Java. Библиотека профессионала. Москва 2002, Издательский дом "Вильяме".

29. Ческис В. JT. Динамическое формирование объектов. Опубликовано в журнале «Программист» № 10/2002: http://www.codenet.ru/progr/bcb/create-object.php

30. Шеховцов О.И. Методология автоматизированного проектирования интегрированных систем управления Текст.: учеб. пособие / О.И. Шеховцов; ЛЭТИ им. В.И.Ульянова (Ленина). Л.: ЛЭТИ, 1987. - 73 с.: ил. - (в пер.) : 0.15 р. Библиогр.: с.72.

31. Шеховцов О.И. Советов Б.Я. Проблемы типизации в автоматизированном проектировании АСУ Текст. / Известия:. / Б.Я.Советов. 1996. - Вып. 490: Системы обработки информации и управления / Редкол.: (гл. ред.) и др. - С. 15-18. - ISBN 5-76290083-5.

32. Шураков В.В. "Автоматизированное рабочее место для статической обработки данных", 1990г.

33. Салли Шлеер и Стефана Меллора. Объектно-ориентированный анализ: моделирование мира в состояниях.

34. Ф. Бернштейн Middleware: модель сервисов распределенной системы. http://www.osp.ru/dbms/1997/02/4 lprint.htm#partl.

35. Ольга Д.И. Обзор паттернов проектирования, http://www.citforum.ru.

36. Э.Гамма Р.Хелм Р.Джонсон Дж.Влиссидес. Приемы объектно-ориентированного проектирования паттерны проектирования. Публикована Питер 2004.

37. A. Campbell, G. Coulson, and М. Kounavis. "Managing Complexity: Middleware Explained." IT Professional,

38. A J H Simons Object-oriented analysis and design. Department of Computer Science -University of Sheffield.

39. A Rational Approach to Software Development Using Rational Rose 4.0 http://www.rational.com/support/techpapers/roseapproach/. 1997.

40. Booch G., Rumbaugh J. UML 1.1 Semantics, (http://www.rational.com/uml/) 1997.

41. Booch G., Rumbaugh J.UML 1.1 Notation Guide (http://www.rational.com/uml/) 1997.

42. B.P. Douglass Real-Time UML. Developing Efficient Objects for Embedded Systems: Addison-Wesley Publishing Co., 1998, 365 p.

43. Barker R. CASE Method. Entity-Relationship Modeling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.

44. Communications, Elsevier Science, 21:4, April, 1998.

45. D. Schmidt, D. Levine, and S. Mungee. "The Design of the TAO Real-Time Object Request Broker." Computer.

46. Floyd Marinescu EJB-Design patterns. John Wiley- Son publishing New York- Toronto-Singapore -2002.

47. G. Booch, Jim Rumbaugh, Ivar Jacobson The Unified Modeling Language User Guide: Addison-Wesley Publishing Co., 1999, 512 p.

48. G. Booch The Visual Modeling of Software Architecture for the Enterprise. Rose Architect. October 1998, Vol. 1, No 1. p 18-25.

49. Ivar Jacobson, G. Booch, Jim Rumbaugh The Unified Software Development Process: Addison-Wesley Publishing Co., 1999, 512 p.

50. IEEE Computer Society, 1:5, September/October 1999, 22-28.

51. J. Zinky, D. Bakken, and R. Schantz. "Architectural Support for Quality of Service for CORBA Objects", Theory and Practice of Object Systems, 3:1, April 1997.

52. Jesse Liberty Programming C#. Publisher: O'Reilly. First Edition July 2001. ISBN: 0596-00117-7,680 pages.

53. Jim Rumbaugh, Ivar Jacobson, G. Booch Unified Modeling Language Reference Manual: Addison-Wesley Publishing Co., 1999, 576 p.

54. Jacobson I. Object-Oriented Software Engineering. A Use Case Driven Approach. Addi-son-Wesley Publishing Company, 1993.

55. James W. Cooper. Introduction to Design Patterns in C#. Copyright © 2002 by IBM T J Watson Research. Center February 1, 2002

56. P. Bernstein. "Middleware: A Model for Distributed System Services." Communications of the ACM, 39:2, February 1996, 86-98.

57. Rumbaugh J., Blacha M. Premerlani W., Eddy F. Lorensen W. Object-Oriented Modeling and Design. Prentice-Hall, Inc., 1991.

58. P. Verissimo and L. Rodrigues. Distributed Systems for System Architects, Kluwer Academic Press, 2001.

59. SherifM. Yacoub, HanyH. Ammar Pattern-Oriented Analysis and Design: Composing Patterns to Design Software Systems. Publisher Addison Wesley -2003.

60. Yourdon E. Modern Structured Analysis. Prentice-Hall, 1989.

61. Viraj N. B. A middleware architecture for integrating services on the grid. A thesis submitted to theGraduate School—New Brunswick. New Brunswick, New Jersey May, 2003.

62. User's Guide for- Microsoft® Visio® 2000 © 2000 Visio Corporation. All rights reserved.