Содержание к диссертации
Введение
ГЛАВА 1 Анализ проблемы тестирования и диагностирования программных средств 14
1.1 Методы тестирования и диагностирования программных средств 14
1.2 Тестирование классов с использованием потока данных 27
1.3 Методы оценки сложности вычислительных алгоритмов и их распараллеливания 30
1.4 Постановка задачи исследования 36
ГЛАВА 2 Методы тестирования и диагностирования вычислительных алгоритмов с использованием графа потока данных 39
2.1 Особенности тестирования и диагностирования объектно-ориентированного программного обеспечения 39
2.2 Основные термины и определения, используемые при разработке модели и алгоритмов диагностирования программного обеспечения 41
2.3 Структура разработанного метода тестирования и диагностирования объектно-ориентированных вычислительных алгоритмов 50
2.4 Модель диагностирования программного обеспечения с использованием графа потока данных 53
2.5 Метод автоматизированного построения граф-модели потока данных алгоритма для целей диагностирования и отладки вычислительного алгоритма в процессе тестового прогона 57
2.6 Алгоритмы анализа графа потока данных вычислительного алгоритма, полученного в процессе тестового прогона, для целей тестирования и диагностирования 74
2.7 Исследование методов упорядочивания списка проверочных вершин граф-модели потока данных с целью повышения эффективности работы алгоритмов.. 79
2.8 Выводы 86
ГЛАВА 3 Автоматизация разработанных методов и внедрение в программный проект для практического применения 87
3.1 Интеграция класса Number в тестируемый проект для целей диагностирования вычислительных алгоритмов 87
3.2 Разработка спецификации конвертора 91
3.3 Интеграция графа потока данных в проект C++ на платформе Visual Studio Net 2005 с использованием конвертора 96
3.4 Выводы 97
ГЛАВА 4 Применение графа потока данных для анализа и оптимизации вычислительных алгоритмов 99
4.1 Применение граф-модели потока данных для оценки сложности вычислительных алгоритмов 99
4.2 Анализ сложности реализации программных алгоритмов с целью их оптимизации на основе графа потока данных 104
4.3 Модель графа потока данных для целей распараллеливания вычислительного алгоритма ПО
4.5 Выводы 119
ГЛАВА 5 Практическая реализация разработанных методов диагностирования ошибок программного обеспечения 120
5.1 Описание работы программы расчеты зачетов налоговых платежей 120
5.2. Оптимизация диагностирования программы зачета налоговых платежей 122
5.3. Выводы 124
Заключение 125
Список литературы
- Тестирование классов с использованием потока данных
- Основные термины и определения, используемые при разработке модели и алгоритмов диагностирования программного обеспечения
- Разработка спецификации конвертора
- Анализ сложности реализации программных алгоритмов с целью их оптимизации на основе графа потока данных
Введение к работе
Актуальность проблемы.
Постоянное расширение сферы применения программного обеспечения во всех областях человеческой деятельности с одновременным увеличением требований к надежности и качеству разработки определяют проблему надежности использования программного обеспечения. Большое значение в успешном решении этих задач принадлежит методам и средствам автоматизированного тестирования и диагностирования программных средств.
Современное программирование все больше при разработке сложного программного обеспечения опирается на объектно-ориентированную парадигму. При этом сама разработка проекта строится при помощи определения классов, используемых в программе, построения дерева классов и реализации кода проекта. При правильном использовании классов, точно отражающих прикладную область приложения, объектно-ориентированный метод дает более короткие, понятные и легко контролируемые программы по сравнению с процедурно-ориентированным подходом.
Тем не менее, нетривиальное программное обеспечение, разработанное с помощью объектно-ориентированного программирования, не гарантирует отсутствия ошибок в программе. Для целей повышения надежности и качества объектно-ориентированного программного обеспечения необходимо решать задачи автоматизации тестирования и диагностики, что требует разработки новых моделей, методов и алгоритмов.
Проблема снижения трудоемкости диагностирования объектно-ориентированного программного обеспечения с целью локализации ошибок (под ошибкой понимаем дефект в программе, повлекший несоответствие требованиям спецификаций) - задача актуальная, поскольку на тестирование и отладку программного обеспечения уходит до 80 процентов затрат на разработку. Основная проблема диагностирования программного обеспечения заключается в том, что ошибка, проявление которой выявлено на этапе тестирования, может находиться не в месте ее проявления. Соответственно, для эффективной локализации ошибок в процессе тестирования следует сохранять необходимую для целей диагностирования информацию о работе программы.
Фундаментальные теоретические и прикладные вопросы тестирования и диагностики программного обеспечения изложены в работах Майерса, Бейзера, Макгрегора, Боехма и ряда других зарубежных авторов. Среди отечественных авторов следует отметить Пархоменко П.П. и Липаева В.В.. В качестве модели тестирования и диагностирования программного обеспечения в этих работах предлагается использовать управляющий граф программы. Следует отметить, что методы, разработанные для данной модели, хорошо зарекомендовали себя при тестировании и диагностике процедурно-ориентированного программного обеспечения. При переходе к объектно-ориентированному программному
обеспечению основные свойства объекта (инкапсуляция, наследование и полиморфизм) накладывают дополнительные особенности на тестирование и диагностику ошибок в программе. Кроме того, объектно-ориентированная парадигма подразумевает событийную управляемость. Это означает, что передача управления может осуществляться путем генерации сообщений различными объектами с дальнейшим разбором сообщений соответствующими обработчиками и передачей этих сообщений объектам, для которых данные сообщения предназначены. В результате использование модели в виде графа по управлению становится недостаточным для целей диагностирования программ объектно-ориентированной парадигмы.
В тоже время модель представления программ в виде графа потока данных, отражающего информационные зависимости между операциями над данными в программе, позволяет значительно расширить возможности автоматизирования решения задач локализации ошибок за счет повышения информативности тестовых прогонов программного обеспечения.
В современных условиях задачи тестирования и диагностирования ошибок в программном обеспечении стоят достаточно остро, так как своевременная локализация местоположения ошибки и ее устранение значительно повышают эффективность процесса проектирования сложного программного обеспечения и снижает стоимость его разработки. Таким образом, разработка новых моделей и методов диагностирования является актуальной задачей.
Цель работы
Разработка и исследование моделей, методов и алгоритмов диагностирования программ на граф-моделях потока данных с целью локализации местоположения ошибки в вычислительном программном коде. Автоматизация разработанных методов для их практического применения.
Методы исследования
В теоретических исследованиях диссертационной работы использовались методы теории графов, теории множеств, методы оптимизации, численное моделирование, модели, методы и алгоритмы теории надежности. Для практической апробации разработанных алгоритмов применено программное моделирование тестирования и диагностирования, реализованное на языке Delphi 5. Графический материал при проведении исследований получен с использованием пакета Microsoft Excel.
Объекты исследования
Объектами исследования являются программные реализации вычислительных алгоритмов на языке C++ для различных сред разработки.
Научная новизна диссертационной работы
1. Разработана граф-модель потока данных для диагностирования
программного обеспечения, позволяющая существенно сократить затраты по
поиску и локализации ошибки в программном обеспечении за счет
увеличения информативности тестирования.
Разработан алгоритм построения в фоновом режиме графа потока данных при тестировании программы с сохранением идентификаторов обработанных данных для целей диагностирования ошибок.
Разработан метод оптимизации списка операций, подвергаемых проверке в случае выявления несоответствия требованиям спецификаций, на основе анализа графа потока данных алгоритма.
4. Предложены критерии ранжирования операций над данными,
подверженных проверке, в соответствии которым построена оптимальная
последовательность их проверок. Получены оценки эффективности критериев
ранжирования.
5. Разработан метод оценки сложности алгоритма с целью его
оптимизации на базе граф-модели потока данных. Предложен метод
автоматизации получения исходных данных для целей распараллеливания
алгоритма с использованием граф-модели потока данных.
Практическая значимость работы
Применение разработанной модели диагностирования программ объектно-ориентированной парадигмы позволяет повысить эффективность выявления местоположения ошибки в программах, реализующих сложные вычислительные алгоритмы. Оптимизация объема диагностической информации, подверженной проверке, полученной в результате тестовых прогонов, обеспечивает снижение трудоемкости разработки программного обеспечения на этапе отладки. Автоматизация процесса построения списка выполненных операций над данными, подверженных проверке с автоматическим сохранением их имен, позволяет повысить информативность проведенного тестового прогона.
Выявление ошибок на ранних стадиях проектирования программного обеспечения значительно снижает стоимость его эксплуатации, а также вероятность катастрофических последствий.
Разработанные математические модели и алгоритмы доведены до практической реализации, что подтверждено свидетельством о государственной регистрации программы для ЭВМ.
Реализация результатов работы
Разработанные математические модели реализованы в среде Microsoft Visual Studio NET 2003. Алгоритмы анализа информации о тестовом прогоне реализованы в среде Delphi 5; используются в учебном процессе в виде прикладных задач в лекциях курсов «Надежность, эргономика и качество АСОиУ» и «Технология программирования» для студентов, обучающихся по специальности 22.02.00 «Автоматизированные системы обработки информации и управления» в ГОУ ВПО Нижегородского Государственного Технического Университета им. Р.Е. Алексеева. Разработанный программный продукт «Диагностирование вычислительного процесса» передан в Центр контроля и диагностики Госстандарта РФ, в Научно-исследовательский вычислительный центр Федеральной налоговой службы и в ООО «Теком».
Апробация работы
Основные результаты диссертационной работы докладывались и обсуждались на Всероссийских научно-технических конференциях "Информационные системы и технологии" ИСТ-2004, ИСТ-2005, ИСТ-2006, на Международной научно-технической конференции "Информационные системы и технологии" ИСТ-2007, на VI Международной конференции «Идентификация систем и задачи управления» SICPRO '07, на 11-й Нижегородской сессии молодых ученых (технические науки).
Публикации
По результатам диссертационной работы опубликовано 13 работ в печатных изданиях, в том числе 2 работы в изданиях, рекомендованных ВАК.
Структура и объём работы
Диссертационная работа изложена на 156 печатных листах, включает 18 рисунков и состоит из введения, 5 глав, заключения, списка литературы и 6 приложений.
Тестирование классов с использованием потока данных
В ряде работ [36, 68] предлагаются методы упорядочения маршрутов тестирования по следующим критериям ранжирования: по длительности исполнения, по числу команд в маршрутах, по количеству условных переходов, по вероятности выполнения маршрутов. Очевидно, что процесс тестирования и диагностирования программ существенно зависит от порядка реализации маршрутов тестирования.
Следующим этапом реализации процедуры тестирования является построение тестовых примеров [66]. В данной области широкое применение нашли методы символического моделирования тестов. При этом вдоль каждого пути тестирования записываются условия прохождения программы по этому пути в виде некоторого предиката. Полученная в итоге среда предикатов решается методами математического программирования. Найденное таким образом решение определяет совокупность тестовых примеров обнаружения ошибки. Данные методы символического тестирования и диагностирования ошибок были предложены в работах [84, 83]. Дальнейшее развитие данные методы получили в работах [7, 11, 62, 12, 37, 30, 55], где для решения систем неравенств, получаемых на путях тестирования, применяется метод проб и ошибок [55], а в работах [7, 11] -методы линейного программирования. В работе [62] решается одна из сложнейших задач символического тестирования - определение функции программы. Функция программы рассматривается здесь как полная система функций путей тестирования программы. В работах [37, 30] рассмотрена система автоматизации тестирования программ, в основе которых лежит символическое моделирование тестов. В работе [55] делается попытка объединить структурный подход и символическое моделирование. Методы символического тестирования, рассмотренные в работах [84, 83, 7, 11, 62, 12, 37, 30, 55] ориентированы, главным образом, на обнаружение ошибок, без указания причин их возникновения. В работе [52] делается акцент на то, что одним из главных современных направлений в диагностировании программных средств является разработка методов не только обнаружения, но и локализации ошибок.
Задача локализации ошибок в программных средствах аналогична задаче локализации дефектов в технических системах, однако имеет ряд отличительных особенностей, делающих ее более сложной. В частности - это отсутствие проверочного эталона, многообразие типов ошибок, мест их возникновения и форм их проявления [83].
Наиболее часто в практике отладки программ (процесса, осуществляемого после прохождения тестов и состоящего из двух этапов -определения местоположения ошибки в программе и ее корректировка) применяются методы «грубой силы», индукции и дедукции.
Метод «грубой силы» - это локализация ошибок в программе с использованием дампа памяти, постановкой операторов печати (логов) после каждой строки программы, использование автоматических средств отладки.
Диагностирование на основе дампов памяти представлено в работах [48, 56, 31]. Отладка заключается в анализе значений, располагающихся в ОЗУ, начиная с некоторого адреса. Если иметь знания о содержимом памяти при корректной работе программы, то такой метод принесет положительный эффект. Однако таким способом можно обнаружить неверные данные, но не всегда установить причину их появления. Как указано в работе [48], общая методология выявления причины ошибки посредством анализа дампа памяти отсутствует. Не ясно, в каких точках распечатка состояния памяти способна дать информацию об имеющихся ошибках.
Второе направление метода «грубой силы» связано с введением в программу регистрирующих операторов в некоторых контрольных точках[5, 26, 45, 48, 57]. Назначение контрольных точек - ресурсоемкая задача. А для программы, являющейся объектом с большим числом состояний, задача оптимального выбора расположения точек контроля, при наличии ограничений на их размещение, является сложной задачей.
В работе [26] предлагается адаптивный генетический алгоритм эволюционного моделирования для решения задачи назначения оптимального количества точек контроля, обеспечивающих требуемый объем диагностической информации. Объектами исследования являлись сложные процедурно-ориентированные программные системы. Программы представлялись графом причинно-следственных связей.
Для сложных программ применение методов назначения минимальной совокупности точек контроля, основанных на анализе матриц проверок, когда критерием различимости ошибки является различимость всех столбцов матрицы проверок, становится в принципе невозможным - возникают проблемы с памятью при хранении и обработке промежуточных результатов работы алгоритмов.
Генетические алгоритмы представляют собой новое направление в поисковых алгоритмах, применяются для решения задач с большим числом возможных состояний, по своей сути являясь алгоритмами нахождения глобального экстремума многоэкстремальной функции. Они значительно сокращают перебор в сложных задачах и легко адаптируются к изменению условий проблемы, что важно при решении задачи назначения контрольных точек в программах различной природы.
Адаптация генетического алгоритма к решению задач назначения контрольных точек в программе процедурно-ориентированной парадигмы потребовало настройки его параметров, а именно: - выбора схемы для реализации оператора кроссовера (когда новое множество контрольных точек создается из элементов двух существующих множеств путем объединения частей этих множеств);
Основные термины и определения, используемые при разработке модели и алгоритмов диагностирования программного обеспечения
Большое число ошибок содержится в вычислительных алгоритмах, обрабатывающих большое число переменных, содержащих циклы с большим числом параметров, реализующих рекурсивные вызовы функций [18]. На поиск ошибок в этих программах уходит значительная часть средств, идущих на разработку программного обеспечения.
Таким образом, возникает необходимость в разработке новых эффективных диагностических моделей и автоматизации методов диагностирования, позволяющих осуществлять поиск ошибок не только с точностью до отдельных конструкций кода программы, но и определять причины и момент возникновения ошибок. Например, какая именно переменная, и в какой момент работы программы получила неверное значение, что привело к неверным результатам работы программы в определенный момент времени.
В общем случае, диагностика ошибок должна осуществляться на заданном программистом уровне - от некоторого модуля или блока программы до ошибок, получаемых при выполнении элементарных операций переменными программы.
Отметим, что автоматизация процессов поиска ошибок с указанием причин их возникновения является актуальной задачей, не решенной до настоящего времени.
Использование модели в виде графа потока данных и разработка автоматизированных методов анализа полученных в процессе тестовых прогонов таких графов дает возможность существенно облегчить процедуру диагностики программного модуля [6].
Определение 2.8. Граф потока данных - это ориентированная граф-модель, состоящая из входных узлов, узлов вывода, запоминающих узлов, обрабатывающих узлов данных и соответствующих связей и свойств. Входной узел - узел, через который вводятся данные. Узел вывода - это узел, через который данные выводятся. Запоминающий узел - перенос данных из ОЗУ на жесткий диск и обратно. Обрабатывающий узел - узел с одной или более входящими связями и, по крайней мере, с одной исходящей связью. Входящие связи обозначают объекты данных, а исходящая связь обозначает вычисленную функцию этих объектов данных. Вершины в таком графе соответствуют действиям над данными, а дуги - связям между этими действиями, означающими непосредственное использование данных одних вершин для получения значений в других вершинах.
Определить причину возникновения ошибки можно, реализовав алгоритм обработки данных с одновременным сохранением информации о состоянии памяти для каждого значения переменных, в которых наиболее вероятна ошибка в диагностируемой части программы.
В этом случае анализ всей истории работы алгоритма с данными до полученного момента обнаружения ошибки позволит значительно сузить диапазон возможных мест возникновения ошибки (например, в каком вызове функции, на какой итерации, в каких операторах, при каких значениях переменных и т.д.).
Алгоритмы, в соответствии с которыми решение поставленных задач сводится к арифметическим действиям, назовем вычислительными алгоритмами [1].
Определение 2.9. Под элементарными операциями, используемыми в вычислительных алгоритмах, будем понимать арифметические операции (в том числе поразрядные операции), операции отношения, операции ввода/вывода и вычисления элементарных функций.
Данный перечень элементарных операций может быть дополнен или сокращен в зависимости от специфики тестируемого алгоритма, т.е. наличия в нем тех или иных операций. Сюда могут быть включены побитовые и логические операции, а также другие операции, применимые к классу вещественных чисел. Применение модели в виде графа потока данных позволяет, в зависимости от поставленной задачи, диагностировать ошибки на уровнях вычисления арифметических операций, вычисления функций и целых блоков программы.
Кроме того, применение модели тестирования и диагностирования в виде графа потока данных позволяет диагностировать ситуации, связанные с возникновением «висячих» переменных. Под висячими переменными понимаются те переменные, которым присваивались значения, но в дальнейшем в программе они не использовались.
Приведем пример, когда компилятор выдает предупреждение о том, что существует переменная, которая описана, но не инициализирована. Это предупреждение, как правило, говорит о некорректной реализации программного кода. Это частный случай «висячей» переменной.
Теперь рассмотрим случай, когда переменная будет описана, инициализирована, но в программе нигде в дальнейшем не использована. Стандартного предупреждения компилятора в процессе компиляции программы в этом случае не будет. Тем не менее, такую ситуацию следует отслеживать, т.к. это может привести к ошибкам работы алгоритма в том случае, если далее будет использована переменная с таким же именем.
Разработка спецификации конвертора
Разработанный для целей диагностирования программного обеспечения класс Number - это класс, включающий в себя всю функциональность класса вещественных чисел с интегрированной возможностью построения графа потока данных с различным уровнем детализации.
Исходный класс Number определен небольшим стандартным набором операций с вещественными числами и некоторыми математическими функциями. Класс Number и переопределенные операции интегрированы в отдельный библиотечный файл. Отдельно определены макросы, позволяющие повысить информативность тестового прогона для целей диагностирования.
Для каждого уровня детализации вычислительного алгоритма определен свой набор исполняемых операций. Последовательность исполнения вычислительных операций и их результат один и тот же. Разница лишь в агрегации операций в вершины графа.
Интеграция класса Number для целей диагностирования сводится к добавлению в программный проект директив препроцессора по включению файлов класса и замене описаний переменных, подверженных анализу в процессе диагностирования ошибок типом Number. В начало каждого файла (программного модуля), подверженного диагностированию, добавляется препроцессорная директива #include APDAMac.h (APDA - automation program s diagnostic analysis -автоматизация программы диагностического анализа). Данная директива подключает созданный нами файл, в котором определены все необходимые для целей диагностирования макросы. Кроме того, в ней определены директивы включения файлов класса Number. В данных файлах определены вычислительные операции над переменными и действия по построению графа потока данных алгоритма в процессе тестового прогона для всех трех уровней детализации.
Замена описаний (второй шаг интеграции класса Number в программный проект) может осуществляться двумя методам: - ручная обработка исходного программного кода, подверженного тестированию и диагностированию, с отслеживанием каждого введенного изменения разработчиком (использование стандартного средства текстового редактора C++ Find and Replace); - автоматизированная модификация исходного программного кода, подверженного тестированию и диагностированию, с помощью разработанного для этих целей алгоритма, реализованного в виде конвертора. При этом все изменения программного кода, необходимые для внедрения разработанной модели, вносятся автоматически. Оба метода имеют свои преимущества и недостатки.
Первый метод более гибкий по отношению к программной реализации (модификации подвергаются только фрагменты программного кода, представляющие интерес для диагностирования) и применяется, когда количество переменных, подлежащих переопределению для целей диагностирования, невелико. Но при этом он менее информативен в плане диагностирования ошибок, поскольку не предполагает автоматического хранения для каждой вершины данных о местоположении соответствующей операции внутри программного кода. Второй метод предполагает модификацию программного кода на этапе отладки в рамках отдельных файлов программного проекта и применяется, когда затраты на ручное переопределение диагностируемых переменных неоправданно высоки. Отметим, что все изменения в программе, необходимые для интеграции в нее модели с целью диагностирования ошибки, убираются после окончания тестового прогона и не влияют на работу программы в дальнейшем. Таким образом, второй метод позволяет использовать более мощные средства отладки с автоматическим модифицированием и восстановлением программного кода после завершения тестового прогона.
Для примера работы первого метода интеграции модели в диагностируемый проект рассмотрим программный код работы с пользовательским классом «числовых элементов», представленный ниже:
Анализ сложности реализации программных алгоритмов с целью их оптимизации на основе графа потока данных
В данной главе приведена экспериментальная часть работы по диагностированию процедур программы зачетов платежей на основе методов, разработанных в диссертационной работе.
Налоговые расчеты являются сложным вычислительным процессом из-за большого количества переменных, участвующих в расчете и большого количества зависимостей по данным между ними.
Современные средства автоматизирования диагностирования вычислительного процесса, применяемые для отладки программ налоговых расчетов, используют списки вызовов функций в процессе тестового прогонов и программы визуализации SQL-запросов в виде диаграмм.
Диаграммы SQL позволяют визуализировать запрос, отображая графически зависимости по данным на стадии проектирования. Список вызовов функций отображает зависимость исполняемых операторов в процессе тестового прогона.
Проведенный анализ показал отсутствие средств в области диагностирования ошибок, позволяющих визуализировать зависимости по данным в процессе тестового прогона. Даная задача эффективно решается при использовании граф-модели потока данных.
Вопрос зачета (возврата) налогов всегда актуален. Практически любая организация хотя бы раз переплачивала налог в бюджет. Переплата возникает у налогоплательщика по разным причинам. В частности, он может допустить неточности в исчислении налогов при определении налоговой базы и ставок, а также обычные технические ошибки при таких расчетах. Переплата может образоваться и в результате ошибок, которые сделаны при перечислении налоговых платежей. Например, при заполнении платежного поручения. Обнаружить переплату может и налогоплательщик, и налоговые органы.
Решение задачи автоматизации зачетов платежей реализовано в специализированной программе.
С 2008 года вступили в силу некоторые изменения в НК РФ, которые были внесены Федеральным законом № 137-ФЗ. Внесение изменений в программу в соответствии с новыми требованиями ставят задачу проведения повторного тестирования и диагностирования программного продукта. Сложность и требования к качеству обуславливают применение средств автоматизированного тестирования и диагностирования. В Приложении 4 представлен фрагмент программного кода, хранящий процедуры, используемы для зачета налоговых платежей. Точка входа в расчет: ХП ProcPaymentOffsets. Кроме того, в данном фрагменте описаны процедуры: - Add309310InPA 08.12.2005 17:10:08 SP - ArrStr_Offset_In 21.11.2006 14:10:07 SP - Offset_Save 28.12.2005 11:52:48 SP - OffsetOfPaym_Main 09.06.2008 12:50:29 SP - OffsetOfPayments 06.09.2007 11:55:12 SP -- TargetOffsetOnD300 06.12.2007 18:25:28 SP - TargetOffsetOnD307 14.12.2007 16:42:31 SP Размер вычислений, используемых в данных процедурах, предполагает наличие автоматизированных средств диагностирования в случае выявления несоответствия спецификациям. Важно выявить: какие процедуры и данные использовались в процессе тестового прогона.
Средства визуализации SQL-запросов для данного кода однозначно определяют зависимости по данным в рамках отдельных запросов. Но не отображают зависимостей по данным между запросами. Списки вызовов отображают логику исполнения тестового прогона, но слабо визуализированы и в случае выявления несоответствий требованиям спецификаций способствуют локализации местоположения ошибки с точностью до множества вызываемых функции. Применение граф-модели потока данных для данного кода позволяет отобразить зависимости по данным для тестового прогона в целом.
Для простоты реализации граф потока данных предлагается строить только для существенных, с точки зрения диагностирования ошибок, операций программы: описания переменных внутри вызываемых функций и вызовы функций с соответствующими наборами передаваемых параметров. Тогда выявленное несоответствие требованиям спецификаций будет локализовано с точностью до вызванных процедур с соответствующим набором атрибутов.
Для более детализированного построения графа потока данных переопределяются операции внутри отдельных процедур, повлиявших на выявленное несоответствие требованиям спецификаций.
В результате тестового прогона зависимости по данным однозначно определяются графом потока данных (рисунок 5.1). Темным цветом выделены аргументы, передаваемые при вызове той или иной процедуры (значения данных аргументов проверяются в первую очередь в случае выявления несоответствия спецификаций).
