|
|
Дипломная работа - Тырин А.А. (АП-91). Назначение и область применения
4.5 Структура модуля 4.5.1 Основные понятия
Пользователь – зарегистрированный в системе человек.
Физическая таблица – зарегистрированная в базе данных таблица для хранения информации об однотипных объектах. Таблица может содержать только часть информации об объекте, а также может являться таблицей связи для реализации N:N связей [20] между другими таблицами.
Справочник – виртуальное хранилище данных для работы с однотипными объектами. Справочник обязательно имеет главную физическую таблицу, а также может иметь несколько связанных таблиц, в случае если информация об объектах такого типа разбита на несколько частей, которые содержатся в разных физических таблицах.
Объект – конкретная запись в справочнике.
Запрос – пакет информации, содержащий данные об изменении существующей в базе данных информации о конкретном объекте. Запрос может содержать информацию о создании нового объекта или редактировании/удалении существующего.
Мультизапрос – это запрос, объединяющий в одну логическую группу несколько объектов для удобной обработки информации. Объекты мультизапроса могут являться как однотипными, так и разнотипными.
Схема маршрутизации запросов – детерминированный конечный автомат, вершинами которого являются состояния, а дугами – переходы между состояниями, реализующий логику взаимодействия пользователей при редактировании данных для обеспечения контроля их качества.
Роль – некоторая логическая группа пользователей, выполняющая определенные действия с запросами при их прохождении по схеме маршрутизации. Каждому состоянию схемы маршрутизации, за исключением конечных, должна соответствовать ровно одна роль.
Тип роли – логическая группа ролей, объединенная определённым признаком для удобного разграничения полномочий между разнотипными ролями.
Состояние – атрибут запроса, обозначающий его текущее положение в схеме маршрутизации запросов. Состояние привязано к конкретной роли, поскольку работа с запросом в определённом состоянии может выполняться пользователями, обладающими одной и той же ролью. Состояния бывают четырёх типов: «Начальное», «В процессе», «Обработан», «Отклонён». Каждое из этих типов обозначает прогресс запроса в схеме от его формирования до внесения изменений в базу данных или его отклонения пользователем или системой.
Переход – процесс изменения состояния запроса. Существует 3 типа переходов: Forward, Back, Abort. Тип Forward обозначает продвижение запроса по схеме вперед к состоянию, где он будет обработан. Back возвращает запрос по цепи назад. Переход Abort отклоняет запрос, который далее не рассматривается пользователями. Из любого промежуточного состояния схемы маршрутизации должен быть задан ровно один переход типа Forward, может быть задан максимум один переход типа Abort и несколько переходов типа Back. Из начального состояния схемы маршрутизации должен быть задан ровно один переход. Этот переход должен иметь тип Forward. Из конечных состояний не может быть задано ни одного перехода.
Смежные состояния – состояния схемы маршрутизации, соединённые переходом типа Forward, при этом исходящее состояние называется предыдущим, а входящее – следующим. Двум смежным состояниям не может соответствовать одна и та же роль.
Набор полей – перечень атрибутов объекта доступных на редактирование для роли.
Бизнес-процесс (БП) – перечень соответствий между ролями схемы маршрутизации запросов и набором полей, доступных для редактирования, а также набор допустимых операций со справочниками. В случае если в рамках одной схемы маршрутизации при создании запроса пользователю доступны несколько бизнес-процессов, то он должен выбрать один из них.
4.5.2. Концепция модуля.
Необходимость разработки модуля настройки маршрутизации запросов образовалась в процессе внедрения в систему АСОТ технологии мультизапросов. В первоначальной версии системы у каждого справочника была своя схема маршрутизации запросов. Такая структура программы не позволяла разнотипным объектам проходить по одной и той же схеме маршрутизации в рамках одного запроса, что исключало возможность использования технологии мультизапросов. Также, стоит отметить, что на 35 справочников существовало всего лишь 4 уникальные схемы маршрутизации, что говорит об избыточности данных. Также изменение одинаковых схем являлось довольно трудоёмким и неудобным процессом. Эти факторы тоже повлияли на решение о смене структуры программной части по маршрутизации запросов.
  
Интерфейс создания и редактирования запросов
Ядро.
Основной компонент АСОТ
Рис 4.4 Модуль настройки схем маршрутизации
Часть, выделенная голубым фоном (рис. 4.4), показывает структуру разрабатываемого модуля настройки схем маршрутизации. Модуль разбит на три логических элемента: «Настройка схем маршрутизации», «Маршрутизация запросов» и «Запись в БД». Также на схеме изображены компоненты, с которыми модуль настройки схем маршрутизации обменивается данными. С помощью интерфейса создания и редактирования запросов пользователи формируют информацию об изменении данных и отправляют её по настроенной схеме. В ядре АСОТ реализованы все базовые функции работы программы, в том числе и обмен данными с БД.
«Настройка схем маршрутизации» представляет собой интерфейс, с помощью которого администратор системы создаёт и редактирует все сущности системы маршрутизации: регистрирует физические таблицы, создаёт справочники, типы ролей и схемы маршрутизации. В схемах маршрутизации необходима настройка состояний, переходов, ролей, наборов полей и бизнес-процессов.
«Маршрутизация запросов» выполняет функцию распределения запросов по ролям по предварительно настроенной схеме маршрутизации.
«Запись в БД» осуществляет запись изменённой информации в базу данных с помощью функций описанных в ядре АСОТ. Перед непосредственной записью данных программа выполняет несколько операций, для проверки полноправности вносимых изменений.
Новая структура модуля решила ряд проблем первоначальной версии программы, но она не может обеспечить должную гибкость схем маршрутизации при решении каких-либо конкретных задач, например: динамическое изменение пути запроса в зависимости от заполненных атрибутов и их значений. Для достижения этой цели в систему были внедрены такие средства как: бизнес-процесс и условия остановки в состояниях.
Бизнес-процесс – это режим обработки запроса, со своими ограничениями и допусками. С помощью этого режима можно задавать допустимые операции со справочниками и наборы полей объектов. Также бизнес-процесс используется как флаг для условий остановки в состоянии. При определении бизнес-процесса программа маршрутизации может остановить запрос в конкретном состоянии или пропустить его, в зависимости от описанного администратором системы условия.
По умолчанию переход в следующее смежное состояние выполняется автоматически. С помощью метаязыка можно устанавливать правила, при которых в состоянии будет произведена остановка. Правила остановки можно устанавливать только на промежуточные состояния и проверяться они будут только при выполнении переходов типа Forward. В правиле описывается набор условий, связанных логическими операторами.
В случае если при выполнении перехода обнаруживается, что пользователь, осуществляющий переход, может работать в следующем смежном состоянии, то переход в него выполняется автоматически, после чего вновь проверяется доступность работы пользователя в следующем смежном состоянии, и т.д.
Для того чтобы правила остановки выполнялись, они должны быть правильно описаны на специально разработанном метаязыке.
4.5.3 Описание правил на метаязыке
В схеме маршрутизации запрос проходит путь от начального состояния («создан») до конечного («обработан» или «отклонён») через множество промежуточных состояний, определённых администратором системы при настройке схемы. Состояния запроса определяют роль, которой этот запрос доступен для обработки. По умолчанию промежуточные состояния пропускаются системой, но при необходимости администратор системы может описать правила остановки для конкретных состояний, при выполнении условий которых запрос будет останавливаться в них для обработки пользователем.
Документация по использованию метаязыка приведена ниже.
Общие положения.
Правило – набор условий соединённых между собой логическими операторами с определённым порядком выполнения действий с помощью скобок.
Условие – выражение, сравнивающее значение некоторого поля объекта запроса с заданным пользователем или проверяющее определённые параметры запроса.
Описание условий.
Условие может проверять следующее:
Операция над объектом
Изменение значения поля
Наличие изменённых полей кроме заданного
Пустое поле
Вложение
Значение поля
Интерпретатор распознаёт следующие служебные слова: «операция», «изменено», «пустое», «приложен файл». Нераспознанные слова интерпретатор будет воспринимать как название поля.
Проверка операции над объектом.
Для того чтобы задать проверку операции над объектом необходимо написать служебное слово «операция» (без кавычек), далее через пробел задать оператор сравнения: либо «=» либо «<>» и после этого обозначить тип операции – один из: «добавление», «редактирование» или «удаление».
Пример: операция = удаление
операция <> редактирование
операция=добавление – ошибка
Примечание: очень важно соблюдать пробелы между словами и операторами, так как слитно написанную строку интерпретатор воспримет как одно слово и выдаст ошибку. Регистр в свою очередь не имеет значения, поэтому пользователь может написать «Операция» или «УДАЛЕНИЕ». Эти правила распространяются на все остальные служебные слова и конструкции, в том числе и на логические операторы.
Проверка изменённого или пустого значения поля.
Служебными словами для проверки изменённого или пустого значения поля являются «изменено» и «пустое» соответственно. Следующее слово после служебного будет определено как названия поля объекта. Важно, чтобы название поля являлось одним словом (т.е. без пробелов) и соответствовало имени атрибута объекта в базе данных.
Пример: изменено number
пустое street_name
изменено full address – ошибка
Проверка наличия изменённых полей кроме заданного.
Конструкция проверки наличия изменённых полей кроме заданного состоит из служебного словосочетания «изменено кроме» и названия атрибута объекта. Разделение оператора и имени поля также осуществляется с помощью пробела.
Пример: изменено кроме graphics
изменено_кроме street_name – ошибка
Проверка наличия приложенного файла.
Проверка наличия приложенного файла описывается служебной конструкцией «приложен файл». Эта конструкция является условием, дополнительные параметры и операторы сравнения не требуются.
Пример: Приложен файл
приложенФайл – ошибка
Сравнение значений полей.
Конструкция сравнения значений полей состоит из трёх частей: наименование поля, оператор сравнения, сравниваемое значение. Все три части, как и в предыдущих случаях, должны быть отделены друг от друга пробелами, а значение должно быть заключено в кавычки. Доступные операторы сравнения:
= - равно
<> - не равно
> - больше
< - меньше
>= больше или равно
<= - меньше или равно
Пример: number <> “20”
street_name = “ул. Арбат”
full_number = 10/17 – ошибка
Примечание: При описании правил запрещено использовать символы «
» и «|», так как они являются служебными и требуются для разбора строки правил.
Описание правил.
При описании правил используются логические операторы «и», «или», отрицание «не», а также скобки для установки порядка вычисления выражения. Операторы могут стоять соединять как простые условия, так и целые логические выражения, заключённые в скобки. Отрицание также может стоять перед условием или выражением в скобках.
При вычислении логического выражения сначала вычисляется отрицание («не»), затем конъюнкция («и»), и последней – дизъюнкция («или»). Порядок действий вычисляется слева направо.
В выражении «изменено graphics или version = “2” и операция <> удаление» будет следующий порядок действий:
version = “2” и операция <> удаление = результат
изменено graphics или результат = конечный_результат
Если в это выражение добавить скобки: «(изменено graphics или version = “2”) и операция <> удаление», порядок действий изменится:
изменено graphics или version = “2” = результат
результат и операция <> удаление = конечный_результат
Далее следуют несколько примеров описания правил:
не пустое structure или full_number = “20а”
(изменено graphics или version = “2”) и операция <> удаление
(Приложен файл и version > 1) не пустое number – ошибка (между закрывающей скобкой и отрицанием должен стоять оператор)
И операция = удаление и не приложен файл – ошибка (логический оператор «и» не может стоять в начале выражения)
4.5.4. Структура служебной базы данных.
Изменение структуры модуля настройки и выполнения маршрутизации запросов, а также новая функциональность привела к необходимости изменения структуры служебной базы данных. Эта база данных отвечает за хранение всей информации о схемах маршрутизации, пользователях, их ролях, полномочиях этих ролей и так далее. Новая структура базы данных изображена на рисунке 4.5:
Рис. 4.5 Структура служебной БД
Схема разбита на несколько цветовых категорий:
Красная – описание схем маршрутизации;
Зелёная – администрирование пользователей;
Синяя – таблицы связей;
Жёлтая – остальные сущности, модуля настройки и выполнения маршрутизации запросов.
Описание схем маршрутизации
Данные о схемах маршрутизации распределены между несколькими таблицами базы данных. Schemes – таблица, в которой хранятся идентификаторы и названия схем маршрутизации. Также здесь содержится файл графического изображения схемы: состояния и переходы, их положение относительно друг друга. States – таблица состояний. В этой таблице хранится название состояния, схема, которой принадлежит состояние, роль, которая работает в данном состоянии, а также правило остановки в этом состоянии. Правило остановки является строкой, перечисляющей все условия, разделённые служебными символами. В State_types перечислены типы состояний. На данный момент таких типа 4: «начальное», «в процессе», «обработан», «отклонён». Transitions – таблица переходов. Помимо информации о входном и выходном состоянии здесь хранятся значения двух флагов: обязательное указание пользователя при переходе, комментарий обязателен. Transition_types содержит типы переходов. Таких перехода всего 3: «Направить» (Forward), «уточнить» (Back), «отклонить» (Abort). Более подробно они описаны в пункте 4.5.1.
Администрирование пользователей
Для предоставления пользователям доступа к системе в АСОТ реализована система авторизации пользователей. Администрирование пользователей выполняет функцию обеспечения безопасности данных, с которыми работают пользователи следующим образом:
Выдача уникального пароля пользователю для предотвращения входа в систему от чужого лица;
Ограничение прав доступа к ресурсам и выделение полномочий индивидуально каждому пользователю;
Привязка идентификатора пользователя к любой операции совершённой в системе для определения совершившего данную операцию пользователя.
Используемая таблица Users. В этой таблице хранятся идентификатор пользователя, его авторизационные данные, контактные данные (ФИО, e-mail), а также время последнего входа в систему и количество активных запросов, в которых он участвует. В таблице Users_processes_actors хранятся связи пользователей и ролей для конкретного бизнес-процесса в определённой схеме.
Сущности схем маршрутизации
Для хранения информации о ролях используется таблица Actors. У роли есть имя, принадлежность схеме маршрутизации, а также тип. Типы ролей в свою очередь хранятся в отдельной таблице Actor_types.
Справочники, используемые для схем маршрутизации, добавляются в таблицу Refbooks_.'>Refbooks. У справочника должна быть обязательно главная физическая таблица. Все необходимые физические таблицы регистрируются администратором и хранятся в Physical_tables. У справочника есть также связанные таблицы. Для реализации связей между Refbooks и Physical_tables типа N:N (много ко многим) используется таблица связей Refbooks_physical_tables. В схеме маршрутизации может использоваться определённый набор зарегистрированных в системе справочников. Данные о зарегистрированных в схеме справочниках хранятся в таблице связей Refbooks_schemes.
Бизнес-процессы перечислены в таблице Processes. В ней хранится название бизнес-процесса и его принадлежность схеме. Для определения допустимых операций со справочниками в конкретном бизнес-процессе существует таблица Processes_refbooks. Можно создать бизнес-процесс, который допускает только удаление объектов конкретного справочника. Набор допустимых ролей определяет те атрибуты объекта, которые может редактировать пользователь. Информация об этих наборах хранится в Field_sets. Сами же названия полей вынесены в отдельную таблицу Field_sets_fields. У этой таблицы есть также связь с Refboooks, так как имя поля является атрибутом справочника.
Ещё в базе данных есть две таблицы связей Processes_actors_field_sets и Users_processes_actors. Первая описывает связь ролей и наборов полей в бизнес-процессе, а вторая связь пользователей и ролей в бизнес процессе. Это означает, что у одной роли может быть несколько наборов полей, а у одного пользователя может быть несколько ролей и наоборот.
|
|
|
Скачать 0.55 Mb.