Содержание к диссертации
Введение
ГЛАВА 1. Алгоритмы обработки изменяющихся во времени данных ...51
1.1. Представление хронологических данных 52
1.1.1. Обозначения и определения 55
1.1.2. Реализация операций 59
1.1.3. Высокопроизводительное хронологическое дерево 63
1.1.4. Резюме 70
1.2. Целостность хронологических данных 71
1.2.1. Постановка задачи 71
1.2.2. Целостность среза 76
1.2.3. Целостность всего хронологического дерева 78
1.2.4. Добавление связи в срез 79
1.2.5. Добавление множества связей в срез 81
1.2.6. Резюме 88
1.3. Применение хронологических структур в системе электронного документооборота 90
ГЛАВА 2. Математическая модель преобразования данных 94
2.1. Формы представления данных 94
2.2. Преобразование данных: подзадачи 101
2.2.1. Хранилище (Storage) 101
2.2.2. Модуль загрузки (Loader) 106
2.2.2.3. Модуль выгрузки (Saver) 108
2.2.4. Модуль проверки (Checker) 112
2.2.5. Соединение модулей 120
2.3. Компонентная модель KDOM 123
2.3.1. Loader 126
2.3.2. Saver 129
2.33. Storage 130
2.3.4. Schema 133
2.3.5. Checker 138
2.3.6. Резюме 140
2.4. Язык представления метаинформации 141
2.4.1. Описание типов данных 142
2.4.2. Описание визуальных представлений 144
2.4.3. Описание форматов вывода 149
Заключение... 153
Литература
- Высокопроизводительное хронологическое дерево
- Целостность всего хронологического дерева
- Преобразование данных: подзадачи
- Компонентная модель KDOM
Введение к работе
Современная индустрия программного обеспечения является наиболее динамично развивающейся отраслью человеческой деятельности. Подлинная 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]), формализующая процесс повторного использования проектных решений, и применимая практически в любом технологическом процессе разработки ПО.
Современные тенденции таковы, что дальнейшее развитие
научных исследований в области теории разработки программных
комплексов смещается теперь от вопросов построения глобальных
парадигм проектирования к вопросам выявления общих принципов
проектирования для отдельных классов систем. Одному из таких
классов, ставшему весьма актуальным в связи с Интернет-бумом
последних десяти лет, и посвящена настоящая работа. Речь пойдет о
проектировании программных комплексов электронного
документооборота.
Системы электронного документооборота — это программные комплексы, предназначенные для автоматизации процесса удаленного обмена большими массивами форматированной информации. Будучи необходимыми составляющими многих автоматизированных систем, системы электронного документооборота находят в последнее время (особенно в связи с развитием Интернета) широчайшее применение во многих сферах человеческой деятельности. Вместе с тем, общие принципы проектирования таких систем остаются понимаемыми их разработчиками скорее лишь на интуитивном уровне; в литературе по теоретической информатике не дается систематического изложения этого вопроса.
В России в настоящее время создано и внедряется достаточно большое количество систем электронного документооборота, различающихся по технологическим подходам и рыночным нишам. Наиболее развитыми, законченными программными комплексами электронного документооборота являются системы «Дело» (разработчик — ООО «Электронные офисные системы», г. Москва), «Евфрат» (ЗАО «Когнитивные технологии», г. Москва), «Спринтер» (разработчик 000 «Такском», г. Москва, см. [27]), «Курьер» (ЗАО «Комита», г. Санкт-Петербург), «СБИС++» (ЗАО «Тензор», г. Ярославль, см. [28]) и некоторые другие. Из вышеперечисленных систем, в первой, по мнению автора, наиболее глубоко реализовано внутреннее хранилище информации, во второй — система управления цепочками документов. Три последних упомянутых системы являются наиболее характерными представителями систем, в которых электронный документооборот понимается как передача форматированных массивов данных, без их синтаксической обработки. Анализ практики внедрения этих систем, их достоинств и недостатков, технологических особенностей, является важным источником материала для обобщения и поиска закономерностей.
На рынке программных продуктов для автоматизации деятельности хозяйствующих субъектов отечественные продукты, естественно, конкурируют с зарубежными разработками, такими как Documentum (компания EMC Documentum, Калифорния, США) и Hummingbird DM (компания Hummingbird, Торонто, Канада). Однако проникновение иностранных систем электронного документооборота на российский рынок пока не является ощутимым (фактически,
ограничиваясь несколькими десятками внедрений двух указанных систем), что может быть объяснено
относительно высокой стоимостью (системы документооборота лицензируются, как правило, «на каждого конечного пользователя», и разница в стоимости лицензии между отечественным программным комплексом и импортным аналогом может достигать двух порядков);
специфичностью российского законодательства (специализированные ГОСТы в области делопроизводства, архивного дела, защиты информации делают невозможной или затруднительной локализацию многих зарубежных продуктов);
собственно высоким качеством отечественных продуктов, которое делает их вполне конкурентоспособными даже и при сравнимых ценах и удовлетворении всех законодательных ограничений1.
Поэтому, зарубежные программные комплексы в целом были исключены из сферы внимания автора, за исключением некоторых
В этом не следует видеть нечто удивительное или исключительное. Российская IT-индустрия по ряду объективных причин практически безнадежно отстала от зарубежной в целом ряде областей - операционные системы и общесистемные средства, сетевое ПО и СУБД, интегрированные среды разработки и офисные пакеты. На Западе старт бизнесу в этих направлениях был дан на 10-20 лет раньше, чем в России, и не стоит удивляться, что это привело к нашему катастрофическому отставанию. Однако в целом ряде других областей Россия занимает лидирующие или, по крайней мере, значимые позиции: трехмерная графика, распознавание образов, машинный перевод, антивирусные технологии, сжатие информации, передача потокового видео и многие другие. Это те области, в которых, во-первых, активное развитие началось только в последние 10-15 лет (когда российская ГТ-индустрия уже жила по законам бизнеса и была включена в мировое информационное пространство), и, во-вторых, требуется применение особо наукоемких технологий, и удалось приложить мощь отечественной фундаментальной науки. Поэтому отечественным системам электронного документооборота тоже не всегда следует
специализированных разработок, не представленных на российском рынке, но содержащих реализацию ярких и современных идей. Это, например, программный продукт 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 миллионов электронных документов. Благодаря этому, система «Контур-Экстерн» является крупнейшим из эксплуатируемых в России программных комплексов электронного документооборота, как по своим масштабам, так и по темпам развития.
Автор работы выражает благодарности
научному руководителю, профессору, доктору физико-математических наук Виталию Анатольевичу Баранскому за многочисленные ценные наблюдения, замечания и обсуждения в процессе подготовки диссертации;
техническому директору компании «СКБ Контур» Эдуарду Романовичу Шифману за вдохновляющие обсуждения, помогшие пробросить мостик от теории к практике.
Высокопроизводительное хронологическое дерево
Для реализации хронологического дерева, поддерживающего заявленные выше методы и обладающего высокой производительностью, мы предлагаем использовать хронологическую модификацию известной структуры «левый ребенок — правый брат», которая широко применяется для представления в памяти обычных деревьев (см. [3]). Напомним, что эта структура состоит из трех массивов Parent, LChild и RBrother, которые индексированы идентификаторами объектов и содержат ссылки на родителя, левого ребенка и правого брата каждого узла соответственно. Реализация базовых операций навигации для такой структуры данных очевидна.
Будем теперь более широко трактовать массивы Parent, LChild и RBrother; посмотрим на них как на отображения, которые ставят в соответствие ключу — идентификатору объекта — значение: идентификатор родителя, левого ребенка и правого брата соответственно. Отображение само по себе является популярным АТД; в языке C++ оно реализовано в виде контейнерного класса тар. Используя любой язык программирования нетрудно реализовать АТД «отображение» (поддерживающий очевидные методы добавления, удаления и извлечения пары ключ-значение) с помощью, например, хэш-таблицы. Визуально мы можем изобразить эти отображения так: Tree := { OID = PID, OID = LCID, OID = RBID }; — АТД «дерево» можно эффективно реализовать с помощью трех экземпляров АТД «отображение».
Используя введенную нотацию, предложим теперь эффективную реализацию хронологического дерева: ChTree := { OID = (Start r PID), OID = (Start = LCID), OID = (Start = RBID) }; Отображение (Start = PID) хранит в себе историю изменений указателя на родителя данного объекта и представляет собой упорядоченный по ключу Start набор значений идентификатора родителя PID для моментов времени Start. Например, история из трех записей ( 01.2005 = 5, 04.2005 = NULL, 09.2005 = 1 ) обозначает, что данный объект до января15 не был определен (если в системе не приняты некоторые умолчания; например, на практике можно полагать, что неопределенный объект является изолированным одноэлементным деревом, то есть, что значения PID, LCID и RBID по умолчанию равны NULL), с января по март его родительским элементом был объект с идентификатором 5, с апреля по август данный объект был корнем некоторого дерева, а с сентября и по настоящий момент времени его родителем является объект с идентификатором 7. Заметим, что мы здесь предположили, что система оперирует с открытыми справа полуинтервалами времени; конечно же, это тоже вопрос договоренности, хотя использование именно таких полуинтервалов и представляется наиболее естественным.
История изменений указателей на левого ребенка и правого брата имеет аналогичный смысл. Ранее мы предполагали, что длины всех историй изменения всех указателей всех объектов системы равномерно ограничены некоторой небольшой константой К. На практике это обычно имеет место (например, если рассматривается задача персонифицированного учета с подразделениями и сотрудниками в качестве элементов данных хронологического дерева, то длина истории изменения указателя на родителя отражает количество переходов сотрудника из отдела в отдел). Впрочем, как мы увидим, в нашей реализации хронологического дерева все временные зависимости от К окажутся логарифмическими, поэтому длина истории изменения указателя не представляет, вообще говоря, особой практической важности.
Итак, мы предлагаем реализацию хронологического дерева в виде трех отображений, первое из которых ставит в соответствие объекту историю изменений его указателя на родителя, а второе и третье — то же самое для левого ребенка и правого брата. Теперь мы должны описать эффективную реализацию заявленных пяти операций работы с хронологическим деревом на такой структуре данных.
Целостность всего хронологического дерева
Теперь, когда мы построили алгоритм, проверяющий целостность среза, заданного массивом Parent, за время O(N) (а быстрее, очевидно, это сделать невозможно), мы можем указать и оптимальный в общем случае алгоритм проверки целостности фиксированного состояния всего хронологического дерева. Этот алгоритм заключается в последовательном просмотре в хронологическом порядке всех срезов дерева, с анализом целостности каждого из них. Понятно, что, так как два последовательных среза могут, вообще говоря, различаться сколь угодно сильно, лучше такого прямолинейного алгоритма в самых общих предположениях ничего не может быть.
Однако, если имеет место какое-либо естественное ограничение на меру близости двух срезов на последовательные даты, ситуация изменяется. Так, если предположить (такое ограничение, как правило, имеет место на практике), что на каждый момент времени приходится не более К изменений, где К « N, то удается указать существенно более эффективный алгоритм проверки целостности всего хронологического дерева. Идея алгоритма состоит в том, чтобы проверять целостность каждого следующего среза не «с нуля» (то есть, прогоняя полностью алгоритм 1.2 сканирования массива Parent, задающего данный срез), а использовать при проверке информацию о целостности предыдущего среза, и о том, какие изменения (числом не более К), произошли за квант времени, отделяющий предыдущий (целостный) срез от нынешнего. Ниже будет приведен алгоритм проверки целостности следующего среза (алгоритм решения динамической задачи проверки целостности дерева), возникающего при внесении в данный целостный срез порции из К изменений, работающий за время О (К Н),щ&И — высота дерева. На основании этого алгоритма в заключение данного раздела мы предложим общий «интеллектуальный» алгоритм проверки целостности всего хронологического дерева.
Добавление связи в срез
Начнем с несложного алгоритма добавления в существующий («текущий») целостный срез одной связи (добавление связи, которая будет действовать со «следующего» момента времени, означает, что срез на следующий момент времени описывается точно таким же массивом Parent, как текущий срез, кроме значения этого массива для какой-то одной вершины графа).
Определение 1.2. Пусть Р — некоторый массив Parent (то есть его элементы проиндексированы натуральным числами от 1 до N и содержат целые значения от 0 до N). Изменение в массиве Р — это пара целых чисел (OID, PID) таких, что 1 OID N и 0 PID N. Результат применения изменения (OID, PID) к массиву Р — это массив Р , заданный соотношениями
P [i]=P[i], если i OID, P[i] = PID, если і = OID. Определение 1.3. Пусть Р — массив Parent, задающий ациклический граф. Изменение (OID, PID) будем называть допустимым, если результат применения этого изменения Р — также ациклический граф. В противном случае, такое изменение будем называть недопустимым. Алгоритм 1.3. [Проверка допустимости изменения в целостном массиве Parent] Входные данные: массив Parent, который задает ациклическую структуру; целые числа OID и PID. Выходные данные: TRUE, если после присвоения Parent[OID]:=PID массив по-прежнему будет задавать ациклическую структуру, и FALSE — иначе.
Преобразование данных: подзадачи
Первая подзадача заключается в организации внутреннего хранилища данных. Для того чтобы определить представление информации, недостаточно только указать одну из двух рассмотренных выше форм; каждый конкретный набор данных может иметь множество различных машиночитаемых и множество различных человекочитаемых представлений — оставаясь при этом одним и тем же набором данных с точки зрения семантики. Поскольку в любом случае внешних представлений будет не менее двух, необходимым элементом системы документооборота является внутреннее хранилище16 информации.
Хранилище — это машиночитаемая форма представления информации внутри информационной системы, основанная на внутреннем формате представления информации. Внутренний формат может совпадать с одним из внешних форматов (таких, посредством которых происходит обмен данными с контрагентами, являющимися информационными системами). На практике, такое совпадение имеет место только в наиболее примитивных системах электронного документооборота.
Такова, например, система электронного представления налоговой отчетности «Спринтер», разработанная московским ООО «Такском» (техническое описание см. [27]). Эта система ограничивается механической передачей информации с узла отправителя отчетности на узел получателя. Благодаря этому система «Спринтер» обходится только одним форматом данных (в качестве внутреннего и внешнего для взаимодействия с информационными системами налогоплательщика и налогового органа). Платой за простоту является отсутствие возможности масштабирования системы (подключения третьего и последующих контрагента к хранилищу данных), отсутствие возможности проведения автоматизированного контроля заполнения данных на сервере системы и т.д.
Необходимость разработки внутреннего формата и выделенного хранилища данных обосновывается следующими соображениями:
система электронного документооборота представляет различным контрагентам одну и ту же информацию в различных формах;
внутри системы, таким образом, необходимо поддерживать метаинформацию обо всех формах представления циркулирующей в системе информации;
части этой метаинформации, относящиеся к различным формам представления информации, обязательно различаются, и обязательно имеют достаточно много общего;
внешние форматы контролируются контрагентами и обслуживают их текущие нужды и потребности, а потому могут быть с течением времени подвержены существенным изменениям; внутреннее же хранилище системы должно по возможности сохранять стабильность.
Пример 2.2. Вернемся к знакомой ситуации обработки данных налоговой отчетности. Метаинформация, необходимая системе документооборота для визуализации этих данных в виде экранных форм, доступных для редактирования и распечатки, обязательно должна включать сведения о том, например, в какую строку, и в какой столбец формы попадает данный реквизит, вводится ли он вручную или выбирается из справочника, доступен ли он для редактирования и т.д.
Все эти сведения абсолютно не нужны для формирования текстового файла, зато метаинформация, используемая при выгрузке сведений налоговой отчетности в виде файлов установленного формата, должна содержать информацию о последовательности реквизитов в текстовом файле, о составе и структуре показателей служебной части сообщения, о кодах реквизитов и т.д.
И в то же время, и для представления данных в человекочитаемом виде, и для представления тех же самых данных в машиночитаемом виде, система, вне зависимости от вида представления информации, должна знать, в частности, синтаксические ограничения для каждого реквизита (является ли он числом, строкой или датой, какую имеет размерность), принадлежность каждого реквизита тому или иному блоку, условия присутствия для каждого реквизита (например, определенный реквизит может появляться в экранной форме и в текстовом файле только при условии определенного значения другого реквизита) и т.д.
Компонентная модель KDOM
Для практической реализации задач преобразования информации и сопутствующей этим преобразованиям обработки информации, автором была спроектирована компонентная программная модель, получившая название KDOM17. Система KDOM — это набор программных компонентов, выполненных в технологии Microsoft .NET Framework, и взаимосвязей между ними (интерфейсов). С точки зрения логики внешних приложений, модель KDOM полностью отвечает описанному выше методологическому подходу к решению задач преобразования информации. Модель KDOM используется на практике в серверной части системы «Контур-Экстерн» .
Ниже будет представлена и описана используемая в программном комплексе «Контур-Экстерн» версия компонентной модели KDOM. Эта версия состоит из всех компонентов базовой модели, а также из нескольких реализаций компонентов, специализированных для решения задач системы «Контур-Экстерн».
KDOM состоит из пяти наборов компонентов. Четыре из них нам уже известны — это хранилище, модули загрузки, выгрузки и проверки. Пятым является хранилище метаданных (Schema). В описании модели хранилище метаданных намеренно показано как отдельный логический блок (в предыдущем параграфе мы говорили о том, что метаданные находятся во внутреннем хранилище), чтобы подчеркнуть тот факт, что метаинформация является информационной моделью прикладной задачи и используется всеми компонентами модели.
Рассмотрим теперь внутреннее устройство каждого из блоков инфраструктуры KDOM.
Напомним, что модуль загрузки преобразует данные внешнего источника во входной поток хранилища. Таким образом, с одной стороны модуль загрузки работает с различными форматами и представлениями данных (форматами контрагентов), а с другой стороны — с постоянным форматом (внутренним форматом хранилища). Если пытаться реализовывать модуль загрузки как единый программный компонент, мы придем к необходимости поддерживать различные версии этого компонента при работе с различными внешними источниками, поскольку форматы контрагентов могут быть сколь угодно сложными и требовать создания специальных программ синтаксического анализа.
Из этих соображений, в модели KDOM модуль загрузки состоит из двух программных компонентов, которые называются Parser и Scaner.
Scaner — это синтаксический анализатор формата внешнего контрагента. На вход Scaner a подается файл определенного формата (или поток пар «реквизит-значение» человекочитаемой формы документа), a Scaner, преобразует эти данные в поток значений. При этом встроенный Scaner использует синтаксическое описание формата.
Например, Scaner может разбивать входной форматированный файл по определенным лексемам, выделять значения по позиционному признаку (имея таблицу соответствия внутренних кодов реквизитов и номеров строк файла) и т.д. Язык описания синтаксических правил анализа форматированных файлов, на котором создаются описания форматов для Scaner a, достаточно богат. Таким образом, большинство форматированных файлов могут быть проанализированы и представлены в виде потока значений штатным Scaner oM системы KDOM.
Однако, не всегда это возможно. На практике, имеют место ситуации, когда представление входного файла в виде набора значений является слишком сложным, чтобы его можно было описать исключительно синтаксическими правилами. Например, определение местоположения того или иного реквизита в файле может быть сделано только на основании каких-либо вычислений и т.п. В таких случаях все равно приходится разрабатывать специальные программные модули для анализа форматированных файлов.
Поэтому, система KDOM, предоставляя в распоряжения разработчика стандартный синтаксический анализатор с его языком настройки, предоставляет также возможность реализации собственного Scaner a и подключения его в схему работы.
