Содержание к диссертации
Введение
Глава 1. Обзор существующих методов тестирования программного и постановка задачи исследования 9
1.1 Жизненный цикл ПО 9
1.2 Качество ПО 15
1.3 Структурная сложность ...17
1.4 Тестирование 23
1.5 Классификация ошибок 34
1.6 Постановка задачи 36
Глава 2. Базовая модель объектно-ориентированного программного обеспечения 38
2.1 Особенности ОО ПО по сравнению с традицинным ПО 38
2.2 Автоматная модель объектно-ориентированного программного обеспечения 44
2.3 Автотрассировка 49
2.4 Выводы по главе 2 67
Глава 3. Диагностическая модель. Методы и алгоритмы тестирования объектно-ориентированного программного обеспечения 68
3.1 Модель и стратегия определения состояния объектно-ориентированного программного обеспечения 68
3.2 Оптимизация выбора тестов по информационному критерию 71
3.3 Принятие решения о векторе состоянияі автомата но критерию максимума апостериорной вероятности 73
3.4 Выводы по главе 3 85
Глава 4. Практические аспекты тестирования 86
Заключение 107
Библиографический список 108
Приложение 1 код программы, реализующий алгоритм автоматического построения графа переходов конечного автомата 119
Приложение 2 дипломы и свидетельства о регистрации программы и отчета по научно-исследовательской работе 151
- Жизненный цикл ПО
- Особенности ОО ПО по сравнению с традицинным ПО
- Модель и стратегия определения состояния объектно-ориентированного программного обеспечения
- Оптимизация выбора тестов по информационному критерию
Введение к работе
Актуальность темы. Несмотря на сравнительно недавнее появление объектно-ориентированных (ОО) языков, таких как Smalltalk, Object Pascal, C++, Ada, объектно-ориентированное программирование (ООП) стало наиболее широко используемым стилем разработки программного обеспечения (ПО) в мире. ООП – методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования. ООП подразумевает событийную управляемость. Бертран Мейер, один из основателей ООП, определял объекты как “нечто имеющее идентичность, состояние, поведение”. С целью управления качеством ОО ПО необходимо решать задачи автоматизации тестирования, что требует разработки новых моделей, методов и алгоритмов, приспособленных к ОО ПО.
Фундаментальные теоретические и прикладные вопросы тестирования ПО изложены в работах В.В. Липаева, П.П. Пархоменко, В.И. Сагунова, G. Myers, B. Beizer, D. MacGregor, B. Boehm, C.V. Ramamoorthy и ряда других отечественных и зарубежных ученых. В качестве модели тестирования ПО в этих работах предлагается использовать управляющий граф программы. Однако, методы, разработанные для данной модели, хорошо зарекомендовали себя при тестировании традиционного (процедурного) ПО, но при непосредственном применении к ОО ПО имеют трудно решаемые проблемы.
Удобным средством описания ОО ПО является модель, построенная на основе теории конечных автоматов: она обладает ясностью семантики (трактовки элементов модели), наглядностью и выразительностью, и в то же время достаточно строга и формальна. Среди отечественных ученых множество работ по проблеме проектирования и реализации ПО с помощью конечных автоматов принадлежит Шалыто А.А. Представление программы с использованием элементов автоматной модели: состояний, событий, действий, переходов позволяет повысить эффективность тестирования ПО за счет проверки не только возвращаемых кодов, но и содержащихся в объекте данных.
Несмотря на то, что конечные автоматы используются уже давно для формального описания поведения систем, моделей, приспособленных к тестированию ОО ПО, нет. Классическая автоматная модель обладает рядом недостатков: отсутствие понятия параметров, в том числе и с бесконечной областью определения, отсутствие понятия времени, не определена семантика взаимодействия нескольких автоматов. Таким образом, разработка новых моделей и методов тестирования ОО ПО на основе теории конечных автоматов является актуальной задачей.
Целью диссертационной работы является разработка и исследование моделей, методов и алгоритмов тестирования ОО программ на граф-моделях переходов конечных автоматов с целью поиска ошибки в исходном коде программы.
Для достижения поставленной цели решены следующие задачи:
анализ существующих моделей, методов и алгоритмов тестирования ПО и выявление ограниченности возможности их использования применительно к ОО ПО;
разработка тестов с учетом особенностей ОО парадигмы;
обоснование целесообразности применения конечных автоматов для моделирования ОО ПО;
оптимизация процедуры тестирования;
формирование методики тестирования ОО ПО;
программная реализация разработанных алгоритмов тестирования;
применение полученных в диссертации научных результатов на практике.
Методы исследования, применяемые в работе, основаны на теории множеств, теории графов, теории автоматов, теории информации, теории надежности, методах оптимизации. Для практической апробации разработанных алгоритмов применено компьютерное моделирование, реализованное на языке С++.
Научная новизна работы состоит в следующем:
-
Обоснована целесообразность использования граф-модели переходов конечного автомата для разработки базовой (основной) модели объектно-ориентированного программного обеспечения, которая объединяет статические и динамические аспекты программы и тем самым является достаточной для проведения эффективного тестирования.
-
В рамках предложенной базовой модели разработана новая диагностическая модель объектно-ориентированного программного обеспечения, ориентированная на разработку методов и алгоритмов решения задач тестирования с учетом особенностей ОО парадигмы, а именно:
на основе информационного критерия разработан метод выбора оптимального подмножества тестов из допустимого множества для локализации ошибок произвольной кратности;
разработан алгоритм принятия решения о состоянии ОО ПО по критерию максимума апостериорной вероятности.
Практическая ценность и рекомендации по использованию результатов.
Разработаны средства автоматизации внедрения разработанной модели в программный проект с минимальной модификацией программного кода.
Полученные в диссертационной работе результаты могут использоваться для решения практических задач тестирования ОО ПО событийно-управляемых систем, в том числе телекоммуникационных, систем контроля и управления физическими устройствами, а также для тестирования функциональности ПО с точки зрения пользовательского интерфейса. Результаты настоящей работы были использованы при разработке программ в ЗАО “Интел А/О”.
Результаты работы использованы в госбюджетной НИР (Отчет по НИР «Диагностика технических и программных систем с использованием современных информационных технологий». № государственной регистрации 01.2009.00405 от 28.01.09 – Н.Новгород: НГТУ), выполненной по целевой межвузовской программе «Диагностические и информационно- поисковые системы».
Обоснованность и достоверность результатов диссертационной работы подтверждается корректностью использования математического аппарата и представленными результатами компьютерного моделирования.
Апробация работы. Основные положения диссертации и результаты диссертационной работы представлялись и докладывались на следующих научных конференциях:
X Международной конференции «Фундаментальные и прикладные проблемы приборостроения и информатики» (Москва, 2007);
VII Международной конференции «НТИ-2007. Информационное общество. Интеллектуальная обработка информации. Информационные технологии» (Москва, 2007);
VII Международной молодежной научно-технической конференции «Будущее технической науки» (Нижний Новгород, 2008);
Международных научно-технических конференциях «Информационные системы и технологии (ИСТ-2008, ИСТ-2009)» (Нижний Новгород);
Международном симпозиуме «Интеллектуальные системы INTELS’08» (Нижний Новгород, 2008);
XIII Международной открытой научной конференции «Современные проблемы информатизации» (Воронеж, 2008);
ХII Международной научно-практической конференции «Системный анализ в проектировании и управлении» (Санкт-Петербург, 2008).
На конкурсе научных работ аспирантов X Международной конференции «Фундаментальные и прикладные проблемы приборостроения и информатики» (Москва, 2007) и VII Международной молодежной научно-технической конференции «Будущее технической науки» (Нижний Новгород, 2008) доклады автора были отмечены дипломами первой и третьей степени.
Публикации. По теме диссертации опубликовано 12 работ, в том числе 1 статья в журнале из перечня ВАК РФ, свидетельство о государственной регистрации программы для ЭВМ.
Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения и списка литературы, включающего 128 наименований. Работа изложена на 118 страницах, содержит 11 таблиц и 15 иллюстраций.
Жизненный цикл ПО
Оценка качества как составная часть тестирования производится на протяжении всего жизненного цикла ПО.
Под жизненным циклом ПО понимают весь период его разработки и эксплуатации (использования), начиная от момента возникновения замысла ПО и кончая прекращением всех видов его использования [27-29,76]. Жизненный цикл включает все процессы создания и использования ПО (software process).
Стадия разработки (development) ПО состоит из этапа его внешнего описания, этапа конструирования ПО, этапа кодирования (программирование в узком смысле) ПО и этапа аттестации ПО. Всем этим этапам сопутствуют процессы документирования и управление (management) разработкой ПО. Этапы конструирования и кодирования часто перекрываются, иногда довольно сильно. Это означает, что кодирование некоторых частей программного средства может быть начато до завершения этапа конструирования.
Внешнее описание (Requirements document) ПО является описанием его поведения с точки зрения внешнего по отношению к нему наблюдателю с фиксацией требований относительно его качества. Внешнее описание ПО начинается с определения требований к ПО со стороны пользователей (заказчика).
Конструирование (design) ПО охватывает процессы: разработку архитектуры ПО, разработку структур программ ПО и их детальную спецификацию.
Кодирование (coding) создание текстов программ на языках программирование, их отладку с тестированием ПО.
На этапе аттестации ПО производится оценка качества ПО, после успешного завершения которого разработка ПО считается законченной.
Программное изделие (ПИ) - экземпляр или копия, снятая с разработанного ПО. Изготовление ПИ - это процесс генерации и/или воспроизведения (снятия копии) программ и программных документов ПО с целью их поставки пользователю для применения по назначению. Производство ПИ - это совокупность работ по обеспечению изготовления требуемого количества ПИ в установленные сроки [31]. Стадия производства ПО в жизненном цикле ПО является, по-существу, вырожденной (не существенной), так как представляет рутинную работу, которая может быть выполнена автоматически и без ошибок. Этим она принципиально отличается от стадии производства различной техники. В связи с этим в литературе эту стадию, как правило, не включают в жизненный цикл ПО.
Стадия эксплуатации ПО охватывает процессы хранения, внедрения и сопровождения ПО, а также транспортировки и применения (operation) ПИ по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения ПО и фазы сопровождения ПО [76,107].
Применение (operation) ПО - это использование ПО для решения практических задач на компьютере путем выполнения ее программ.
Сопровождение (maintenance) ПО - это процесс сбора информации о его качестве в эксплуатации, устранения обнаруженных в нем ошибок, его доработки и модификации, а также извещения пользователей о внесенных в него изменениях [27,76,107].
Исторически, в ходе эволюционного развития теории проектирования программного обеспечения и по мере его усложнения, сложились основные модели жизненного цикла [100]. Эти модели выражают последовательность этапов жизненного цикла ПО.
Проект разработки программного обеспечения (ПО) должен осуществляться в соответствии с моделью жизненного цикла (ЖЦ). Действия, связанные с обеспечением качества, должны планироваться и проводиться с учетом особенностей выбранной модели ЖЦ.
В нашей стране жизненный цикл разработки ПО установлен стандартом ГОСТ [80] и содержит следующие стадии и этапы (табл. 1.3).
В работе [43] используется понятие системное проектирование - это период ЖЦ ПО начиная от формулирования первичного замысла на создание ПО до начала детального проектирования и разработки. Результатом должно являться согласованное и формализованное разработчиком и заказчиком представление о целях, назначении, функциональных задачах и качестве будущих ПО.
Системный проект программного средства должен содержать достаточно полные требования к функциям и характеристикам качества комплекса программ, описание и графическое представление его архитектуры, базы данных и взаимодействия компонентов, предполагаемую модель жизненного цикла, предварительные планы последующих этапов и работ. Кроме того, в него должны входить проекты технического задания.
В требованиях к ПО предлагается указывать, какие функции должны осуществляться, а не то, как они могут реализовываться. Они используются для задания функциональных и конструктивных требований, а так же ограничений проектирования.
Построение корректных требований к системе во многом зависит от надлежащей обработки изменений требований. Управление изменениями даёт уверенность в том, что создаваемая система является корректной, и будет правильной в дальнейшем.
Фаза детального проектирования является решающей в создании программ. Она основывается на принципах структурного проектирования [47].
Методология структурного анализа и структурного проектирования ПО начинается с общего обзора функций системы. Затем она должна детализироваться сверху вниз в виде иерархической структуры. Таким образом, процедуры сбора, хранения и переработки информации расчленяются на отдельные элементы данных и действия, совершаемые над этими данными. Структурный анализ позволяет разделить систему на функциональные части, выделить функциональные описания отдельных частей, исследовать в них информационные потоки и формализовать структуры данных.
Структурное проектирование крупномасштабных ПО основано на модульном принципе [47].
Проектирование модулей включает в себя разработку описания алгоритмов обработки данных, внутренних структур данных, межмодульных интерфейсов, структурных схем передач управления. С их помощью определяются функции, порядок следования отдельных шагов обработки, ситуации и типы данных, вызывающие изменения процесса обработки, а так же повторно используемые функции программы.
В информационных модулях (ИМ) целесообразно использовать типовые структуры, ориентированные на эффективную обработку данных в конкретной проблемной области [49]. Объединение ИМ позволяет создавать более сложные структуры данных определённого целевого назначения. Иерархия связей между этими компонентами в некоторой степени соответствует процессу обработки и потокам данных и относительно слабо связана со структурой программных компонентов в ПО. Структуры ИМ целесообразно координировать между собой с учётом цели и места их использования программными компонентами.
В последнее время структурное проектирование сложных КП на базе готовых программных и информационных компонентов качественно изменяется и активно развивается на основе концепции и стандартов открытых систем. Цель - повышение общей экономической эффективности разработки и функционирования информационных систем, а так же логической и технической совместимости их компонентов, обеспечение мобильности и применения готовых программ и данных. Это обеспечивает: - возможность переноса (мобильность) прикладных систем и ПО с минимальными изменениями на широкий диапазон аппаратных и операционных платформ; - совместную работу (интероперабельность) с другими прикладными системами и ПО на локальных и удаленных платформах; - взаимодействие с пользователями в стиле, облегчающем последним, переход от системы к системе (мобильность пользователей).
Особенности ОО ПО по сравнению с традицинным ПО
Уже около двух десятилетий объектно-ориентированное программирование является наиболее широко используемым стилем разработки ПО в мире. Про этот стиль написано столько книг, а поддерживающие его языки настолько различны, что на данный момент среди разработчиков не существует однозначного понимания, что такое объектно-ориентированное программирование. Если попытаться обобщить все имеющиеся мнения на этот счет, получится нечто слишком абстрактное. Поэтому, прежде всего, опишем вкратце, что понимается под объектно-ориентированным программированием в данной работе.
Объектно-ориентированная парадигма характеризуется следующими основными видами концепций [57].
Объектная декомпозиция. Этот вид декомпозиции основан не на вопросе "Что делает система?", как декомпозиция сверху вниз, а на вопросе "Кто действует в системе?". Поскольку этот аспект является более устойчивым, то и построенная таким образом архитектура хорошо приспособлена к эволюции. В результате модули системы рождаются из сущностей, которые, однако, характеризуются не внутренним содержанием, а теми сервисами, которые они предоставляют. Такие сущности называются абстрактными типами данными (АТД). Формально абстрактный тип данных состоит из множества операций, снабженных описаниями из областей определения — предусловиями, и множества аксиом, которые задают свойства операций. Классы. Класс — это полная или частичная реализация АТД и единственный вид модуля в О О системе. Такие модули взаимодействуют между собой через интерфейсы (с точностью до обозначений интерфейс соответствует понятию АТД, на котором основан класс). Интерфейс класса содержит сигнатуры его компонентов: запросов и команд, а также семантические свойства: предусловия и постусловия запросов и команд, инварианты класса. Компоненты класса соответствуют операциям АТД, предусловия компонентов - предусловиям операций, постусловия и инварианты — аксиомам АТД.
Предусловия, постусловия и инварианты также называются утвероісдениями, в совокупности они образуют контракт класса или его компонента. Метод разработки ПО, в котором утверждения являются неотъемлемой частью текста программной системы, называется проектированием по контракту [105]. В соответствии с этим методом система считается корректной только в том случае, если перед вызовом любого компонента выполняется его предусловие, а по завершению работы компонента — его постусловия. Инвариант класса должен выполняться во всех устойчивых состояниях любого объекта этого класса (в тех состояниях, которые могут наблюдать клиенты класса). Вызывая компонент (метод) некоторого класса клиент указывает имя компонента и если требуется, его фактические аргументы. Различных компонентов в классе обычно всего несколько. В то время как различных аргументов может быть необозримо много. При этом имя компонента определяет действие (алгоритм вычислений), а значение аргументов — только результат действий (результат вычислений).
В отличие от модулей в структурной парадигме программирования (например, в языках Pascal, Ada), класс одновременно является модулем и типом. Любой тип объектно-ориентированной программной системе основан на некотором классе.
Объекты. Если класс полностью реализует АТД, то он может иметь экземпляры — объекты. Связь между объектом и классом имеет двоякую природу, как и сам класс. С одной стороны, класс — это тип объекта (и понятие типа здесь практически ничем не отличается от понятия типа переменной в объектно-ориентированных языках), а с другой, - класс как модуль определяет те операции, которые применимы к объекту.
Объект — это единственный вид сущности, имеющийся в объектно-ориентированной программной системе во время выполнения. Вызов компонента на некотором объекта — основной вид операции в объектно-ориентированных вычислениях.
Наследование — это механизм, позволяющий создавать повторно используемые программные модули. С точки зрения класса как модуля, наследование - механизм расширения, позволяющий определять новые классы, частично используя определение уже существующих. С помощью этого механизма возможно, во-первых, построить модифицированный класс без необходимости внесения изменений в существующий класс (следовательно, и в описания его клиентов), а во-вторых, вносить такие модификации, которые изначально не предполагались автором класса.
Связь между наследуемыми классами описывается с использованием модели иерархии наследования. При графическом представлении данной модели классы изображаются эллипсами, а связи по отношению наследования показываются в виде одинарных стрелок. Стрелка указывает вверх от наследника к родителю. Стрелка - это не просто произвольная пиктограмма, она указывает на одностороннюю связь между своими двумя концами. В данном случае:
Всякий экземпляр наследника можно рассматривать как экземпляр родителя, а обратное неверно.
В тексте наследника всегда упоминается его родитель, но не наоборот. Это, на самом деле, является важным свойством ОО-метода, вытекающим из принципа Открыт-Закрыт, согласно которому класс не "знает" списка своих наследников и других собственных потомков.
С точки зрения класса как типа наследование — это механизм порождения подтипов. Подтипы, в свою очередь, обеспечивают один из видов полиморфизма, при котором к сущности некоторого типа, может быть во время выполнения, присоединен объект его подтипа. Полиморфизм позволяет клиентам одинаково работать с множеством "похожих" классов. И поэтому является мощным механизмом повторного использования кода.
Исследования, в которых вместе фигурируют автоматы и объектно-ориентированное программирование, ведутся различными авторами в течение длительного времени. Например, известно множество шаблонов для объектно-ориентированной реализации автоматов, а диаграммы состояний стали частью объектно-ориентированного языка моделирования UML [63]. Однако, судя по тому, что автоматы на сегодняшний день редко используются при проектировании и реализации сложного поведения, результаты исследования нельзя назвать удовлетворительными.
Что касается языка UML, в нем существуют три основных препятствия для использования диаграмм состояний, как общепризнанного и распространенного средства описания сложного поведения. Во-первых, кроме диаграмм состояний для описания поведения предлагается использовать и другие типы диаграмм, и не существует общих правил, определяющих, когда и какие диаграммы следует применять. Во-вторых, в рамках унифицированного процесса разработки программ [68] не было предложено подходов для совместного использования диаграмм, описывающих структурные и поведенческие свойства программ. И, в-третьих, диаграммы для описания поведения в среде пользователей UML в основном используются как язык общения между разработчиками и для документирования программ, в то время как подобающая им роль - точная спецификация, которая может служить источником для ее программной интерпретации.
Модель и стратегия определения состояния объектно-ориентированного программного обеспечения
Пусть G=(V,E,X,p) - ориентированный граф состояний (граф переходов). Путем (маршрутом) Р из вершины v0 в vt называется последовательность смежных дуг графа (е0, ..., ej такая, что et.j Q et при l i t. Множество путей {Pb...,PR}, соединяющих вход и выход графа Gen вершинами назовем покрытием этого графа, если любая дуга лежит хотя бы на одном из путей данного множества. Покрытие с минимальным числом путей назовем минимальным покрытием графа.
На основании построенной граф-модели можно получить необходимые тестовые сценарии: любой путь из начальной вершины в конечную является тестом. Каждому тесту соответствует определенное подмножество вершин графа, через которые он проходит в процессе реализации. Эти вершины назовем проверяемыми данным тестом, а остальные непроверяемыми.
Совокупность тестов должна выбираться таким образом, чтобы они покрывали все вершины графа. При прохождении теста через вершину графа состояние автомата может выйти за пределы допустимых, что соответствует возникновению ошибки на данном этапе тестирования. Эта ошибка может привести к возникновению ошибок и на последующих этапах тестирования.
Если заданный тест не прошел, то на наличие ошибок подозреваются все вершины графа, которые были активизированы, при этом результат тестирования обозначим через 1. Результаты проверок по набору тестов образуют вектор zy-eZ.
Таким образом, каждой вершине графа можно поставить в соответствие возможное изменение состояния автомата, которое может оказаться недопустимым, т.е. ошибочным. В рамках диагностической модели состояние ПО можно описывать вектором состояний автомата.
Разработка стратегии определения вектора состояний автомата производится с учетом следующих основных принципов (рис. 3.2):
1. Подмножества векторов состояний автомата sk, соответствующие различным результатам тестирования zy , не пересекаются. Действительно, если бы они пересекались, то нашелся бы такой вектор состояний автомата, которому соответствовали бы два различных вектора zy, чего быть не может. 2. Каждому вектору Zj соответствует подмножество вершин графа, подозреваемых на наличие ошибок Подмножества вершин графа, соответствующие различным векторам zj, могут пересекаться в
Таким образом, стратегия определения вектора состояний автомата сводится к определению подмножества векторов, которое соответствует полученному вектору Zj и, следовательно, к определению подмножества вершин графа. Стратегия определения вершин графа, действительно содержащих ошибки, может быть различной. В частности, можно проверить каждую вершину графа отдельно, начиная с вершин, ошибки в которых определяют наиболее вероятные вектора состояний автомата.
При этом необходимо решить следующие задачи оптимизации: - определение минимального множества тестов, которое необходимо для обеспечения заданной глубины локализации состояния автомата; - определение глубины локализации при заданном множестве тестов.
Для решения указанных выше задач необходимо упорядочить тесты по количеству информации, которое они доставляют. Располагая упорядоченной последовательностью тестов, можно определить их минимальное подмножество, которое обеспечивает заданную глубину локализации, или максимизировать ее при заданном количестве тестов. Например, если необходимо обеспечить глубину локализации состояния с коэффициентом, равным =0,94, то из диаграммы (рис.3.3) следует, что в качестве минимального множества тестов необходимо выбрать тесты с номерами 5,4,2,3. Аналогично решается обратная задача. Если из допустимого множества тестов имеется возможность использования только теста 3, то для обеспечения максимальной глубины локализации необходимо выбрать тесты с номерами 5,4,2,3, при этом коэффициент К примет максимальное значение, равное =0,94.
Пусть имеется т тестов. Результатом тестирования является т-мерный вектор Zj, которому соответствует определённое подмножество векторов состояний автомата. Очень важно принять решение в пользу наиболее вероятного вектора состояний автомата.
Оптимизация выбора тестов по информационному критерию
Строго говоря, такое переопределение меняет поведение программы. Так как новые переопределенные объекты становятся больше по размеру (хотя бы потому, что в них приходится хранить номер созданной вершины графа и, возможно, другую дополнительную информацию). Поэтому, например, в операциях побайтового ввода-вывода их использовать уже нельзя, хотя объекты встроенных типов зачастую так выводить очень удобно (например, во временных файлах, когда различия в хранении чисел в разных машинах не играют роли). С другой стороны, можно изначально писать программу с использованием переопределенных типов и получить всю мощь автотрассировки при отладке, тем более что с помощью условной компиляции можно убрать переопределение в любой момент, повысив производительность для версии-релиза.
Трасса (причем со связями по управлению) вполне может быть построена профилировщиком типа Callgrid (из пакета Valgrind). Тем не менее, это уже не автотрассировка, т.к. граф передачи управления строится с помощью отладчика и его точек останова, автоматически расставляемых в точках входа функций. Он позволяет определить, какие функции вызывались и в каких местах, однако связи по данным не определяет, а автотрассировка позволяет, в принципе, их определить и даже вывести значения данных в определенных точках.
Межпроцессное взаимодействие Так как при автотрассировке трасса генерируется самой тестируемой программой, в которую вносятся соответствующие изменения, генерируемые данные должны чем-то приниматься и обрабатываться. Изменения в тестируемой программе должны быть минимальны (только необходимые переопределения типов для автоматической генерации вершин графа и связей). Поэтому есть смысл ту часть программы, которая принимает и обрабатывает граф, определяет пути и т.п., вынести в отдельный процесс. Тогда в тестируемой программе потребуется только переопределить типы и добавить модуль передачи графа головной программе, что намного удобнее и надежнее. Такого рода взаимодействие может быть реализовано самыми разными способами, например:
1. Тестируемая программа пишет трассу в файл, который затем читается тестирующей. Этот путь простой, но не позволяет отслеживать прохождение трассы в «реальном времени» и, кроме того, обмен с дисковым файлом является довольном медленным;
2. Можно также использовать примитив межпроцессного взаимодействия (IPC - InterProcess Communication) типа программного канала (трубы) для передачи команд по созданию вершин, связей, информации о текущей точке выполнения программы тестирующему модулю. В таком случае эти два модуля могут располагаться, в принципе, даже на разных хостах сети. Так как команды поступают сразу же при прохождении соответствующего участка трассы, граф может быть построен «в реальном времени». Можно сохранить граф в файл с целью его последующего анализа.
Разработанное программное обеспечение использует второй подход. Для организации обмена данными используется механизм именованных программных каналов (named pipes) Windows NT. Именованные программные каналы доступны всем процессам, запущенным в системе, поэтому с их помощью можно организовать обмен между двумя процессами.
Подход для организации обмена данными поверх программного канала в нашем случае используется тот же, что и в реализации удаленного вызова процедур (RPC). Головная программа сначала создает именованный программный канал (он называется \\.\pipe\autotracing). Затем она запускает тестируемый модуль, который, в свою очередь, открывает этот канал и по мере необходимости отправляет в него различные команды. При завершении тестируемого модуля канал закрывается.
Все задачи буферирования и синхронизации при работе с программным каналом решает ОС, поэтому нам при реализации IPC заботиться об этом не нужно. При переполнении буфера канала пишущий процесс автоматически блокируется до тех пор, пока место не освободится (т.е. пока процесс не считает данные). При опустошении блокируется читающий процесс до поступления данных. Все это выполняется автоматически. Так как передача идет через системный программный канал, доставка данных гарантируется, поэтому об этом тоже заботиться не нужно.
Для удобства вызовов на клиентской стороне создаются заглушки (stubs), которые могут быть вызваны как обычные функции. Тем не менее, они не выполняют сами никакой работы кроме той, что отправляют по программному каналу код операции и ее параметры, а затем ждут результата.
На стороне «сервера» (т.е. процесса, исполняющего вызовы) канал прослушивается постоянно и при наличии поступивших данных из канала извлекается код операции, определяется, какой функции он принадлежит и вызывается соответствующий обработчик. Последний извлекает из канала параметры и выполняет требуемую работу, возможно, помещая в канал результат выполнения, если он нужен.
Каждая функция помимо номера имеет свое символьное имя (например, lookup или addedge) на случай того, что набор функций и их номера могут в будущем измениться. Причем выделена специальная функция lookup, которая принимает строку имени функции от клиента и возвращает ему соответствующий идентификатор, который представляет собой обычное целое 32-битное число (на Win32). Функция lookup всегда имеет нулевой идентификатор.
Первое, что выполняет клиент после подключения к программному каналу, это выяснение идентификаторов нужных функций. В случае построения графа методом автотрассировки для нашей программы определены следующие функции. Схематично опишем их с указанием типа параметров в скобках и типа возвращаемого значения перед именем (string — строка с завершающим нулем, int — целое число основного для архитектуры и ОС размера (например, 4 байта на х86 под управлением 32-.битной Windows), void — отсутствие параметра или возвращаемого значения).
