Содержание к диссертации
Введение
Глава 1. Анализ методов обеспечения достоверности и описания данных в АСУ 8
1.1 Достоверность, как характеристика обработки данных в АСУ Основные определения 9
1.1.1 Уровни обеспечения достоверности данных в АСУ 11
1.1.2. Методы контроля достоверности 11
1.1.3 Механизмы контроля достоверности 15
1.1.4 Анализ возможности использования методов контроля на различных этапах обработки данных 16
1.2. Использование методов повышения достоверности данных в АСУ 19
1.2.1 Применение методов контроля достоверности данных в СУБД
1.2.2 Применение методов контроля достоверности данных в ППО 22
1.3 Анализ моделей и технологий описания данных, хранимых в БД 24
1.4 Конкретизация объекта иследования 25
Выводы по главе 1 27
Глава 2. Разработка комплексной модели описания информации реляционной БД 29
2.1. Определение и свойства модели описания данных 29
2.1.1. Статическая составляющая модели "Сущность - связь " 30
2.1.2. Модель процессов 34
2.1.3.Модель состояний 39
2.2 Организация вычислений и описание зависимостей между данными таблица 48
2.2.1 Синтаксис 48
2.2.2 Семантика 49
2.2.3 Произвольные операции на ЭТ 51
Выводы по главе 2 57
Глава 3. Разработка методов определения достоверности информации БД 59
3.1 Определение достоверности информации 59
3.1.1 Нижняя и верхняя оценки достоверности 60
3.1.2 Влияние структуры БД на достоверность информации 67
3.1.3 Определение достоверности информации БД с учетом классов решаемых задач 68
3.2 Выбор процедур контроля в физической структуре БД 71
3.3 Построение канонической структуры БД с учетом требований к достоверности информации 75
3.4 Определение достоверности информации при отображении канонической структуры БД в физическую 84
3.5 Определение достоверности информации при отображении логической структуры БДв физическую. 87
Выводы по главе 3 91
Глава 4 Разработка принципов построения и реализации системы определения достоверности информации БД муниципальных АСУ 92
4.1. Организация автоматизированной системы определения достоверности информации БД муниципальных АСУ 92
4.1.1 Структура и описание основных режимов работы 93
4.2 Организация системы автоматизированного тестирования 106
4.2.1 Организация эталонного репозитория 111
4.3 Проблемно ориентированный язык 113
4.4. Практическое применение АСОДИ в АСУ муниципальных служб 118
4.4.1 Использование АСОДИ и CAT в деятельности Государственной Налоговой Инспекции(ГНИ) 119
4.5 Технические характеристики разработанных комплексов 120
Выводы по главе 4 122
Заключение 123
Список литературы 126
Приложения 132
- Анализ возможности использования методов контроля на различных этапах обработки данных
- Статическая составляющая модели "Сущность - связь "
- Построение канонической структуры БД с учетом требований к достоверности информации
- Структура и описание основных режимов работы
Введение к работе
Коренная реформа системы управления народным хозяйством страны является одной из центральных задач экономической политики нашего государства на современном этапе развития. Одним из путей повышения качества управления является создание и использование высокоэффективных автоматизированных систем управления (АСУ) для различных звеньев народного хозяйства. При этом приоритетное внимание уделяется развитию АСУ муниципальных служб, занятых формированием доходной части бюджета, таких как государственная налоговая инспекция, государственный Комитет по управлению имуществом, государственный Комитет по статистике.
Основу деятельности муниципальных служб составляет обработка и анализ значительного количества финансовых и аналитических документов предприятий, организаций и частных лиц (в дальнейшем - хозяйствующих субъектов). Результатом этой обработки является расчет задолженности хозяйствующих субъектов перед бюджетами различных уровней и проведение необходимых работ по сведению этой задолженности к минимуму.
Одним из основных условий эффективного функционирования таких систем является обеспечение требуемого уровня достоверности хранимых и обрабатываемых данных, которые используются при построении аналитической и статистической отчетности и на основе которых принимаются управленческие решения. Под достоверностью информации баз данных (БД) будем понимать степень соответствия хранящейся в БД информации об объектах некоторому эталонному описанию в конкретный момент времени.
Основными причинами снижения достоверности информации, хранимой в БД муниципальных служб, являются частые терминологические, структурные и смысловые изменения понятий (информационных объектов), обрабатываемых в этих системах, правил их учета и анализа [19]. Эти изменения объясняются как нестабильным и динамичным законодательством РФ, так и изменчивостью характера деятельности хозяйствующих субъектов. Вносимые изменения носят случайный характер и приводят к нарушению достоверности информации, хранимой в БД, и как следствие, к ошибкам в работе прикладных программных комплексов, поддерживающих процессы принятия решений. Помимо перечисленных выше причин снижения достоверности данных, следует отметить неэффективное или недостаточно полное использование методов и механизмов контроля данных, используемых в прикладных программных комплексах, на различных стадиях их обработки, программные и аппаратные сбои и т.д.
Используемые в настоящее время подходы к созданию автоматизированных информационных систем (АИС) муниципальных служб приводят, как правило, к появлению программных комплексов, в которых достоверность информации обеспечивается лишь на этапе ее контроля в модулях прикладного программного обеспечения. Примерами таких систем, находящихся в эксплуатации в подразделениях налоговой службы, являются АИС, разработанные ГНИВЦ при ГНС РФ, ЗАО "ОВИОНТ", ЗАО "БИТ", КБ "Российский кредит" [21]. В подобных системах всегда существуют проблемы оценки достоверности информации, хранящейся в базах данных, и, как следствие, достоверности получаемых отчетов. Так как применяемые в перечисленных системах методы и механизмы контроля информации ориентированы на выявление и исправление только определенного типа ошибок обрабатываемой информации, они не анализируют достоверность информационного пространства в целом.
Перечисленные выше проблемы эволюции характерны для многих муниципальных и федеральных компьютерных систем, подверженных оперативным изменениям. Поэтому для них проблема комплексного определения достоверности информации, хранимой в БД, становится достаточно актуальной.
Предпочтительным вариантом ее решения является разработка таких методов и средств определения достоверности информации, которые позволяли бы всесторонне и системно оценить достоверность используемого информационного пространства. Что и является целью настоящей диссертационной работы.
Для достижения поставленной цели в диссертации ставятся и решаются следующие задачи:
1. Анализ и классификация методов обеспечения достоверности и механизмов контроля информации при ее обработке в АСУ.
2. Построение модели комплексного описания информации, хранимой в реляционных базах данных, включая ограничения на значения атрибутов отношений и взаимодействия между отдельными отношениями.
3. Разработка методов описания зависимостей между атрибутами отношений, хранимых в БД, и "правил" их взаимодействия;
4. Разработка алгоритмов анализа достоверности структурных конструкций хранимых отношений.
5. Получение аналитических выражений для определения достоверности информации баз данных муниципальных АСУ.
6. Практическое подтверждение эффективности полученных научных результатов.
Главным теоретическим результатом работы является разработанная автором модель комплексного описания информации, хранимой в реляционных базах данных, включая ограничения на значения атрибутов отношений и взаимодействия между отдельными отношениями. Эта модель позволяет направленно контролировать достоверность хранимой информации при ее использовании программными приложениями АСУ. Предложен подход к решению задачи анализа механизмов контроля достоверности информации, используемых в программных приложениях. Получены аналитические выражения для расчета достоверности информации, хранимой в БД. Решена задача выбора оптимальных методов контроля достоверности хранимой информации.
Разработанные модель взаимодействия табличных информационных объектов (МВТО-модель) и методы оценивания достоверности хранимой информации, впервые полученные и опубликованные автором, являются развитием известных ранее моделей и методов и позволяют формализовать и автоматизировать как процесс определения достоверности информации, так и процесс анализа эффективности механизмов контроля достоверности, используемых в прикладных программных продуктах.
Практическая ценность полученных результатов заключается в том, что их использование позволяет сократить время некорректного функционирования муниципальных АСУ, вызванного обработкой недостоверной информации. При использовании предложенных модели и методов созданы программные комплексы "Ведение лицевых счетов юридических и физических лиц", "Система оперативно-бухгалтерского учета хозяйствующих субъектов", "Система автоматического тестирования" и др. в составе АИС "Налог-21", находящейся сегодня в промышленной эксплуатации в министерстве по налогам и сборам РФ.
Программные комплексы реализованы на универсальных языках программирования "С" и "00 Pascal" в операционных системах MS DOS и MS Windows.
Работы проводились по договорам с ОАО МКНТ (Госзаказ), ГНИ по г. Москве и ГНИ по г. Твери, московской регистрационной Палатой. По результатам диссертации опубликовано восемь печатных работ.
Текст диссертационной работы состоит из введения, четырех глав, заключения и приложений.
Первая глава посвящена анализу современных методов и технологий обеспечения достоверности информации, обрабатываемой в АСУ. Традиционно в системах такого рода достоверность данных анализируется на этапе сохранения информации в базе данных. Использование этого подхода не позволяет учесть влияния ряда факторов (программные и аппаратные сбои, изменения структур хранения и алгоритмов обработки информации, неэффективное или некорректное использование методов и механизмов контроля достоверности данных и т.д.), которые также приводят к появлению ошибочной информации в БД или к нарушению ссылочной целостности данных.
В связи с этим возникает потребность проведения комплексного анализа достоверности информации, хранимой в БД. Одной из наиболее важных проблем, возникающих при проведении анализа информационного объекта, является выбор надлежащего способа его описания. Анализ существующих моделей и технологий описания данных, хранимых в БД, изучение информационных потоков в муниципальных службах показали, что для определения достоверности хранимой информации необходима разработка такой модели описания хранимых данных, которая позволяла бы объединить в себе логическую модель базы данных (информационную модель), модель состояний и потоковую модель. Такая модель, очевидно, должна содержать метаданные для описания сложных зависимостей и правил взаимодействия данных.
Таким образом, определяются задачи, которые решаются в диссертационной работе - создание комплексной модели описания хранимой в БД информации для последующей оценки ее достоверности. Эта модель должна иметь выразительные возможности, позволяющие описывать хранимые отношения реляционной модели данных, ограничения на значения отдельных атрибутов, "правила" взаимодействия отношений в процессе работы программных приложений муниципальных АСУ.
Во второй главе рассматриваются вопросы построения комплексной модели описания данных, учитывающей выделенные ранее особенности хранимой информации. Комплексное описание данных в рамках предлагаемой модели включает описание структур взаимосвязанных таблиц; описание процессов, связывающих таблицы; конструирование, так называемой, сети таблиц, наглядно представляющей размещение взаимодействующих таблиц по позициям сети. Каждой конструкции разработанной модели дается формальное определение.
Далее в главе предлагается подход к описанию аналитических зависимостей, связывающих отдельные атрибуты таблиц. За основу берется формульное описание вычислений. Само описание зависимостей предлагается представлять в символьном виде и хранить совместно с информацией о структуре анализируемой БД, в специально разработанном репозитории.
В третьей главе представлены подходы к решению задач анализа достоверности данных, основанные как на применении структурных методов, обеспечивающих анализ и синтез оптимальных канонических, логических и физических структур БД, так и на применении определенных механизмов и систем повышения достоверности данных. Разработана методика определения достоверности информации при хранении ее в БД. В качестве основной единицы исследования достоверности информации предложено использовать запись БД, так как именно на уровне записей БД в большинстве современных СУБД реализуются выделенные в предметной области функциональные взаимосвязи, а также осуществляется контроль правильности их прохождения (просмотра) в структурах хранения.
Четвертая глава посвящена рассмотрению основных принципов создания системы оценивания достоверности хранимой информации, используемой при подготовке управленческих решений в муниципальных службах. Описываются структура и алгоритмы разработанной системы, ее ведущие модули. Приводится описание программных реализаций предложенных в работе методов оценивания достоверности.
Описываются основные этапы анализа достоверности информации баз данных муниципальных служб в рамках разработанной модели описания данных. Приводятся примеры зависимостей между отношениями, правил и условий взаимодействия атрибутов отношений. Все примеры описаны на разработанном в диссертации проблемно-ориентированном языке описания взаимодействий и вычислений.
Приводятся примеры использования разработанных модели и методов для анализа эффективности примененных в прикладных программных комплексах механизмов обеспечения достоверности информации, хранимой в БД. Анализ механизмов обеспечения достоверности проводится для компьютерных систем, автоматизирующих деятельность Государственной Налоговой Инспекции и Налоговой Полиции (автоматизированные системы "Ведение лицевых счетов юридических и физических лиц" и "Ведение оперативно-бухгалтерского учета"). Разработанные модель и методы анализа достоверности информации положены в основу системы автоматизированного тестирования БД муниципальных АСУ - CAT "Тест-Налог".
Приводятся технические характеристики разработанных программных средств.
В заключении приводятся основные выводы и результаты, полученные в процессе выполнения диссертационной работы и акты об их внедрении в налоговых инспекциях Москвы и Твери.
Анализ возможности использования методов контроля на различных этапах обработки данных
Одним из необходимых требований современных приложений к базам данных является не только хранение данных, но также запись и применение к данным определенных деловых правил. Связывание правил с данными позволяет сделать данные более «активными», позволяя системе управления базами данных автоматически осуществлять контроль достоверности данных, а также автоматизировать многие деловые процедуры. Подобная «активность» данных делает их более ценным ресурсом, так как приложения могут коллективно использовать не только сами данные, но и «поведение» данных. Правила сохраняются в базе данных, поэтому их не нужно кодировать заново для каждого приложения - это позволяет избежать избыточности и обеспечить целостность данных. Свойства активности данных очень полезны для защиты целостности данных, обработки исключительных ситуаций, вырабатывания отсутствующих данных и сохранения контрольных записей об изменениях в базе данных. В общем случае свойства активности данных позволяют указать некоторый ряд правил, исполнение которых будет контролироваться системой. Определение этих правил в самой базе данных, а не в работающих с ней приложениях, позволяет избежать возможной избыточности или несогласованности, а также упростить работу разработчиков приложений. Активные данные особенно важны в среде клиент/сервер, когда приложения разрабатываются разобщенными группами, так как они предоставляют механизм определения глобальных правил, которые будут действовать во всех приложениях. Основные свойства активности данных можно разделить на две общие категории: «ограничения» и «триггеры». Ограничения представляют собой операторы декларативного характера, которые будут действовать в системе, например, «Размер уставного капитала всегда являются положительной величиной». Триггеры представляют собой автоматические действия, которые выполняются всякий раз при наступлении определенного события или условия, например, «когда приходит платеж необходимо проверить наличие расчетного счета у организации». Различные СУБД поддерживают различные типы ограничений. Так, СУБД Oracle 7.3 или DB2 поддерживает ограничения типа:
NOT NULL - не допускают появления нулевого значения в определенном атрибуте (столбце); 2. UNIQUE - не допускают появления в столбце или в группе столбцов повторяющихся значений; 3. PRIMARY KEY - объявляют для столбца или группы столбцов оба ограничения NOT NULL и UNIQUE; 4. CHECK - представляют собой предикаты, такие как BONUS вид CHECK опции: относятся к виду и не позволяют вводить или изменять с помощью вида данные, не соответствующие определению вида 5. FOREIGN KEY (известные также как «референциальная целостность») определяют взаимоотношения между таблицами, называемыми «родительской таблицей» и «дочерней таблицей». Любое отличное от нуля значение с ограничением FOREIGN KEY в дочерней таблице требует наличия соответствующего ключевого значения в родительской таблице. В то время как ограничения представляют собой объявление правил, триггеры определяют необходимость выполнения некоторых действий при наступлении определенного события. Отдельные опции, поддерживаемые триггерами DB2, включают в себя: 1 .Активизацию триггера операциями вставки, удаления или обновления для заданной таблицы, или обновлением конкретных столбцов в таблице. 2.Выполнение предусмотренных триггером действий до или после наступления события, активизировавшего триггер. 3.Выполнение триггера только один раз при активизации оператором SQL, или выполнение один раз для каждой из строк, затронутых оператором SQL (это может быть ноль строк, одна строка или несколько строк). 4.Вычисление при активизации предиката, называемого «условием триггера». Выполнение основной части триггера производится только при истинности условия триггера. 5.Включение в основную часть триггера одного или нескольких операторов SQL. В этих операторах можно использовать специальные переменные, относящиеся к значениям «до» и «после» в строке или группе строк, вызвавших активизацию триггера. Если в основной части триггера производится попытка модифицировать базу данных, то авторизация прав на совершение этой операции осуществляется по правам определившего триггер пользователя, а не по правам пользователя, активизировавшего триггер. Как ограничения, так и триггеры могут служить для задания деловых правил, защиты целостности базы данных и повышения полезности и ценности данных. Однако, каждое из свойств активности данных имеет собственный набор достоинств. Ограничения задаются в виде объявлений, что предоставляет системе больше возможностей для оптимизации. В отличие от триггеров ограничения вводятся в действие с момента их создания - если некоторые из имеющихся строк нарушают новое ограничение, то ограничение может быть отменено или нарушающие ограничение строки могут быть перенесены в таблицу исключений. Кроме того, ограничение может защищать базу данных от недействительных ситуаций независимо от того, каким именно образом возникла такая ситуация, тогда как триггер активизируется только конкретной операцией вставки, обновления или удаления. С другой стороны, триггеры являются более мощным средством, чем ограничения, так как они имеют доступ к значениям данных как «до», так и «после» совершения операции
Статическая составляющая модели "Сущность - связь "
Для описания динамики изменения состояний таблиц, заданных ранее в терминах "сущность-связь", воспользуемся моделью процессов, и далее моделью состояний, которые входят во вторую составляющую ВТО -модели. Под взаимодействием табличных объектов будем понимать процесс передачи (чтения) или преобразования (записи) значений атрибутов одной таблицы в зависимости от условий, заданных на значениях атрибутов других (возможно, включающих первую) таблиц.
Процесс взаимодействия таблиц будем определять переходами. Переходом назовем пару {условия, действия}, заданную над атрибутами взаимодействующих таблиц. Для того, чтобы переход был определен, должна существовать, хотя бы одна таблица, над которой выполняются действия и чтения и записи. Конкретные алгоритмы действий определяют вид отображений между взаимодействующими таблицами.
Таким образом, переход позволяет описать связь между таблицами (сущностями) в терминах, истинность которых легко проверить, что необходимо для определения достоверности хранимых данных. Если таблицы (сущности) не образуют связанную модель данных, в терминах ER -модели, но между данными таблиц необходимо задать зависимость (читаемые значения атрибутов таблиц преобразуются переходом в записываемые значения атрибутов таблиц), то переход может быть задан и в этом случае.
Дадим формальное определение модели процессов. начисление, записанное в лицевом счете. Следовательно, в процессе уплаты налога между "Плательщиком" и "Потребителем" выполняются два действия (перехода): "Начисление налога" (tl) и "Уплата налога " (t2). Шаг 3. Определение действий чтения и записи. Действиям чтения на диаграмме соответствуют дуги, направленные в переход (Т), а действиям записи - дуги, направленные из перехода. На дугах указываются атрибуты таблиц, над которыми выполняются действия чтения и записи (s). Шаг 4. Определение операторов (f). Для переходов tl и t2 определим действия, соответственно, fl и 2. В параметрах операторов указаны атрибуты, над которыми производятся операции чтения и записи. Шаг 5. Определение условий выполнения переходов (g). Запуск переходов зависит от логических условий, в состав которых входят атрибуты, указанные на дугах чтения, параметры условий. Для переходов tl и t2 - это соответственно условия gl и g2. На рис. 2.2 изображена построенная диаграмма, которая описывает процесс уплаты налога следующим образом. Переход tl - "Начисление налога" может быть запущен, если выполняется условие его запуска (gl): не истекли сроки подачи расчетных документов (е22), не имеются льготы на освобождение от начисления налога (е21) , нет переплаты по другим налогам. При срабатывании перехода определяется возможность уплаты начисленных сумм сущностью Е1 и устанавливается срок платежа (е13) требуемого налога - оператор f 1. Переход "Уплата" может быть запущен, если удовлетворяются условия его запуска (g2): определена возможность начисления налога по Е2 (el4) и наступил срок уплаты (е13). При срабатывании перехода соответственно изменяется результирующие данные в лицевом счете "Плательщика" (el2) и величина выплаченной суммы "Получателя" платежа (е22), устанавливается состояние возможности проведения погашения долга между Е1 и Е2 как не определенное. В рассматриваемом примере переходы могут срабатывать одновременно. Пример может быть расширен до более сложного взаимодействия. Введем определение свойств, которыми обладает модель процессов. Это - связываемость таблиц, ординарность, рефлексность и однородность модели. Дадим краткое определение каждого свойства: Связываемость. Две таблицы называются связываемыми, если в результате выполнения операторов / описывающих действия над атрибутами таблиц, значения данных этих таблиц удовлетворяют функции отображения а из модели данных (см. определение 1), причем вид отображения при обновлении значений данных таблиц не изменяется. Ординарность. Модель называется ординарной, если все ее таблицы связываемые. Модель рассматриваемого примера является ординарной.
Построение канонической структуры БД с учетом требований к достоверности информации
Определение предметной области системы и построение канонической структуры БД включает в себя определение информационных требований пользователей, формирование мультиграфов информационных структур, групп типов элементов данных, выделение ключей в группах и объединение мультиграфов информационных структур в единый мультиграф канонической структуры БД.
Предметная область системы задается множеством информационных требований пользователей системы, которые определяют процедуры обработки данных в БД и состоят из множества типов элементов данных и связей между ними. Связи между типами элементов данных отображают процедуры обработки данных в БД (поиск, запись или обновление данных). При анализе информационных требований пользователей ИС определяется множество необходимых типов элементов данных и связей между ними, выявляются дублируемые типы элементов данных и избыточные взаимосвязи. Информационные требования пользователей ИС представляются мультиграфами Gpv, в которых множество вершин отображает типы элементов pv данных, множество дуг - связи между ними. Множество вершин упорядочивается по уровням иерархии, определяются типы вершин (входные, промежуточные или висячие вершины). На основе информации о входных и промежуточных вершинах формируются группы вершин, состоящие из одной входной или промежуточной вершины и множества смежных с ней висячих вершин. Определяются дублируемые висячие вершины в сформированных группах, производится их анализ и удаление. При наличии избыточных связей между группами анализируются характеристики параллельных путей и производится удаление одной из дуг в них. С использованием информации о характеристиках дуг определяются множества ключевых типов элементов данных в сформированных группах. Построение канонической структуры БД представляет собой процесс объединения мультиграфов Gpv, отображающих отдельные информационные требования в единый мультиграф Gc . При этом производится объединение множеств вершин, отображающих ключевые типы элементов данных, и множеств вершин, отображающих атрибуты данных в информационных требованиях пользователей. Возможны ситуации, когда одна и та же вершина в различных информационных требованиях отображает ключевой тип элементов данных и атрибут данных. В этих случаях мультиграф Gc дополняется связью между ключами соответствующих групп, а вершина атрибут - удаляется. Анализируется избыточность путей в мультиграфе Gc . При наличии параллельных путей на основе информации о семантике дуг определяется возможность удаления в них одной из дуг. При наличии пересекающихся атрибутов (висячих вершин с двумя и более входящими в них дугами) удаляются связи в одной из групп между ключом и пересекающимся атрибутом, и добавляется связь с соответствующими характеристиками между ключами этих групп. Завершающим этапом построения канонической структуры БД является определение циклов, их анализ и при необходимости преобразование в линейные структуры введением специальных указателей. Рассмотрим задачу анализа предметной области задачи и формирования информационных структур более подробно. Пусть, предметная область ИС задается множеством П = { pv : pv є ПУ, v є U } информационных требований пользователей системы, каждое из которых состоит из множества Kpv типов элементов данных и множества Rpv связей между ними. Для формализации описания информационных требований связи между типами элементов данных преобразуются следующим образом: если между двумя типами элементов данных имеется связь типа (1 - 1), то она разбивается на две: (1- 1) и (1 -1) - в прямом и обратном направлении. Семантическое значение каждой из полученных связей определяется семантическим значением исходной связи; ? если между двумя типами элементов данных имеется связь типа (1 - М), то вводятся связь типа (1- М) в прямом направлении и связь типа (1 -М) в обратном направлении (семантическое значение каждой из полученных связей определяется семантическим значением исходной связи); ? если между двумя типами элементов данных имеется связь типа (M - N), то она разбивается на две группы связей типов (1 - N ) и (М - 1), каждая из которых преобразуется в соответствии с предыдущим пунктом. Поставим в соответствие каждому pv-му информационному требованию пользователей ИС мультиграф G pv = V pv,A pv,Y pv , где: V pv = {Vk : ke К pv} - множество вершин , отображающих типы элементов данных; A pv = { Ar = Akk r= (Vk Vk ) г : к,к єКр, reRp} - множество дуг, отображающих связи между ними.
Структура и описание основных режимов работы
Система CAT позволяет отслеживать достоверность информации, хранимой в БД, на всех этапах жизненного цикла муниципальных информационных систем. Ниже приведем описание основных модулей этой системы, встроенной в автоматизированную систему налоговой службы АИС "Налог-21". Как видно из приведенной для иллюстрации структурно-функциональной схемы (рис. 4.3), CAT представляет собой шесть функционально независимых модулей тестирования, которые и определяют основные режимы ее работы.
Модуль настройки системы тестирования (TestPlan). Этот модуль является связующим для остальных модулей CAT и имеет интерфейсную часть с пользователем, которая позволяет осуществлять следующие действия: a. Осуществлять планирование выполнения различных тестов. b. Управлять и анализировать результатами тестирования. С. Создавать различные отчеты по результатам проведенных тестов и выдаче необходимых рекомендаций или созданию требуемых SQL -скриптов, которые позволили бы решать возникающие противоречия. d. Создавать и хранить дополнительные тесты и результаты их выполнения, нереализованные в основных модулях тестирования, получаемые на основе разработанного языка создания тест - скриптов. e. Вести мониторинг ошибок с возможностью ведения журнала ошибок (error.log ), строки которого могут быть импортированы в репозиторий, описывающий поведение системы и который может быть передан разработчикам для проведения необходимых мероприятий, которые невозможно осуществить на месте. Для каждой ошибки система запоминает дату, время и наименование тестовой процедуры, номер и состояние ресурсов компьютера , в частности объем свободной памяти на момент фиксации ошибки. 2. Модуль конфигурационного тестирования (TestCfg). Модуль конфигурационного тестирования осуществляет проверку корректности настройки окружения системы и проверку настройки конфигурации прикладных модулей системы по следующим позициям: a. Проверка внешнего окружения системы (те наличие необходимых внешних утилит загрузки, количества установленных обработчиков и буферов, наличия необходимых директорий для временных файлов, локальных замков БД, каталога транзакций и т.д.). b. Проверка наличия всех необходимых таблиц БД, их доступности. Анализ соответствия имеющихся таблиц описанию соответствующих таблиц в эталонном репозитории. c. Проверка наличия всех внешних ключей настройки конфигурации системы и корректности их установки. d. Проверка единообразия настройки пересекающихся элементов настройки для различных компонент АИС. e. Проверка корректности имеющихся внешних ресурсов системы их описанию в эталонном репозитории. f. Отключение режимов проведения отладки компонент АИС. 3. Модуль тестирования конфигурации форм и их информационной наполненности (TestFrm). Данный модуль проверяет корректность имеющихся на местах информационных баз описания форм отчетных документов по следующим позициям : а. Корректность синтаксиса описания форм. Поскольку особенности реализации различных форм могут разнится в зависимости от места применения информационной системы, пропадает необходимость хранить исходное описание формы в эталонном репозитории и остается возможным проверять лишь корректность синтаксиса описания формы. b. Корректность информационной наполненности форм. Данный режим позволяет проверить правильность взаимосвязи результирующих расчетных данных их расчетному значению заложенному на языке описания форм. c. Корректность составленных формул. Данный режим производит контрольные вычисления по вновь внесенным в БД формулам и в случае обнаружения ошибок в синтаксисе указывает неверно записанные предложения языка. 4. Модуль тестирования исходных текстов и эмулирования работы пользователя (TestSrc). Данный модуль применяется на этапе разработки информационной системы и в процессе тестирования функционирования основных экранных форм системы. При разработке данного модуля не ставилась задача отслеживания ошибок определяемых компилятором , а делался упор на определение интерфейсных ошибок исходных тестов программы. В данном модуле можно выделить следующие основные режимы : a. Проверка уникальности используемой мнемоники элементов экрана (горячие клавиши) b. Проверка соответствия выделяемых ресурсов для отображения списков строк (ListBox) c. Проверка последовательностей обхода полей формы (TabOrder) d. Проверки правильности выравнивания элементов экрана относительно друг друга, вертикальных и горизонтальных осей. e. Проверяет соответствие величины компонентов экранных форм величине самой экранной формы. f. Проверяет соответствие выделяемых ресурсов для компонент отображения состояния таблиц с размерностью и количеством записей в отображаемой таблице. д. Проверки наличия избыточных компонент формы, вызов которых не происходит в самой форме, h. Проверка наличия в системе не вызываемых окон, і. Производит эмулирование работы пользователя в собранном проекте путем произвольного нажатия различной комбинации клавиш с целью проверки функционирования различных режимов системы на предмет "зависания", j. Генерация оптимального кода запроса на языке нижнего уровня по сформированному SQL запросу. 5. Модуль системы определения достоверности информации БД (СОДИ). Данный модуль предназначен для определения достоверности хранящейся в БД информации и описан в предыдущем разделе главы. 6. Модуль тестирования информационной наполненности системы (Testlnf). Модуль тестирования информационной наполненности БД отвечает за соответствие наполненности информационных справочников системы на местах состоянию информационных справочников эталонного репозитория.
