Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Статический анализ программ.doc
Скачиваний:
31
Добавлен:
01.05.2014
Размер:
82.43 Кб
Скачать

Статический анализ программ. Метрики для измерения качества программного обеспечения.

Эта статья является одной из серии статей посвященных статическому анализу программного обеспечения. В данной статье делается обзор метрик, которые предложил R.C.Martinв книге [1]. Эти метрики могут использоваться для оценки качества проектов объектно-ориентированного программного обеспечения на основе анализа взаимозависимости подсистем проекта. Проекты, подсистемы в которых имеют сильную зависимость друг от друга, в дальнейшем сложно модифицировать, повторно использовать  и сопровождать. Однако полностью избежать зависимости подсистем в проекте невозможно. Таким образом, можно находить в проекте нежелательные зависимости между подсистемами и удалять их.

Введение.

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

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

  • на изоляции повторно используемых частей системы от не используемых повторно

  • на локализации изменений в системе при ее сопровождении.

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

Зависимости.

Что делает проект "твердым", "хрупким" и затрудняет его повторное использование. Это делает взаимозависимость подсистем внутри того проекта.

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

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

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

Пример: программа копирования.

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

 

Имеются три модуля. Модуль Copyвызывает функции двух других модулей. Можно представить цикл в модулеCopy. В теле этого модуля происходит вызов модуляReadKeyboard, который считывает символ клавиатуры и посылает этот символ в модульWritePrinter.

Два модуля нижнего уровня подходят для повторного использования. Это та разновидность повторного использования, которую мы получаем от библиотек подпрограмм. Однако модуль Copyне может быть многократно использован ни для чего, кроме как для копирования с клавиатуры на принтер. Это недостаток, поскольку "интеллект" системы находится именно в этом модуле. МодульCopyпредставляет интересное поведение, которое желательно использовать повторно.

Например, рассмотрите новую программу, которая копирует символы с клавиатуры в файл на диске. Конечно было бы желательно использовать модуль Copy, поскольку он инкапсулирует на высоком уровне желательное для нас поведение. Он "знает", как копировать символы из одного места в другое. К сожалению, модульCopyзависим от модуляWritePrinter, и поэтому не может повторно использоваться в новом контексте.

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