ТЕСТИРОВАНИЕ ИСХОДНОГО КОДА ДЛЯ ОЦЕНКИ ТРУДОЗАТРАТ РАЗРАБОТЧИКА
» (), Тверь
Тел.: (08, e-mail: *****@***ru
В настоящее время в качестве единицы измерения для производительности труда разработчика обычно используется число строк программы, созданных им за определенный промежуток времени. Данная оценка не является достаточно надежной, поскольку большая часть профессиональных программистов – это системные аналитики, которые, потребляя свыше 70% общих ресурсов, выделяемых на программирование, вообще не создают ни одной строки программного кода, а заняты лишь анализом приложений и постановкой задачи. Однако объективной причиной использования данного критерия является трудность получения других надежных оценок, поэтому трудозатраты на создание программного проекта оценивают через объем кода.
Современные среды разработки (такие как, например, MSVC++, BCB, Delphi и др.) позволяют значительно автоматизировать процесс написания программы путем генерации определенной части ее исходного кода. Фактически, разработчик реализует лишь бизнес-логику работы программного проекта, что влечет за собой снижение трудоемкости разработки. Поэтому для более точной оценки трудозатрат необходимо проанализировать исходный код программы с целью выделения кода, написанного непосредственно разработчиком.
Задача в общем случае не имеет однозначного решения, поскольку любой автоматически сгенерированный средой разработки код может быть в точности воспроизведен опытным разработчиком. Поэтому сформулируем задачу следующим образом: необходимо определить, какие строки кода могли быть автоматически добавлены в исходный код программы средой разработки. Для решения необходимо знать особенности той среды разработки, в которой создавался исходный код программного средства.
Добавляемые автоматически средой разработки строки исходного кода являются, как правило, шаблонными, поэтому их идентификация может быть осуществлена с применением лексического анализа. Согласно определению, лексический анализ – это процесс распознавания транслятором во входном тексте смысловых единиц (лексем): идентификаторов, чисел, операторов и т. п. Задачей транслятора в нашем случае является выявление определенной последовательности лексем, однозначно свидетельствующей о наличии в программе кода, который потенциально может быть добавлен средой разработки.
На данном этапе возникает задача построения базы знаний, в которой с учетом используемой среды разработки и языка программирования должна храниться необходимая для выполнения анализа информация. Кроме того, такая база знаний должна предусматривать возможность ее дополнения, поскольку современные системы разработки предоставляют программисту возможность вставки шаблонов наиболее часто используемого кода. Эти шаблоны также могут учитываться при анализе исходного кода как автоматически сгенерированный текст.
Для представления информации в базе знаний предполагается использование нотации Бэкуса-Науэра (BNF либо ее расширенного варианта EBNF), позволяющей описать грамматику основных лексем используемого языка программирования, опираясь на его алфавит, а также выражений, идентифицируемых транслятором как автоматически сгенерированный текст. Например, согласно грамматике языков С/С++, идентификатор можно описать следующим образом:
<identifier> ::= <nondigit> {<nondigit> | <digit>}
<nondigit> ::= “_” | “a” | “b” | “c” | “d” | “e” | “f” | “g” | “h” | “i” | “j” | “k” | “l” | “m” | “n” | “o” | “p” | “q” | “r” | “s” | “t” | “u” | “v” | “w” | “x” | “y” | “z” | “A” | “B” | “C” | “D” | “E” | “F” | “G” | “H” | “I” | “J” | “K” | “L” | “M” | “N” | “O” | “P” | “Q” | “R” | “S” | “T” | “U” | “V” | “W” | “X” | “Y” | “Z”
<digit> ::= “0” | “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” | “9”
Аналогичным образом можно описать выражение, которое требуется найти в исходном тексте программы. Например, начало карты сообщений, автоматически создаваемой средой разработки MSVC++, в исходном тексте может выглядеть примерно следующим образом:
BEGIN_MESSAGE_MAP(СMyApp, CWinApp)
Запишем это выражение, используя нотацию Бэкуса-Науэра:
<expr1> ::= “BEGIN_MESSAGE_MAP(” <identificator> “,” <identificator> “)”
В данном случае мы не выделяем имя макроса как идентификатор, каковым он является в действительности, поскольку в противном случае данная запись окажется неоднозначной и сможет выделить в исходном тексте также вызовы некоторых функций. Проблема здесь заключается в том, что нотация Бэкуса-Науэра применима к описанию грамматики для контекстно-независимых языков. Языки С/С++ являются контекстно-зависимыми. Несмотря на это, рассматриваемый подход представляется вполне реализуемым.
Таким образом, задача тестирования исходного кода с целью оценки трудозатрат разработчика сводится к выполнению следующих этапов:
– описание грамматики лексем, позволяющей однозначно выделять их в исходном коде для заданного языка программирования;
– однозначное описание грамматики выражений для поиска их транслятором;
– создание базы знаний;
– проектирование и реализация транслятора, позволяющего выполнять автоматизированный поиск заданных последовательностей лексем (выражений).
Непосредственным результатом работы транслятора является значение объема кода, автоматически сгенерированного средой разработки, т. е. не написанного вручную. Путем дополнительной оценки полного объема кода и нахождением разности между полученными значениями получаем значение объема кода, написанного непосредственно разработчиком.
