5.3. Структурирование программного комплекса на основе категорийной модели госудаственных учетов

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

В качестве базовых моделей для решения приведенных задач в разное время предлагались модели John A. Zachman, Robert Barker, Д.Хендерсона, У.Меллинга, А.Шеера. Вместе с тем в данных подходах не предложен конкретный математический аппарат, который был бы применим для анализа модели, а также для поиска наилучших решений в пространстве возможных альтернатив[Error: Reference source not found,Error: Reference source notfound].

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

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

Можем констатировать: сложность ИС характеризуется уровнем сложности объектов и уровней

связей между ними; сложность также зависит от внутренней информации ИС, и определяется

числом объектов и установленных отношений различных уровней; можем разделить ИС на информационные объекты (функциональные

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

1

Таким образом, целесообразно реализовать пополнение и хранение данных в виде совокупности многомерных OLAP-кубов, с архитектурой хранилища на основе многомерной СУБД. При этом, процессы обработки и пополнения ХД новыми данными должны быть независимыми и осуществляться с применением OLTP технологии.

Анализ программных комплексов реализующих OLAP-технологии как метода обработки многомерных данных в открытой предметной

областиРассмотрим технологию обработки данных, представленных

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

Различают 3 типа многомерных OLAP-систем: Multidimensional Online Analytical Processing (MOLAP) - система

многомерной оперативной аналитической обработки[Error: Referencesource not found];

Relational Online Analytical Processing (ROLAP)-реляционная система оперативной аналитической обработки[Error: Reference source not found];

Hybrid Online Analytical Processing (HOLAP)-смешанная или гибридная система оперативной аналитической обработки [Error:Reference source not found].

Сложность в применении OLAP можно подразделить на 2 аспекта: первый заключается обеспечении полноты и непротиворечивости данных, а второй в создании запросов для выбора, как базовых данных, так и в разработке схемы. С учетом изложенного в §1.3, рассмотрим разновидности OLAP-систем[9]. Многомерные OLAP-системы. Данные могут быть организованы в виде гиперкубов или поликубов. В первом случае, как уже приводилось ранее, во все хранимые данные должны иметь одинаковую размерность.

2

При организации в виде поликубов, значения показателей хранятся с собственным набором измерений для каждого показателя. Обработка данных производится также собственным для каждого куба инструментом системы [Error: Reference source not found]. Достоинства и недостатки MOLAP могут быть представлены диаграммой, приведенной на рис. 1.15. Реляционные OLAP-системы. В настоящее время в большинстве программных средств обеспечения аналитических запросов используется именно реляционный подход. Особым случаем ROLAP систем является реляционная система оперативной аналитической обработки реального времени - Real-time Relational Online Analytical Processing  (R-ROLAP).

Рис. 1.15 - Достоинства и недостатки MOLAP

3

В R-ROLAP для хранения агрегированных данных не производится создание специальных реляционных таблиц, расчет агрегатов происходит в момент выполнения запроса, для чего многомерный запрос к системе преобразуется в SQL-запрос к реляционным данным в автоматическом режиме. С учетом изложенного в § 1.3 достоинства и недостатки ROLAP могут быть представлены диаграммой, приведенной на рис. 1.16.

Рис. 1.16 -  Достоинства и недостатки ROLAP

Гибридные OLAP-системы. Недостатки ROLAP и MOLAP привели к созданию новой технологии, под которой понимается любая архитектура, использующая принципы реляционной или многомерной OLAP системы. Поскольку HOLAP основана на запросах, то также как и ROLAP и MOLAP не поддерживает ассоциативных связей между данными. При сочетании инструментов, реализующих обе модели одновременно, используются достоинства и компенсируются их недостатки. Именно это является наиболее приемлемым решением проблем в применении программных инструментальных средств в многомерном анализе.Для исследования задач анализа данных чаще всего производится их отображение на формализованный язык. С увеличением числа параметров

4

происходит увеличение размеров и сложности системы, что приводит к существенному усложнению ее моделирования с помощью известных математических выражений. Становится практически невозможным создание соответствующей модели. Л. Заде была предложена модель, которая вместо математических выражений использовала слова, отражающие качество. Это позволяло создать достаточно качественную модель, и предметом обсуж-дения становится уже нечеткость самих слов языка описывающего систему [Error: Reference source not found]. Основной проблемой анализа многомерных матриц данных является необходимость сведения их к двум измерениям, т.к. человеческий мозг не способен одновременно оперировать таким количеством измерений пространства. Для этого была разработана специальная группа методов статистического анализа данных, получившая название – многомерный анализ данных. Применимость методов многомерного анализа данных применительно к конкретной ситуации приведена в виде диаграммы на рис. 1.17.

Рис. 1.17 – Схема использования методов многомерного анализа данныхПроведение последовательного анализа по одному измерению

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

5

(рисунок 1.18). Такие данные получили название многомерный информационный объект [Error: Reference source not found].

Рис. 1.18 – Зависимость мерности данных от типа анализаВсе данные в ХД могут быть поделены на три основных категории, это

метаданные - описание контента, детализированные (атомарные) данные и агрегированные данные.

Присутствие контента дает возможность реализовывать быструю и комфортную навигацию согласно всевозможным уровням данных, дает возможность четко показывать реализованную структуру ХД и т. д. Проведенные обследования выявили, то что большая часть конечных пользователей работают с агрегированными показателями [Error: Referencesource not found,Error: Reference source not found]. В структуре ХД учитывается право получения агрегированных данных с дальнейшей навигацией согласно всем уровням агрегирования. Классификация конечных пользователей на 5 типов представлена диаграммой на рис. 1.19.

6

Рис. 1.19 - Классы конечных пользователейПрограммное обеспечение ХД может быть реализовано в виде трех категорий средств загрузки, средств мониторинга и средств создания и развития (рис.1.20).

Концептуальная модель «хранилища данных» приведена на рис. 1.21.Наиболее целесообразно обеспечить одновременное хранение в рамках аналитической программной системы всех трех типов данных, начиная от детализированных данных и оканчивая аналитические таблицы данных.

7

Рис. 1.20 – Категории объектов в структуре ХД Также целесообразно использовать многоуровневую архитектуру ХД,

дополненного слоем так называемых "навигационных метаданных" между программной системой и физическим ХД. Ввиду разнотемповости OLTP систем необходим промежуточный склад данных.

Таким образом, описываемое ХД создается в 3-х уровневой архитектуре в виде: самостоятельной системы для внутренних программных систем, и в качестве надстройки над множеством существующих OLTP [Error: Reference source not found].

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

8

Рис. 1.21 - Концептуальная модель ХДТаблица фактов будет содержать данные, дающие характеристику

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

Для любого измерения может быть составлен список уникальных значений из данных и произведено агрегирование фактов для записей, у которых значения размерностей одинаков. Теперь можем обеспечить связь разных таблиц (или кубов), путем соответствующего сопоставления элементов в таблицах измерений с соответствующими атомарными значениями [Error: Reference source not found].

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

Выводы по теме1. На основе проведенного анализа общих проблем проектирования и

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

9

2. На основе проведенного анализа основных направлений в построении моделей хранилищ данных и средств их реализации сделан вывод о целесообразности пополнения и хранения данных в виде совокупности многомерных OLAP-кубов и их отношений для архитектуры хранилища данных на основе многомерной СУБД. Процессы обработки и пополнения ХД новыми данными должны быть независимыми и осуществляться с применением OLTP технологии.

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

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

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

Практически все информационные системы и аналитические программные системы их реализующие в определенной степени содержат функции долговременного хранения и обработки информации. ХД строятся на основе ММД, что предполагает выделение необходимых измерений и фактов для анализа по данным измерениям. Исходя из ранее приведенного анализа, можем разделить структуру информационной системы на информационные объекты, которые в аналитической программной системе будут функциональными модулями, описать все их отношения, которые в программной системе будут выступать в роли интерфейсов взаимодействия. В итоге обеспечиваем полноту множества учитываемых отношений между объектами информационной системы определяющими ее поведение [Error:Reference source not found].

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

10

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

(неочищенных) данных при загрузке в ХД из OLTP систем; реляционного или многомерного ХД; многомерного OLAP хранилища; средств доступа и анализа данных.

Основываясь на выше сказанном, для аналитической программной системы необходимо наличие многоуровневой архитектуры ХД. Данную архитектуру дополнить слоем "навигационных метаданных" между аналитической программной системой и физическим ХД. Такое решение может быть оформлено в виде 3-х уровневой архитектуры с самостоятельной системой для аналитической программной системы, и в качестве надстройки над множеством взаимодействующих OLTP систем (рис.3.13).

Рис. 3.13 - Архитектура ХДДля каждого измерения OLAP куба составляется список, содержащий множество уникальных значений элементов столбцов и производится предварительное агрегирование данных, имеющих одинаковые значения размерностей. Задействовав аппарат промежуточных таблиц - кросс таблицы, можем связать элементы разных таблиц между собой, путем сопоставления каждой записи в таблицах измерений [Error: Reference source not found] списка элементов номеров данных, при формировании которых использовались эти измерения. Для данных такими сведениями могут быть координаты расположения в кубе. Могут быть созданы, по правилам описанным выше, многомерные OLAP-таблицы, дальнейшее связывание

11

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

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

1. функции программы образуют: класс объектов, для каждой пары объектов которого и задано множество морфизмов , для каждой пары которых (морфизмов), например, и

определена их композиция . Т.е. функции программы образуют категорию множеств;

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

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

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

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

12

связь между функциями программы, видом учета и пользователем описывается функторами, которые ставят в соответствие объекту одной категории объект другой категории. Любой поисковый запрос формирует новый объект - модуль исполнения запроса, который также является отдельной категорией, связь которого с пользователем (в частности) описывается функтором. Используя указанные категории в качестве базиса, можно построить многомерную матрицу, каждая ячейка которой является категорией. Все это позволяет реализовать программный комплекс в виде множества объектов, определяемых данной матрицей. Каждый объект может быть оформлен в виде отдельного модуля. Очевидно, что для программной реализации может быть использовано несколько языков программирования, реализующих возможность использования модуля в конкретных условиях наилучшим образом, а взаимодействие между ними организовано согласно требований функциональной стандартизации[Error: Reference source not found].

Для того, чтобы получить АПС в виде целостной функционирующей единицы, процесс анализа предметной области и синтеза программных элементов может быть представлен в виде дерева проблем[Error: Referencesource not found], приведенных на рис. 5.9.

Рис.5.9 - Дерево проблем процесса проектирования АПСПриведем расшифровку данного дерева проблем, точнее состояний

узлов данного дерева[Error: Reference source not found]:1. необходимо выбрать уровень  абстрактности описания   информационной системы   и   процесса проектирования аналитической программной системы;2. необходимо определиться с принципом отделения друг от друга уровней информационной системы;3. необходимо определить   механизм   связей   между   объектами   системы и уровнями;4. необходимо определиться с языком   описания   структур АПС   и   информационной системы  согласно выбранному уровню абстракции;5. необходимо решить вопрос с описанием связей на некотором формальном языке;6. необходимо определить механизм навигации между уровнями;7. необходимо определить все варианты поведения информационной системы и ее подсистем, а также АПС ее реализующей и описать на уровне моделей ее поведение;

13

8. необходимо определить взаимное влияние уровней ИС и на ИС целом;9. необходимо определить влияние композиции на функционирование аналитической программной системы;10.необходимо определить методы структурной декомпозиции (композиции) ИС и АПС;11.необходимо определиться с применением инструментов автоматизированного построения структур ИС и АПС.

Таким образом, ПК является ИС, объединяющей совокупность информационных подсистем (т.к. каждый АРМ выступает в виде отдельной информационной подсистемы). Для решения задачи создания оптимальной структуры необходимыми этапами являются создание описательной модели указанной информационной системы и выбор содержательных критериев структуры. Для описания информационной системы далее используем методы теории категорий множеств, базирующиеся на понятиях о множествах и отношениях между ними. Пусть – АРМ ПК. Тогда может быть описана, как совокупность множеств

, где - тезаурус с дескрипторным множеством ;

- коллекция программных модулей, поддержки функций ПК; - множество операций (функциональных) ПК;

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

- коллекция программных модулей, поддержки ОС; - множество поддерживаемых ОС;

– отображение, сопоставляющее каждой поддерживаемой ОС коллекцию программных модулей.

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

– отображение, сопоставляющее каждой поддерживаемой ОС коллекцию программных модулей.

- список допустимых операций пользователей; - множество пользователей системы;

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

- список допустимых операций с учетами; - множество видов учетов;

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

14

j =1,...,nОпределим тезаурус в виде конечного непустого множества слов , для которых существует подмножество (не кустое), так называемое множество дескрипторов. Тогда ПК может быть определен через локальные составляющие:

(5.5)

(5.6)

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

1. В ряде исследований, приведены теоретические основы работы с БД характеризующиеся неполной информацией[Error: Reference source not found]. Создание альтернативных методов работы с разреженными OLAP кубами предполагает во-первых формализацию методов оценки плотности OLAP куба, во-вторых - создание алгоритма, предназначенного для упреждающего получения информации об отсутствии требуемых сведений и следовательно «пустой выборки» не доходя до этапа выполнения самого запроса. В конечном счете все сводится к применению системы специализированных языков интеллектуального поиска.

2. Предложенное описание на языке теории нечетких множеств позволяет получить иерархическую информационную систему с полным определением данных.

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

15

4. Разработан метод построения иерархий формальных грамматик Н. Хомского, позволяющий формировать границы между семантическим и синтаксическим описанием процессов ПО и функциональными программами АПС. Предложено правило соблюдения этой иерархии от предметной области до полностью программной части системы, реализуемой по CASE технологии, т.е. на уровне интерпретаторов, трансляторов и компиляторов.Структура и краткая характеристика разработанного программного комплекса "Факт"

Согласно проведенных исследований и приведенных выше выводов в качестве аналитической программной системы был разработан программный комплекс "Факт", обеспечивающий за счет использования методов нечеткой логики и теории категорий множеств возможность динамической интеграции автоматизированных учетов на логическом уровне непосредственно на рабочей станции пользователя. В состав программного комплекса входит более 160 модулей, для программной реализации которых были использованы следующие языки программирования: ассемблер, паскаль, СИ, ТМТ паскаль, среда разработки Дельфи, разработчики и редакторы ресурсов.

В указанной АПС предусмотрено использование различных вариантов физической организации ХД, это реляционная БД, многомерная структура или набор файлов, структура с размещение информации в которой представлена метаданными, т.е. ссылочными данными о структуре, месте нахождения и трансформации соответствующих данных. Хранение и использование метаданных в виде многомерной модели позволяет максимально быстро обратиться к ним, благодаря чему будут с одинаково большой скоростью производиться выборка суммируемых (агрегированных) показателей и необходимая навигация и трансформации по любому измерению. В целях достижения оптимальной скорости выполнения запросов с сохранением размеров ХД без существенного увеличения применяется вариант гибридной OLAP, где детализированные данные остаются в реляционной БД (там где они находились изначально), а показатели сформированные аналитические сведения и таблицы (агрегированные) выносятся в специально созданную структуру – ХД.В процессе использования АПС, пользователям зачастую приходится выполнять сложные аналитические задания, составляя логические запросы непосредственно в БД. Во многих запросах задействуются атрибуты элементов или автономных БД, или правила интеграции которых, и их логика связывания не позволяет выполнить комплексный запрос. Обеспечить физическую интеграцию таких автономным БД по правилам исполняемого запроса не всегда представляется возможным и не актуальным для подавляющего большинства сотрудников использующих АПС. При этом правила этой предполагаемой интеграции не являются постоянными или зависят от моментного содержания сторонней (третьей) БД. В качестве решения предложено логическое объединение автономных БД в виде виртуального хранилища, о чем говорилось в предыдущих главах. Для решения данной проблемы локально для пользователя АРМа создается

16

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

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

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

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

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

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

17

структура программного комплекса, представима матрицей (§2.4), объектами учета которой являются программные модули системы. Выполнение определенных срезов данной многомерной структуры будет определять либо существующую конфигурацию АПС, либо создание новой конфигурации, создание нового вида учета, определение политики интеграции с уже существующими учетами, при этом для хранения и формирования ряда индексных реквизитов взаимодействующих объектов учета, на основе разработанных методов, применена технология многомерного анализа OLAP. Фрагмент формальной интегральной модели программного комплекса приведен на рис. 6.1.

Рис. 6.1 - Фрагмент формальной интегральной модели программного комплекса

При проведении реинжиниринга происходит замена (добавление) соответствующих программных модулей сохраняющих соответствия с объектами предметной области. Один из параметров многомерной матрицы - время. Отсюда сохраняется возможность повторного выполнения (старых) заданий, путем указывания времени (т.н. времени актуализации). Тем самым обеспечивается "повторяемость" и прослеживаемость.Структура нейросетевого блока обеспечения интерактивной оптимизации скорости работы комплекса, для каждого рабочего места приведена на рис.6.2.Разработана референтная модель категории определяющих критериев для создания ПК:

18

1. Обеспечение требований необходимой открытости (универсальности): должна обеспечиваться работа под управлением минимально

необходимого количества ОС; при программировании модулей должен применяться

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

Рис.6.2 - Структура нейросетевого блока

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

использование CASE средств; открытая архитектура и возможности экспорта/импорта.

2. Реализация максимально возможной независимости от платформы: платформо-независимый программный интерфейс; реализация недостающей функциональности платформы с

помощью программной эмуляции.3. Дробное резервирование информации, в том числе в форме OLAP-

кубов, с максимальной независимостью от программного обеспечения их обработки:

независимость данных от языка программирования программного модуля;

ипользование общепринятых, стандартных нотаций и соглашений.

На основе референтной модели разработана система, включающая нормативную документацию по ПК "Факт". Информация о минимально

19

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

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

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

6.2. Архитектура программных компонент обеспечения функционирования программного комплекса "Факт"

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

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

20

относительную независимость этих стадий, может быть решен вопрос их распараллеливания. Предложенная итеративная модель в виде рекуррентной формулы, позволяет это. Причем в течение этого переходного периода, для осваивания и проверки новых технологий, может быть решен вопрос об использовании адаптеров, о которых говорилось ранее. Несмотря на то, что будет происходить комплексное снижение производительности информационной системы, такой вариант позволяет постоянно содержать в рабочем состоянии все компоненты как создающейся АПС так и унаследованных БД. Более того, можно организовать, в качестве привития навыков работы с интегрированными данными АПС, использование их новых возможностей.Например, ряд атрибутов документов разных учетов, которые находятся в пределах одной БД и имеют схожее семантическое значение, могут быть логически объединены в новый класс (группу), получившую название "внутренняя". Для аналогичных атрибутов разных БД ввести класс "внешней" группы (о которой говорилось ранее). При этом “связывание” и "развязывание" атрибутов документов в указанные классы, может выполняться в произвольном порядке, т.к. будут действительны только для конкретного пользователя. В результате пользователи продолжают работать по знакомой и хорошо освоенной технологии, и только в случае надобности в получении дополнительной информации активизирует интеграционно - поисковый процесс.В настоящий период есть систематизация аналитических программных систем по принципу технологического построения в части организации автоматизированных рабочих мест, из числа которых возможно выделить получившие широкое распространение классы:

класс автономных АРМ. Данный класс включает в себя вид АРМ, которые не связаны с другими АРМ;

класс слабосвязанных АРМ. Данный класс включает в себя вид АРМ, которые связанны с другими АРМ путем обмена данными через переносимые файлы или общие файлы, размещенные в общем ресурсе). Данный вид АРМ не связан по функциям;

класс сильносвязанных АРМ. Данный класс включает в себя вид АРМ, которые связанны: по данным через общие структуры БД, по функциям, в том числе и через общее ядро. Данный вид АРМ реализует переходную технологию от файл-серверной архитектуры к клиент-серверной архитектуре;

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

Иерархия (классификация) функций информационной системы и аналитической программной системы ее реализующей, с точки зрения технологического построения приведена на рис. 6.3.

На самом нижнем уровне (так называемый - "нулевой") находятся функции (так называемые "вызовы") операционной системы, реализующие

21

операции ввода-вывода информации. На "первом" уровне находятся функции файловой системы операционной системы или СУБД (которые используют свою файловую систему). На "втором" уровне находятся процедуры выборки данных СУБД.

Рис. 6.3 - Иерархия функций ИС и АПС

К данному уровню относятся процедуры реализации сетевых блокировок и транзакционного механизма и такие процедуры как "считать текущую запись в буфер", "перейти на определенное число записей" и т.д. На "третьем" уровне находятся непроцедурные функции СУБД, такие как SQL и т.д. На "четвертом" уровне располагаются технические функции приложения, такие как функция преобразования данных, функции реализации пользовательского интерфейса и т.п. К данному уровню не относятся пользовательские функции разработанные для данного вида СУБД и отвечающие за логику программной системы. На "пятом" уровне находятся функции определяющие логику деятельности, это - бизнес - функции АПС.

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

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

1. Разнести функции администрирования ядра и клиентской части и установить между ними дополнительный компонент – «исполнитель задания» отвечающий за непосредственное получение информации из ядра.

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

22

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

3. Способ установления связи между ними должен быть возложен на специальный программный аппарат недоступный ядру.

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

Очевидно, что в этой технологии, «исполнитель задания» наиболее уязвимое звено. Предлагается для обеспечения надежности производить генерацию – создание данного модуля для выполнения каждого определенного задания. Учитывая, что жизненный цикл этой программы составляет не более нескольких секунд (на практике гораздо меньше), организацией его защиты от поражения вредоносными программами или взлома можно пренебречь. Фрагмент архитектуры процесса выполнения задания ПК приведен на рис. 6.4.

Рис. 6.4 - Фрагмент архитектуры процесса выполнения задания ПК

При организации работы с «распределенными» базами данных архитектура процесса, как правило определяется конкретной СУБД, однако архитектура части процесса, свойственная программному комплексу остается относительно постоянной и может быть представлена схемой[9], приведенной на рис. 6.5.

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

23

и устройства ввода вывода. Для организации доступа к ХД или взаимодействия с ядром программной системы оболочка АРМ производит взаимодействие с виртуальным ядром.

Рис. 6.5 - Фрагмент архитектуры процесса выполнения задания с распределенными БД ПК

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

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

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

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

24

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

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

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

Для идентификации и проверки подлинности пользователей АПС применяются соответствующие механизмы операционной системы и программные средства, специально разработанные для описываемой базы данных[Error: Reference source not found].

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

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

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

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

25

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

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

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

- разрешить редактирование только тех документов, которые созданы тем же пользователем;

- фиксировать дату последнего изменения документа;- фиксировать имя пользователя, при редактировании документа.

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

Созданный таким образом профиль пользователя может быть впоследствии откорректирован или удален при помощи этой же программы.

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

Для решения этой задачи введен аппарат “меток безопасности”. В зависимости от значения, присутствующего в “метке безопасности” конкретного документа, возможно принятие того или иного решения по предоставлению прав доступа к информации данного документа. Например:

- закрытие от просмотра ряда реквизитов документа для данного пользователя или класса пользователей;

- запрет на редактирование ряда реквизитов документа для данного пользователя или класса пользователей;

- закрытие от просмотра всего документа для данного пользователя или класса пользователей;

- запрет от просмотра всего документа для данного пользователя или класса пользователей;

26

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

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

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

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

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

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

27

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

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

В архитектуре АПС можно выделить следующие части:1. головная программа; 2. посредник, предназначенный для реализации связи между

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

модули, реализующие определенные полезные функции.Таким образом, структура ПК "Факт" соответствует предложенной

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

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

28

Рис. 6.6 – Основы концепции построения ИС учета населения

При построении ИС предусматривались 2 вероятных вида предоставления услуг органами государственной власти жителям:

• процесс получения услуги посредством обращения гражданина в орган государственной власти, к примеру – услуги республиканского адресно-справочного бюро при УФМС Российской федерации по РБ [Error:Reference source not found];

• процесс получения услуги гражданином напрямую через обращение к аналитической программной системе. В связи с отсутствием в настоящее период действующих законов об электронном документе и «раскрываемой информации» персональных сведений, этот режим был законсервирован[Error: Reference source not found].

В качестве аналитической программной системы используется программный комплекс "Факт". Информационная системы выстроена по адресно-территориальному принципу[Error: Reference source not found], имеет трех уровневую архитектуру, которая приведена на рис.6.7:

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

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

29

Рис. 6.7 – Трехуровневая архитектура АПС учета населения

"верхний" уровень архитектуры служит целям формирования и сопровождения БД учета населения региона в целом, с обеспечением ряда специфических функций включая идентификацию поступающих данных при наличии неполной или нечеткой информации по основным установочным данным, а также формирование репозитория на основании предположительной идентификации по похожести основных идентификационных данных и т.д.[Error: Reference source not found].

Остановимся поподробнее на описании АПС каждого упомянутого уровня.

"Нижний" уровень архитектуры. В дополнение к ранее сказанному необходимо добавить, что значимым итогом внедрения АПС этого уровня является автоматическое обеспечение актуальности информации в "нижнем" уровне и формирование “бесплатного” источника актуализации БД более высоких уровней[Error: Reference source not found].

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

30

технологические построения - классы АРМ о которых говорилось ранее[Error:Reference source not found]:

класс слабосвязанных АРМ; класс сильносвязанных АРМ; класс логических АРМ, связанных одновременно по данным и по

функциям при использовании АПС в локальной или распределенной сети. Повышенное внимание уделено помехозащищенности и надежности

хранения информации, с целью чего же реализованы технологические процессы распределенного взаимодействия задач. Предусмотрена возможность частичного копирования данных и формирования дополнительных копий. В качестве отдельного структурного объекта АПС присутствует программный модуль - поисковый генератор, реализующий выполнение поисковых заданий согласно любой совокупности атрибутов. Задаваемые условия поиска могут иметь сложную структуру, включая формулы и операторные скобки, использование аппарата макросредств - системных и создаваемых пользователями, запоминанием условий задания и при необходимости его изменения или неоднократного повторения , а также "отката" к предшествующему варианту. При работе в одноранговых сетях или одиночном компьютере предусмотрены режимы дополнительного санкционирования доступа. Представленная реализация аналитической программной системы функционирует под управлением операционной системы WINDOWS. Предусмотрено масштабирование режимов работы начиная от автономных АРМ до работы в распределенной информационной сети, настройка не требует специальных знаний[169,170].

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

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

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

31

проживания или редактирование адреса регистрации граждан по соответствующим им полным или неполным идентификационным сведениям. Также в АПС данного уровня реализуется формирование проблемно-ориентированных списков исходя из первичных данных по любым заданным группирующим признакам[169,170].

Информационно-справочное обслуживание населения производится путем исполнения большого числа, как формализованных, так и неформализованных заданий. Актуализация БД производится за счет технологии обмена данными с АПС других уровней. Т.е. согласно предложенной методологии АПС каждого уровня образуют отдельные категории, отношения между ними являются также объектами и реализуются в виде отдельного программного модуля. Информационные потоки, между этими двумя категориями идут в обоих направлениях:

основной поток идет с "низкого" уровня к "среднему" уровню и включает в себя новые данные или подвергшиеся редактированию;

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

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

В функции АПС этого уровня в частности входит осуществление следующих ключевых технологий и задач:

• ввода данных от абсолютно всех АПС "среднего" и "нижнего" уровней;

• обеспечение непрерывного режима работы - 24/7 с обеспечением своевременного аналитического и информационного обслуживания большого количества абонентов и АПС "среднего" и "нижнего" уровней.

При актуализации АПС "верхнего" уровня, ввода в ХД информационных сведений из АПС "нижнего" и "среднего" уровней встает проблема обеспечения однократного учета документов, что требует решения проблемы однозначной идентификации, на базе полного набора основных и дополнительных сведений из адресных листков "прибытия" и "убытия". Список атрибутов, с помощью которых производится идентификация, формируется специальным программным модулем нечеткой идентификации, фрагмент алгоритма которого приведен на рис. 6.8. Так, идентификация объекта учета будет считаться завершенной успешно, если выполняются одно из указанных ниже условий[169,170]:

полное совпадение основных установочных данных на человека - ФИО, даты и места рождения и адреса места регистрации или пребывания;

при отсутствии полного совпадения ФИО, но наличием соответствия с достаточной степенью похожести ФИО и даты рождения и полном соответствии места рождения и адреса места регистрации или пребывания;

32

отсутствие полного совпадения места рождения и адреса места регистрации или пребывания (но есть совпадение с достаточной степенью похожести) и есть полное совпадение ФИО и даты рождения;

полное совпадение ФИО и даты рождения, а также полное совпадение идентификационных номеров документа, удостоверяющего личность гражданина;

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

Так как три идентификационных атрибута документа, удостоверяющего личность «вид–серия–номер» однозначно идентифицируют человека, первоначально происходит сопоставление этих реквизитов поступающего документа с присутствующими в БД. В случае совпадения сверяются показатели ФИО. Полное соответствие указанных атрибутов инициирует окончание процедуры идентификации. Последующими стадиями процесса идентификации является проверка на соответствие (или степень похожести) комбинации атрибутов «ФИО–дата и место рождения – адрес места регистрации или пребывания.

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

33

Рис. 6.9 – Фрагмент структурной схемы АПС "верхнего" уровня

Атрибуты документов разделены на соответствующие классы, по каждому классу высчитывается степень соответствия, с учетом нормированных коэффициентов значимости установленных для каждого критерия. При получении общего результата не ниже 0.85 принимается решение об успешной идентификации, если результат ниже 0.60 - решение об отсутствии идентификации, в интервале от 0.61 до 0.84 - требуется привлечение в роли эксперта сотрудника. Фрагмент структурной схемы АПС "верхнего" уровня приведен на рис. 6.9.

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

34

6.4. Архитектура информационной системы "Программа Информирования, Анализа и Контроля (ПИАК)" на базе ПК "Факт"

В качестве примера рассмотрим архитектуру автоматизированной информационной системы «ПИАК-дежурная часть» (расшифровывается как Программа Информирования, Анализа и Контроля), где в качестве основы аналитической программной системы использован программный комплекс «Факт». Одним из звеньев по организации раскрытия преступлений, зарегистрированных в Книге учета сообщений о происшествиях (КУСП) независимо от территории оперативного обслуживания, является подразделение дежурной части ОВД. Их роль в укреплении правопорядка, контроля над оперативной обстановкой на территории республики и обеспечения незамедлительного реагирования в установленном законом порядке на поступившую информацию о преступлениях и происшествиях остается высокой.

Информация о происшествиях и преступлениях, зарегистрированных в КУСП и заполненная в соответствии с «Инструкцией о порядке приема, регистрации и разрешения в органах внутренних дел Российской Федерации заявлений, сообщений и иной информации о происшествиях»[Error:Reference source not foundError: Reference source not found] вводится в ОВД в базу данных «ПИАК» в виде электронной карточки. Карточка по электронным каналам связи МСПД «Дионис» или по выделенной телефонной или оптоволоконной линии передается в дежурную часть МВД по РБ в сроки, предусмотренные нормативными документами. О направлении донесения делается отметка в КУСП с указанием времени, когда и кем принято сообщение.

Создание системы информационной системы «ПИАК-дежурная часть» было осуществлено на базе и в полном соответствии с формализованной орг. структурой и основными принципами, представленными на рис.6.10.

35

Рис. 6.10 - Основы концепции построения АПС "ПИАК"

При построении ИС предусматривались 2 вероятных вида предоставления услуг органами государственной власти гражданам[Error:Reference source not found,Error: Reference source not found]:

• процесс получения услуги посредством обращение гражданина в орган государственной власти;

• процесс получения услуги гражданином напрямую через обращение к аналитической программной системе. В связи с отсутствием в настоящее период действующих законов об электронном документе и «раскрываемой информации» персональных сведений, этот режим был законсервирован[Error: Reference source not found]. В качестве аналитической программной системы используется программный комплекс "Факт". Информационная системы выстроена по территориальному принципу[Error:Reference source not found], имеет трех уровневую архитектуру, которая приведена на рис.6.11:

Рис. 6.11 – Фрагмент трехуровневая архитектура АПС "ПИАК"

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

36

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

"средний" уровень архитектуры предназначен для формирования в БД учетных и аналитических сведений по обслуживаемому району (городу). Реализация АПС данного уровня позволяет обеспечить необходимое информационное сопровождение работы дежурных частей, формирование проблемно-ориентированных списков исходя из первичных данных по любым заданным группирующим признакам[Error: Reference source notfoundError: Reference source not found].

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

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

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

"перекрестный" поток идет от "среднего" уровня к "низкому" уровню и включает в себя перекрестные сведения. Передаваемые АПС "низкого" уровня одной территории обслуживания через АПС "среднего" уровня в АПС "низкого" уровня другой территории. При этом в АПС "среднего" уровня формируется соответствующая запись в БД, которая выступает в роли контролируемого объекта учета. Контроль снимается после прихода подтверждения о постановки на учет по новой территории;

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

ввода данных от абсолютно всех АПС "среднего" и "нижнего" уровней;

37

обеспечение непрерывного режима работы - 24/7 с обеспечением своевременного аналитического и информационного обслуживания большого количества абонентов и АПС "среднего" и "нижнего" уровней.

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

Оперативная информация, учитываемая системой, в частности содержит следующие сведения:

Дату, время поступления сообщения или заявления о преступлении или происшествии в орган или учреждение внутренних дел, номер регистрации по КУСП.

Данные о заявителе: фамилия, инициалы, год рождения, место работы, должность, место жительства.

Дату, время, место, мотив, способ и другие обстоятельства совершения преступления.

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

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

Состав следственно-оперативной группы. Сведения о лицах, подозреваемых в совершении преступления:

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

Данные об изъятых следах, вещественных доказательствах и приметах скрывшихся с мест происшествия преступников.

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

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

При дорожно-транспортных происшествиях – данные о принадлежности транспортного средства, его марка и модель, номерной знак; сведения о водителе, его состоянии, категории прав на управление, водительский стаж; количество пассажиров и сведения о пострадавших; данные о причинах совершения ДТП.

38

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

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

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

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

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

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

Описанные аналитические программные системы в течение ряда лет используются в МВД по Республике Башкортостан, обеспечивая весь требуемый спектр работ по выполнению поисковых и аналитических

39

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

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

Качественный эффект от создания АПС учета населения состоит в существенном увеличении эффективности работы соответствующих органов государственной власти, в части оказания предписанных государственных услуг и с другой стороны улучшения качества планирования своей деятельности на основе мониторинга социально-демографической структуры и состава населения[Error: Reference source not found].В рамках проведенного исследования, были проанализированы различные варианты архитектур и выбраны наиболее оптимальные решения. Так, в качестве технологической архитектуры используется комбинация из клиент-серверной и трехзвенной архитектуры, что позволяет объединить их достоинства и облегчить внедрение. Основываясь на предложенной методологии и методах, архитектура программного комплекса представима в виде многомерной матрицы, различные срезы которой формируют режимы работы, профили пользователей и совокупность программных модулей используемых для конкретной реализации. Один из срезов данной матрицы приведен на рис. 6.12.

40

Рис. 6.12 – Фрагмент архитектуры программного комплексаВозможности, предоставляемые гибкой архитектурой программного

комплекса, позволяют использовать АРМ, как в связке с сервером БД, так и автономно - для обычных пользователей, где возможно использование компьютерной техники более простой конфигурации, что открывает возможность экономии при внедрении и снижении нагрузки на сеть, а также более оптимального масштабирования программного комплекса в целом и достижения лучших функциональных и потребительских показателей. Фрагмент архитектуры процесса взаимодействия модулей режимов программного комплекса приведен на рис. 6.13.

41

Рис. 6.13 – Фрагмент архитектуры процесса взаимодействия модулей режимов программного комплекса

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

функциональными процессами;• повышение качества управления соответствующим контентом; • повышение эффективности распределения ресурсов по этапам ЖЦ

соответствующих БП и качества управления по принципу обратной связи;

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

42