Модели и алгоритмы обработки информации в программных комплексах электронного документооборота тема диссертации и автореферата по ВАК РФ 05.13.18, кандидат физико-математических наук Волков, Леонид Михайлович

• Волков, Леонид Михайлович
• кандидат физико-математических наук
• 2006

Оглавление диссертации кандидат физико-математических наук Волков, Леонид Михайлович

ВВЕДЕНИЕ.

0.1. Цель исследования.

0.2. Актуальность исследования.

0.3. Постановка задачи.

0.3.1. Терминология.

0.3.2. Компоненты системы.

0.3.3. Программные модули.

0.3.4. Вспомогательные элементы модели.

0.3.5. Организация документооборота.

0.3.6. Обеспечение информационной безопасности в системе.

0.4. Теоретические основы.

0.4.1. Управление целостностью.

0.4.2. Транзакции и параллельность.

0.4.3. Обеспечение информационной безопасности.

0.5. Краткое описание достигнутых результатов.

0.6. Структура работы.

ГЛАВА 1. АЛГОРИТМЫ ОБРАБОТКИ ИЗМЕНЯЮЩИХСЯ ВО ВРЕМЕНИ ДАННЫХ.

1.1. Представление хронологических данных.

1.1.1. Обозначения и определения.

1.1.2. Реализация операций.

1.1.3. Высокопроизводительное хронологическое дерево.

1.1.4. Резюме.

1.2. Целостность хронологических данных.

1.2.1. Постановка задачи.

1.2.2. Целостность среза.

1.2.3. Целостность всего хронологического дерева.

1.2.4. Добавление связи в срез.

1.2.5. Добавление множества связей в срез.

1.2.6. Резюме.

1.3. Применение хронологических структур в системе электронного документооборота.

ГЛАВА 2. МАТЕМАТИЧЕСКАЯ МОДЕЛЬ ПРЕОБРАЗОВАНИЯ ДАННЫХ.

2.1. Формы представления данных.

2.2. Преобразование данных: подзадачи.

2.2.1. Хранилище (Storage).

2.2.2. Модуль загрузки (Loader).

2.2.2.3. Модуль выгрузки (Saver).

2.2.4. Модуль проверки (Checker).

2.2.5. Соединение модулей.

2.3. Компонентная модель KDOM.

2.3.1. Loader.

2.3.2. Saver.

2.3.3. Storage.

2.3.4. Schema.

2.3.5. Checker.

2.3.6. Резюме.

2.4. Язык представления метаинформации.

2.4.1. Описание типов данных.

2.4.2. Описание визуальных представлений.

2.4.3. Описание форматов вывода.

Введение диссертации (часть автореферата) на тему «Модели и алгоритмы обработки информации в программных комплексах электронного документооборота»

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

Взрывное развитие отрасли неизбежно было связано с тем, что практическая составляющая оказалась далеко впереди теоретической. Проектирование и разработка серьезных программных комплексов велись в 80-х и 90-х годах прошлого столетия зачастую на интуитивном уровне — необходимой теории просто еще не существовало! Отсюда и такой большой процент «брака», и удивительные провалы лидеров IT-рынка (наиболее ярким и памятным примером является, наверное, крах проекта OS/2 компании IBM). В самые последние годы, на основании анализа удачных и неудачных проектов недавнего прошлого, как самостоятельная отрасль компьютерных наук начала развиваться теория проектирования программного обеспечения.

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

Основополагающими работами в области теории проектирования программного обеспечения стали статьи и книги Г. Буча (в первую очередь отметим монографии [5, 39, 40]); несколько позже инициатором и вдохновителем исследований в этой области стала корпорация Microsoft (основные результаты этих исследований сжато представлены в книге [29]). Результатом исследований стали несколько модельных систем разработки промышленных программных комплексов, из которых наиболее значимыми являются:

• парадигма объектно-ориентированного анализа и проектирования Буча, инструментальной основой которой являются язык UML и программные средства автоматизации разработки компании Rational Software;

• методология разработки программного обеспечения Microsoft Solutions Framework (MSF), поддерживаемая в иинструментальных плафтормах разработки компании Microsoft (прежде всего, в платформе Microsoft Visual Studio);

• методология разработки программного обеспечения и организации совместных действий команды разработчиков «экстремальное программирование» (eXtreme Programming —

ХР), поддерживаемая в многочисленных инструментальных системах, разрабатываемых на принципах open source;

• парадигма «паттернов проектирования» Э. Гаммы и соавторов ([10]), формализующая процесс повторного использования проектных решений, и применимая практически в любом технологическом процессе разработки ПО.

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

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

В России в настоящее время создано и внедряется достаточно большое количество систем электронного документооборота, различающихся по технологическим подходам и рыночным нишам. Наиболее развитыми, законченными программными комплексами электронного документооборота являются системы «Дело» (разработчик — ООО «Электронные офисные системы», г. Москва), «Евфрат» (ЗАО «Когнитивные технологии», г. Москва), «Спринтер» (разработчик ООО «Такском», г. Москва, см. [27]), «Курьер» (ЗАО «Комита», г. Санкт-Петербург), «СБИС++» (ЗАО «Тензор», г. Ярославль, см. [28]) и некоторые другие. Из вышеперечисленных систем, в первой, по мнению автора, наиболее глубоко реализовано внутреннее хранилище информации, во второй — система управления цепочками документов. Три последних упомянутых системы являются наиболее характерными представителями систем, в которых электронный документооборот понимается как передача форматированных массивов данных, без их синтаксической обработки. Анализ практики внедрения этих систем, их достоинств и недостатков, технологических особенностей, является важным источником материала для обобщения и поиска закономерностей.

На рынке программных продуктов для автоматизации деятельности хозяйствующих субъектов отечественные продукты, естественно, конкурируют с зарубежными разработками, такими как Documentum (компания EMC Documentum, Калифорния, США) и Hummingbird DM (компания Hummingbird, Торонто, Канада). Однако проникновение иностранных систем электронного документооборота на российский рынок пока не является ощутимым (фактически, ограничиваясь несколькими десятками внедрений двух указанных систем), что может быть объяснено

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

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

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

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

1 В этом не следует видеть нечто удивительное или исключительное. Российская IT-индустрия по ряду объективных причин практически безнадежно отстала от зарубежной в целом ряде областей - операционные системы и общесистемные средства, сетевое ПО и СУБД, интегрированные среды разработки и офисные пакеты. На Западе старт бизнесу в этих направлениях был дан на 10-20 лет раньше, чем в России, и не стоит удивляться, что это привело к нашему катастрофическому отставанию. Однако в целом ряде других областей Россия занимает лидирующие или, по крайней мере, значимые позиции: трехмерная графика, распознавание образов, машинный перевод, антивирусные технологии, сжатие информации, передача потокового видео и многие другие. Это те области, в которых, во-первых, активное развитие началось только в последние 10-15 лет (когда российская IT-индустрия уже жила по законам бизнеса и была включена в мировое информационное пространство), и, во-вторых, требуется применение особо наукоемких технологий, и удалось приложить мощь отечественной фундаментальной науки. Поэтому отечественным системам электронного документооборота тоже не всегда следует специализированных разработок, не представленных на российском рынке, но содержащих реализацию ярких и современных идей. Это, например, программный продукт PDFFaktura (компания Ximantix, Мюнхен, ФРГ) с блестящей реализацией идеи автоматического и взаимно однозначного преобразования документа из машиночитаемой формы и обратно; система Governikus (BOS, Бремен, ФРГ) - комплекс решений для документооборота с правительственными органами и некоторые другие.

Разработчики всех вышеуказанных систем, естественно, уделяли внимание вопросам понимания принципов их проектирования (иначе не могло бы быть и речи о серьезных проектах, находящих применение в промышленных масштабах). Специфические теоретические вопросы, посвященные тем или иным аспектам электронного документооборота, находили отражение в работах авторских коллективов под руководством В.Л.Арлазорова (исследования проводились в Институте системных исследований РАН, см. [1, 2, 14, 22]) и В.Э.Баласаняна (в Институте архивного дела, см. [4, 30, 31]), а также некоторых других. Однако данные работы были направлены, в первую очередь, на уточнение понимания принципов работы хранилищ документов и настройки прав доступа к документам в рамках одного сервера обработки данных. Вопросы собственно электронного документооборота — пересылки форматированных данных между различными узлами их обработки, — с точки зрения принципов проектирования соответствующих программных комплексов ранее не рассматривались. равняться на иностранные аналоги: область молодая и наукоемкая, а потому многим зарубежным программным комплексам есть, что перенять у российских.

Впервые в отечественной литературе уделяется также внимание специальному типу хранилищ данных, имеющему особенное значение в промышленных комплексах документооборота, оперирующих крупными массивами информации, накапливаемыми со временем. Общая теория современных реляционных хранилищ данных создавалась в 70-80-х годах прошлого века в работах Ф.Кодда ([44]), К.Дж. Дейта (особо значима фундаментальная монография [15]) и многих других авторов. Тогда же впервые попали в зону пристального внимания математиков хронологические структуры данных (предназначенные для хранения и обработки массивов информации, изменяющейся во времени). Основной вклад в изучение хронологических структур данных внес лауреат премии Неванлинны Р.Тарджан с группой соавторов ([49, 50]). В настоящей работе изучаются вопросы практического применения хронологических структур данных в современных информационных системах, для которых характерно размещение массивов данных в реляционных СУБД.

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

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

Практическим результатом проведенной автором работы стала система «Контур-Экстерн» — флагманская разработка компании «СКБ Контур», лидер отечественного рынка систем электронного документооборота. Разработка системы «Контур-Экстерн» и связанные с ней исследования в области моделей и алгоритмов обработки информации в программных комплексах электронного документооборота были начаты летом 2000 года. В это время, в частности, были разработаны алгоритмы обработки информации, изменяющейся во времени с использованием хронологических деревьев (эти результаты представлены в первой главе диссертации), что позволило с самого начала обеспечить эффективное хранение и проверку целостности больших объемов обрабатываемых в системе данных. Основная часть этих исследований была опубликована в работе [61]. Тогда же была принята идеология «тонкого клиента», определившая необходимость разработки мощной модели серверного узла, на котором производится обработка форматированной информации. Обоснование (как технологическое, так и экономическое) выбора данной технологии для программного комлпекса электронного документооборота было впервые дано в публикации [58].

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

Проведенная в начале 2002 года первая опытная эксплуатация системы в условиях больших нагрузок и объемов документооборота, выявила определенные слабости первоначальной теоретической модели обработки данных. В 2002-2003 годах автором была построена описанная во второй главе диссертации математическая модель информационных потоков в программных комплексах электронного документооборота. В связи этим, была предпринята полная переработка программного кода системы. Созданная модель информационных потоков не публиковалась (как коммерческая тайна компании «СКБ Контур») до оформления автором патента [65], в котором она была полностью описана. После публикации патента общие принципы модульной архитектуры системы «Контур-Экстерн» были представлены в работах [70] и [71].

С января 2003 года начата промышленная эксплуатация созданного программного комплекса, получившего название «Контур-Экстерн». Важнейшие компоненты этого программного комплекса (серверный и локальный узлы обработки форматированной информации) защищены авторскими свидетельствами [66, 67].

С ростом объемов документооборота и увеличением количества поддерживаемых типов и форматов документооборота, в 2004 году основной акцент исследований был смещен на повышение производительности и устойчивости системы. В результате этих исследований была начата очередная (третья по счету) смена внутренней архитектуры системы, которая продолжается и по настоящий день одновременно с расширением масштабов промышленной эксплуатации системы. Результаты исследований по глобальной архитектуре программного комплекса изложены в публикации [62]. Практике первых лет промышленной эксплуатации системы «Контур-Экстерн» посвящена статья [63]. Представленная в настоящей работе теоретическая модель полностью соответствует принятой на сегодняшний день практической модели обработки информации в программном комплексе «Контур-Экстерн». * *

Автор настоящей работы в период с 2000 по 2002 год был проектировщиком и ведущим программистом проекта «Контур-Экстерн», в 2002-2003 годах руководителем разработки проекта, с середины 2003 года по настоящее время — осуществляет общее руководство разработкой, обслуживанием и продвижением системы. В течение всего периода разработки и развития системы автор был основным (а до середины 2003 года — единственным) проектировщиком проекта, к компетенции которого относились все решения в отношении внутренней архитектуры разрабатываемого программного комплекса.

В настоящее время в России абонентами системы «Контур-Экстерн» является более 120 тысяч юридических и физических лиц, налоговых органов, органов местного самоуправления, кредитных организаций. Система внедрена и функционирует в документообороте налогоплательщиков и налоговых органов в 80 субъектах Российской федерации (из 88). Ежеквартально посредством системы «Контур-Экстерн» в электронном виде формируется, передается и обрабатывается более 2.5 миллионов электронных документов. Благодаря этому, система «Контур-Экстерн» является крупнейшим из эксплуатируемых в России программных комплексов электронного документооборота, как по своим масштабам, так и по темпам развития.

Автор работы выражает благодарности научному руководителю, профессору, доктору физико-математических наук Виталию Анатольевичу Баранскому за многочисленные ценные наблюдения, замечания и обсуждения в процессе подготовки диссертации; техническому директору компании «СКБ Контур» Эдуарду Романовичу Шифману за вдохновляющие обсуждения, помогшие пробросить мостик от теории к практике.

0.1. Цель исследования

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

Цель исследования заключается

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

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

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

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

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

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

0.2. Актуальность исследования

Компьютеры, появившиеся в середине 20-го столетия, эксплуатировались в первую очередь как мощные вычислительные устройства. Сам английский термин computer («вычислитель») и его русский аналог ЭВМ (электронная вычислительная машина) указывали именно на этот функционал компьютеров как на основной. Однако, в процессе развития компьютерной техники счетно-вычислительная функция ушла на второй план: экспоненциальное возрастание емкости устройств хранения информации, сопровождавшееся ростом вычислительных мощностей привело к тому, что компьютер стал главным помощником человека в деле хранения и обработки все увеличивающихся объемов информации, характерных для информационного общества. Уже в 70-х годах прошлого века большая

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

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

2 Здесь надо отметить, что в последнее время, в связи с развитием клиент-серверных технологий, систем «тонкого клиента», в системах внутреннего корпоративного документооборота собственно документооборот больше не происходит. Дело в том, что в этих системах класса docflow организуется глобальное хранилище документов системы на общем сервере, а «передача» документа от одного пользователя к другому заключается лишь в перенастройке прав доступа к документу в этом общем хранилище. Таким образом, фактически передача документов имеет место лишь только в системах внешнего документооборота. Поэтому, на наш взгляд, по отношению к клиент-серверным системам

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

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

В связи с необходимостью ресурсосбережения, выправления тяжелой экологической ситуации, создавшейся на планете, крайне важным классом являются системы безбумажного документооборота, в которых весь обмен данными происходит исключительно в электронном виде. Как правило, при документообороте между независимыми субъектами, системы безбумажного документооборота одновременно должны являться системами юридически значимого docflow правильнее применять термин (и этот термин находит все большее распространение в последнее время) «СУД» — система управления документами (соответствующий общепринятый англоязычный термин - DMS, document management system), — что гораздо более точно отражает функциональность таких систем и суть происходящих внутри них процессов. Всегда ниже, говоря о системе электронного документооборота, мы будем подразумевать систему, в которой наличествуют по крайней мере две географически разнесенных точки обработки документов, и имеет место процесс «физического» документооборота — передачи электронных документов по телекоммуникационным каналам связи. электронного документооборота, то есть обеспечивать возможность проверки легитимности информации, поступающей из внешнего источника.

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

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

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

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

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

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

0.3. Постановка задачи

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

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

0.3.1. Терминология

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

Определение 0.1. Документ — единица обмена информацией в системе защищенного электронного документооборота, представляющая собой пару объектов файловой системы: файл установленного формата и файл, содержащий множество электронных цифровых подписей документа.

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

В системе электронного документооборота открытого назначения единицей обмена информацией (документом) является файл установленного формата.

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

Определение 0.3. Формат — формализованное описание состава и структуры показателей для определенного типа документов. Формат определяет типы данных по каждому из показателей, условия их присутствия, порядок следования в файле и другие условия, соблюдение которых необходимо для проведения автоматизированной обработки файлов.

Определение 0.4. Абонент системы — участник документооборота, обладающий ЭЦП, и осуществляющий обмен форматированными документами с другими абонентами.

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

0.3.2. Компоненты системы

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

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

Рабочее место абонента системы используется для доступа к серверу системы. Абонент имеет возможность устанавливать соединение с сервером системы и работать с размещенным там программным обеспечением.

Удостоверяющий центр — основа криптографической инфраструктуры системы. В удостоверяющем центре в соответствии с Федеральным Законом №1-ФЗ от 10.01.2002 года «Об электронной цифровой подписи» (см. [32]) осуществляется сертификация открытых криптографических ключей абонентов системы. Сертификаты открытых ключей используются для осуществления ЭЦП, шифрования и взаимной аутентификации абонентов системы.

0.3.3. Программные модули

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

Программное обеспечение сервера оператора системы является основным модулем системы. Это программное обеспечение предоставляет следующую функциональность:

• ввод данных абонентом через web-интерфейс в установленные формы;

• контроль файлов на соответствие установленным форматам в режиме реального времени;

• импорт данных из файлов установленного формата;

• доверенная аутентификация абонентов и организация разграничения доступа абонентов к своим базам данных;

• доставка документов от абонентов системы в контролирующие органы и обратно;

• архивирование электронных документов, протоколирование процесса документооборота.

0.3.4. Вспомогательные элементы модели

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

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

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

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

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

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

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

0.3.5. Организация документооборота

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

• автор документа — абонент, получатели — группы абонентов;

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

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

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

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

0.3.6. Обеспечение информационной безопасности в системе

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

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

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

Любой документ, возникающий в системе, вне зависимости от его авторства и предназначения, обязательно подписывается ЭЦП автора документа в момент отправки документа посредством системы. Электронная цифровая подпись применяется в соответствии с Федеральным Законом №1-ФЗ от 10.01.2002 года «Об электронной цифровой подписи» ([32]) и служит юридически значимым средством заверения обращающихся в системе документов. Каждый документ в системе, подписывается, как правило, двумя ЭЦП (отправителя и получателя), и хранится в двух экземплярах (не считая резервной копии на сервере системы).

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

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

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

0.4. Теоретические основы

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

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

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

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

0.4.1. Управление целостностью

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

Пример 0.1. Ограничением реального мира (в данном примере — законодательным) является условие обязательного наличия у всякого субъекта информационного обмена с налоговым органом индивидуального номера налогоплательщика (ИНН), причем ИНН юридического лица состоит из 10 цифр, а ИНН физического лица — из 12 цифр. Соответственно, любое хранилище любого из узлов обработки данных системы электронного документооборота налогоплательщиков и налоговых органов имеет в составе предиката целостности (в качестве одного из конъюнктов) и соответствующее условие, не допускающее появление в качестве значение реквизита ИНН одной из записей, скажем, 11-значного числа, или 10-значного, если значение реквизита «Тип налогоплательщика» указывает на физическое лицо. При этом логическая организация хранилища данных не имеет значения; в любом случае, в нем присутствует программный модуль, обеспечивающий проверку ограничений целостности.

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

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

Декларативные ограничения целостности можно разделить на три вида:

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

• ограничения кванта данных (задают множество допустимых значений для конкретного кванта данных);

• ограничения набора данных (задают взаимосвязи между значениями квантов данных);

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

Пример 0.2. Для типа данных «эллипс», который определяется координатами центра и длинами полуосей, может быть задано3 такое ограничение домена:

TYPE Ellipse

REPRESENTATION

STRUCT{A REAL, В REAL, Center POINT}

CONSTRAINT Ellipse.A >= Ellipse.В

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

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

Пример 0.3. Вот как может быть сформулировано описанное выше ограничение на ИНН:

CONSTRAINT INN

ISEMPTY(Org) WHERE

Org.Type=l AND Org.INN.Length!=10) OR (Org.Type=2 AND Org.INN.Length!=12)

3 В примерах этого параграфа использован учебный SQL-подобный язык Tutorial D из книги К.Дж.Дейта «Введение в системы баз данных» ([15]).

Все типы ограничений целостности используются для решения одной и той же задачи — наделить систему достаточно хорошим «пониманием» предиката хранилища данных. Фундаментальный закон, который называют золотым правилом, гласит:

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

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

0.4.2. Транзакции и параллельность

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

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

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

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

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

Транзакции имеют четыре основных свойства, которые принято называть ACID-свойствами (от atomicity, consistency, isolation, durability).

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

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

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

• Begin Transaction

• Commit

• Rollback

Оператор Begin Transaction фиксирует точку начала транзакции. Оператор Commit фиксирует точку завершения транзакции. После выполнения оператора Commit транзакция считается завершенной успешной, а ее результаты — необратимыми. Оператор Rollback вызывается, если транзакция, по каким-либо причинам, оказалась неудачной. Он может быть вызван как явно, при обработке некоторых исключительных ситуаций в коде транзакции, так и принудительно, если проверка ограничений целостности при вызове оператора Commit показала, что транзакция не завершила работу с целостным состоянием хранилища данных. Результатом работы оператора Rollback является возврат хранилища данных в состояние, непосредственно предшествовавшее вызову оператора Begin Transaction5.

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

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

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

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

• транзакции, успешно завершенные после последней контрольной точки, осуществляются заново;

• транзакции, не завершившиеся к моменту сбоя системы, отменяются.

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

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

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

В контексте систем обработки и хранения информации, необходимо решить три основных проблемы параллельности. Это

• проблема потери результатов обновления;

• проблема зависимости от незафиксированных результатов;

• проблема несогласованной обработки данных.

Проблема потери результатов обновления — одна из самых типичных. Транзакция А читает набор данных X в момент времени tb а транзакция В — в момент времени t2. Обе транзакции обрабатывают извлеченный набор данных (один и тот же), и транзакция А обновляет набор данных X в момент времени t3. На этом транзакция А успешно завершает свою работу, результаты работы фиксируются. После этого, в момент времени t4 завершает свою работу и транзакция В, также записывая в хранилище данных некоторое обновленное значение набора данных X. При этом, очевидно, результаты работы транзакции А оказываются утраченными.

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

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

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

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

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

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

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

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

• эксклюзивные блокировки сохраняются вплоть до конца транзакции — до ее отката или фиксации; разделяемые блокировки также обычно сохраняются до конца транзакции.

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

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

0.4.3. Обеспечение информационной безопасности

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

Основными угрозами информационной безопасности являются

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

• угроза искажения содержания электронного документа в процессе его передачи;

• угроза искажения информации об авторстве электронного документа.

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

Практическое применение средств криптографической защиты информации в Российской Федерации связано с соблюдением определенных ограничений, налагаемых действующим законодательством. Так, ограничено распространение СКЗИ и их техническое обслуживание. Эту деятельность, равно как и предоставление услуг в области шифрования сведений, не представляющих собой государственную тайну, могут выполнять только лицензиаты ФСБ России ([34]). Государственные лицензии требуются также на право проектирования, разработки и производства, защищенных с использованием СКЗИ телекоммуникационных информационных систем. Осуществляя разработку программного комплекса и последующее распространение этого комплекса, используемых в его составе СКЗИ, лицензиат ведет поэкземплярный учет программных средств защищенной системы, СКЗИ и ключей ([26]). Применяемые в составе программного комплекса защищенного документооборота СКЗИ должны быть сертифицированы ФСБ России на соответствие отечественных криптографическим стандартам ГОСТ 28147-89, ГОСТ Р 34.10-2001, ГОСТ Р 34.11-94 ([11, 12, 13]). Наконец, для обеспечения юридической значимости электронных документов необходимо обеспечить соответствие всех процедур электронной подписи положениям Федерального Закона №1-ФЗ «Об электронной цифровой подписи» ([32]).

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

• задача обеспечения защиты от несанкционированного доступа — путем применения всеми участниками документооборота СКЗИ, сертифицированных на соответствие ГОСТ 28147-89, и обеспечивающих симметричное шифрование передаваемых электронных документов в соответствии с указанным ГОСТ;

• задача обеспечения целостности электронного документа — путем применения СКЗИ, сертифицированных на соответствие ГОСТ Р 34.11-94, и обеспечивающих хэширование передаваемых электронных документов в соответствии с указанным ГОСТ;

• задача обеспечения возможности установить авторство электронного документа — путем применения СКЗИ, сертифицированных на соответствие ГОСТ Р 34.10-2001, и обеспечивающих ЭЦП передаваемых электронных документов в соответствии с указанным ГОСТ, а также путем развертывания инфраструктуры открытых ключей в соответствии с ФЗ «Об ЭЦП».

Указанными свойствами обладает ряд представленных на рынке коммерческих СКЗИ, из которых в составе программного комплекса «Контур-Экстерн» поставляются «Крипто-Про CSP» версии 2.0 (разработчик — ООО «Крипто-Про») или «Домен-К» версии 3.0 (разработчик — ОАО «Инфотекс»).

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

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

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

• вырабатывается одноразовый симметричный сеансовый ключ, соответствующий ГОСТ 28147-89;

• на этом ключе производится криптографическое преобразование в соответствии с указанным стандартом;

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

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

0.5. Краткое описание достигнутых результатов

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

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

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

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

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

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

• Указанные программные комплексы внедрены в процесс организации защищенного электронного документооборота налогоплательщиков и налоговых органов на всей территории Российской Федерации.

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

0.6. Структура работы

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

Заключение диссертации по теме «Математическое моделирование, численные методы и комплексы программ», Волков, Леонид Михайлович

Заключение

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

Оформлены авторское свидетельства №2004611946 и №2004611947 от «23» августа 2004 года, соответственно «Система защищенного электронного документооборота «Контур-Экстерн», на имя Л.М.Волкова и Э.Р.Шифмана ([66]), и АРМ «Прием», на имя Л.М.Волкова ([67]).

Оформлен патент на полезную модель «Автоматизированная система для подготовки и представления отчетности» №43983 от «10» февраля 2005 года на имя Л.М.Волкова и Э.Р.Шифмана ([65]).

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

Основа внешней архитектуры системы «Контур-Экстерн» — так называемый принцип «тонкого клиента», избавляющий налогоплательщика от необходимости обновлять программное обеспечение для формирования отчетности на его рабочем месте. Имеется возможность как подготовки отчетности непосредственно на сервере системы, так и импорта данных из автоматизированных систем бухгалтерского учета большинства производителей. Поддерживается обмен запросами и выписками из лицевого счета налогоплательщика, неформализованный документооборот, отправка сообщений банка налоговому органу об открытии/закрытии счетов. Система «Контур-Экстерн» ежегодно проходит сертификацию в ГНИВЦ ФНС России.

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

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

Список литературы диссертационного исследования кандидат физико-математических наук Волков, Леонид Михайлович, 2006 год

1. Акимова Г.П., Богданов А.С., Емельянов Н.Е., Соловьев А.В., Тищенко В.А. Применение новых информационных технологий в делопроизводстве. // в сб. «Развитие безбумажной технологии в информационных системах». — М.: Институт системного анализа РАН, 1999.

2. Арлазаров В.Л., Емельянов Н.Е. Прикладные аспекты построения систем на основе документооборота. // в сб. «Документооборот. Прикладные аспекты». — М.:Институт системного анализа РАН, 2004.

3. Ахо А., Хопкрофт Дж., Ульман Дж. Структуры данных и алгоритм. — М.: Вильяме, 2003. — 384 с.

4. Баласанян В.Э. Электронный документооборот как эффективный инструмент управления. // Финансовая газета. — 2005, №6. — С. 14.

5. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. — СПб.: Бином, 2001. — 560 с.

6. Вехов В.Б. Компьютерные преступления: Способы совершения и раскрытия / под ред. акад. Б.П. Смагоринского. — М.: Право и Закон, 1996. — 182 с.

7. Вихорев С.В. Что есть что в информационном праве. // http://cyber-crimes.ru/library/articles/legalregulation/.

8. Вихорев С. В., Кобцев Р. Ю. Как узнать — откуда напасть или откуда исходит угроза безопасности информации // Защита информации. Конфидент. — 2002, №2. — С. 44-49.

9. Вихорев С.В., Конфиденциальная информация и законодательство Российской Федерации. //М.: Сборник тезисов выступлений на конференции «Безопасность информации», 2002.

10. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. — СПб.: Питер, 2004. — 368 с.

11. ГОСТ 28147-89 «Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования». — Постановление Госстандарта СССР от 02.06.1989 №1409.

12. ГОСТ Р 34.10-2001 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи». — Постановление Госстандарта России от 12.09.2001 №380-ст.

13. ГОСТ Р 34.11-94 «Информационная технология. Криптографическая защита информации. Функция хэширования». — Постановление Госстандарта России от 23.05.1994 №154.

14. Даниленко А.Ю., Минкин А.И. Анализ основных принципов построения и особенностей защиты информации в системах электронного документооборота. // в сб. «Документооборот. Концепции и инструментарий». — М.: Институт системного анализа РАН, 2004.

15. Дейт К.Дж. Введение в системы баз данных. — М.: Вильяме, 2005. — 1328 с.

16. Дмитриев И.Л., Задворнов И.Н., Федьков Е.А. Автоматизированная система для подготовки и представленияотчетности в контролирующие органы. — Патент на изобретение №RU 02154298 от 28.12.1999.

17. Женило В. Р., Кирин В. И. Цифровой электронный документ // в сб. трудов X Междунар. науч. конф. "Информатизация правоохранительных систем". — С. 46.

18. Кормен Т., Лейзерсон Ч., Ривест Р. Алгоритмы: Построение и анализ. Второе издание. — М.: МЦМНО, 2004. — 960 с.

19. Кукарникова Т.Э. Некоторые проблемы правового регулирования электронного документооборота // Воронежские криминалистические чтения (под ред. О .Я. Баева), вып. 1. — Воронеж: Издательство Воронежского государственного университета, 2000. — С. 110-117.

20. Кукарникова Т.Э. О проблемах правового статуса электронного документа // Воронежские криминалистические чтения (под ред. О.Я. Баева), вып. 3. — Воронеж: Издательство Воронежского государственного университета, 2002. — С. 114-123.

21. Налоговый кодекс Российской Федерации. — Собрание законодательства РФ, №31, 03.08.1998 года, ст. 3824 и №32, 07.08.2000 года, ст. 3340.

22. Порай Д.С., Соловьев А.В., Корольков Г.В., Реализация концепции темпоральной базы данных средствами реляционной СУБД. // в сб. «Документооборот. Концепции и инструментарий». — М.: Институт системного анализа РАН, 2004.

23. Приказ МНС России №БГ-3-32/149 от 25.03.2002 «Об утверждении форматов представления сведений налогой и бухгалтерской отчетности в электронном виде».

24. Приказ МНС России №БГ-3-32/169 от 02.04.2002 «Об утверждении Порядка представления налоговой декларации в электронном виде по телекоммуникационным каналам связи».

25. Приказ ФСБ России №66 от 09.02.2005 «Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации (Положение ПКЗ-2005)».

26. ООО «Такском», Техническая документация и описания к программному комплексу «Спринтер», 2000-2005. — http://www.taxcom.ru/system/technology/.

27. ЗАО «Тензор», Технологическая документация и описания к программному комплексу «Сбис++. Электронная отчетность», 2004-2005. — http://nalog.tensor.ru/product/technology/.

28. Уилсон С.Ф., Мэйплс Б., Лэндгрейв Т., Принципы проектирования и разработки программного обеспечения. — М.: Русская редакция, 2000. — 688 стр.

29. Храмцовская Н.А. Проблемы использования ЭЦП в оперативной работе предприятия // Делопроизводство и документооборот на предприятии. —2005, №6.

30. Храмцовская Н.А., Проблемы долговременного хранения документов, подписанных электронно-цифровой подписью или е аналогом. / Делопроизводство и документооборот на предприятии. — 2005, №7.

31. Федеральный Закон «Об электронной цифровой подписи». — Собрание законодательства РФ, №2, 14.01.2002 года, ст. 127.

32. Федеральный Закон «Об информации, информатизации и защите информации». — Собрание законодательства РФ, №8, 20.02.1995 года, ст. 609.

33. Alexander С., Ishikawa S., Silverstein М. A pattern language: towns, buildings, construction. — Oxford: Oxford University Press, 1977.

34. Bayer R., McCreight E. Organization of large ordered indexes. // Acta Informatica. — 1972, No. 1. —p. 173-189.

35. Beck K., Johnson R. Patterns generate architectures // Proceedings of the European conference on object-oriented programming, Bologna. — Springer, 1994 —p. 139-149.

36. Boehm B. Software engineering economics. — N.Y.: Prentice Hall, 1981.

37. Booch G., Rumbaugh J., Jacobson I. The Unified Modelling Language user guide. —N.Y.: Addison-Wesley, 1998.

38. Booch G., Rumbaugh J., Jacobson I. The unified software development process. — N.Y.: Addison-Wesley, 1999.

39. Booch G., Vilot M. The design of the С++ Booch components // Proceedings of the Object-oriented programming systems, languages and applications conference, Ottawa. — ACM Press, 1990, — p. 1-11.

40. Brown W., Malveau R., McCormick III H., Mowbra T. Antipatterns: Refactoring Software, Architectures and Projects in Crisis. — Wiley and sons, 1998.

41. Chazelle B. How to search in history. // Informatics and Control. — 1985,No. 64.—p. 77-99.

42. Codd E.F. A Relational Model of Data for Large Shared Data Banks. // Communications of the ACM. — 1970, Vol. 13, No. 6.

43. Codd E.F. Recent Investigations in Relational Data Base Systems. // ACM Pacific. — 1975. — p. 15-20.

44. Coad P. Object-oriented patterns. // Communications of the ACM. — 1992,No. 35(9).—p. 152-159.

45. Coplien J. Pattern languages of program design. — N.Y.: Addison-Wesley, 1995.

46. Dietz P.F. Fully persistent arrays. // First workshop on Algorithms and Data Structures, 1989 in Berlin: Springer Verlag. — Lecture Notes on Computer Science No. 382. — p. 67-74.

47. Driscoll J.R., Sarnak N., Sleator D.D., Tarjan R.E. Making data structures persistent// J.Comput.System.Sci. — 1989, No. 28, Vol. 1. — p. 86-124.

48. Driscoll J.R., Sleator D.D., Tarjan R.E. Fully persistent lists with catenation// JACM. — 1994, No. 41, Vol. 5. —p. 943-959.

49. Kaplan H., Okasaki C., Tarjan R.E. Simple confluently persistent catenable lists. // SIAM Journal on Computations. — 2000, No. 3, Vol. 30.—p. 965-977.

50. Kaplan H., Tarjan R.E. Purely functional representations of catenable sorted lists. //Proceedings of the 28th annual ACM Symposium on the Theory Computing. — N.Y.: ACM Press, 1996. — p. 202-211.

51. Maguire S. Debugging the development process. — Redmond: Microsoft Press, 1994.

52. MSDN (Microsoft Software Developer Network) Library, Microsoft, http://msdn.microsoft.com.

53. Royce W. Software project management: a unified framework. — N.Y.: Addison-Wesley, 1998.

54. Sleator D.D., Tarjan R.E. Self-adjusting binary trees. // Proceedings of 15th annual ACM Symposium on Theory of Computing. — N.Y.: ACM Press, 1983, —p. 235-245.

55. XML (extensible Markup Language) Standart, World Wide Web Consorcium, http://www.w3c.org.

56. РАБОТЫ АВТОРА ПО ТЕМЕ ДИССЕРТАЦИИ

57. Волков Л.М. Будущее бухгалтера. // М.: PCWeek/RE. — 2001, №36. —С. 34-35.

58. Волков J1.M. Электронная цифровая подпись в безбумажном документообороте хозяйствующих субъектов и государственных контрольных органов. //М.: PCWeek/RE. — 2002, №43. — С. 20.

59. Волков Л.М. Настал ли час электронной цифровой подписи? // М.: Байт. —2003, №3.

60. Волков Л.М. Задачи целостности для хронологических структур данных. // В сб. «Проблемы теоретической и прикладной математики. Труды 34-й региональной молодежной конференции». Екатеринбург: УрО РАН. - 2003. - С. 250-253.

61. Волков Л.М. Принцип единого окна: как построить систему электронного документооборота между государственными органами и хозяйствующими субъектами. // М.: PCWeek/RE. — 2005, №46. — С. 52-54.

62. Волков Л.М. Отчетность через Интернет: сегодня и на деле. // М.: Российский налоговый курьер. — 2005, №9. — С. 24.

63. Волков Л.М. Хронологические структуры данных. Способы представления в памяти. // Екатеринбург: Известия УрГУ. Компьютерные науки. 2006, №1. - С. 15-25.

64. Волков Л.М., Шифман Э.Р. Автоматизированная система подготовки и представления отчетности. — Патент на полезную модель №43983, приоритет от 10.02.2005.

65. Волков Л.М., Шифман Э.Р. Система защищенного документооборота «Контур-Экстерн». — Свидетельство орегистрации авторского права на программу для ЭВМ №2004611946 от 23.08.2004.

66. Волков JI.M. Автоматизированное рабочее место приема и обработки информации АРМ «Прием». — Свидетельство о регистрации авторского права на программу для ЭВМ №2004611947 от 23.08.2004.

67. Volkov L. Kontur-Extern — an infractructure for secured digital exchange. //Proceedings of the BitKom Seminar, CeBIT. Hannover: Deutsche Messe. - 2005. - S. 31-33.

68. Volkov L. Digital data exchange. // Proceedings of the 1st Russian-Korean International Workshop on Mobile and Telecommunication Technology. Yekaterinburg: Ural State University. - 2005. - P. 7071.