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

На правах рукописи УДК 517

Волков Леонид Михайлович

МОДЕЛИ И АЛГОРИТМЫ ОБРАБОТКИ ИНФОРМАЦИИ В ПРОГРАММНЫХ КОМПЛЕКСАХ ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА

05.13.18 — математическое моделирование, численные методы и комплексы программ

Автореферат

диссертации на соискание ученой степени кандидата физико-математических наук

Екатеринбург— 2006

Работа выполнена на кафедре алгебры и дискретной математики Уральского государственного университета им. А.М.Горького.

Научный руководитель:

доктор физико-математических наук, профессор В.А. Баранский, доктор технических наук, профессор А.А. Захаров, кандидат физико-математических наук, доцент В.Б. Костоусов.

Нижегородский государственный университет им Н.И. Лобачевского.

Официальные оппоненты:

Ведущая организация:

Защита состоится 2006 года в часов на заседании

диссертационного совета К 212.286.01 по присуждению ученой степени кандидата физико-математических наук при Уральском государственном университете им. A.M. Горького по адресу: 620083, Екатеринбург, пр. Ленина 51, комн. 248.

С диссертацией можно ознакомиться в научной библиотеке Уральского государственного университета им. А.М. Горького.

Г

Автореферат разослан 2006 года.

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

В.Г. Пименов

Общая характеристика работы

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

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

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

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

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

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

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

На практике создаются и внедряются программные комплексы, ориентированные на решение только части задач электронного документооборота, и не претендующие, таким образом, на гибкость и масштабируемость. Например, в представленной на отечественном рынке системе «Комита-Отчет» (разработчик -ЗАО «Комита», Санкт-Петербург) решается только задача физической передачи форматированных данных по каналам связи, но остается открытой проблема подтверждения валидности данных. А в популярной системе «Такском-Спринтер» (ООО «Такском», Москва) отсутствуют механизмы для работы со всеми историческими состояниями форм электронных документов (см. [5]). Такие проблемы характерны не только для России: в 2005 году Германии из-за ошибок в проектировании провалился национальный проект по представлению налоговой отчетности через Интернет, так как программное обеспечение не было рассчитано на масштабирование в условиях лавинообразного увеличения нагрузки.

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

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

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

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

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

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

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

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

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

При этом для решения задачи, имеющей большое практическое значение, удается привлечь и развить известные научные результаты теоретической информатики. Так, в своем исследовании структур данных, обеспечивающих доступ ко всем своим историческим состояниям, мы опираемся на работы Р.Е.Тарджана и соавторов ([7]), а говоря о принципах построения объектной модели обработки информационных потоков, мы развиваем методологию проектирования Г.Буча и Э. Гаммы ([6], [3]). Организация хранения хронологических структур данных в реляционных СУБД требует привлечения теории последних, изложенной, например, в монографии К.Дж.Дейта ([4]).

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

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

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

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

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

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

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

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

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

Под руководством и с участием диссертанта в компании «СКБ Контур» была разработана основанная на изложенных в диссертации моделях и алгоритмах система защищенного электронного документооборота «Контур-Экстерн». Основное назначение системы — организация передачи налоговой и бухгалтерской отчетности от налогоплательщиков и налоговых органов. Практическое внедрение системы «Контур-Экстерн» состоялось, к 1 августа 2006 года, в 80 регионах Российской Федерации (га 88). Количество абонентов системы на 1 августа 2006 года превысило 125000. Ежеквартальные объемы документооборота в системе превышают 1.5 миллиона электронных документов. В течение всего времени промышленной эксплуатации системы (с января 2003 года) удвоение количества абонентов происходило не более чем за год.

Апробация работы. Основные результаты диссертации докладывались на конференциях «Инфофорум. Безопасность информации в современном обществе» (Москва, 2003, 2004, 2005), «Проблемы региональной информатизации» (Ханты-Мансийск, 2002,2003,2004,2005), «Информатизация налоговых органов» (Московская область, 2004, 2005, 2006), «Инфоком. Решения для электронной России» (Москва, 2003), на Уральской конференции молодых ученых (Екатеринбург, 2003), российско-германском семинаре BitKom (Ганновер, 2005), российско-корейском семинаре по информационным технологиям (Екатеринбург, 2005), на научных семинарах кафедры алгебры и дискретной математики УрГУ.

Основные результаты диссертации были также опубликованы в виде тезисов в сборниках трудов вышеперечисленных конференций ([15-18]).

Система «Контур-Экстерн», спроектированная автором и разработанная под его руководством, отмечена премией конкурса «Лучший инновационный проект Уральского федерального округа», проводившегося в 2002 году под руководством Полномочного представителя Президента Росссийской Федерации в УрФО П.М.Латышева. Система «Контур-Экстерн» является также лауреатом национальной конференции в области информационной безопасности «Инфофорум-2003» (в номинации «Технология года») и «Инфофорум-2005» (в номинации «Проект года»).

Публикации. Основные результаты диссертации опубликованы в работах [8]-[11], [17], [18], список которых приводится в конце автореферата.

Авторские права на созданные диссертантом программные комплексы оформлены в виде свидетельств [13], [14]. Разработанная модель обмена информацией в системе защищенного юридически значимого электронного документооборота защищена Патентом Российской Федерации [12].

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

Структура и объем работы. Диссертация состоит из введения, двух глав, заключения и списка литературы, содержащего 71 наименование. Материал диссертации изложен на 163 страницах, снабжен 12 иллюстрациями.

Автор работы выражает благодарности

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

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

Содержание работы

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

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

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

Те или иные аспекты архитектуры систем электронного документооборота неоднократно были предметом рассмотрения в научной и технической литературе. В литературном обзоре особое внимание уделено отечественным и зарубежным функциональным прообразам систем электронного документооборота - системам управления документами (таким, как «Евфрат» - [1]) и системам передачи данных по каналам связи (см., например, [5]). Анализ результатов предшественников позволяет выделить подзадачи, решение которых позволило бы на практике создать и внедрить программный комплекс электронного документооборота, достаточно производительный и гибкий для эксплуатации в составе государственной системы электронного документооборота с хозяйствующими субъектами. Среди этих подзадач особое внимание привлекают те, которые оставались нерешенными на момент начала автором его исследовательской работы. В частности, выясняется, что задача построения систем электронного документооборота требует решения двух проблем, ранее не исследовавшихся применительно к практике разработки программных комплексов электронного документооборота:

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

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

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

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

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

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

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

ChTree := { OID => (Start => PID), OID => (Start => LCID), OID => (Start => RBID) };

Здесь отображение (Start => PID) хранит в себе историю изменений указателя на родителя данного объекта и представляет собой упорядоченный по ключу Start набор значений идентификатора родителя PID для моментов времени Start LCID и RBID суть идентификаторы левого ребенка и правого брата данного элемента дерева соответственно (терминология и обозначения заимствованы из [1])-

Наиболее сложной задачей является инициализация рассматриваемой структуры за один проход из списка связей (OID, PID, Start). Для решения этой задачи автором разработан алгоритм, обоснование корректности которого представляет собой один из основных результатов главы. На вход алгоритма поступает тройка (OID, PID, Start); используя указанные в ней данные, необходимо обновить шесть массивов (историй): ParentID, LCID и RBID для объекта PID и то же самое для объекта OID. Здесь трудность заключается, в первую очередь, в пересчете массива указателей на правого брата объекта OID при инициализации хронологического дерева. Для решения этой ключевой подзадачи разработан и обоснован

Алгоритм 1.1.

Шаг 1. Положим S=Start.

Шаг 2. Если S>=ti, то выход. Иначе, для момента времени S, вычислить левого ребенка объекта PID, пусть это будет объект Сь Пусть также связь, определяющая, что Q — это левый ребенок PID в момент времени S, действует до момента времени si. Положим i=l.

Шаг 3. Если Q = NULL, то перейти к следующему шагу. Иначе, вычислим Q+i как правого брата объекта Q в момент времени S. Вычислим также s¡ как момент времени, до которого действует связь, определяющая, что C¡+i — это правый брат объекта C¡ в момент времени S.

Шаг 4. Теперь у нас построен список С],... Сь детей объекта PID на момент времени S. Вычислим Т = min{si, ..., Sk}. Тогда, по построению, T>S и Т — это момент времени, до которого список детей объекта PID, построенный на момент времени S, остается неизменным (возможно, что Т=оо)

Шаг 5. Найдем такой номер ребенка ш, что Cm < OID < Cm+i. Перестроим истории изменений правого брата для объектов Ст и OID так, чтобы с момента времени S по момент времени Т правым братом объекта Ст был бы OID (это надо сделать, если т>0), а правым братом объекта OID был бы Cm+i (возможно, при этом, что Cm+i=NULL).

Шаг 6. Положим S=T. Перейдем ко второму шагу.

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

структурой данных в памяти D. Дано некоторое состояние структуры D. Верно ли, что это состояние описывает некоторый объект типа Т?». Динамическая задача проверки целостности отвечает на другой вопрос: «Определенное состояние данных D описывает объект класса Т. В данные внесены некоторые изменения. Верно ли, что новое состояние структуры данных D' по-прежнему описывает некоторый объект класса Т?»

Очевидно, что если найден алгоритм, решающий статическую задачу, то с помощью этого же алгоритма можно решать и динамическую задачу — достаточно лишь применить найденный алгоритм к состоянию данных D\ Поэтому, теоретический и практический интерес представляет такой вопрос:

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

Этот вопрос конструктивно решается применительно к хронологическим деревьям. Для этого вводятся следующие понятия:

Определение 1.2. Пусть Р —массив Parent некоторого дерева (то есть его элементы проиндексированы натуральным числами от 1 до N и содержат целые значения от 0 до N). Изменение в массиве Р — это пара целых чисел (OID, PID) таких, что 1 á OID á N и 0 < PID й N. Результат применения изменения (ОГО, PID) к массиву Р — это массив Р*, заданный соотношениями Р '[i] = PfiJ. если i * OID, PfiJ = PID, если i = OID.

Определение 1.3. Пусть Р — массив Parent, задающий ациклический граф. Изменение (OID, PID) будем называть допустимым, если результат применения этого изменения Р' — также ациклический граф. В противном случае, такое изменение будем называть недопустимым.

Определение 1.4. Пусть Р — некоторый массив Parent. Набор изменений в массиве Р — это множество пар целых чисел (OID,, PID¡), таких, что

• Для каждого i, пара (OIDi, PID¡) — изменение в смысл определения 1.2;

• Если i * j, то OID; Ф OIDj.

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

Теорема 1.1. Если каждое изменение в наборе недопустимо, то и весь набор недопустим.

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

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

Теорема 1.2. Алгоритм 1.4 обеспечивает проверку допустимости набора изменений Changes в массиве Parent и работает за время 0(К2-Н), где // — высота леса, заданного массивом Parent, а К— количество изменений в наборе.

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

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

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

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

Для решения этой задачи обработки информации автор предлагает и обосновывает разработанную им общую математическую модель информационных потоков в программном комплексе электронного документооборота. Модель состоит из четырех основных компонентов (модулей) - storage (хранилище), loader (модуль загрузки данных), saver (модуль выгрузки данных), checker (модуль автоматизированной проверки).

Необходимость разработки внутреннего формата и выделенного хранилища данных обосновывается следующими соображениями:

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

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

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

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

Хранилище данных должно обеспечивать следующую функциональность:

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

• возможность быстрого сохранения и восстановления данных;

• поддержку транзакций;

• поддержку интерфейсов загрузки информации и обхода.

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

Модуль загрузки:

• принимает данные определенного формата из внешнего источника;

• принимает описание формата из хранилища;

• принимает параметры загрузки;

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

• ограничивает (изменяет) поток значений в соответствии с параметрами загрузки;

• направляет результирующий поток значений в хранилище через интерфейс загрузки.

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

Задача модуля выгрузки заключается в следующем:

• Получить от контрагента задание на выгрузку определенных данных;

• Преобразовать это задание в систему команд интерфейса обхода;

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

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

Подпись отчет»

Год Период Отч; 2006 ОКЕИ:ЭВЗ КояШэкФОтч: 195

ппп

□000110001000:16210301000011000110 П000110002000:14238820000 П000110003000:691194458

пооа наоочооо: о мя ■ 11000120000100:0

р-'■■-Л;'--л'V;'' у^'л-^:1

о.

КШЗШШ'Ш'..

Рис. 1. Результат работы модуля выгрузки — машиночитаемый документ.

л!

Рпд*Д Распределение в

Раздел 00921

оп базы (строка 0100) вчиеяешпеп физических лицпв интервалампкялы регреегш*

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

строка ФБ ФСС Фонды ОМС ФБ ФСС Фонды ОМС

1 г 3 А 5 6 7 8

До 280 ООО 010 0 0 0 0 0 0

От МО 001 ГУ*, да (НЮ ООО и*, в тем чисх.: 020 0 0 0 0 0 0

280 ООО 17«. 021 0 0 0 0 0 0

сушн. февышакщая 220 ООО руб. 022 0 0 0 X X X

Свыше 600 ООО руй.. в Той вим: 030 0 0 0 0 0 0

МЮ ЛПЛ гоЛ пп л л п п л л

1 I

Рис. 2. Результат работы модуля выгрузки — человекочитасмый бланк

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

Модуль проверки:

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

• принимает из хранилища формализованное описание ограничений;

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

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

• формирует протокол своей работы (рис. 3) с описанием обнаруженных нарушений и возвращает его заказчику проверки;

НИМ——

1 Daooooaqoq-oooooüooo

; Проверка фар*1ы "Единым социальный налагали лиц, промэеадлщмк емплет« «руги* лицам (200$ гад)4 . I Форм* отмйтмосги í i Кодналогооой-палучател*-. 6699 -i ' V - V '- . ''' ' '

i (код: 115104б;при»на*'енда докуменгагрекемаиг не еалп/тен; период-отчетности: Год)4 } Проверено 100%-__- - . '* ^ •'.- • , -'' •___■ •'______' . . -Л' . „ - "1-ч1"!г •.•',••

рнипашававааашанааавааааааааааааааатнааатааа"

jr¡ Всаг» 4ивмФ<мс: • И'" __

Отчёт об ошибках л^1■•..•,-. : . . • . »

' Двяояянгелтые сеедеиня .

| Информационная ч£сть\-'- J 1 1 '* • •1 , •-..••.-/•-"• ' •. '-'- ■ . •'

Ч'Общие сведения иифор^цмшмой " ' , ^ 'ч ;лнаруим»н фпрматт^3ме^»емие: Ъоот0000сю*«э21б54ад7000рсс06')

.чИдентификатор до1<уувмта(ИдДок)' .. .■••■•;;-<iя•••;'•', 1 "л^ '."■'л' ' ' ' - ■ ,'' . • . ' •. -у-' '- «.

'.• форма отчетности1'

I Содержание формы.. . • • •% v\::i4o • < -7.\ •• "л

• ч Рекеиаиты- '" . л г |.3наувние/нв может бытьпустым* (Значение; ") •

^'содержание форм*, <_• Г,::^ ^ . • С. . } ? • •'.": ; •-'Л*'-.'*' •''

»•Реквизита -:-1.':-' г -. • ""• • ' может бытв пустым. (Значат*»*; ") .

** Пр****"»"А* до*уманте(ПркэБидДо*$ . 1 \ г'-. {• ■ \ ' , ' 'V • ■ ' ■' ' _

одержание формы . чРекеиаиты-

. Ч Отчетный год(ГодПариодОтм); | Содержание формы

| ч Рек*и*еты . . . . Значение не но жат быть пу^тгём.(Значение: *)

Рис. 3. Протокол работы модуля проверки в системе «Контур-Экстерн».

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

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

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

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

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

• пользователь имеет возможность инициировать проверку состояния хранилища и получать протокол с результатами проверки;

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

Рис. 4. Соединение модулей обработки информации в системе электронного

документооборота

Автором предлагается программная реализация этой математической модели процессов обработки информации в виде компонентной модели KDOM, основанной на XML-метаописаниях. Система KDOM — это набор программных компонентов, выполненных в технологии Microsoft .NET Framework, и взаимосвязей между ними (интерфейсов).

Рис- 5. Схема модели KDOM в нотации UML

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

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

Важнейшими свойствами системы KDOM являются ее

• расширяемость — разработчик имеет возможность создавать свои реализации компонентов Saver и Scaner для стыковки готовой внутренней архитектуры KDOM с любыми внешними приложениями и пользовательскими интерфейсами;

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

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

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

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

Q0

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

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

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

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

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

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

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

5. ООО «Такском», Техническая документация на программный комплекс «Спринтер», 2000-2005. — http://www.taxcom.rLi/svstem/technologv/.

6. 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.

7. 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.

Работы автора по теме диссертации

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

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

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

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

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

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

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

15. Волков Л.М. Электронный документооборот между предприятиями и государственными контрольными органами. // в сб. «Проблемы региональной информатизации и пути их решения. Сборник трудов научно-практической конференции». - Ханты-Мансийск: Комитет по информационным ресурсам ХМАО. - 2002. - С. 76-79.

16. Волков Л.М. Практика интеграции технологии PKI и прикладных систем электронного документооборота. // «Сборник материалов летней сессии 5-й Всероссийской конференции «Информационная безопасность России в условиях глобального информационного общества» под ред.

члена-корреспондента РАЕН А.В.Жукова. - М.: Редакция журнала «Бизнес+Безопасность». -2003. - С. 105-109.

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

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

ВВЕДЕНИЕ.

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.

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

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.