Путь к ошибке в нашем примере показан на рисунке 1(b), выделенном жирной линией. Он связывает, используя отношения доминирования, сайт отказа T с предком ошибки W (т.е. узел последовательность T -→ O -→ R -→ Y -→ W ).
Вышеуказанный путь используется для обозначения на ICFG подграфа, на котором необходимо выполнить следующие действия полный ежпроцедурный анализ потока данных (переход от сайта с ошибками к сайту с ошибками). Другими словами, путь на DT определяет подграф, на ICFG, который, для нашего бегущего примера, выделена на Рис. 1(а) круглыми заполненными узлами. Эта часть системы содержит оба узла узел, связанный с ошибкой, и узел, связанный с возможным сбоем, вызванным ошибкой. На рисунке 1(c) показан небольшой отрывок анализа потока данных, выполненного на шаге (7) на подграфе "Отладка-отладка" ICFG, аннотированный информацией о потоке данных.
На рисунке показаны только подграфы узлов, которые были идентифицированы на предыдущем шаге вместе с отношениями потока данных. На этом этапе, анализ типов и анализ переменных также проводится для изучения доступа к переменным, ссылкам и поля. Таким образом, можно выполнить анализ "живых" переменных, чтобы найти переменные, которые "живые", на каждый узел на подграфе. Анализ живых переменных может быть использован для поиска плохих цепочек use-definition и предлагать подозрительные определения и использование, систематическим образом, ученику. Например, в нашем примере определены константа и два поля. Во время обхода ICFG узлов в Путь к ошибке, отношения потока данных между переменными предлагаются в каждом контексте, что позволяет учеников строить предположения и гипотезы о том, по каким утверждениям и отношениям между потоками данных являются самыми подозрительными и требуют большего расследования.
Это помогает учащемуся разработать системный подход к исследованию эволюции состояния программы, который может быть повторно использован позже, когда он столкнется с обнаружением новых ошибок. Важно также, что отношения, чтобы найти ошибку, являются одними из тех, которые предлагаются инструментом в суженном пространстве: это позволяет ученикам понять и рассуждать о меньшей части системы, ведущей их, гораздо более вероятно, к обнаружению ошибок и последующему их исправлению.
5. Отладочная среда обучения.
Предлагаемый подход был реализован в качестве инструмента под названием "Отладка учебной среды". (DTE). На рисунке 2 показана архитектура DTE. Как показано на рисунке, DTE представляет собой расширение для Платформа Eclipse IDE. Среда построена на Eclipse Java Development Tools (JDT) до получить доступ к информации с исходным кодом и использовать Eclipse Modeling Framework (EMF) для реализации его модель наведения, которая визуализируется и управляется с помощью структуры Eclipse Sirius. Она получает как введите исходный код прослушанной системы в виде проекта рабочей области и метаданные об ошибках в указанном виде учителем. В частности, обработчик метаданных ошибок получает исходный код системы, а также метаданные об ошибках для генерации модифицированной версии исходного кода, в которой точка входа, багг и место отказа помечено с помощью рамки аннотаций, предоставляемой инструктору в виде стандартной Java-карты Библиотеки. Аннотированный исходный код используется сборщиком ICFG и компонентами IFDS Solver [7]. отвечающий за генерацию, соответственно, графика управляющего потока и анализа потока данных. Пользовательский IFDS Solver вычисляет DT и определяет путь к ошибке, используемый для ограничения порции системы, к которой применяется межпроцедурный анализ данных.
Вывод IFDS Solver используется генератором руководящих данных для расчета руководящих данных (т.е. управляющего потока) и отношений потока данных, ведущих от ошибки к неудаче, который поддерживает начинающего разработчика во время отладки. Сеанс отладки выполняется с помощью стандартной среды разработки Eclipse IDE отладчик, позволяющий разработчикам использовать стандартные средства проверки состояния программы для подтверждения или для опровержения их гипотезы.
Тем не менее, DTE предоставляет оцененное предложение по контексту. Это позволяет разработчику сосредоточиться только на подмножество элементов исходного кода, которые имеют прямую или косвенную зависимость от багга. Выдержка из отчета представлена на рисунке 3. Отчёт состоит из трёх основных частей. Первая слева область исходных кодов, в которой показаны утверждения контекста вызова в путь от ошибки к ошибке. Отрывок пути находится в правой части отчета: он показывает текущий вызывающий контекст, связанный с его окрестностями через известные связи потока данных. В третьей части, внизу, есть для текущего контекста список всех переменных (локальные переменные, полей или выражений), которые должны быть проверены в связи с прямыми или косвенными отношениями к месту ошибки.
Например, рассмотрим контрольный пример, приведенный на рисунке 1(c). Здесь DTE, из анализа потока данных выполняется по пути отказа от ошибки T -→ W , восстанавливает все интересные пути к узлу Y, и подчеркивает отношения, которые должны быть исследованы. В нашем небольшом примере, в контексте на месте сбоя, подход предлагает исследовать оба правильных соотношения "использование-определение" для поле логгера (которое правильно инициализировано) и подозрительное использование по умолчанию в буфере поля (т.е. несомненно, неправильное двойное определение, приводящее к ошибке).
Студенты будут изучать и то, и другое и развивать метод определения надлежащих условий для выбора и анализа возможно неправильного потока данных, отношения, идущие по наиболее многообещающим путям. Важным аспектом всего процесса DTE является спецификация метаданных об ошибках. Среда была спроектирована таким образом, чтобы позволить учителям определить управляемый сеанс отладки с использованием любой Java-программной системы, для которой ошибка уже известна. Это включает в себя оба упражнения, откалиброванные для навыков студентов и реальные программные системы с открытым исходным кодом. Этот процесс требует спецификации двух ключевых элементов: местоположения ошибки и сбоя местоположение. Усилия по инструктажу DTE для поддержки отладки при известной и исправленной ошибке низкий. Местоположение ошибки предоставляется в виде аннотации к исходному коду ошибки. Место отказа должно быть предоставлено с использованием аннотированного тестового случая, обозначенного как точка входа, и используется чтобы воспроизвести неудачу, связанную с жучком. В частности, в аннотации указано заявление программы, которая генерирует сбой при выполнении теста при известных предположениях.
DTE основан на фреймворках Soot и Heros1, используемых для сборки ICFG и, соответственно, как IFDS/IDE Solver, отношения потока данных.
Повторное использование ошибочного исходного кода... 6. Определение и планирование эксперимента.
