CC BY
19
Научно-технические ведомости СПбГПУ 1' 2009. Информатика. Телекоммуникации. Управление
3.Баргесян A.A., Куприянов М. С., Степаненко В. В.
и др. Технологии анализа данных: Data Mining. Visual Mining. Text Mining. OLAP. Изд. 2-е. СПб.: БХВ-Петербург. 2008. 384 с.
4. Каира.IOB A.B., Кошкарев A.B., Тнкунов A.B. Основы геоинформатики: Учебное пособие для студенческих вузов. В 2 кн. Кн. 1. М.: Изд. центр "Академия", 2004. 352 с.
5. Шаши Шекхар, Санжей Чаула. Основы пространственных баз данных / Пер. с англ. М.: КУДИЦ-ОБРАЗ. 2004. 336 с.
6. Ехлаков Ю.П., Жуковский О.И., Рыбалов Н.Ь.
Принципы построения web-ориентированной ГИС промышленного предприятия // Изв. Томского политехи. ун-та. 2006. Т. 309. № 7. С. 146-152.
7. Ошепков С.С., Лакеев U.C., Жуковский О.И. Задачи пространственно-временного анализа в среде ВЕБ-ГИС сервера // Современные техника и технологии: Сб. тр. XIV междунар. науч.-практ. конф. студентов, аспирантов и молодых ученых, г. Томск. 24-28 марта 2008г. В 3 т. Т. 2. Томск: Изд-во Томск, политехи, ун-та, 2008. С. 364-365.
Л. В. Кулагина, Н. В. Кулагин Механизм управления информационной системой
на многосерверной платформе
При разработке информаш юнных систем (ИС), построенных на распределенной базе данных (БД), одна из наиболее сложных задач — организация взаимодействия входящих в состав системы функциональных элементов (ФЭ). представляющих собой функционально завершенные программные единицы приложений — процедуры, функции, объекты и серверов, которые хранят процедуры баз данных, команды Тгапвас^ОЬ.
Рассмотрим ИС как некоторый объект, который состоит из набора функциональных элементов /%,..., Рп и может находиться в конечном множестве точек абстрактного пространства состояний. Каждое из состояний ИС зависит от значений переменных общего поля данных и характеризуется признаками Рг .... Рт в абстрактном многомерном пространстве состояний. Рассмотрим один из них более подробно. Признак состояния — это логическая переменная, принимающая одно из двух значений—-нуль либо единицу. Пространство признаков представляет собой гиперпространство. Поскольку признак может принимать одно из двух значений, то функционирование ИС можно описать в виде переходов между вершинами /«-мерного гиперкуба. Значение конкретного признака зависит от условий данного признака, наложенных на общее поле данных ИС. Проверка условий и изменение признаков состояний осуществляются последовательным перебором этих признаков.
Управление функциональными элементами предлагается проводить на двух уровнях: при-
ложения (П) и базы данных. Управление ФЭ на уровне П рассматривалось в работах [1-3].
Для описания структуры приложения любого уровня сложности достаточно набора ФЭ и анализатора состояний. Создание анализатора состояний, использующего непосредственно проблемные данные, для каждого приложения является задачей уникальной и не менее сложной. чем разработка структуры взаимодействия ФЭ. Для упрощения данной задачи определим уровень абстрактного описания состояния приложения. Описывать данные состояния наиболее просто, если использовать приемы объектно-ориентированного программирования (ООП), однако при описании структуры программы можно и не использовать ООП. В рамках ООП введем еще один элемент, представляющий собой класс особых объектов — признаки состояния (ПС), которые принимают одно из двух значений: "Установлен" или "Сброшен". Структуру объекта ПС отражает табл. 1. Объект состоит из методов для изменения основного поля, принятия и проверки условий применительно к данным задачи. В ПС разные функциональные элементы можно включить тремя способами, которые отличаются условием запуска ФЭ. С каждым способом запуска будут связаны свои ФЭ. Пусть с первым способом запуска (назовем его "Пролог") связаны определенные ФЭ. которые полностью и последовательно срабатывают при каждом появлении значения "Установлен". С установкой значения "Сброшен" связан второй
способ запуска ФЭ, так называемый "Эпилог", при этом ФЭ срабатывают аналогичным образом. Кроме этих есть еще один способ запуска ФЭ— "Очередь". При каждой смене значения ПС выполняется первый элемент из "Очереди", который после этого удаляется, а на его место встает следующий элемент.
Мы описали рабочие процедуры объекта ПС, но в состав каждого такого объекта входят также процедуры управления им. такие, как установка условий, по которым ПС будет изменять свое значение, директивный перевод ПС в состояния "Установлен" или "Сброшен", а также процедуры для работы с "Эпилогом", "Прологом" и "Очередью". Рассмотрим их подробнее.
Процедуры "Пролога" и "Эпилога" —статические, они встраиваются в объект ПС на стадии написания программы. Процедуры "Очереди" — динамические, встраиваются и уничтожаются в объекте ПС на стадии работы программы, что позволяет делать ее изменяемой в самом процессе работы, а не на стадии компиляции. При таком подходе нет никаких ограничений на ФЭ, и разработчик может пользоваться готовыми ФЭ из различных библиотек либо своими собственными наработками.
Структура класса "Признак состояния".
При введении абстрактного пространства состояний, а также в рамках ООП введение такого элемента, как объект ПС, позволяет более легкими средствами построить типовой анализатор состояния программы — контроллер состояний (КС), входящий в состав подсистемы управления приложения, предназначенный для регистрации его признаков состояния, а также управления ими в зависимости от изменений в общем поле данных или во внешней среде в результате диалога оператора с приложением.
Рассмотрим работу КС в П подробнее. При инициализации программы происходят инициализация данных и КС. при этом в контроллере происходит регистрация всех объектов типа ПС, присвоение им соответствующего регистрационного номера и их внутренняя инициализация. Последнее предполагает, что основное поле ПС принимает значение "Не установлен", а затем инициализируются начальные условия ПС над общим полем данных. После инициализации данных задачи, КС и всех ПС управление передается первому зарегистрированному в КС признаку состояния. После того, как управление перешло первому ПС. проверяются его условия применительно к данным задачи. Если условия
истинны, то ПС устанавливается в состояние "Установлен", если ложны, — в состояние "Не установлен". Далее в зависимости от основного значения выполняются функциональные элементы "Пролога" или "Эпилога". Затем, если было изменение основного значения, выполняется один ФЭ из очереди и управление передается из ПС в контроллер, который последовательно передает управление следующему зарегистрированному в нем объекту ПС. тот работает аналогично первому ПС и т. д. После отработки последнего зарегистрированного в КС объекта ПС управление передается первому и т. д.. петлеобразно. На этом работа контроллера заканчивается. Этот метод делает контроллер состояний программно независимым от самого П. используемых им ФЭ и ПС. что позволяет один и тот же контроллер использовать в различных приложениях. Разница заключается только в том, что в каждом конкретном П в КС будут регистрироваться свои уникальные признаки, а в ПС будут содержаться свои уникальные ФЭ. Абстрактный характер признаков состояния позволяет процесс разработки и модификации приложения свести к решению последовательности локальных задач, каждая из которых заключается в создании ФЭ и ПС. определяющих условия его работы. При диалоге оператора с приложением действия контроллера приостанавливаются, после окончания диалога — возобновляются. Изменения, которые внес оператор, затрагивают либо данные задачи, либо условия или функциональные элементы какого-то из ПС. После возобновления работы контроллера на очередном запуске ПС изменения будут учтены и П будет уже работать по новому алгоритму.
Теперь рассмотрим подробнее управление ФЭ в ИС на уровне базы данных.
Для регистрации признаков состояния в БД [4. 5] заводится служебная таблица "Sign_of_ condition". Ее поля и их типы следующие.
Название поля
Kod
Name
Sign
01d_Sign
Kod_DB
Condition
Condition_TR U E
Condition_FA LSE
Condition_Invert_Sign
Number_Sing
Тип поля Int IDENTITY Char
Bit in not null
Bit in not null
Tinyint
Char
Char
Char
Char
Int
Научно-технические ведомости СПбГПУ 1' 2009. ^Информатика. Телекоммуникации. Управление
Признак состояния в таблице представляет собой запись. Рассмотрим один из них более подробно. Признак состояния представляет собой логическое поле Sign, принимающее одно из двух значений: "Установлен" либо "Сброшен". В логическом поле Sign хранится текущее положение признака, а в Old_Sign — предыдущее значение признака. Изменение предыдущего значения происходит при отработке триггера данной таблицы на UPDATE.
Значение конкретного признака зависит от соответствующего ему условия, хранящегося в поле "Condition" и написанного на Transact-SQL. Во время проверки условия функциональные элементы могут работать тремя способами, которые отличаются условием запуска ФЭ. При этом используется логическая структура, похожая на ту, которая была рассмотрена выше применительно к управлению на уровне приложений. С каждым способом запуска будут связаны свои ФЭ. Пусть с первым способом запуска ("Пролог") связаны определенные ФЭ, которые полностью и последовательно работают при каждом появлении значения "Установлен". Данные ФЭ перечисляются в поле "Condition_ TRUE" согласно требованиям Transact-SQL. С установкой значения "Сброшен" связан второй способ запуска ФЭ, называемый "Эпилогом". При этом ФЭ работают аналогичным образом и перечисляются в поле "Condition_ FALSE". Кроме этих есть еще один способ запуска ФЭ — "Очередь". При каждой смене значения ПС выполняются элементы "Очереди".
Введение служебной таблицы "Sign_of_ condition" с признаками абстрактного пространства состояний позволяет легко построить типовой анализатор состояния ИС на уровне БД— контроллер состояний (КС), входящий в состав подсистемы управления ИС и предназначенный для управления запуском функциональных элементов в зависимости от изменений в данных ИС.
Для построения КС можно использовать службу "SQL Server Agent". Работа "SQL Server Agent" строится с использованием компонентов следующего типа — "Jobs" (задание), которые описывают задания, выполняемые автоматически в соответствии с установленным расписанием или вызываемые вручную при необходимости. Кроме того, задания могут
вызываться в моменты простоя процессора. Для облегчения построения КС в базе данных имеются две процедуры. Первая — "ЕХЕС_ Sign" — предназначена для работы с конкретной записью в таблице "Sign_of_condition". Другая процедура— "EXEC_ALL_Sign" — представляет собой курсор по всем строчкам таблицы "Sign_of_condition". При переборе конкретного признака запускается процедура "EXEC_Sign". Еще одна процедура запускает все признаки с определенным значением поля "Number_Sing".
Признаки, в ИС могут заноситься на центральном сервере (а потом, если необходимо, реплицироваться) или на любом распределенном сервере. В частности основные данные в таблицу заносятся на центральном сервере и, если необходимо, реплицируются на другие распределенные серверы механизмами, которые описаны в [6. 7].
Периодически при запуске задания происходит проверка условий и изменения признаков состояния, что осуществляется последовательным перебором.
После отработки последнего зарегистрированного ПС в "Sign_of_condition" управление передается первому, а затем циклически просматриваются все условия признаков состояния и запускаются необходимые функциональные элементы.
Переход из одного состояния в другое возможен в результате следующего: выполнения какого-либо ФЭ, изменений данных с клиентских мест, репликаций данных. Будем считать, что каждый ФЭ выполняется только в том случае, когда база данных переходит в некоторое множество заранее определенных состояний, т. е. действия ФЭ являются реакцией ИС на переход в эти состояния.
Таков предложенный метод управления взаимодействием функциональных элементов в информационной системе (ИС) [4]. построенной на распределенной базе данных. Разработана структура поддерживающих его инструментальных средств. Метод основан на описании работы системы как последовательности переходов в абстрактном пространстве состояний. Предлагаемый формализм позволяет свести процесс разработки, внедрения и модификации ИС к решению ряда локальных задач.
СПИСОК ЛИТЕРАТУРЫ
1. Управление взаимодействием функциональных элементов в прикладных программах / O.P. Козырев. Н.В. Кулагин. Ю.М. Максимов, В.Г. Ма-нишин. Е.Е. Манишина. М.Я. Николаев//Системы обработки информации и управления: Межвуз. сб. науч. тр. // НГТУ. Н.Новгород. 1997. С. 96-101.
2. Кулапш H.В., Мамедова Т.Ф. Математическая модель системы обработки информации и управления // Средневолжское математическое общество. Саранск. 2001. (Препринт № 37).
3. Кулапш Н.В. Управление взаимодействием функциональных элементов в прикладных программах и базах данных: Тезисы доклада на V Междунар.
конф. "Дифференциальные уравнения и их приложения". Саранск. 2002. С. 260-262.
4. Мамаева Е., Шкарина Л. Microsoft SOL server для профессионалов. СПб.: Питер. 2001.
5. Вишневским А.В. Microsoft SQL Server 2005. Эффективная работа СПб.: Питер. 2008. 544 с.
6. Кулагина Л.В., Кулагин Н.В. Разработка инструментария для создания многосерверной системы ввода и обработки данных // Труды СВМО. 2006. № 2. С. 233-235.
7. Кулагина Л.В., Кулагин Н.В. Разработка много серверной системы передачи и обработки данных // Труды СВМО. 2005. Т. 7. № 1. С. 421-422.
