Метрики кода и их практическая реализация в IBM Rational ClearCase

Страница 3 из 8  Опции документа Обсудить Выскажите мнение об этом учебном пособии Помогите нам улучшить содержание

Практическая реализация применения метрических показателей в IBM Rational ClearCase

Общая информация

Для получения данных и расчета показателей применяются различные программные продукты, предназначенные для получения метрик. НО, как не раз говорилось выше – нельзя анализировать только код, даже и при помощи очень хороших метрик, необходимо также анализировать связь кода с требованиями, результатами тестирования, сопоставлять объем кода для решения задачи, устанавливать среднее время решения типовой задачи, соотнося ее с количеством кода.

При простой обработке данных по метрикам мы получаем количественные показатели по коду, хранимому в репозитории или в отдельно выделенной папке. Применить данный метод мы также можем при выстраивании отношений с подрядной организацией (вспоминаем пример про Индию), когда при получении кода необходимо его анализировать по контрольным показателям. Также необходимо сравнивать вновь полученный код с кодом, полученным в предыдущей версии.

Попробуем выделить цепочку действий: от подачи запроса, его утверждения до реализации. Рисунок 2 показывает простой сценарий взаимодействия между подсистемами при документировании запроса и его реализации. При таком комплексном подходе получаем возможность трассирования изменений, в том числе увязывания метрик кода с общепроектными метриками.

Полная трассировка, возможность проследить дерево изменений как сверху вниз (от запроса до кода), так и снизу вверх (от кода к запросу).

На рисунке 2 документируется запрос, на его основе формируется одно требование, по которому формируется план работ, с задачами, распределенными между двумя программистами. Что видно сверху (от запроса):

• количество строк кода, разработанного на основе данного запроса;
• при типовом запросе менеджер проекта в следующий раз может спрогнозировать количество строк;
• сколько версий исходных текстов файлов было изменено;
• сколько экспериментов проводил разработчик для реализации данного запроса;
• количество строк на релиз, билд, версию;
• усилия разработчика при разработке (например, важно для выстраивания мотивационной системы: сложная задача больше оплачивается).

Что видно снизу (от кода):

• автор кода;
• сколько раз переписывал;
• количество добавленных комментариев;
• количество удаленных и добавленных строк;
• какова сложность написанного кода;
• какая задача решалась;
• какое требование реализовывал и на основании какого запроса.

Весь дальнейший материал посвящен только последней подсистеме - ClearCase: мы не будем пытаться связать воедино все метрики, а сконцентрируемся только на метриках кода. Все вышеприведенные примеры взаимодействия были необходимы только для иллюстрации место метрик кода в общем наборе проектных показателей.

Выведем основные:

• Анализ метрик по релизам (чем версия 2.0 отличается от версии 1.0 в отношении количества затраченного времени на реализацию, количества строк кода, и пр.)
• Анализ метрик по заказчикам (если выделяются ветви под каждого заказчика)
• Выборка проектных данных по определенным критериям (проектам, программам, заказчикам, субподрядчикам и.т.п.)

Это все те же метрики, только дополненные и обогащенные хранимой в системе контроля версий информацией. Как известно, любая система контроля версий, и ClearCase в том числе, хранит следующую информацию в репозитории:

• Историю изменений каждого файла проекта;
• Историю изменений каталогов проекта (когда и в каком релизе файлы добавлялись в каталог или удалялись);
• Базовые версии проекта (baseline) – слепки проекта на определенный момент времени – это все зарегистрированные версии проектных файлов, переданных в эксплуатацию или заказчику (релизы, как основные так и промежуточные);
• Информацию обо всех изменениях кода для всех заказчиков;
• Информацию обо всех изменениях кода, полученного от субподрядчиков;
• Самое главное, что для всей информации сохраняется статистика о том кем, когда и с каким комментарием выполнялось то или иное изменение.

Одного хранения метрик мало, необходим еще и анализ. Нам просто необходимо, чтобы система контроля версий была способна давать анализ по КАЖДОМУ атому хранимой в репозитории информации, чтобы возможно было в дальнейшем устраивать многомерный и глубокий анализ не только в статике, но и в динамике (например, от релиза к релизу).

ClearCase как приложение является расширяемым, то есть его можно интегрировать с любым внешним приложением, которое способно собрать метрики. Причем, информацию о показателях важно хранить не в только в базе данных системы сбора метрик, но и в самом ClearCase. Благо, сам ClearCase позволяет хранить в себе ЛЮБУЮ дополнительную информацию.

Сбор метрик в ClearCase может организовываться двумя принципиально разными способами:

• В режиме реального времени – суть метода заключается в том, что ClearCase в момент выполнения активного действия может вызвать для анализа то самое внешнее приложение. Активным действием можно считать такую важную операцию разработчика как регистрация изменений в репозитории (просто check-in)
• В отложенном режиме – сервер ClearCase сам запускается каждую ночь и собирает метрики для измененных за рабочий день данных. То есть функция обычного коллектора.

Разумное использование обоих методов заключается в предварительном анализе потребностей организации и определяется на начальном этапе вместе с набором собираемых показателей.

Приведем простой пример: одна из многих деятельностей разработчика – формирование измененной версии исходного кода (выполнение операций check-in и check-out). Нам, с точки зрения процесса, важно, чтобы разработчик не смог зарегистрировать в репозитории версию, которая не соответствует корпоративным правилам - например, соотношение LOC и COM – соотношение строк комментария к строкам кода. Соответственно ClearCase должен запретить регистрацию изменений, если они формально не подходят по каким-либо признакам.

Обращаем особое внимание на то, что мы говорим только о КОЛИЧЕСТВЕННЫХ показателях, но никак не о качественных!

Вывод в данной ситуации прост – выбираем систему реального времени для данного вида операции.

Данная часть статьи покажет, каким образом можно интегрировать систему анализа метрик и ClearCase. Мы проведем вас от начальной идеи и до практической реализации.

В первой части статьи мы касались того момента, что важно не просто хранить метрическую информацию по основным вехам (например, по релизам), а важно хранить также промежуточные результаты, которое позволят проводить более точный анализ. На рынке есть множество средств (см. литературу в конце статьи), которые позволяют замерять определенные показатели, связанные с кодом, НО для хранения метрической информации предлагается использовать внешние хранилища. У данного способа есть два принципиальных недостатка:

1. хранение информации во внешней базе не позволяет точно трассировать метрики кода к проектным метрикам
2. в основном для замера используются уже сформированные базовые версии, без учета «кухни» промежуточных версий, которых может быть достаточное количество. Эта часть особенно важна при последующей оценке сложности и объема кода.

Для иллюстрации данного подхода мы взяли одно из средств метрического анализа кода «СССС» и попытались сделать так, чтобы она «обсчитывала» все промежуточные версии, хранимые в системе версионного управления ClearCase. Которые и будут использованы для последующего анализа.

В начало

Определение требований к примеру

Итак, давайте кратко определимся с тем, что мы собираемся сделать:

1. Выбираем собираемые и хранимые метрики
2. Определяем способ хранения
3. Выбираем метод сбора информации
4. Определяем способ представления
5. Делаем «бантики»

Сначала о исходных данных. У нас есть некий тестовый пример – репозиторий ClearCase, в котором хранятся файлы проекта С и CPP. Разные файлы корректировались разное количество раз. В репозитории есть две базовые версии «REL1.0» и «REL2.0». Разные файлы по-разному размечались, в соответствии с тем какое количество раз были отредактированы. Репозиторий называется «vvv»

1. Выбираем собираемые и хранимые метрики

На данном этапе определяемся с хранимыми метриками. Понятно, что в жизни их будет много, но нам сейчас важна модель.

Собираемые метрики:

• Number of modules – число модулей
• Lines of Code – строки кода
• Lines of Comments – строки комментария
• McCabe's Cyclomatic Complexity - цикломатическая сложность
• Lines of code per line of comment – соотношение строк кода и комментария
• Cyclomatic Complexity per line of comment - цикломатическая сложность на количество строк

Учитываем, что «a-d» это целые числа, «e» - вещественное число, «f» может являться как вещественным так и простой строкой (для иллюстрации типов, представим, что она будет строкой)

2. Определяем способ хранения

На лекциях очень часто приходится отвечать на вопрос из серии «а может ли ClearCase…». Ответ всегда односложный – «Да, может».

Нам известно, что при регистрации версии в репозитории, ClearCase запоминает комментарий к версии, множество свойств (логин пользователя и дату и многое другое). Так же ClearCase запоминает входит ли данная версия в какой либо релиз (стоит ли метка на версии). Вроде, нет ничего, что позволило бы хранить статистику по метрикам, но это только на первый взгляд.

Для каждой версии ClearCase позволяет определять состав АТРИБУТОВ, которые будут сопровождать КАЖДУЮ версию файла в репозитории. Состав и число атрибутов – неограниченно.

Атрибут позволяет давать дополнительные описания к версии элемента, к уже существующим комментариям. Например, удобно в качестве дополнительных полей держать атрибуты «warnings» и «errors», которые будут описывать числовые значения, выдаваемые компилятором при компиляции той или иной версии. Во время просмотра дерева историй версий, все атрибуты, связанные с ней (бесконечное число) отображаются наравне с именами меток. Особое значение атрибуты приобретают и при тестировании, если нужно пометить нулем или единицей протестированную версию, то создают атрибут «tested», и соответствующим образом «нумеруют» протестированные версии. Атрибут также может использоваться для хранения меток

Атрибут можно сравнить с переменной, у которой есть НАИМЕНОВАНИЕ и переменное значение. Также у каждого атрибута есть его тип.

Для создания атрибута ему дают имя и тип данных, которые будут храниться.

Существуют следующие предопределенные типы значений:

• Integer. Целое числовое значение. Подходит для большинства применений;
• Real. Число с плавающей точкой. Подходит для глубокой нумерации версий;
• Time. Временное описание;
• String. Дополнительное символьное описание. Используется в тех случаях, когда одного комментария для описания версии недостаточно, например, для выделения протестированной версии можно просто создать атрибут «tested», а в качестве параметров давать значения «да» или «нет»;
• Opaque. Произвольный тип значения. Используется в тех случаях, когда тип значения неизвестен изначально (таких ситуаций лучше избегать).

Для типов значений Integer, Real и Time можно задать ограничитель значений (ограничить диапазон вводимых значений).

Для всех типов значений возможно включение пункта «enumeration», для внесения предустановленных значений (например, только 0 и 1 для атрибута тестирования, или «да» и «нет» для него же).

Также удобно пользоваться пунктом default value, устанавливающим начальные значения для атрибута.

Проще говоря, ClearCase уже содержит все необходимое для хранения метрик. Правда, хотя это и кажется странным, во многих реальных проектах атрибуты почти не используются, так как не всем очевидно их применение и часто отсутствуют процессы сбора и оценки метрик.

3. Выбираем метод сбора информации

Здесь все просто. Выбираем отложенный режим. Будем запускать скрипт, анализирующий изменения в каждой версии на дереве версий.

4. Определяем способ представления

Известно, что у ClearCase есть два способа представления информации:

• Через запрос к репозиторию (в большинстве выполняется через командную строку)
• Через построение специального представления (в данном представлении собираются только версии файлов, выбранным по специальным критериям)

Нам нужны следующие отчеты (запросы):

1. Количественный состав изменений второго релиза по отношению к первому (какие именно файлы и каких версий были в первом релизе и какими они стали во втором). Здесь мы получаем количество промежуточных версий и список измененных файлов.
2. Является производным от первого. Все тоже самое + отображение метрик для каждой версии (оцениваем объем изменений)
3. Состав изменений (список измененных файлов с метриками)
4. Суть проведенных изменений (какие строки в каких модулях были изменены). Информацию представляем с включенными фрагментами кода
5. Отчет обо всех изменениях в файле, с указанием кто, когда и какую конструкцию вносил в файл. Отдельно хочется отметить данный отчет, так как он позволяет каждому новому разработчику анализировать свой модуль на все изменения и получать единым отчетом информацию о его корректировке, что позволяет СУЩЕСТВЕННО экономить время при анализе кода. Простой пример: модуль многократно модифицируется один год. Учитывая, что в ClearCase хранятся все версии (включая экспериментальные, тестовые) новый разработчик перед тем как пробовать ту или иную конструкцию (например, при оптимизации) может посмотреть историю и выяснить, например, что данная конструкция уже была применена и показала себя неэффективной
6. Производный от 5, но с метриками.

Представление:
Построим одно дополнительное представление, в которое попадут только измененные файлы. То есть файлы, которые были в первом релизе, но изменились ко второму. Новые файлы и неизмененные файлы ОТОБРАЖАТЬСЯ не должны

5. «Бантики»

Одна из собираемых метрик – LOC по проекту. Сделаем еще лучше: будем вычислять ее по каталогам (то есть будет суммироваться общее число строк для файлов, размещенных в каталоге).

В зависимости от структуры репозитория (например, каждая папка – подсистема) можем получать достаточно продвинутые отчеты.

Суть «бантика» – показать, как встраиваются новые функции в ClearCase.

Итак, мы определились со всем. Следующие разделы показывают последовательность шагов, необходимых для выполнения задачи.

В начало

Реализация требований в IBM Rational ClearCase

Все скрипты написаны на языке Perl, встроенном в ClearCase, прокомментированы и выделены серым цветом

Реализация пунктов 1 и 2: выбор метрик и определение способа хранения

Первый шаг – создание атрибутов. Атрибуты создаются как в графической оболочке так и через команды командной строки. Выбираем наиболее быстрый способ – командную строку.

Результат работы скрипта – формирование состава атрибутов.

Реализация пункта 3: выбор метода сбора информации

У нас нет времени ждать пока сервер посчитает метрики. Пишем и запускаем скрипт сами.

Здесь находится самая интересная особенность. Для подсчета метрик выбрана бесплатная утилита, коих море в сети Интернет. Особенность утилиты в том, что она сканирует только файлы (версии файлов нам надо подставлять скриптом). Результат работы программа записывает в XML файл, который читается, из него извлекаются метрики и показатели и ставятся в виде атрибутов на версии файла.

После выполнения данного скрипта ClearCase посчитает метрики для всех версий всех файлов репозитория. При последующем запуске он будет обсчитывать только те версии, на которых нет атрибутов.

В зависимости от того, как настроена политика ветвления (по заказчикам, по субподрядчикам и т.д) можно получать довольно любопытные показатели: например, после приемки кода от субподрядчика провести анализ изменений. Либо построить срез по тому, что было реализовано в конкретной версии.

Реализация пункта 4: определение способа представления

1. Количественный состав изменений второго релиза по отношению к первому (какие именно файлы и каких версий были в первом релизе и какими стали во втором). Здесь мы получаем количество промежуточных версий и список измененных файлов.

Пример реализации:

Отчет как раз показывает версии измененных файлов.

2. Является производным от первого. Все тоже самое + отображение метрик для каждой версии (понимаем объем изменений)

Обратите внимание на атрибуты LOC и COM.

3. Состав изменений (список измененных файлов с метриками)

4. Суть проведенных изменений (какие строки в каких модулях были изменены). Информацию представляем с включенными фрагментами кода

Обратите внимание на указываемые типы изменений (inserted, after, changed).

5. Отчет обо всех изменениях в файле, с указанием кто, когда и какую конструкцию вносил в файл. Отдельно хочется отметить данный отчет, так как он позволяет каждому новому разработчику анализировать свой модуль на все изменения и получать единым отчетом информацию о его корректировке, что позволяет СУЩЕСТВЕННО экономить время при анализе кода.

6. Производный от 5, но с метриками.

Формирование представления

Основа любого представления – конфигурационная спецификация. Для получения представления с заданными характеристиками необходимо сначала его создать, а затем видоизменить конфигурационную спецификацию для придания новых свойств.

Предварительно посмотрим скриншот ClearCase Explorer для простого представления, в котором собраны последние версии файлов.

Как видим, нам представлен общий список файлов.

Создаем представление с такой конфигурационной спецификацией:

В начало

Реализация пункта 5: «бантики». Формирование контекстного меню и подсчет метрики LOC для подсистем и проекта вцелом

ClearCase имеет возможности по созданию пунктов контекстного меню для встроенного Explorer и для Windows Explorer.

Наша цель, для реализации пункта 5 сформировать скрипт, проводящий подсчет атрибутов в заданном каталоге

В модуле создания контекстных меню формируем пункт для директорий и ссылаемся на скрипт. В аргументах передаем путь до текущего каталога.

После выполнения манипуляций пункт «calculate» появится на каталогах, хранимых в репозитории.

Активация пункта приведет к вызову скрипта и к выводу следующего окна на экран.

В начало

	Страница 3 из 8