ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 24.11.2023
Просмотров: 102
Скачиваний: 2
приемами объектно-ориентированного программирования, а это может негативно сказываться на дальнейшем развитии системы. Наследование существенно повышает связность, которая при этом может не отражаться остальными метриками оценки системы. Зачастую при построении программного кода можно избежать применения наследования, заменив его равноценными приемами. Например, вместо этого можно использовать инъекцию зависимостей и IoC-контейнеры. Результат вычисления данной метрики, как правило, используется в сыром виде в практических задачах построения архитектуры и рефакторинга. Полученные показатели метрики также можно использовать в более сложных комплексных метриках. Иначе говоря, если значение этой метрики велико, то можно сразу выявить аномалию. Кроме того, эту метрику можно использовать в совокупности с другими, например подсчитать сложность системы по Мак-Кейбу и ее объем, чтобы точнее измерить программную систему.
В целом метрики сложности могут оказать существенную помощь производителям программного обеспечения в процессе контроля и управления качеством программного обеспечения.
Поддерживаемость
Метрики данного типа показывают трудоемкость процесса поддержки и развития программного кода и, как правило, тесно связаны с метриками сложности, но имеют свои особенности, отражающие возможности поддержки системы.
Одной из основных метрик этой категории является метрика Холстеда, в рамках которой определяют четыре измеряемые характеристики программы: число уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов); число уникальных операндов программы (словарь операндов); общее число операторов в программе; общее число операндов в программе. На основании этих характеристик производятся базовые оценки: составляется словарь программы; определяется длина программы, ее объем и сложность. Далее предлагается вычислить различные меры, которые позволяют оценить программный код. Например, выражение для вычисления качества программирования, сложности понимания программы, умственные затраты на создание программы и др.
Метрика Холстеда носит исключительно информационный характер, тем не менее она остается одной из немногих, которые позволяют количественно оценить показатель поддерживаемости системы в будущем, при этом данный показатель имеет прямую корреляцию с качеством выпускаемого продукта.
Инструмент анализа кода
Разработчики на платформе Microsoft могут воспользоваться версией Visual Studio 2008, которая позволяет вычислять базовый набор основных метрик и отслеживать их в режиме реального времени (рис. 2). Тем не менее основной сценарий использования метрик – это информирование менеджеров разработки о том, что качество продукта, возможно, понизилось или повысилось. Поэтому имеет смысл вычислять такие метрики в процессе сборки проекта.Visual Stuido 2008 и Microsoft Build не позволяют выстроить серьезную иерархию метрик, и для этого следует воспользоваться другими инструментами, например NDepend, позволяющим для платформы .NETрассчитывать различные типы связности, наследования и абстрактности, интегрируясь в процесс создания программ в соответствии с требованиями конкретной команды разработчиков.Проблемы при использовании метрик кода Несмотря на то что метрики позволяют контролировать процесс разработки, работа с ними сопряжена с рядом проблем.Во-первых, все известные на сегодняшний день метрики кода недостаточно значимы и точны. Они не способны обеспечить получение объективной картины о состоянии программной системы, а лишь выдают показатели, которые вычислены по заданному алгоритму. Во-вторых, процесс измерения может быть искусственно искажен за счет того, что сотрудники будут «оптимизировать» свой программный код так, чтобы метрики выдавали лучшие результаты. Кроме того, формальное использовании метрик не учитывает опыт сотрудников, уровень компании и может принести не только пользу, но и вред.Тем не менее метрики являются достаточно полезным инструментом в руках разработчиков и менеджеров проектов, позволяющим выявить моменты ухода разработки на более низкий качественный уровень и распознать наиболее сложные участки в системе. Определение числовых показателей может дать новые сведения о разрабатываемом продукте и помочь более грамотно планировать расходы на его дальнейшее развитие.