CC BY
36
н \ на \
АСПЕКТЫ КАЧЕСТВА наа КАЧЕСТВО по на / н
Подсчет плотности ошибок для различных артефактов кода
В.С. ЛУКЬЯНОВ,
д.т.н., профессор Волгоградского государственного технического университета
С.И. КИРНОСЕНКО,
ассистент, аспирант Волгоградского государственного технического университета (kirnosenko@mail.ru)
П
Ключевые
слова:
п □□
□ ПС НПЗ пп п
качество, системы контроля версий, метрики, ошибки, плотность ошибок.
В статье предложена модель данных для описания истории изменений исходного кода программного обеспечения, хранимой системами контроля версий. Модель позволяет выполнять расчет метрик для множеств кода, заданных на основе данных о его местонахождении в файловой системе, принадлежности конкретному разработчику, дате создания и т.п. Реализовано ПО, позволяющее формировать базу данных на основе предложенной модели и выполнять расчет различных метрик.
лотность ошибок - метрика исходного кода, которая часто используется для оценки качества и надежности ПО. Она измеряется в количестве ошибок на единицу объема кода. Существует ряд отдельных программ и расширений для популярных сред разработки, которые позволяют выполнять расчет плотности ошибок. Такие программы, как правило, представляют собой средства статического анализа кода, то есть они оперируют кодом системы, который существует на данный момент. Как следствие, они не могут дать ответ на вопрос о том, какими были метрики в прошлом или подсчитать метрики, для расчета которых необходима информация о прошлых изменениях в коде. С помощью этих средств можно выполнить расчет плотности ошибок всего кода системы или кода ее отдельных компонентов. Но расчет метрик для меньших артефактов кода посредством таких программ невозможен.
Между тем, такие метрики могут представлять значительный интерес как для разработчиков, так и для менеджеров проектов. Например, информация о плотности ошибок кода отдельного программиста может быть использована для оценки его квалификации. Оценка плотности ошибок кода, добавленного после выпуска последней стабильной версии системы, может быть использована для оценки рисков выпуска новой версии в определенный срок. Метрики плотности ошибок, подсчитанные по отдельным файлам, могут быть полезны
для распределения ресурсов тестирования и их сосредоточения на тех участках, где вероятность найти ошибки наиболее высока. Расчет метрик для таких артефактов кода невозможен без дополнительной информации. Получить такую информацию посредством статического анализа кода нельзя, т. к. в коде ее просто нет. Зато такая информация есть в системах контроля версий.
Системы контроля версий - это ПО предназначенное для хранения истории изменений исходного кода. Они позволяют хранить множество версий одних и тех же файлов; получать файлы в том виде, в каком они существовали в определенный момент времени в прошлом; определять, кто вносил изменения и т.п. Для осуществления всех этих операций системы контроля версий хранят большие объемы информации об истории всех изменений, когда-либо имевших место. Анализируя эту информацию, можно в точности восстановить историю изменений вплоть до отдельной строки кода. Именно анализ этой информации позволяет выполнять расчет сложных метрик кода, получение которых посредством простого статического анализа кода невозможно.
Существует множество различных систем контроля версий, но все они устроены по одним и тем же принципам. Всегда есть рабочий каталог со множеством файлов, с которыми работает разработчик. Система контроля версий следит за изменениями в этом каталоге. История изменений хранится в специальном хранилище - репозито-
рии (repository), и представляет собой последовательный набор «снимков» рабочего каталога - ревизий (revision). Каждая ревизия - это копия рабочего каталога по состоянию на определенный момент времени в прошлом. Каждый раз, когда разработчик завершает работу над очередной задачей, он выполняет специальную команду сохранения. В результате такой команды, все изменения, внесенные разработчиком с момента последнего сохранения, запоминаются системой контроля версий, и появляется новая ревизия. Такой набор изменений называется коммитом (commit). Изменения в нем являются одним целым в том смысле, что каждая ревизия системы контроля версий либо содержит их полностью, либо не содержит. В простейшем случае набор изменений не входит в состав ревизий, которые появились до него, а входит в состав ревизий, появившихся после.
Разбиение кода системы на множества по принадлежности к набору изменений и файлу дает возможность расчета метрик не только на основе данных об иерархической принадлежности кода, но и на основе данных о его существовании в определенный момент времени в прошлом. Для осуществления такого разбиения необходимо выполнить импорт и анализ информации из системы контроля версий.
Предположим, необходимо подсчитать плотность ошибок для некоторого множества кода. Для этого необходимо знать объем этого кода и количество ошибок, обнаруженных в нем. Подсчет
.•••' G ..." H G
КАЧЕСТВО ПО пне Ч НЕ \ G
<?$ BugFtx
® Scalar Properties tjlD
.if CommitlD 'ào Navigation Properties
Commit (*) I (&+ rSe ©]
Е Scalar Properties a Scaler Properties
»Sid П *}h> Ï
1 OrderNumber 0..1 *£ Path 1
Revision *—с AddedlnCommitD
^Author I "S DeletedlnCommitID
J?Date 1 S SourceFileD >
^ Message **f SourccCommitlO 0.1
& Navigation Properties 1 ® Navigation Properties
^ Scalar Properties ID ^Sizc
AddedlnitiallylnCornmitiD У ModificationID TargetCodeBlockD ® Navigation Properties
Ь Scalar Properties
rgiD
ComrmtD ^FilelD r Navigation Properties
Схема модели данных для хранения информации из систем контроля версий
объема кода не сложен. А вот подсчет количества ошибок, обнаруженных в этом коде, - задача нетривиальная. Дело в том, что даже если при разработке используются специальные системы учета ошибок, обычно нельзя сказать, какие ошибки к какому коду относятся. Необходимо установить связь между каждой отдельной ошибкой и кодом. Для этого можно применить метод поиска ошибочных изменений [1, с. 146].
Как только исправляющий набор изменений обнаружен, необходимо проанализировать сделанные изменения. Если код удаляется, то он считается ошибочным. Очевидно, что удаляемый код был внесен в более ранних наборах изменений. Необходимо установить в каких именно. Как только это сделано, можно сказать, что ошибка связана с кодом этих наборов изменений, то есть они являются причиной ошибки. При этом варианты классификации наборов изменений, содержащих ошибку, могут быть различными. Можно считать, что ошибку содержат все наборы изменений, затронутые исправлением, или только тот набор, который содержит наибольший объем ошибочного кода. Действуя таким образом, можно установить принадлежность ошибок к коду отдельных наборов изменений, файлов и других более мелких артефактов кода.
Всю информацию, необходимую для выполнения вышеописанного анализа, можно получить посредством трех основных команд системы контроля версий:
^ команды «log», позволяющей получить основную информацию о наборе изменений (имя автора, дата создания);
^ команды «diff», дающей возможность установить, какие строки были добавлены и удалены в конкретном наборе изменений;
^ команды «blame», которая позволяет определить для каждой отдельной строки кода, когда эта строка была добавлена.
Здесь приведены названия команд для системы контроля версий Subversion. В других системах контроля версий эти команды могут называться иначе. Также различаются форматы вывода и объем информации, который можно получить с помощью этих команд.
Вся необходимая для расчетов информация может быть получена из системы контроля версий. Однако делать это каждый раз при расчете метрик нецелесообразно, так как данный процесс связан с необходимостью выполнения множества запросов к системе контроля версий и обработки их результатов. Это обуславливает необходимость некоего промежуточного представления информации, например в виде реляционной базы данных, что позволяет избежать многократного выполнения сложных операций. Кроме того, хранение информации об истории изменений кода в базе данных дает возможность делать выборки средствами развитого языка запросов SQL.
Такой подход применялся ранее. Однако используемые при этом модели данных специфичны для конкретных решаемых задач. Они либо ориентированны на сбор общей статистики, не связанной с конкретными артефактами кода [2, с. 1], либо предназначены для хранения информации об объектной структуре программ [3, с. 83]. Для решения задачи подсчета метрики плотности ошибок необходима информация об объеме кода, содержащегося в каждом отдельном наборе изменений. При этом объектная структура кода не анализируется, так как задача подсчета объектноориентированных метрик не ставится.
Исходя из выше сказанного, разработана модель данных, обеспечивающая хранение всей необходимой информации, полученной из систем контроля версий (см. рисунок).
Модель содержит следующий набор сущностей:
^ Commit (набор изменений в системе контроля версий);
^ BugFix (исправление одной ошибки в одном наборе изменений);
^ File (отдельный файл с исходным кодом);
^ Modification (модификация определенного файла в определенном наборе изменений);
^ CodeBlock (блок добавленного или удаленного кода).
По сравнению с ранее предложенной моделью данных [4, с. 159] текущая обеспечивает сохранение информации об истории кода в копированных
АСПЕКТЫ КАЧЕСТВА
№ 4 • 2011 ВеК| КАЧЕСТВА
71
н ч. на •••
АСПЕКТЫ КАЧЕСТВА
на ..•• н
ФИНАНСЫ И БАНКИ
файлах, упорядочивание наборов изменений в соответствии с их топологической структурой, сохранение информации об изначальном авторстве кода. Главной особенностью предложенной модели является сохранение информации об объеме и принадлежности кода, содержащегося в каждом отдельном наборе изменений. Это позволяет на основе истории, представленной в виде модели, определить для любого момента времени в истории проекта, сколько кода присутствовало в системе и что это был за код. Как следствие, становится возможным расчет метрик для артефактов кода, задаваемых не только условиями нахождения кода в определенном месте файловой системы, но и условиями его существования в определенный момент времени в прошлом.
Разработано программное обеспечение MSR Tools (http://msr. sourceforge.net/), позволяющее осуществлять импорт информации, хранимой в системе контроля версий, в реляционную базу данных на основе предложенной модели данных. Также ПО выполняет расчет различных метрик, в том числе плотности ошибок, для заданных артефактов кода. Поддерживается импорт информации из систем
контроля версий Subversion и Git. Для упрощения построения запросов был разработан специальный предметноориентированный язык (DSL), который позволяет формировать запрос в виде конструкций языка C#. Разумеется, возможности данного языка не предоставляют всей свободы, которую дает SQL. Кроме того, запросы, сформированные таким образом, могут быть неэффективны с точки зрения производительности. Но для выполнения относительно простых запросов это очень удобный инструмент. Для построения сложных запросов всегда можно воспользоваться непосредственно SQL.
Предложенная модель представления истории изменений исходного кода позволяет осуществлять быстрый расчет множества метрик для различных артефактов кода, в частности плотности ошибок. Это может быть код программной подсистемы, код отдельного программиста, код, внесенный в определенный период времени, и т.д. Таким образом, можно получить множество метрик. Анализ этих метрик и динамики их изменения может дать понимание процессов, происходящих при разработке конкретного проекта. Кроме того, эти метрики могут быть применены для
построения новых и улучшения существующих моделей предсказания плотности ошибок. В конечном итоге полученные результаты позволяют надеяться на появление новых методов оценки качества и надежности ПО. ■
Литература
1. Кирносенко С.И. Идентификация исправляющих ревизий в системах контроля версий / С.И. Кирносенко, В.С. Лукьянов // Изв. ВолгГТУ. Серия «Актуальные проблемы управления, вычислительной техники и информатики в технических системах». Вып. 9: Межвуз. сб. науч. ст. / ВолгГТУ. Волгоград, 2010. № 11. C. 146-149.
2. Cvs data extraction and analysis: A case study: Tech. rep. / K.B. Mierle, K.B. Mierle, K. Laven et al. 2004.
3. Towards the integration of versioning systems, bug reports and source code meta-models / G. Antoniol, M. Di, P.H. Gall, M. Pinzger // Electr. Notes Theor. Comput. Sci. 2004. Vol. 127. P. 83-94.
4. Кирносенко C. Извлечение данных для подсчета плотности ошибок кода / C. Кирносенко // Приоритетные направления современной российской науки глазами молодых ученых: Всероссийская научно-практическая конференция молодых ученых и специалистов. Ряз. гос. ун-т им. С.А. Есенина, 2009. С. 159-161.
Проблемы информационного обеспечения анализа денежных потоков в коммерческих организациях
Денежные средства являются наиболее ограниченными ресурсами в рыночной экономике, поэтому успех коммерческой деятельности организации заключается в способности руководства их мобилизовать и эффективно использовать. Действенность каждой управляющей системы во многом зависит от ее информационного обеспечения.
В статье подробно рассматривается проблема качества информационного обеспечения анализа денежных потоков в коммерческих организациях в условиях интегрированного учета денежных потоков. Проанализировано значение интегрированного учета денежных потоков в современных экономических условиях, рассмотрены требования к качеству информации о денежных потоках для финансового, управленческого и стратегического учета. Раскрыты преиму-щества предложенных требований к качеству информации о денежных потоках в условиях интегрированного учета.
И.С. КАДЫРОВ,
аспирант кафедры учета, анализа и аудита Московского государственного университета им.
М.В. Ломоносова (Kadr007@mail.ru)
