Построение системы поддержки регламентов на базе языка запросов GSQL тема диссертации и автореферата по ВАК РФ 05.13.11, кандидат технических наук Потапов, Кирилл Борисович

• Потапов, Кирилл Борисович
• кандидат технических наук
• 2013

Оглавление диссертации кандидат технических наук Потапов, Кирилл Борисович

Содержание

Введение

Глава 1. Обзор подходов к построению регламентов

1.1. Регламент и основы его создания

1.2. Использование систем планирования ресурсов для автоматизации создания регламентов

1.3. Бизнес-процессы как основа регламентов

1.4. Обзор методологий и средств моделирования бизнес-процессов

1.5. Сравнение средств моделирования бизнес-процессов

Выводы по главе 1

Глава 2. Основные принципы и методы создания регламентов с помощью системы бизнес-моделирования

2.1. Обобщенное представление о системах бизес-моделирования

2.2. Расширение обобщенного представления до системы поддержки регламентов

2.3. Использование методологий ARIS для описания регламентов

2.4. Доработка среды ARIS до системы поддержки регламентов

2.5. Варианты реализации механизма доступа к данным

Выводы по главе 2

Глава 3. Язык запросов GSQL для системы поддержки регламентов

3.1. Назначение и возможности языка GSQL

3.2. Основные идеи языка GSQL

3.3. Базовые конструкции GSQL

3.4. Реализация GSQL как дополнения к языку SQL

3.5. Реализация GSQL в качестве самостоятельного языка

Выводы по главе 3

Глава 4. Проектирование системы поддержки регламентов

4.1. Общий случай проектирования системы поддержки регламентов

4.2. Архитектура подсистемы поддержки регламентов

4.3. Проектирование GSQL-сервера

4.4. Разработка и формирование отчетов

Выводы по главе 4

Глава 5. Реализация системы поддержки регламентов

5.1. Описание разработанной подсистемы

5.2. Выбор технологий реализации

5.3. Устройство системы стендовых испытаний

5.4. Результаты разработки

5.5. Апробация и внедрение

5.6. Перспективы дальнейших исследований

Выводы по главе 5

Заключение

Список литературы

Обозначения и сокращения

Введение диссертации (часть автореферата) на тему «Построение системы поддержки регламентов на базе языка запросов GSQL»

Введение

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

Актуальность темы диссертации

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

В последнее время, однако, потребности в автоматизации возросли, требуя внедрения развитых, высококачественных и всеобъемлющих систем поддержки принятия управленческих решений, иначе говоря - систем поддержки управления бизнес-процессами (регламентами). С данной задачей сталкивается любое достаточно крупное учреждение; в случае государственных организаций внимание к данной задаче также обусловлено постановлением правительства РФ № 679 от 11 ноября 2005 г. «О порядке разработки и утверждения административных регламентов исполнения государственных функций (предоставления государственных услуг)».

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

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

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

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

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

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

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

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

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

Озвученная выше научно-техническая задача и методы ее решения соответствуют пп. 9, 11, 12и 17 паспорта специальности 05.13.11 (п.9 - модели и методы разработки программных средств обработки данных и знаний в ВМ, ВК и КС, п. 11 - методы проектирования систем управления базами данных (СУБД) и базами знаний (СУБЗ), в том числе распределенными СУБД и СУБЗ, п. 12 - программные инструментальные средства разработки интеллектуальных систем, в том числе экспертных систем, систем поддержки принятия решений, обучающих систем и др., п. 17 - математическое и программное обеспечение новых информационных технологий).

Цели и задачи работы

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

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

В рамках данных целей, настоящая работа решает следующие задачи:

• исследование существующих подходов к описанию регламентов, а также систем бизнес-моделирования, использующих данные подходы;

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

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

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

Объект и предмет исследования

Объектом исследования являются системы бизнес-моделирования, сетевая и реляционная модели представления данных, а также язык запросов для реляционных СУБД SQL.

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

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

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

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

Научная новизна

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

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

• рассмотрены принципы доработки обобщенного представления о средствах бизнес-моделирования до системы поддержки регламентов;

• разработан и описан специальный язык запросов для данных, организованных подобно графу, получивший название GSQL.

Учебно-методическая ценность

Учебно-методическая ценность диссертационной работы заключается в:

• разработке методов проектирования и построения системы поддержки регламентов в соответствие с технологией создания многокомпонентных систем, а также методологии описания регламентов на основе методологии ARIS;

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

Практическая значимость

Практическая значимость работы выражается в том, что:

• разработана и применена на практике методология описания регламентов;

• разработана реализация языка GSQL как самостоятельного языка запросов для средства бизнес-моделирования ARIS;

• спроектирована и реализована подсистема поддержки регламентов на базе средства бизнес-моделирования ARIS в рамках ОКР «Целостность».

Апробация работы

Результаты работы докладывались и обсуждались на следующих конференциях и семинарах: 1-й, 2-й и 3-й Школах молодых ученых ИЛИ РАН (Москва, 2010, 2011 и 2012 гг.), 12-ой международной научной конференции «Системы компьютерной математики и их приложения» (г. Смоленск, 2011 г.), 12-ой международной научно-технической конференции «Кибернетика и высокие технологии XXI века» (г. Воронеж, 2011 г.), 4-ом межведомственном научно-практическом семинаре «Системы и средства защиты информации» (г. Пенза, 2012 г.).

Кроме того, подсистема поддержки регламентов была апробирована в ходе внедрения в рамках ОКР «Целостность», что подтверждается соответствующим актом.

Публикации

Основные результаты диссертационной работы отражены в 8 публикациях. Из них в журналах, рекомендованных ВАК Минобрнауки РФ - 2 публикации.

Структура диссертации

Диссертация состоит из введения, пяти глав, заключения, списка литературы (39 наименований). Работа изложена на 185 страницах, включающих 37 рисунков, и 11 таблиц.

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

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

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

В четвертой главе рассматривается архитектура как системы поддержки регламентов вообще, так и подсистемы поддержки регламентов, реализованной на практике в рамках ОКР «Целостность».

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

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

Заключение диссертации по теме «Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей», Потапов, Кирилл Борисович

Выводы по главе 2

Основываясь на вышеизложенном, можно сделать вывод о необходимости использования ОМД-БМ при рассмотрении расширения систем бизнес-моделирования и разработке языка запросов на основе данной модели. Такой язык, получивший название GSQL, кроме того совместим с языком SQL, что позволяет легко использовать в разработке опыт, накопленный для реляционными СУБД и средств работы с ними. Также разработанный язык способен лечь в основу реализации дополнительных модулей, разработка которых будет необходимой как исходя из общих требований к СПР, так и пожеланий конкретного заказчика.

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

В главе были рассмотрены этапы доработки системы бизнес-моделирования до СПР, как в общем случае, так и в отношении ARIS. Данная доработка во многом основывается на реализации GSQL, и создание такой реализации можно считать ключевым ее этапом. Тем не менее, все прочие упомянутые этапы и компоненты также важны и существенны. Кроме использования ОБСД, при их выполнении следует также учитывать необходимость отдельной реализации контроля доступа для новых логических объектов системы.

Глава 3. Язык запросов GSQL для системы поддержки регламентов

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

3.1. Назначение и возможности языка GSQL

Реализация языка запросов необходима любой среде бизнес-моделирования, если ее планируется включать как часть в сложную систему. Таким образом, область применения и назначение предлагаемого языка следует ограничить манипуляцией данными, организованными в соответствие с ОМД-БМ с незначительными дополнениями, указанными ниже. Исходя из аналогии с SQL, язык возможно применять как для выборки, так и для добавления, удаления и модификации данных.

Прежде чем продолжать описание языка, следует дополнить требования к организации данных с точки зрения его потребностей. Для реализации GSQL в рамках ОМД-БМ необходимо: п/п Требование Описание требования

1 Наличие фиксированных списков атрибутов и связей Требуется наличие в системе наперед известных, фиксированных списков возможных атрибутов объектов и связей, имеющих в рамках своего списка уникальное имя и уникальный числовой идентификатор. Введение новых атрибутов возможно средствами системы, однако находится вне рамок языка. Использование С8С>Ь предполагает, что оба списка возможных атрибутов (объектов и связей) фиксированы и во время выполнения запросов остаются неизменными.

2 Необходимые атрибуты объектов Требуется наличие у объектов ряда атрибутов, которые могут быть реализованы виртуально, но логически должны присутствовать в системе. Список необходимых атрибутов представлен далее в подпунктах.

2.1 Атрибут идентификатора объекта Представляет собой уникальный идентификатор (не обязательно числовой) среди всех объектов базы данных. п/п Требование Описание требования

2.2 Атрибут метатипа объекта Указывает метатип, представимый как уникальной числовой константой, так и уникальным среди всех метатипов названием. Предполагается, что метатипами будут разделяться модели, элементы диаграмм, группы и т.п. Список метатипов фиксирован и не может изменяться.

2.3 Атрибут типа объекта Содержит тип объекта, также представимый как уникальным числовым идентификатором, так и уникальным среди всех типов названием. Предполагается, что тип разделяет объекты в рамках одного метатипа: например, должности, организационные единицы, работы и т.п. в рамках объектов диаграмм, или диаграммы организационной структуры, ЕРС-диаграммы и т.п. среди моделей.

3 Необходимый атрибут типа связи Требуется наличие аналогичного объекту атрибута типа и у связей также. В рамках данного пункта следует заметить, что кроме указанных, связи могут не иметь иных атрибутов (направление связи в список атрибутов не входит). В случае необходимости, в таких системах как АЮ8 можно считать связи объектами, «разрывающими», в свою очередь, стрелочки между объектами. п/п Требование Описание требования

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

Касательно предложенных атрибутов, однако, следует заметить, что необходимы они преимущественно для разделения объектов на диаграмме. Потому, кроме обязательного для всех объектов атрибута метатипа, у некоторых объектов и связей (например, каталогов и иерархических связей между ними) атрибуты типа могут отсутствовать (точнее, иметь пустое значение - NULL; список возможных атрибутов одинаков для всех объектов/связей).

Концепции, заложенные в язык, позволяют реализовать его в двух вариантах. Первый из них, реализация GSQL как отдельного языка, предназначается сугубо для систем с организацией данных соответственно ОМД-БД, т.е. преимущественно для средств бизнес моделирования. Вторая же состоит в интеграции ключевых конструкций языка в существующую реализацию SQL, с получением универсального языка запросов к базе данных, сочетающей в себе и реляционную модель, и ОМД-БМ. Также данный вариант позволяет использовать большинство дополнительных конструкций того или иного диалекта SQL для работы с ОМД-БМ.

По сути, оба варианта аналогичны. Первый представляет собой простое дополнение ключевых конструкций «минимальным набором» конструкций языка SQL для получения законченного языка выборки данных и манипулирования ими. Потому далее в начале будут описаны ключевые идеи и конструкции языка GSQL, затем рассмотрена их интеграция в SQL, и, наконец, описан один из «минимальных вариантов» реализации GSQL в качестве отдельного языка. При этом подразумевается, что при подобной реализации вполне допустимо брать за основу тот или иной диалект SQL и заменять в нем конструкции SQL ключевыми конструкциями GSQL для обеспечения работы с ОМД-БМ вместо реляционной модели.

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

3.2. Основные идеи языка GSQL

Как известно, источником данных в языке SQL является таблица, не обязательно физически реализованная. Это может быть таблица, построенная после соединения нескольких других таблиц, полученная в результате выполнения подзапроса, некое оптимизированное представление таблицы и т.п., но логически источником данных всегда является одна результирующая таблица с наперед известным количеством и типами столбцов и «прирастающими» в процессе выборки строками (поскольку речь идет о языке SQL, использование терминов реляционной модели представляется неуместным). Таблица эта определена в части FROM запроса на выборку данных, и все остальные части задают операции уже над ней - по крайней мере, логически. Например, в части WHERE производится фильтрация строк таблицы, в части GROUP BY задается их группировка строк и т.п.

Таким образом, если в результате выполнения определенного блока «новых» операций будет получаться таблица - этот блок возможно как легко интегрировать в SQL-запрос, подставив на место одной из таблиц части FROM и присвоив результату псевдоним для обращения в ходе традиционных операций SQL, так и полностью заменить конструкции указанной части запроса, получив новый язык без изменения прочих элементов исходного. Очевидно, сказанное в полной мере относится не только к части FROM, но и к аналогичным конструкциям - всем, где в SQL определяется таблица (как источник данных, как совокупность данных для модификации и т.п.).

Базовой идеей, позволяющей свести разрабатываемый язык к традиционному SQL, является разработка таких конструкций обращения к данным, организованным в соответствие с ОМД-БМ, что позволяют представить запрошенные данные в виде таблицы с учетом всех особенностей их организации. В число данных особенностей следует включить, во-первых, наличие связей между объектами, а во-вторых -возможность наличия заранее неизвестного количества «переходных узлов» между двумя объектами, когда путь от одного к другому проходит согласно связям через ряд промежуточных объектов. Также получаемая таблица, как и любая таблица SQL, должна обладать наперед (до начала собственно выборки данных) известным количеством столбцов вместе с полной информацией о них (как то тип данных), а результат выборки должен «прирастать» к таблице строками соответственно ее столбцам.

Теперь следует заметить, что требованию по наперед известным столбцам полностью соответствует требование к атрибутам объектов и связей. Таким образом, вполне очевидна идея табличного представления множества объектов, где атрибуты соответствуют столбцам таблицы, количество строк равно количеству объектов в множестве, а каждая строка содержит значения атрибутов одного объекта. Как и в SQL, взаимный порядок строк, вообще говоря, не определен, и при необходимости задается с помощью конструкции упорядочивания в запросе (часть ORDER BY). Проиллюстрировать сказанное призвана следующая таблица, соответствующая множеству из трех объектов (таблица 2).

Название Тип Продолжительность [Иные атрибуты.]

Анализ информации Работа 1 ч.

Инженер Должность [NULL]

Главный каталог Каталог [NULL] .

Список литературы диссертационного исследования кандидат технических наук Потапов, Кирилл Борисович, 2013 год

СПИСОК АТР

= —( Атрибут Q—

ВЫРАЖЕНИЕ

СПИСОКАТР

1

а

Рис. 32. Дополнение грамматики модификации и удаления данных при реализации GSQL в качестве самостоятельного языка

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

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

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

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

• строковая константа - последовательность любых символов в одинарных кавычках. Сами одинарные кавычки задаются двукратным своим повторением. Строковые константы регистрозависимы;

• числовая константа - последовательность английских букв и цифр, начинающаяся с цифры. Может содержать внутри себя одну точку и один символ плюса либо минуса после строчной либо прописной английской буквы «£>>;

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

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

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

Выводы по главе 3

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

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

должен дорабатываться в соответствие с практическими потребностями, которые можно выявить лишь непосредственной эксплуатацией и развитием системы. Во-вторых, опыт реляционных СУБД подсказывает необходимость процедурного расширения языка, каким для SQL стали PL/SQL, Transact SQL и др. Однако необходимо заметить, что за счет преемственности GSQL он интегрируется в эти самые расширения столь же легко и по тем же принципам, что и в базовый SQL. Таким образом, процедурное расширение GSQL, хотя и очевидно необходимо, не требует отдельного описания.

Глава 4. Проектирование системы поддержки регламентов

В начале данной главы описывается проектирование системы поддержки регламентов в ее общем виде на основе результатов предыдущих глав. Далее осуществляется переход к конкретному проекту - подсистеме поддержки регламентов, реализованному на практике в ходе одного из проектов, проводимых ИЛИ РАН. Для данной подсистемы описываются общие концепции, определявшие ее реализацию, а также архитектура разработки. В отдельных разделах рассматриваются вопросы проектирования С8С)Ь-сервера подсистемы и компоненты, отвечающей за возможность создания и выполнения отчетов.

4.1. Общий случай проектирования системы поддержки регламентов

Основные этапы доработки обобщенной среды бизнес-моделирования до СПР были изложены в разделе 2.2 настоящей диссертации. Следуя им, возможно сформулировать общие принципы, далее выраженные графически в модели СПР:

• в общем случае СПР связана с ЕЯР-системой, что выражается в модели разделением ее на две части: схема СПР дана сверху, схема ЕЯР-системы - под ней;

• СПР, в свою очередь, разделяется на клиентскую и серверную часть;

• среда бизнес-моделирования, лежащая в основе СПР, должна поддерживать клиент-серверную архитектуру и допускать расширение путем предоставления АР1;

• язык GSQL предоставляет альтернативный доступ к данным среды бизнес-моделирования, стандартизированный и более удобный, нежели API. В то же время GSQL не может полностью заменить API, поскольку не взаимодействует с интерфейсом клиентской компоненты;

• ERP-система, соответственно требованиям современности, считается реализованной на трехуровневой архитектуре: сервер базы данных -сервер приложений - «тонкий» клиент (обычный браузер);

• связь между ERP-системой и средой бизнес-моделирования реализуется на уровне базы данных посредством языка GSQL. Это требуется с целью обеспечения максимальной широты возможностей -например, организации копирования данных в среду бизнес-моделирования при срабатывании триггеров, связанных с таблицами реляционной СУБД;

• прочие компоненты ERP-системы непосредственно с СПР не связаны, поскольку роль, допускающая управление бизнес-процессами, обособлена от прочих.

Модель СПР, соответствующая изложенным принципам, представлена ниже на рис. 33:

- ___✓ ■•■ ■ ws&m

Сервер Клиент среды БМ\ч .

,х среды БМ среды'БМ^ '

API

9

APMgv//;

. , .„пользователя

//,/fv/s //■ - GSQL - -Доп'соедства

Сервер БД ERP-системы

Сервер приложений ERP-системы