CC BY
99
АНАЛИЗ ИЗМЕНЕНИЙ ПРОГРАММНОГО КОДА МЕТОДОМ
КЛАСТЕРИЗАЦИИ МЕТРИК
Е.Г. Князев, Д.Г. Шопырин Научный руководитель - к.т.н., доцент М.В. Тарасюк
В работе представлен метод анализа метрик изменений программного кода, основанный на многомерной статистической кластеризации. Метод позволяет производить классификацию изменений по типам путем интерпретации экспертом кластеров наборов метрик. Метод упрощает процедуру просмотра кода (codereview), создает предпосылки для улучшения процесса разработки программного обеспечения и делает возможным контроль типов изменений, вносимых на различных стадиях разработки.
1. Введение
1.1. Введение в MSR и DataMining
Добыча данных из программных репозиториев (mining software repositories, MSR) [1] заключается в предоставлении средств обработки неупорядоченной информации, содержащейся в программном репозитории, выделении значимых показателей из исходных исторических данных модификации программы. Добыча данных из программных репозиториев (хранилищ исходного кода) совмещает в себе методы традиционной добычи данных с методами анализа исходного кода программ и позволяет, среди прочего, добиться улучшения процесса разработки программы на основе анализа истории ее изменений в прошлом.
Традиционная добыча данных (data mining) - это технология анализа хранилищ данных, базирующаяся на методах и инструментах поддержки принятия решений [2].
Задачи, решаемые MSR, делятся на два круга: поиск ассоциативных правил и отыскание общих характеристик изменений. Задача поиска ассоциативных правил применяется в MSR для предсказания последствий произведенных изменений. Например, как изменится количество ошибок в программе при внесении определенного изменения, какие модификации будут произведены в дальнейшем и т. д. Часто изменения могут быть не полностью документированы, и тогда результаты работы методов могут оказаться неточными [3, 4]. Задача отыскания общих характеристик изменений освещена, например, в работе [5]. В частности, в ней ставится вопрос, каков наиболее общий тип изменения при исправлении ошибки. В настоящей работе предлагается метод, который, как и [5], можно отнести к задаче отыскания общих характеристик изменений MSR.
1.2. Задача классификации изменений
Многие современные системы контроля версий хранят историю исходного кода в терминах добавления и удаления строк. Однако для проведения глубокого анализа изменений кода требуется информация о семантике произведенных модификаций [6]. Для решения проблемы в данной работе ставится задача классификации изменений программного кода. Метод классификации изменений должен автоматически производить выделение семантически различных изменений на основе значений их метрик. В данной работе не предлагается ставить четкие критерии для каждого типа изменения, наоборот, задача ставится максимально широко, так как предполагается использование методов добычи данных при ее решении. Такой подход позволит адаптивно анализировать исходные данные, выделяя в числе общих типов, также специфичные для конкретного процесса разработки шаблоны.
1.3. Краткий список существующих методов
Среди существующих методов анализа программных репозиториев выделяются несколько групп [7].
• Методы анализа служебной информации ревизий репозиториев - метод поиска семантических зависимостей [8, 9], анализ «запросов на изменение» [10].
• Эвристические методы - метод предсказания изменений [3], метод автоматический классификации изменений [11], [12] посредством анализа комментариев.
• Методы анализа синтаксиса изменений - метод эвристического сравнения синтаксических деревьев версий [5], метод анализа разницы версий [13] при помощи встраиваемых в исходный код тегов.
• Методы, основанные на добыче данных - метод обнаружения совместно появляющихся изменений [4].
Более подробно эти методы будут рассмотрены ниже.
1.4. Предложенный метод В данной работе предложен новый метод, основанный на кластеризации метрик изменений исходного кода. При помощи метода k средних МакКуина [2, 14] производится разбиение множества изменений на заданное число кластеров, каждый из которых соответствует определенному типу изменений.
1.5. Преимущества метода кластеризации метрик изменений Преимущества предложенного метода состоят в следующем.
• Объективность: для анализа используется исходный код, а не комментарий, сопровождающий изменение. Оценка по исходному коду адекватна, в отличие от классификации комментариев к изменениям, ведь комментарии могут не в полной мере соответствовать характеру изменений [11].
• Настраиваемость: для оценки изменений выбирается множество метрик программного кода. В зависимости от того, по каким аспектам изменений предполагается группировка, выбираются те или иные метрики [15, 16] (см. п. 3.4).
• Адаптивность: при кластеризации задается лишь результирующее количество групп, следовательно, для каждого отдельно взятого исходного кода будут выделяться специфичные множества изменений, которые будут интерпретированы экспертом как те или иные группы изменений (см. п. 3.3).
1.6. Практическое применение
Представленный в работе метод успешно опробован на практике. Реализован программный инструмент кластеризации ревизий репозитория системы контроля версий subversion [17]. Метрики исходного кода, написанного на любом из языков C, C++, C#, Java, вычислялись при помощи инструмента MSquared Resource Standard Metrics [18]. Разработанный инструмент доказал эффективность практического применения метода кластеризации метрик изменений на проекте Navi-Manager [19].
1.7. Краткое содержание следующих разделов
В разделе 2 статьи приводится краткий обзор упомянутых выше методов MSR, решающих задачи классификации изменений и другие близкие задачи путем анализа изменений исходного кода. В разделе 3 описывается предложенный метод классификации изменений. В разделе 4 рассматривается пример практического применения инструмента классификации изменений при разработке программного продукта Navi-Manager - системы управления флотом.
2. Предшествующие исследования
Среди методов, применяемых в рамках MSR, можно выделить [7]:
• методы разбора информации, хранящейся системой контроля версий;
• эвристические методы;
• анализ синтаксиса изменений;
• методы добычи данных.
2.1. Методы разбора информации, хранящейся системой контроля версий
Метод, представленный в работах [8, 9], основан на анализе свойств изменений, хранящихся системой контроля версий для истории исходного кода. Производится поиск общих семантических зависимостей между классами с точки зрения добавления или модификации определенного класса. Классы, модифицируемые одним и тем же автором приблизительно в одно и то же время, предполагаются зависимыми.
В работе [10] изучаются изменения на уровне исходных файлов. Последовательные изменения группируются в так называемые «запросы на изменение». Исследуются вопросы: является ли целью «запроса на изменение» добавление новой функциональности или исправление ошибки, различны ли «запросы на изменение» на различных стадиях эволюции.
Методы, основанные на разборе служебной информации из системы контроля версий, не обладают достаточной мощностью. Исходный код и содержание комментария в таких методах, как правило, не анализируются. При данном подходе невозможно сделать выводов относительно типов произведенных изменений, их структуры. Но использование служебной информации системы контроля версий в комбинации с методами анализа исходного кода приводит к повышению качества результатов.
2.4. Эвристические методы
Анализ информации об изменениях системы контроля версий может быть улучшен с применением эвристики на основе информации, выделенной из исходного кода или модели исходного кода. Множество эвристик, основанных на идентификаторе разработчика, внесшего изменение, отношении вызова-использования-определения в коде, распределении кода по файлам предложено в работе [3]. Эвристики используются для предсказания вхождений - кандидатов на изменение - исходя из предположения, что изменено заданное вхождение.
В работе [11] предложен метод автоматической классификации, основанный на анализе комментариев к изменениям кода. В комментарии производится поиск слов, специфичных для каждого из типов изменений. Если вхождение слова найдено, изменение классифицируется как принадлежащее группе, описываемой этим словом. Например, слова «исправлено», «ошибка» характеризуют группу исправлений ошибок, а слова «добавлено», «реализовано» - группу добавления новой функциональности. Далее сравниваются результаты автоматической и экспертной оценки для тестового набора данных. При таком подходе согласованность результатов достигает 70 %.
Метод [11] основывается на анализе комментариев, однако иногда разработчики не всегда исчерпывающе и корректно описывают все произведенные модификации кода. Вообще, содержание комментария субъективно. Текст, написанный человеком, часто может быть интерпретирован различным образом. Поэтому на практике не всегда корректно судить о содержании изменений, основываясь лишь на комментариях к ним.
2.7. Методы анализа синтаксиса изменений
В работе [5] при помощи эвристического алгоритма сравнения синтаксических деревьев, построенных для последовательных версий исходных файлов, строится синтаксическая разница между версиями. Затем вычисляется, сколько функций и вызовов было добавлено, модифицировано, сколько условных выражений было изменено и т.д.
В работе [20] анализируется разница версий с помощью тегов, предварительно встроенных в код. Благодаря тегам обнаруживаются добавленные, измененные и удаленные синтаксические вхождения и вычисляются типы синтаксических изменений. В результате работы метода даются ответы на вопросы: добавились ли новые методы в определенный класс, есть ли изменения в директивах препроцессора, было ли модифицировано условие любого условного оператора и т. д.
Методы анализа синтаксиса изменений в большинстве своем сложны, зависят от конкретного языка программирования. Применение таких методов в чистом виде для анализа типов изменений оправданно только для простых изменений. В случае если структура изменения сложна, метод не позволит дать однозначный ответ на вопрос о его типе.
2.10. Методы, основанные на добыче данных
Методы добычи данных предоставляют множество технологий, имеющих потенциальное применение в MSR. В работе [4] ставится цель обнаружить совместно появляющиеся в программной системе изменения: когда отдельное вхождение было модифицировано (например, функция с именем A), какие еще функции будут также модифицированы (например, функции с именами B, C).
3. Метод кластеризации метрик изменений
В данной работе решается задача классификации изменений программного кода методом кластеризации метрик изменений. Согласно классификации методов MSR из [7] (см. п. 2), предложенный подход принадлежит к методам добычи данных.
3.1. Формализация задачи
Изменение программного обеспечения S трактуется в работе как отображение множества исходных данных S в другое - множество модифицированных данных S : 5: S ——^ S V
Изменения происходят по инициативе разработчика. В данной работе рассматриваются только изменения исходного кода программного обеспечения.
Согласно обозначениям систем контроля версий каждому состоянию сопоставляется неотрицательное целое число, ревизия или версия исходных данных r:
5r : Sr — ^ Sr+1 •
В ходе разработки, тестирования и поддержки программного обеспечения исходный код часто модифицируется согласно нескольким шаблонам (паттернам), например, таким как реализация новой функциональности, рефакторинг, исправление ошибки [21]. На практике принадлежность изменения к одному из шаблонов устанавливается путем просмотра содержания изменения. Эта задача трудоемка и требует высокой квалификации разработчика, так как нет четких критериев оценки типа изменения. В данной работе предлагается выделять типы изменений при помощи кластеризации их метрик.
Метрика программного обеспечения (software metric) - это мера M, позволяющая получить численное значение некоторого свойства программного обеспечения S или его спецификаций [15, 16]. Например, количество строк исходного файла, цикломати-ческая сложность, количество ошибок на строку кода, количество классов и интерфейсов, связность и другие.
Метрика изменения программного обеспечения определяется здесь по аналогии -это мера M\ характеризующая изменение S программного обеспечения. Например, количество модифицированных строк кода, изменение цикломатической сложности, изменение количества классов и другие. Для аддитивных метрик справедливо соотношение:
MS = M* (Sr, Sr+i)= MSr+1 - MSr, (1)
здесь M - метрика исходного кода, соответствующая метрике изменения M\ Sr -исходный код до изменения ör, Sr+1 - исходный код после этого изменения.
Задача кластеризации метрик изменений состоит в построении множества C:
C = {ci, C2,...,c„], ci = [ör, ök | Md(Sr, Sk) < Dmm}, (2)
здесь MD - мера близости между объектами, называемая расстоянием, Dmin - величина, определяющая меру близости для включения объектов в один кластер. MD определяется следующим образом:
Md (Sx, Sy) = p<MM\...M\ >( Sx, Sy) = p(<mlx, m^-m^, <my m2y,...m„y>), (3) где p - мера в пространстве Rn, - метрика изменения, mix, miy - значения метрик M\ изменений Sx, Sy соответственно. Применительно к задаче кластеризации метрик изменений p - мера в пространстве кластеризации Rn; M\ - отдельное измерение пространства кластеризации; mix, miy - координаты точек в пространстве кластеризации. В качестве меры точек p в пространстве Rm в работе выбирается мера Евклида:
р(< ^ x2,..., x„ >,< yj,y^..^yn >) = д/(x -yj2 + (x2 -y2)2 + ...+ (xn - yn)2 •
3.2. Описание метода В работе для решения задачи кластеризации применяется метод к средних Мак-Куина [2, 14]. Пусть известно число кластеров n, выбраны метрики для оценивания изменений при кластеризации, а мера расстояния p между точками пространства кластеризации Rn принята евклидовой. Алгоритм кластеризации изменений следующий:
(1) Произвести начальное разбиение множества объектов {Sr} случайным образом:
C0 = {ci, С2, ..., Cn}, Ci = {Sr | Sr £ Cj, j Ф- i}.
(2) Принять номер итерации l = 1.
(3) Определить центры кластеров cci по формуле:
£[5r е Ci]MX5r) cci = —-
e Ci]
r
(4) Обновить множества распределения объектов по кластерам Cl = (c):
Ci = (Sr | MD(Sr, ccj) = min MD(Sr, cck)).
(5) Проверить условие: IICl- Cl-111 < e,
где e - точность разбиения. Если условие выполнено, то завершить процесс, иначе перейти к шагу (3) с номером итерации l = l + 1.
Вышеописанное позволяет автоматически разбить множество изменений на кластеры. В каждый кластер группируются наиболее схожие друг с другом изменения.
3.3. Экспертная интерпретация изменений
В данном разделе под интерпретацией понимается отображение множества кластеров C, полученных при помощи метода Мак-Куина, во множество типов изменений из постановки задачи:
In : с{t„ t2,..., tn},
где {tj} - множество типов изменений, вводящихся экспертом. Например, исправление ошибки, реализация новой функциональности, удаление функциональности.
Задача поиска интерпретации In в данной работе отдается эксперту. Эта задача значительно более проста, чем исходная, так как на практике имеет смысл различать лишь небольшое число типов изменений. Определение количества кластеров и интерпретация каждого кластера производится экспертом на основе выборочного анализа изменений, принадлежащих каждому кластеру. Анализируется изменение исходного кода и комментарий, сопровождающий изменение. В результате устанавливается, какому из типов tj соответствует данный кластер ci.
В случае если в один кластер попадают изменения различных типов, возможна одна из ситуаций.
• Неверно выбрано количество кластеров для разбиения. Количество кластеров выбрано меньше числа реально присутствующих типов изменений. В этом случае следует увеличить количество кластеров n при выполнении кластеризации.
• В исходных данных присутствуют смешанные изменения. На практике возможны изменения, содержащие в себе несколько типов модификаций. Однозначная классификация таких изменений затруднительна.
• Набор метрик кластеризации неполон. При кластеризации не учитывается один из значимых параметров изменений, который должен влиять на изменение. Необходимо сконструировать соответствующую метрику, опытным путем проверить ее влияние на результат разбиения и включить в набор метрик кластеризации.
• Типы изменений неотличимы с точки зрения программного кода. Существуют типы изменений, которые невозможно отличить путем анализа программного кода. Необходима дополнительная информация для принятия решения. Такие типы следует либо рассматривать как один, либо ввести в процесс кластеризации дополнительные (не основанные на программном коде) метрики. Задача типизации таких изменений находится за рамками данной работы.
Необходимо заметить, что процесс интерпретации кластеров изменений может быть недетерминированным, так как выполняется человеком.
3.4. Выбор метрик для кластеризации
В формуле (3) п. 3.1 для меры близости между объектами Ми, используемой в методе кластеризации, присутствует набор метрик изменений МУ Выбор этих метрик должен быть обоснован интересующими эксперта аспектами классификации. Селекция конкретных метрик осуществляется путем анализа их влияния на результат кластеризации. Процесс выбора метрик М\ для кластеризации заданного набора типов изменений состоит в следующем.
(1) Формируется обучающая выборка - статистическая выборка изменений 8, по которой будет строиться набор метрик.
(2) Экспертом классифицируются изменения обучающей выборки 8 по типам
(3) Выбирается произвольная метрика изменения М" , предположительно связанная с различением набора типов изменений.
(4) Задается уровень значимости статистического критерия. Для данного уровня значимости проверяется статистическая гипотеза об отсутствии связи типов выбранных изменений и значения метрики М" для данных изменений. Если гипотеза не подтверждается, тогда метрика М" включается в набор кластеризации.
(5) Производится кластеризация изменений выборки 8 с набором выбранных метрик.
(6) Для заданного критического уровня значимости производится проверка статистической гипотезы об отсутствии связи автоматической и ручной классификации [22]. Если гипотеза подтверждается, то продолжить алгоритм с пункта (3), иначе конец алгоритма.
После окончания работы алгоритма заданный набор метрик используется для кластеризации генеральной совокупности изменений.
4. Пример практического применения метода автоматической классификации
В качестве иллюстрации работы метода кластеризации метрик изменений на практике в текущем разделе приводятся результаты применения метода на проекте КауьМаиа§ег [19]. КауьМаиа§ег - это система управления флотом, состоящая из серверной и клиентской частей. Система преимущественно реализована на языке С#. Общее количество строк кода - более 100 000.
Все оценки и выводы делаются на основании тестового набора. Все действия производятся согласно алгоритму из п. 3.4.
4.1. Выбор метрик
(1) В данном разделе анализируется набор из 29 случайным образом выбранных изменений, произведенных в проекте КауьМаиа§ег в течение 6 месяцев разработки.
(2) Изначально экспертом выбирается следующий набор типов изменений: добавление новой функциональности, удаление функциональности, исправление ошибки, ре-факторинг, косметические изменения.
(3) Выбираются следующие метрики, предположительно связанные с различением данных типов изменений:
- eLOC (effective lines of code) - эффективное количество строк кода;
- CC (cycolmatic complexity) - цикломатическая сложность;
- IC (interface complexity) - интерфейсная сложность (общее количество параметров во всех методах);
- C/S (classes/structs) - количество классов и структур [23].
Метрики изменений строятся как аддитивные при помощи формулы (1).
(4) Уровень значимости статистического критерия выбирается равным 0.05.
(5) В табл. 1 приведены сравнительные результаты экспертной и автоматической классификации для выбранного набора изменений.
Ревиз. Эксп. Класт. eLOC СС IC C/S Комментарий
12883 удал. 1 -112 -28 -39 -8 Перенос файлов между проектами, удаление ненужных.
16742 реф. 2 -4 5 18 0 Переделан на общую логику процессор InmarsatD+.
16743 реф. 2 -9 3 8 0 Обобщена обработка GlobeWireless.
17135 реф. 2 -6 -1 0 0 Обобщена логика FindOrCreateUserSource.
17404 реф. 2 -11 0 -6 0 Переведены службы и тесты на использование контекстной сессии.
17551 реф. 2 -9 -2 -5 -1 Убран дублирующийся класс DictionaryHelper.
18048 реф. 2 -6 -2 0 1 Рефакторинг работы с интервалами.
18142 реф. 2 -13 5 13 0 Реализована по-новому отри-совка меток.
18281 удал. 3 -48 -9 -6 -1 Уменьшено дублирование.
12955 нов. 4 3 0 0 0 Отчеты по сетям дополнены полями.
12956 косм. 4 1 0 0 0 Косметика.
16515 косм. 4 0 0 0 0 Убран реализованный TODO.
17613 испр. 4 1 0 0 0 Увеличен таймаут PositionDiscarder до 5 минут.
17778 испр. 4 2 0 0 0 Правка неточностей и опечаток.
17929 испр. 4 4 0 0 0 Исправлено несколько логических ошибок в работе TrackAgent.
17970 косм. 4 0 0 0 0 Переименован ITrack-Fetch.Interval в DestInterval.
18187 косм. 4 0 0 0 0 В CompoundTrack добавлен TODO.
18273 испр. 4 2 1 3 0 Поправлена ошибка при проверке флагов рисования элемента меню.
Таблица 1. Результаты автоматической классификации и экспертной интерпретации
изменений из проекта Ыау|-Мападег
18368 косм. 4 0 0 0 0 Убран бесполезный комментарий.
18382 нов. 4 2 0 0 0 При загрузке устанавливаются сохраненные значения для свойств trackAgent.
18431 испр. 4 3 1 0 0 Треки перестали отключаться при изменении промежутка времени в Playback.
15115 испр. 5 10 1 1 0 Поправлена установка vessel.LastReportTime.
15191 нов. 5 13 1 0 0 1. Добавлены блоки try..catch в методы OnStart, OnStop сервиса.
16580 нов. 5 12 4 0 0 Добавлен перенос max LastReportTime, LastSourceld в логику слияния кораблей.
16899 нов. 5 7 2 2 0 Добавлена инверсия цвета текста в колонку L в Vessel List View.
18390 нов. 5 15 6 3 0 Проверяется правильность ввода значений TrackMarksPeriod.
16337 нов. 6 26 6 5 0 Точечные объекты теперь экспортируются/ импортируются в Addlnfo как Text.
18421 нов. 6 22 0 0 0 На главную форму добавлено меню погоды.
16443 нов. 7 33 4 5 0 В диалог опций добавлена новая опция.
Таблица 1 (продолжение). Результаты автоматической классификации и экспертной интерпретации изменений из проекта Ыау|-Мападег
В колонках слева направо представлены: ревизия изменения в системе контроля версий, результат экспертной классификации, результат автоматической кластеризации на основе метрик изменений, значения метрики изменения эффективного количества строк кода, изменения цикломатической сложности, изменения интерфейсной сложности, изменения количества классов и структур, комментарий к изменению.
Количество выбранных кластеров в таблице - 7, набор интерпретируемых типов изменений - новая функциональность («нов.»), удаление функциональности («удал.»), исправление ошибки («испр.»), рефакторинг («реф.»), косметическое изменение («косм.»). В качестве пояснения следует заметить, что число кластеров выбрано большим, чем количество типов изменений, так как при интерпретации несколько кластеров относятся к одному типу (например, кластеры 1 и 3, кластеры 6 и 7). (6) В табл. 2 приведены результаты проверки статистической гипотезы об отсутствии связи автоматической и экспертной классификации. Дополнительно приведены оценки зависимости отдельных метрик изменений и экспертной классификации.
Автоматический метод еЬОС СС 1С С/Б Кластеризация на основе метрик
Экспертный метод
Экспертная классификация 0,493511 0,003259 0,343601 0,034002 0,224454 0,120888 0,379072 0,021282 0,588552 0,000392
Таблица 2. Связь метрик с экспертной классификацией. Приведены значения коэффициента Пирсона и уровни значимости
Статистическая гипотеза об отсутствии связи между экспертной классификацией и кластеризацией на основе выбранных метрик таким образом отвергается (уровень значимости ~ 0,0004 ниже заданного критического уровня 0,05, величина коэффициента Пирсона больше 0,5: ~ 0,59). Следовательно, нет необходимости продолжать выбор метрик для получения значимых результатов кластеризации на основе выбранных метрик.
4.2. Улучшение результатов
Статистические гипотезы об отсутствии связи между отдельно взятыми метриками и экспертной классификацией также отвергаются во всех случаях, кроме метрики 1С. Подтвержденная гипотеза об отсутствии связи между значениями метрики 1С и экспертной классификацией говорит о том, что метрика 1С не влияет на результат, и ее можно исключить. Возможен также анализ корреляционной связи событий появления отдельных групп и кластеризации на основе выбранных метрик. В табл. 3 приведены результаты вычисления таких величин.
Автоматический метод Кластеризация на основе
Экспертный метод метрик
Новая функциональность 0,668393
0,000037
Рефакторинг -0,66147
0,000047
Исправление ошибки 0,110010
0,284986
Экспертная классификация 0,588552
0,000392
Таблица 3. Связь экспертных типов с автоматической классификацией. Приведены значения коэффициента Пирсона и уровня значимости
Статистическая гипотеза о независимости появления экспертного типа в данной таблице и результата автоматической классификации в случае типа «исправление ошибки» подтверждается. Следовательно, выбранный набор метрик не в состоянии различать тип изменения «исправление ошибки». Для обнаружения этого типа изменений потребуется дополнительная информация, например, из системы учета ошибок.
Для кластера 4 (см. табл. 1) не наблюдается хорошего согласования экспертной оценки с автоматической классификацией. Этот кластер содержит модификации, отнесенные экспертом к различным типам: новая функциональность, рефакторинг, исправление ошибки, косметические изменения.
После отказа от отдельного класса исправления ошибок и от метрики 1С и последующей кластеризации получены результаты, представленные в табл. 4.
Рев. Эксп. Класт. eLOC CC C/S Комментарий
12956 косм. 1 1 0 0 Косметика.
16515 косм. 1 0 0 0 Убран реализованный TODO.
17613 нов. 1 1 0 0 Увеличен таймаут PositionDiscarder до 5 минут.
17970 косм. 1 0 0 0 Переименован ITrackFetch.Interval в DestInterval.
18187 косм. 1 0 0 0 В CompoundTrack добавлен TODO.
18368 косм. 1 0 0 0 Убран бесполезный комментарий.
17135 реф. 2 -6 -1 0 Обобщена логика FindOrCreateUs-erSource.
17551 реф. 2 -9 -2 -1 Убран дублирующийся класс Dic-tionaryHelper.
18048 реф. 2 -6 -2 1 Рефакторинг работы с интервалами.
16743 реф. 3 -9 3 0 Обобщена обработка GlobeWireless.
18142 реф. 3 -13 5 0 Реализована по-новому отрисовка меток.
12955 нов. 4 3 0 0 Отчеты по сетям дополнены полями.
17778 нов. 4 2 0 0 Правка неточностей и опечаток.
17929 нов. 4 4 0 0 Исправлено несколько логических ошибок в работе TrackAgent.
18273 нов. 4 2 1 0 Поправлена ошибка при проверке флагов рисования элемента меню.
18382 нов. 4 2 0 0 При загрузке устанавливаются сохраненные значения для свойств trackAgent.
18431 нов. 4 3 1 0 Треки перестали отключаться при изменении промежутка времени в Playback.
15115 нов. 5 10 1 0 Поправлена установка vessel.LastReportTime.
15191 нов. 5 13 1 0 Добавлены блоки try..catch в методы OnStart, OnStop сервиса.
16580 нов. 5 12 4 0 Добавлен перенос max LastReportTime, LastSourceId в логику слияния кораблей.
16899 нов. 5 7 2 0 Добавлена инверсия цвета текста в колонку L в Vessel List View.
18390 нов. 5 15 6 0 Проверяется правильность ввода значений TrackMarksPeriod.
16337 нов. 6 26 6 0 Точечные объекты экспортируются/импортируются в AddInfo как Text.
18421 нов. 6 22 0 0 На главную форму добавлено меню погоды.
16742 реф. 7 -4 5 0 Переделан на общую логику процессор InmarsatD+.
Таблица 4. Результаты автоматической классификации и экспертной интерпретации
изменений из проекта Ыау|-Мападег
Состав колонок в табл. 4 аналогичен составу колонок табл. 1.
Количество выбранных кластеров - 7, интерпретируемые типы изменений - новая функциональность или правка ошибок («нов.»), удаление функциональности («удал.»), рефакторинг («реф.»), косметическое изменение («косм.»).
Проверка статистической гипотезы (без учета дробления кластеров для одного типа изменения) доказала, что качество кластеризации при введении новой метрики значительно улучшено: коэффициент Пирсона = 0,89, P = 8,3*10-10. Согласованность экспертных данных с данными кластеризации на данном примере составляет 96 %.
5. Заключение
В данный момент методы добычи данных из хранилищ исходного кода слабо проработаны. Имеет место эпизодичность их практического внедрения в связи с недолгой историей исследований в этой области. Целью разработки нового метода было внести упорядоченность в работу с историей изменений программного кода.
Предложенный в работе метод предполагает участие эксперта в процессе кластеризации. Задача определения количества кластеров решается опытным путем, а именно, выполнением алгоритма кластеризации над исходными данными с несколькими значениями n (см. п. 3.2). Проблема выбора числа групп для кластеризации описана, например, в [2].
Как уже упоминалось в п. 1, преимуществом предложенного в работе метода, отличающим его от других методов (см. п. 2), является адаптивность, достигаемая за счет выбора метрик, соответствующих требуемому разбиению (см. п. 3.4).
Классификация может применяться для поиска дестабилизирующих программную систему изменений, оценки эффективности реализации проекта и других задач. Укажем варианты использования автоматической классификации изменений.
• Упрощение процедуры просмотра кода. Поиск добавленной возможности проще производить по списку изменений, добавляющих новую функциональность.
• Возможность запрета изменений на определенных этапах разработки. На этапе тестирования продукта может быть запрещена реализация новой функциональности.
• Контроль процесса разработки программного обеспечения при помощи анализа соотношений вносимых изменений. Появляется возможность оценивать скорость и качество разработки по соотношению внесенных исправлений ошибок, реализации новой функциональности и произведенных рефакторингов.
Практическое применение метода выявило проблему смешанных изменений (см. п. 3.3), сочетающих в себе разнородные модификации кода. Настоящим методом не всегда возможна корректная классификация таких изменений. Надо заметить, что наличие смешанных изменений на практике нежелательно и даже вредно. При их наличии усложняется процедура просмотра кода и другая работа с историей программного продукта. Обнаружение смешанных изменений в процессе кластеризации - предмет дальнейших исследований.
6. Литература
1. Zimmermann T. Knowledge Collaboration by Mining Software Repositories // Proceedings of the 2nd International Workshop on Supporting Knowledge Collaboration in Software Development (KCSD 2006). Tokyo, Japan, 2006, P. 64-65.
2. Баргесян А.А., Куприянов М.С., Степаненко В.В., Холод И.И. Технологии анализа данных: Data Mining, Visual Mining, Text Mining, OLAP. 2-е издание. СПб: БХВ-Петербург, 2007. 375 с.
3. Hassan A.E., Holt R.C. Predicting Change Propagation in Software Systems // Proceedings of 20th IEEE International Conference on Software Maintenance (ICSM'04). Chicago, Illinois, September 11-14, 2004. P. 284-293.
4. Zimmermann T., Wei.gerber P., Diehl S., Zeller A. Mining Version Histories to Guide Software Changes // Proceedings of 26th International Conference on Software Engineering (ICSE'04). Edinburgh, Scotland, United Kingdom, May 23-28, 2004. P. 563-572.
5. Raghavan S., Rohana R., Podgurski A., Augustine V. Dex: A Semantic-Graph Differencing Tool for Studying Changes in Large Code Bases // Proceedings of 20th IEEE International Conference on Software Maintenance (ICSM'04). Chicago, Illinois, September 1114, 2004. P. 188-197.
6. Fluri B., Gall H. Classifying Change Types for Qualifying Change Couplings // Proceedings of the International Conference on Program Comprehension (ICPC). Athens, Greece. June 2006, P. 35-45.
7. Kagdi H., Collard M., Maletic J. Towards a Taxonomy of Approaches for Mining of Source Code Repositories // ACM SIGSOFT Software Engineering Notes, Proceedings of the 2005 international workshop on Mining software repositories MSR '05. St. Louis, Missouri, 2005. P. 1-5.
8. Gall H., Hajek K., Jazayeri M. Detection of Logical Coupling Based on Product Release History // Proceedings of 14th IEEE International Conference on Software Maintenance (ICSM'98). Bethesda, Maryland. March 16-19, 1998. P. 190-198.
9. Gall H., Jazayeri M., Krajewski J. CVS Release History Data for Detecting Logical Couplings // Proceedings of Sixth International Workshop on Principles of Software Evolution (iWPSE'03). Helsinki, Finland. September 01-02, 2003. P. 13-23.
10. German, D. M. An Empirical Study of Fine-Grained Software Modifications // Proceedings of 20th IEEE International Conference on Software Maintenance (ICSM'04). Chicago, Illinois. September 11-14, 2004. P. 316-325.
11. Hassan A.E., Holt. R.C. Source Control Change Messages: How Are They Used And What Do They Mean? 2004. Draft Available Online: http://www.ece.uvic.ca/~ahmed/home/pubs/CVSSurvey.pdf
12. Mockus A., Votta L.G. Identifying reasons for software change using historic databases // Proceedings of the International Conference on Software Maintenance (ICSM). San Jose, California, 2000. P. 120-130.
13. Maletic J.I., Collard M.L. Supporting Source Code Difference Analysis // Proceedings of IEEE International Conference on Software Maintenance (ICSM'04). Chicago, Illinois. September 11-17, 2004. P. 210-219.
14. Мандель И. Д. Кластерный анализ. М.: Финансы и статистика, 1988. 176 с.
15. Орлов С. А. Технологии разработки программного обеспечения: Учебник для вузов. 3-е изд. СПб: Питер. 2004. 528 с.
16. Липаев В.В. Выбор и оценивание характеристик качества программных средств: Методы и стандарты. М.: Синтег. 2001. 224 с.
17. http://subversion.tigris.org/
18. http://m squaredtechnologies.com/m2rsm/index.htm
19. http://www.transas.com/telematics/products/navi-manager/default.asp
20. Collard M.L. Meta-Differencing: An Infrastructure for Source Code Difference Analysis. Kent State University, Kent, Ohio USA. Ph.D. Dissertation Thesis, 2004.
21. Фаулер М. Рефакторинг: улучшение существующего кода. СПб: Символ-Плюс, 2003. 432 c.
22. Вадзинский Р.Н. Справочник по вероятностным распределениям. СПб: Наука. 2001. 294 с.
23. http://msquaredtechnologies.com/m2rsm/docs/rsm_metrics_narration.htm
