Метрика числа ошибок в программе

Обновлено: 07.07.2024

При конструировании объектно-ориентированных программных систем значительная часть затрат приходится на создание визуальных моделей. Очень важно корректно и всесторонне оценить качество этих моделей, сопоставив качеству числовую оценку. Решение данной задачи требует введения специального метрического аппарата. Такой аппарат развивает идеи классического оценивания сложных программных систем, основанного на метриках сложности, связности и сцепления. Вместе с тем он учитывает специфические особенности объектно-ориентированных решений. В этой главе обсуждаются наиболее известные объектно-ориентированные метрики, а также описывается методика их применения.

Метрические особенности объектно-ориентированных программных систем

Объектно-ориентированные метрики вводятся с целью:

q улучшить понимание качества продукта;

q оценить эффективность процесса конструирования;

q улучшить качество работы на этапе проектирования.

Все эти цели важны, но для программного инженера главная цель — повышение качества продукта. Возникает вопрос — как измерить качество объектно-ориентированной системы?

Для любого инженерного продукта метрики должны ориентироваться на его уникальные характеристики. Например, для электропоезда вряд ли полезна метрика «расход угля на километр пробега». С точки зрения метрик выделяют пять характеристик объектно-ориентированных систем: локализацию, инкапсуляцию, информационную закрытость, наследование и способы абстрагирования объектов. Эти характеристики оказывают максимальное влияние на объектно-ориентированные метрики.

Локализация

Локализация фиксирует способ группировки информации в программе. В классических методах, где используется функциональная декомпозиция, информация локализуется вокруг функций. Функции в них реализуются как процедурные модули. В методах, управляемых данными, информация группируется вокруг структур данных. В объектно-ориентированной среде информация группируется внутри классов или объектов (инкапсуляцией как данных, так и процессов).

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

Так как в объектно-ориентированной системе базовым элементом является класс, то локализация здесь основывается на объектах. Поэтому метрики должны применяться к классу (объекту) как к комплексной сущности. Кроме того, между операциями (функциями) и классами могут быть отношения не только «один-к-одному». Поэтому метрики, отображающие способы взаимодействия классов, должны быть приспособлены к отношениям «один-ко-многим», «многие-ко-многим».

Инкапсуляция

Вспомним, что инкапсуляция — упаковка (связывание) совокупности элементов. Для классических ПС примерами низкоуровневой инкапсуляции являются записи и массивы. Механизмом инкапсуляции среднего уровня являются подпрограммы (процедуры, функции).

В объектно-ориентированных системах инкапсулируются обязанности класса, представляемые его свойствами (а для агрегатов — и свойствами других классов), операциями и состояниями.

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

Информационная закрытость

Информационная закрытость делает невидимыми операционные детали программного компонента. Другим компонентам доступна только необходимая информация.

Качественные объектно-ориентированные системы поддерживают высокий уровень информационной закрытости. Таким образом, метрики, измеряющие степень достигнутой закрытости, тем самым отображают качество объектно-ориентированного проекта.

Наследование

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

Поскольку наследование — основная характеристика объектно-ориентированных систем, на ней фокусируются многие объектно-ориентированные метрики (количество детей — потомков класса, количество родителей, высота класса в иерархии наследования).

Абстракция

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

Класс — это абстракция, которая может быть представлена на различных уровнях детализации и различными способами (например, как список операций, последовательность состояний, последовательности взаимодействий). Поэтому объектно-ориентированные метрики должны представлять абстракции в терминах измерений класса. Примеры: количество экземпляров класса в приложении, количество родовых классов на приложение, отношение количества родовых к количеству неродовых классов.

Эволюция мер связи для объектно-ориентированных программных систем

В разделах «Связность модуля» и «Сцепление модулей» главы 4 было показано, что классической мерой сложности внутренних связей модуля является связность, а классической мерой сложности внешних связей — сцепление. Рассмотрим развитие этих мер применительно к объектно-ориентированным системам.

7.Набор метрик Чидамбера и Кемерера

В 1994 году С. Чидамбер и К. Кемерер ( Chidamber и Кетегег) предложили шесть проектных метрик, ориентированных на классы [24]. Класс — фундаментальный элемент объектно-ориентированной (ОО) системы. Поэтому измерения и метрики для отдельного класса, иерархии классов и сотрудничества классов бесценны для программного инженера, который должен оценить качество проекта.

Набор Чидамбера-Кемерера наиболее часто цитируется в программной индустрии и научных исследованиях. Рассмотрим каждую из метрик набора.

Метрика 1: Взвешенные методы на класс WMC ( Weighted Methods Per Class )

Допустим, что в классе С определены п методов со сложностью с1. , c 2 . с n . Для оценки сложности может быть выбрана любая метрика сложности (например, цикломатическая сложность). Главное — нормализовать эту метрику так, чтобы номинальная сложность для метода принимала значение 1. В этом случае

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

Очень часто применяют упрощенную версию метрики. При этом полагают С i = 1, и тогда WMC — количество методов в классе.

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

2. Подсчитываются методы, определенные в текущем классе, и все унаследованные методы. Этот подход подчеркивает важность пространства состояний в понимании класса (а не инкрементности класса).

Существует ряд промежуточных вариантов. Например, подсчитываются текущие методы и методы, прямо унаследованные от родителей. Аргумент в пользу данного подхода — на поведение дочернего класса наиболее сильно влияет специализация родительских классов.

На практике приемлем любой из описанных вариантов. Главное — не менять вариант учета от проекта к проекту. Только в этом случае обеспечивается корректный сбор метрических данных.

Метрика WMC дает относительную меру сложности класса. Если считать, что все методы имеют одинаковую сложность, то это будет просто количество методов в классе. Существуют рекомендации по сложности методов. Например, М. Лоренц считает, что средняя длина метода должна ограничиваться 8 строками для Smalltalk и 24 строками для C++ [45]. Вообще, класс, имеющий максимальное количество методов среди классов одного с ним уровня, является наиболее сложным; скорее всего, он специфичен для данного приложения и содержит наибольшее количество ошибок.

Метрика 2: Высота дерева наследования DIT ( Depth of Inheritance Tree )

DIT определяется как максимальная длина пути от листа до корня дерева наследования классов. Для показанной на рис. 14.3 иерархии классов метрика DIT равна 3.


Рис. 14.3. Дерево наследования классов

Соответственно, для отдельного класса DIT , это длина максимального пути от данного класса до корневого класса в иерархии классов.

По мере роста DIT вероятно, что классы нижнего уровня будут наследовать много методов. Это приводит к трудностям в предсказании поведения класса. Высокая иерархия классов (большое значение DIT ) приводит к большей сложности проекта, так как означает привлечение большего количества методов и классов.

Вместе с тем, большое значение DIT подразумевает, что многие методы могут использоваться многократно.

Метрика 3: Количество детей NOC ( Number of children )

Подклассы, которые непосредственно подчинены суперклассу, называются его детьми. Значение NOC равно количеству детей, то есть количеству непосредственных наследников класса в иерархии классов. На рис. 14.3 класс С2 имеет двух детей — подклассы С21 и С22.

С увеличением NOC возрастает многократность использования, так как наследование — это форма повторного использования.

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

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

Метрики DIT и NOC — количественные характеристики формы и размера структуры классов. Хорошо структурированная объектно-ориентированная система чаще бывает организована как лес классов, чем как сверхвысокое дерево. По мнению Г. Буча, следует строить сбалансированные по высоте и ширине структуры наследования: обычно не выше, чем 7 ± 2 уровня, и не шире, чем 7 + 2 ветви [22].

Метрика 4: Сцепление между классами объектов СВО ( Coupling between object classes )

СВО — это количество сотрудничеств, предусмотренных для класса, то есть количество классов, с которыми он соединен. Соединение означает, что методы данного класса используют методы или экземплярные переменные другого класса.

Другое определение метрики имеет следующий вид: СВО равно количеству сцеплений класса; сцепление образует вызов метода или свойства в другом классе.

Данная метрика характеризует статическую составляющую внешних связей классов.

С ростом СВО многократность использования класса, вероятно, уменьшается. Очевидно, что чем больше независимость класса, тем легче его повторно использовать в другом приложении.

Высокое значение СВО усложняет модификацию и тестирование, которое следует за выполнением модификации. Понятно, что, чем больше количество сцеплений, тем выше чувствительность всего проекта к изменениям в отдельных его частях. Минимизация межобъектных сцеплений улучшает модульность и содействует инкапсуляции проекта.

СВО для каждого класса должно иметь разумно низкое значение. Это согласуется с рекомендациями по уменьшению сцепления стандартного программного обеспечения.

Метрика 5: Отклик для класса RFC ( Response For a Class )

где Ri > — множество методов, вызываемых методом г, — множество всех методов в классе.

Метрика RFC равна количеству методов во множестве отклика, то есть равна мощности этого множества:

Приведем другое определение метрики: RFC — это количество методов класса плюс количество методов других классов, вызываемых из данного класса.

Метрика RFC является мерой потенциального взаимодействия данного класса с другими классами, позволяет судить о динамике поведения соответствующего объекта в системе. Данная метрика характеризует динамическую составляющую внешних связей классов.

С ростом RFC увеличивается сложность класса. Наихудшая величина отклика может использоваться при определении времени тестирования.

Метрика 6: Недостаток связности в методах L С OM ( Lack of Cohesion in Methods )

Каждый метод внутри класса обращается к одному или нескольким свойствам (экземплярным переменным). Метрика LCOM показывает, насколько методы не связаны друг с другом через свойства (переменные). Если все методы обращаются к одинаковым свойствам, то LCOM = 0.

q НЕ СВЯЗАНЫ — количество пар методов без общих экземплярных переменных;

q СВЯЗАНЫ — количество пар методов с общими экземплярными переменными.

q Ij — набор экземплярных переменных, используемых методом М j

НЕ СВЯЗАНЫ = card < Iij | Ii Ij = 0>,

СВЯЗАНЫ = card Iij | Ii Ij 0>.

Тогда формула для вычисления недостатка связности в методах примет вид

Можно определить метрику по-другому: LCOM — это количество пар методов, не связанных по свойствам класса, минус количество пар методов, имеющих такую связь.

Рассмотрим примеры применения метрики LCOM .

8.Метрики Лоренца и Кидда

Коллекция метрик Лоренца и Кидда — результат практического, промышленного подхода к оценке ОО-проектов [45].

Метрики, ориентированные на классы

М. Лоренц и Д. Кидд подразделяют метрики, ориентированные на классы, на четыре категории: метрики размера, метрики наследования, внутренние и внешние метрики.

Размерно-ориентированные метрики основаны на подсчете свойств и операций для отдельных классов, а также их средних значений для всей ОО-системы. Метрики наследования акцентируют внимание на способе повторного использования операций в иерархии классов. Внутренние метрики классов рассматривают вопросы связности и кодирования. Внешние метрики исследуют сцепление и повторное использование.

Метрика 1: Размер класса CS ( Class Size )

Общий размер класса определяется с помощью следующих измерений:

q общее количество операций (вместе с приватными и наследуемыми экземплярными операциями), которые инкапсулируются внутри класса;

q количество свойств (вместе с приватными и наследуемыми экземплярными свойствами), которые инкапсулируются классом.

Метрика WMC Чидамбера и Кемерера также является взвешенной метрикой размера класса.

Большие значения CS указывают, что класс имеет слишком много обязанностей. Они уменьшают возможность повторного использования класса, усложняют его реализацию и тестирование.

При определении размера класса унаследованным (публичным) операциям и свойствам придают больший удельный вес. Причина — приватные операции и свойства обеспечивают специализацию и более локализованы в проекте.

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

Рекомендуемое значение CS 20 методов.

Метрика 2: Количество операций, переопределяемых подклассом, NOO

(Number of Operations Overridden by a Subclass)

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

Большие значения NOO обычно указывают на проблемы проектирования. Ясно, что подкласс должен расширять операции суперкласса. Расширение проявляется в виде новых имен операций. Если же NO О велико, то разработчик нарушает абстракцию суперкласса. Это ослабляет иерархию классов, усложняет тестирование и модификацию программного обеспечения.

Рекомендуемое значение NOO 3 методов.

Метрика 3: Количество операций, добавленных подклассом, NOA

(Number of Operations Added by a Subclass)

Подклассы специализируются добавлением приватных операций и свойств. С ростом NOA подкласс удаляется от абстракции суперкласса. Обычно при увеличении высоты иерархии классов (увеличении DIT ) должно уменьшаться значение NOA на нижних уровнях иерархии.

Для рекомендуемых значений CS = 20 и DIT = 6 рекомендуемое значение NOA 4 методов (для класса-листа).

Метрика 4: Индекс специализации SI ( Specialization Index )

Обеспечивает грубую оценку степени специализации каждого подкласса. Специализация достигается добавлением, удалением или переопределением операций:

SI = ( NOO x уровень) / M общ ,

где уровень — номер уровня в иерархии, на котором находится подкласс, Мобщ — общее количество методов класса.

Пример расчета индексов специализации приведен на рис. 14.5.


Рис. 14.5. Расчет индексов специализации классов

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

Рекомендуемое значение SI 0,15.

Операционно-ориентированные метрики

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

Метрика 5: Средний размер операции OSAVG ( Average Operation Size )

Рост значения метрики означает, что обязанности размещены в классе не очень удачно. Рекомендуемое значение OSAVG 9.

Метрика 6: Сложность операции ОС ( Operation Complexity

Сложность операции может вычисляться с помощью стандартных метрик сложности, то есть с помощью LOC - или FP -оценок, метрики цикломатической сложности, метрики Холстеда.

М. Лоренц и Д. Кидд предлагают вычислять ОС суммированием оценок с весовыми коэффициентами, приведенными в табл. 14.5.

В настоящее время в программной инженерии еще не сформировалась окончательно система метрик. Действуют разные подходы к определению их набора и методов измерения [10.11-10.13].

Система измерения включает метрики и модели измерений, которые используются для количественной оценки качества ПО.

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

Согласно стандарту [1.16] метрики определяются по модели измерения атрибутов ПО на всех этапах ЖЦ (промежуточная, внутренняя метрика) и особенно на этапе тестирования или функционирования (внешние метрики) продукта.

Остановимся на классификации метрик ПО, правилах для проведения метрического анализа и процесса их измерения.

Типы метрик.

Существует три типа метрик:

  • метрики программного продукта, которые используются при измерении его характеристик - свойств;
  • метрики процесса, которые используются при измерении свойства процесса ЖЦ создания продукта.
  • метрики использования.

Метрики программного продукта включают:

  • внешние метрики, обозначающие свойства продукта, видимые пользователю;
  • внутренние метрики, обозначающие свойства, видимые только команде разработчиков.

Внешние метрики продукта - это метрики:

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

Внутренние метрики продукта включают:

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

Внутренние метрики позволяют определить производительность продукта и являются релевантными по отношению к внешним метрикам.

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

Метрики продукта часто описываются комплексом моделей для установки различных свойств, значений модели качества или прогнозирования. Измерения проводятся, как правило, после калибровки метрик на ранних этапах проекта. Общая мера - степень трассируемости, которая определяется числом трасс, прослеживаемых с помощью моделей сценариев типа UML и оценкой количества:

  • требований;
  • сценариев и действующих лиц;
  • объектов, включенных в сценарий, и локализация требований к каждому сценарию;
  • параметров и операций объекта и др.

Стандарт ISO/IEC 9126-2 определяет следующие типы мер:

Специальной мерой может служить уровень использования повторных компонентов и измеряется как отношение размера продукта, изготовленного из готовых компонентов, к размеру системы в целом. Данная мера используется также при определении стоимости и качества ПО. Примеры метрик:

  • общее число объектов и число повторно используемых;
  • общее число операций, повторно используемых и новых операций;
  • число классов, наследующих специфические операции;
  • число классов, от которых зависит данный класс;
  • число пользователей класса или операций и др.

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

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

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

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

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

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

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

10.1.3. Стандартная оценка значений показателей качества

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

По определению стандарта ISO/IES 9126-2 метрика качества ПО представляет собой "модель измерения атрибута, связываемого с показателем его качества". При измерении показателей качества данный стандарт позволяет определять следующие типы мер:

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

Метрики качества используются при оценке степени тестируемости с помощью данных ( безотказная работа, выполнимость функций, удобство применения интерфейсов пользователей, БД и т.п.) после проведения испытаний ПО на множестве тестов.

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

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

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

Все метрики -атрибута суммируются и образуют -показатель качества. Когда все атрибуты оценены по каждому из показателей качества, производится суммарная оценка отдельного показателя, а потом и интегральная оценка качества с учетом весовых коэффициентов всех показателей ПО.

В конечном итоге результат оценки качества является критерием эффективности и целесообразности применения методов проектирования, инструментальных средств и методик оценивания результатов создания программного продукта на стадиях ЖЦ.

Для изложения оценки значений показателей качества используется стандарт [10.4], в котором представлены следующие методы: измерительный, регистрационный, расчетный и экспертный (а также комбинации этих методов). Измерительный метод базируется на использовании измерительных и специальных программных средств для получения информации о характеристиках ПО, например, определение объема, числа строк кода, операторов, количества ветвей в программе, число точек входа (выхода), реактивность и др.

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

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

Экспертный метод осуществляется группой экспертов - специалистов, компетентных в решении данной задачи или типа ПО. Их оценка базируется на опыте и интуиции, а не на непосредственных результатах расчетов или экспериментов. Этот метод проводится путем просмотра программ, кодов, сопроводительных документов и способствует качественной оценки созданного продукта. Для этого устанавливаются контролируемые признаки, которые коррелированны с одним или несколькими показателями качества и включены в опросные карты экспертов. Метод применяется при оценке таких показателей, как анализируемость, документируемость, структурированность ПО и др.

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

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

Показатели, которые вычисляются с помощью метрических шкал, называются количественные, а определяемые с помощью порядковых и классификационных шкал - качественные.

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

Стандарт ISO/IES 9126-2 рекомендует применять 5 видов шкал измерения значений, которые упорядочены от менее строгой к более строгой:

1 Цель работы: Изучение основ метрической теории программ Холстеда, расчет количественных характеристик для индивидуального модуля.

Краткие теоретические и учебно-методические материалы по теме практической работы

Описание метрик Холстеда

Метрики Холстеда предлагают разумный подход к решению следующих задач:

-предсказание условий, необходимых для программирования по предложенным проектам;

-определение норм первоначальных ошибок;

-количественная оценка языков программирования и эффекта модульности;

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

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

Операторы-комбинации символов, влияющие на значение или порядок операндов.

В основе вычисляемых свойств алгоритма лежат следующие характеристики:

-n1 -число различных операторов данной реализации;

-n2 -число различных операндов данной реализации;

-N1 -общее число всех операторов;

-N2 -общее число всех операндов;

-n2*-число различных входных и выходных операндов.

На основании приведенных выше характеристик вычисляются:

-словарь n = n1 + n2;

-длина реализации N = N1 + N2.

Метрики Холстеда включают следующие характеристики:

1) Длина программы: N'= n1 * log2(n1) + n2 * log2(n2).

Если программа состоит из нескольких модулей (m -число модулей), то для каждого модуля определяется n1 среднее (n1 ср) и n2 среднее (n2 ср). В этом случае длина программы

N' = m*(n1ср* log2(n1 cp) + n2 cp* log2(n2 cp)).

2) Объем программы: V = N * log2(n).

Такая интерпретация дает объем программы в битах. Объем зависит от языка программирования, на котором реализован алгоритм.

3) Потенциальный (минимальный) объем: V* = (2+ n2*) * log2(2+ n2*).

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

4) Граничный объем: V** = (2+ (n2*)* log2(n2*)) * log2(2+ n2*).

5) Соотношения между операциями и операндами (зависимость числа операндов n2 от числа операций n1: A = n2* /(n2* +2) * log2(n2*/2)

-это частота использования операндов.

6) Уровень программы: L = V*/V,

где V* -потенциальный объем, V -объем программы.

L=1 для потенциального языка, в котором присутствует любая процедура, которая могла бы понадобиться (число таких процедур близко к бесконечности).

Альтернативное определение уровня L: L' = (n1*) * n2/(n1*N2), где n1*=2.

7) Интеллектуальное содержание: I = L' * V или: I = 2 * n2/(n1 * N2)*N* log2(n).

8) Работа по программированию (общее число элементарных мысленных различий, требуемых для порождения программы): E=V/L или E = V 2/ V*,где Е –общее число элементарных умственных различений, требуемых для порождения программы.

Это умственная работа, затрачиваемая на превращение заранее разработанного алгоритма в фактическую реализацию на языке программирования.

Правильное разбиение на модули уменьшает работу по программированию:

9) Приближенное время программирования: T' = E/S, где S = 18 моментов (различий)/секунд

Момент -время, требуемое человеческому мозгу для выполнения элементарных различений. Альтернативное определение времени Т: Т' = n1*N2*N*log2(n)/(2*S*n2).

10) Уровень языка: A = L * L* V.

Уровень языка определяет его производительность.

11) Уравнение ошибок:

Число переданных ошибок в программе: B = V/E0,

где E0 = V* x V* x V*/(A x A) -среднее число элементарных различений между возможными ошибками в программировании.

«Переданные ошибки» -ошибки, остающиеся после отладки модуля.

Пример программного кода:

For I=1 to 10 do

Write (‘Vvedi chislo’);

If A < Min then Min:= A;

Writeln (‘MIN=’, Min);

Подсчет характеристик программы:

Оператор Номер Число вхождений
Readln
Writeln
;
:=
Begin…end
Write
If
For
=
<
n1=10 N1=23

Операнд Номер Число вхождений
A
I
Min
n2=3 N2=11

Длина реализации N=N1+N2=23+11=34.

Число входных и выходных операндов n2*=3.

Расчёт с помощью формул Холстеда:

1. Длина программы: N’=10*log(10) +3*log(3)=11,4

2. Объём программы: V=34*log2(13)=125.8

3. Потенциальный (минимальный) объём: V* = (2+ 3) * log2(2+ 3)=11.6

4. Граничный объем: V** = (2+ (3)* log2(3)) * log2(2+ 3)=15.7

5. Соотношения между операциями и операндами (зависимость числа операндов n2 от числа операций n1: A = 3 /(3 +2) * log2(3/2) = 0.4
B = 3-2*0.4 = 2.2
n2 = 0.4*10+2.2 = 6.2

6. Уровень программы: L = 11.6/125.8 = 0.1

7. Интеллектуальное содержание: I = 2 * 3/(10 * 11)*34* log2(13) = 6.7

8. Работа по программированию (общее число элементарных мысленных различий, требуемых для порождения программы): E=125.8/0.1 = 1258

9. Приближенное время программирования: T' = 1258/18 = 69.9

10. Уровень языка: A = 0.1 * 0.1* 125.8 = 1.258

11. Уравнение ошибок:
Число переданных ошибок в программе: B = 125.8/9755.6 = 0.01
Е0 = 11.6 * 11.6 *11.6/(0.4 * 0.4) = 9755.6

Контрольные вопросы:

1. Где можно использовать метрики Холстеда?

В программировании для решения следующих задач:
-предсказание условий, необходимых для программирования по предложенным проектам;

-определение норм первоначальных ошибок;

-количественная оценка языков программирования и эффекта модульности;

-обоснование метода измерения различий между программами, написанными специалистами

2. Чем определяются характеристики программы?

В основе вычисления метрик Холстеда лежит концепция, согласно которой алгоритм состоит только из операторов и операндов, на анализе которых и происходит определение хар-к программ.

3. Как оценить качество реализации алгоритма по метрикам?

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

4. В чем недостаток программометрии?

Неэтичность: утверждается, что неэтично судить о производительности программиста по метрикам, введённым для оценки эффективности программного кода.

Замещение «управление людьми» на «управление цифрами», которые не учитывает опыт сотрудника и их другие качества.

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

Неточность: Нет метрик, которые были бы одновременно и значимы и достаточно точны.

Вывод: В результате выполнения данной работы была изучена тема «Оценка характеристик программ системой метрик Холстеда».

1.13. Метрика числа ошибок в программе. Закон Миллера

Предсказывает число первоначальных ошибок (до отладки и тестирования) и не может служить доказательством правильности (корректности) программы, даже если ее значение равно нулю.
^ Джордж Миллер – мозг человека может обрабатывать не более 7+-2 «объектов» одновременно (Закон «7+-2»): 9 двоичных чисел, 8 десятичных чисел, 7 букв алфавита, 5 односложных слов.
Представив эту способность мозга как критическое значение получим ее программное значение.

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

Из уравнения уровня языка

Для английского языка , тогда для описания программы на уровне английского языка

Если  – среднее число элементарных различений между возможными ошибками в программировании, а  – число ошибок в программе, то  но при этом не будет учтено наличие какой-либо избыточности в программе. Мерой такой избыточности является уровень программы . Следовательно, более реально

При постоянных усилиях на отладку интенсивность обнаружения ошибок следует считать пропорциональной оставшемуся их количеству.

Время наработки на отказ (

(основная масса ошибок выявляется во время отладки, то есть, приблизительно равна )

^ Количество ошибок в текстах программ пропорционально работе программирования, которая может быть вычислена.

Предположив, что с каждым из написанных фрагментов программы связана хотя бы одна ошибка, получим:

 расчетный объем программы.
^

1.14. Порядок расчета метрических характеристик программных средств. Расчет начальной надежности программы

Точность расчета метрических характеристик ПС достигается в случае, если правильно оценен параметр  в постановке задачи.
^ 1. Расчет структурных параметров ПС.

Учитывая, что оптимальное число входных переменных модуля равно 8, число модулей ПС должно быть равно:

Если , необходимо сделать поправку на число модулей в соответствии с выражением

^ 2. Расчет длины программы.
Длина модуля  слов.

Полная длина программы 

Последним членом часто пренебрегают.
^ 3. Расчет объема программы
Объем одного модуля: 

Объем ПС: 
^ 4. Расчет количества команд ассемблера

 – коэффициент пересчета Кнута на команды ассемблера
^ 5. Расчет календарного времени программирования.

^ 6. Расчет начального количества ошибок (перед комплексной отладкой)

7. Расчет начальной надежности ПС
В пределах календарного времени разработки  период отладки определяется из неравенства

Будем считать, что отладка занимает у разработчика половину времени, 

Читайте также: