CC BY
24
ровать спектр более детализированных моделей, на основе которого сгенерировать исполняемые модели и прототипы реальных систем телекоммуникационных приложений.
Предлагаемый подход позволяет также выявить и исправить некоторые классы ошибок, недостатков и некорректностей в исходных требованиях.
СПИСОК ЛИТЕРАТУРЫ
1. Летичевский, А.А. Спецификация систем с помощью базовых протоколов [Текст]/А.А. Летичевский, Ю.В. Капитонова, А.А. Летичевский (мл.) [и др.]//Кибернетика и системный ана-лиз.-2005.-№° 4.-С. 3-21
2. Buhr, R.J.A. Use Case Maps for Object-Oriented Sytems [Текст]/Ю.А. Buhr, R.S. Casselman. -Prentice Hall, 1995.
3. Use Case Map Navigator [Электронный ресурс] http://jucmnav.softwareengineering.ca
4. Никифоров, И.В. Использование Use Case Map в современной технологической цепочке разработки программного обеспечения [Текст]/ И.В. Никифоров, Ю.В. Юсупов//ХХХУШ Неделя
науки СПбГПУ. Матер. межвуз. науч.-техн. конф. СПб.: Изд-во Политехнического ун-та.-2009. -С. 92-93.
5. Letichevsky, A. Basic Protocols, Message Sequence Charts, and the Verification of Requirements Specifications [Текст]/А. Letichevsky, J. Kapitonova,
A.(Jr). Letichevsky [et al.]//ISSRE 2004, Workshop on Integrated reliability with Telecommunications and UML Languages, Rennes. -4 Nov. 2005. -P. 30-38.
6. Котляров, В.П. Автоматизация формализации требований программного проекта [Текст]/
B.П. Котляров, А.В. Петров//Научно-технические ведомости СПбГПУ.-2009.-№ 3.-C. 236-241.
УДК 004.415
М.Ш. Даишев, Л.П. Котлярова
МЕТОДИКА ОТЛАДКИ НА ОСНОВЕ ВОСПРОИЗВЕДЕНИЯ ТРАССЫ ИСПОЛНЕНИЯ ПРИЛОЖЕНИЯ НА ЯЗЫКЕ JAVA
Разработчики программного обеспечения тратят много времени, пытаясь воспроизвести дефекты, возникающие в ходе нефункционального тестирования, тестирования в реальном окружении или в уже изданном программном продукте. Основная сложность отладки таких дефектов заключается в необходимости воспроизведения дефекта в окружении разработчика. В нефункциональном тестировании часто возникает ситуация, когда дефект возникает только после нескольких дней устойчивой работы приложения. Обычно такие проблемы принято решать добавлением многоуровневого логирования, которое позволяет получить некоторую информацию о сбое. Однако часто подобная схема не срабатывает по причине недостатка отладочной информации, или из-за прекращения воспроизводимости дефекта, или из-за существенного увеличения времени до по-
явления дефекта. Во встроенном программном обеспечении с ограниченными ресурсами исправление подобных дефектов может растягиваться на недели.
Большинство известных систем отладки базируется на сохранении содержимого оперативной памяти (core dump) [1, 2], представляющего собой финальное состоянии системы перед сбоем. К сожалению, подобного решения недостаточно, поскольку сложно определить основную причину дефекта.
Одно из решений данной проблемы - создание системы, которая позволит сохранять поток управления приложения (трассу) в условиях, где дефект повторяется, и впоследствии восстанавливать состояние системы, на момент появления дефекта в окружении разработчика.
^ Научно-технические ведомости СПбГПУ 4' 2010
Система, рассматриваемая в статье, основана на анализе сохраненной трассы и для удобства отладки включает в себя инструментарий построения статического дерева зависимостей и механизм динамического разбиения исходного кода приложения (dynamic slicing method)[3].
Несмотря на существование инструментов отладки и трассировки со схожей функциональностью [4], можно выделить несколько серьезных проблем.
Во-первых, большинство систем основывается на периодическом сохранении состояния оперативной памяти, что требует выделения большого количества памяти. Особенно актуальна данная проблема для случая нефункционального тестирования, когда цикл тестирования может продолжаться несколько дней.
Во-вторых, такие системы часто некорректно работают с многопоточными приложениями, что существенно ограничивает их применение для Java- программирования.
В данной работе представлена методика автоматизации получения трасс выполнения приложения и отладки, с использованием методов динамического разбиения программного кода приложения.
Общая архитектура системы
Рассматриваемая система представляет собой инструментарий, позволяющий сохранять трассу исполнения приложения и выполнять удаленную отладку на исходном коде приложения (рис. 1). Каждый из этих инструментов отвечает за определенные преобразования входных данных, заданных исходным кодом. Модульность построения системы допускает как самостоятель-
ное использование отдельных подсистем, так и их произвольные комбинации, диктуемые проектной необходимостью.
В состав системы входят следующие инструменты:
статический анализатор кода; модуль логирования; модуль отладки.
Рассмотрим более подробно функциональность каждого из модулей.
Статический анализатор кода осуществляет анализ и проверку исходного кода для оптимизации работы модуля логирования и сокращения размера трассы. В ходе анализа выполняются следующие операции:
проверка и поиск наличия недостижимого кода;
анализ неиспользуемых локальных переменных, параметров, private-методов;
поиск и маркировка конструкций ввода-вывода (файловые, сокеты, сетевые операции) для последующего сохранения данных и подачи на вход модуля отладки;
поиск и маркировка java-интерфейсов внешних библиотек;
построение и маркировка дерева зависимостей методов для определения линейных последовательностей вызова методов (inline chains);
вычисление метрик сложности кода для оптимизации использования механизма контрольных точек.
Модуль логирования подключается к виртуальной машине Java (JVM) с помощью интерфейсов JPDA и JVM Tool Interface и используется для сохранения потока управления (трассы) [5]. Схема подключения к виртуальной машине Java представлена на рис. 2.
Рис. 1. Общая архитектура системы
Рис. 2. Схема подключения к виртуальной машине Java
Простейшим способом построения трассы приложения является сохранение последовательности всех исполненных инструкций. В Java имеет смысл рассматривать инструкции как последовательность байт-кодов, что обеспечивает совместимость со сторонними библиотеками, исходный код которых может быть недоступен. Впоследствии, при отладке, инструкциям можно поставить в соответствие конструкции языка Java. Подобные методы обладают существенным недостатком: при длительной работе приложения существенно увеличивается конечный размер трассы [6].
В данной работе рассматривается один из возможных методов минимизации размера трассы. Трасса представляет собой последовательность вызовов методов, создания объектов, операций выделения памяти. Необходимо отслеживать следующие типы инструкций:
• Выделения памяти, для отслеживания моментов создания экземпляров объектов.
• Доступа к памяти. Байт-коды, описывающие обращение к элементам массива или полям объекта. Сохраняется указатель на элемент объекта и идентификатор поля.
• Вызова методов. В языке Java определено четыре кода вызова методов: invokespecial, invokestatic, invokeinterface, invokevirtual. Первые два не нуждаются в трассировке, т. к. информация о вызываемых методах может быть получена из исходного кода. Оставшиеся являются кодами вызова виртуальных методов или интерфейсов, что означает, что конкретная реализация вызываемого метода становится известна только при исполнении приложения.
• Инструкции, у которых более одного предшественника в графе потока управления. Для таких инструкций записывается и предшествующий байт-код.
• Возврата значения и передачи управления. Если в методе существует более одной операции возврата, в трассу записывается конкретная сработавшая инструкция.
На основе информации, полученной статическим анализатором для каждого метода или линейной последовательности, создается таблица вызовов. Вызовы методов и возвращаемое значение методов определяется на основе статического анализа и соответствующих байт-кодов. Каждый ряд в таблице представляет собой последовательность изменений во времени для отдельной инструкции метода в зависимости от состояния системы и входных параметров. Представляем пример таблицы для метода foo().
В левой части таблицы находится исходный код на языке Java, в правой - соответствующий ему байт-код, а в нижней части представлена таблица трасс для приведенного фрагмента кода.
Для обеспечения работы с окружением операционной системы (файловая система, сетевые соединения) был разработан модуль, сохраняющий данные из потоков записи/чтения (стандартные средства языка Java) и использующий их в цикле отладки. Для каждого из потоков сохраняется:
идентификатор потока;
для файлов и интернет-соединений - адрес на виртуальной файловой системе или адрес сервера;
атомарные операции записи/чтения из потока с соответствующими задержками между ними.
Конечный лог-файл для оптимизации размера архивируется алгоритмами словарного сжатия данных.
Модуль отладки принимает на вход исходные файлы Java и трассу, содержащую описание последовательности вызовов методов. Для удобства отладки трасса разбивается на равные интервалы (по времени или по количеству инструкций).
►
4
Научно-технические ведомости СПбГПУ 4' 2010
Исходный код на языке Java и трасса из таблиц вызовов
public int foo(int num){ int result;
int tmp[] = new int[4]; if(num>10){
result = 100; }else{ result = 1;
Demo();
} 10 bipush 100
return result; 12 istore_2
13 goto 18
16 iconst_l
17 istore_2
private void doStuff(){ 18 iload_2
Demo demo = new 19 ireturn
demo.foo(lO); demo.foo(ll); demo.foo(lO);
0 1
3
4
5 7 16
iconst_4 newarray int astore_3 iload_l bipush 10 if_icmple
0:
//class Demo 3: 7: 8: 9: 11:
foo:(I)I
14: 15: 16: 18:
foo:(I)I
21: 22: 23: 25:
foo:(I)I
28:
new #2; dup
astore_l aload_l bipush 10 invokevirtual
pop
aload_l bipush 11 invokevirtual
pop
aload_l bipush 10
invokevirtual _
Таблица байт-кодов метода doStuff()
Байт-код Последовательности
0 <Objl>
11,18,25 <Objl.foo()>
Таблица байт-кодов метода foo()
Байт-код Последовательности
18 17,13,17
На основе исходного кода система восстанавливает значения параметров и вызовов методов, которые были сохранены в трассе, и вычисляет значения локальных переменных, которые не были
сохранены. При цикле отладки для программиста бывает необходимо быстро переходить вверх или вниз по стеку вызовов методов или переходить по трассе выполнения на временные метки в «про-
t
int i; int i;
int sum = 0; int sum = 0;
int product =1;
for(i =0; i < N; ++i) for(i =0; i < N; ++i) {
{ sum = sum + i;
3um = 3um + i;
product = product *i; }
} write(sum);
write(sum);
write(product);
Семинары -►
Рис. 3. Разбиение по критерию (write(sum),{sum}), слева - исходный код, справа - код после разбиения
шлое» или «будущее». Это возможно благодаря использованию табличной организации трассы.
Для удобства отладки и локализации дефектов реализована следующая технология разбиения исходного кода приложения [3]. Возьмем программу Р. Программист задает критерий разбиения в виде (/, V), где I - исследуемая команда в исходном коде; V - множество исследуемых переменных в I. Задачей разбиения является поиск инструкций в Р, которые могут повлиять на значения V в I в результате переходов потоков управления или потоков данных. Таким образом, если во время исполнения разработчик понимает, что значению V в I присвоено непредвиденное значение, то анализ соответствующего блока разбиения может объяснить причину возникновения такой ситуации. Пример алгоритма работы разбиения по критерию (write(sum),{sum})представлен на рис. 3.
Технологии разбиения разделены на две категории: статические и динамические. Статические методы вычисляют фрагмент, влияющий на значения V без учета специфики исполнения при-
ложения. Поэтому при одном и том же критерии разбиения блок, полученный динамическим способом, будет меньше статического.
С другой стороны, динамическое разбиение вычисляется на основе трассы работы приложения, и блоки разбиения оказываются намного точнее и более полезны для разработчика, который занимается отладкой приложения.
Представленная в статье технология компактного сохранения трассы Java приложения для последующего цикла удаленной отладки позволяет значительно снизить трудоемкость анализа и сэкономить время на исправление дефектов, возникающих при нефункциональных видах тестирования. При незначительных расширениях функциональности систему можно использовать как полноценный java-профайлер с расширенный набором функциональности для поиска и отладки дефектов. Преимущества описанных методик были доказаны в ходе их применения в ряде проектов по разработке встроенного программного обеспечения.
СПИСОК ЛИТЕРАТУРЫ
1. Microsoft Corporation. Dr. Watson overview [Электронный ресурс] http://oca.microsoft.com/en/ dcp20.asp
2. Netscape Communications Corp. Netscape quality feedback system [Электронный ресурс] http://wp.netscape.com/
3. Weiser, Mark Program slicing [Текст]/Мжк Weiser//IEEETransactions onSoftwareEngineering.-Jul. 1984.-Vol. 10.-Iss. 4.-P. 352-357.
4. Indus project [Электронный ресурс] http:// projects.cis.ksu.edu/gf/project/indus/
5. JDPA, JVM Tool Interface reference [Электронный ресурс] http://java.sun.com/javase/6/
6. Elnozahy, E.N. A survey of rollback-recovery protocols in message-passing systems [Текст]/ E.N. Elnozahy, L. Alvisi, Y. Wang [et al.]//ACM Computing Survey. -2002.-34(3). -P. 375-408.
