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

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

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

Современное состояние программометрики позволяет с удовлетворительной для практики точностью решать следующие задачи:

· количественный анализ возможности и целесообразности разработки автоматизированных процедур и функций ИС в заданной постановке;

· численная оценка основных параметров будущего ПС (объем, количество модулей, уровней иерархии, надежность в начальный период эксплуатации) на основе постановок задач;

· планирование и управление разработкой ПС, оценка трудоемкости его создания, технико-экономическое обоснование;

· решение вопросов, связанных с метрологией качества ПС.

5.2.1 Примеры стандартных метрик

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

· NUOprtr (Number of Unique Operators) -- число уникальных операторов программы, включая символы -- разделители, имена процедур и знаки операций (словарь операторов);

· NUOprnd (Number of Unique Operands)- число уникальных операндов программы (словарь операндов);

· Noprtr (Number of Operators) -- общее число операторов в программе;

· Noprnd (Number of Operands) -- общее число операндов в программе.

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

· словарь программы (Halstead Program Vocabulary) HPVoc = NUOprtr + NUOprnd;

· длина программы (Halstead Program Length) HPLen = Noprtr + Noprnd;

· объем программы (Halstead Program Volume) HPVol = HPLen log2 HPVoc.

Далее Холстед вводит оценку сложность программы (Halstead Difficulty), которая вычисляется как

HDiff = NUOprtr/2* (NOprnd / NUOprnd)

Используя HDiff Холстед вводит оценку HEff (Halstead Effort):

HEff = HDiff* HPVol, с помощью, которой описывается усилия программиста при разработке.

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

Для вычисления цикломатического числа Маккейба CC (Cyclomatic Complexity) применяется формула:

CC = L - N + 2P,

где L - число дуг ориентированного графа;

N - число вершин;

P - число компонентов связности.

К метрикам сложности также относится:

· NORM (Number of Remote Methods) - количество вызываемых удаленных методов. При формировании значения этой метрики просматриваются все конструкторы и методы класса, и подсчитывается количество вызываемых удаленных методов. Удаленным методом является метод, который не определен в классе и его родителях.

· RFC (Response for Class) - отклик на класс -- количество методов, которые могут вызываться экземплярами класса. Эта метрика вычисляется как сумма количества локальных методов и количества удаленных методов.

· WMPC1 (Weighted Methods per Class 1) - взвешенная насыщенность класса - дает относительную меру его сложности; если считать что все методы имеют одинаковую сложность, то это будет просто число методов в классе. Эта метрика определяется суммой сложности всех методов класса, где каждый метод взвешивается подсчетом его цикломатического числа. Количество методов и их сложность связаны для определения времени и усилий, которые потребуются для разработки и поддержки класса. Вообще, класс, который имеет большее количество методов среди классов одного с ним уровня, является более сложным; скорее всего, он специфичен для данного приложения и содержит наибольшее количество ошибок. Для расчета данной метрики используются только методы определенные в конкретном классе, все методы, наследуемые от родительского класса, не включаются.

· WMPC2 (Weighted Methods per Class 2). Эта метрика является мерой сложности класса, полагающая, что класс с большим количеством методов, чем другой, является более сложным, и что метод с большим количеством параметров также является более сложным. Для расчета данной метрики используются только методы определенные в конкретном классе, все методы, наследуемые от родительского класса, не включаются.

· LOCOM1 (Lack of Cohesion of Methods 1) - недостаток связности методов. Связность - это степень взаимодействия между элементами отдельного модуля, характеристика его насыщенности.

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

Для каждой пары методов класса определяется набор полей, к которым они имеют доступ. Если множество полей имеет доступ к непересекающемуся множеству полей класса, то число P увеличивается на 1. Если оба метода используют хотя бы одно общее поле, то параметр Q увеличивается на 1. После рассмотрения каждой пары методов результат вычисляется как RESULT = (P > Q) ? (P -- Q) : 0. Высокое значение этой метрики говорит о высокой связности методов -- это означает, что потребуются большие усилия при тестировании этих методов, так как методы могут воздействовать на одни и те же атрибуты класса. Это также говорит о низкой готовности к повторному использованию. Метрика была определена Чидамбером и Кемерером (Chidamber & Kemerer) в 1993.

· LOCOM2 (Lack of Cohesion of Methods 2) - связанность методов -- мера насыщенности абстракции. Класс, который может вызывать существенно больше методов, чем равные ему по уровню классы, является более сложным. У класса с низкой связанностью можно подозревать случайную или неподходящую абстракцию: такой класс должен быть переабстрагирован на несколько классов или его обязанности должны быть переданы другим существующим классам. Метрика подсчитывает процентное отношение методов, не имеющих доступа к специфичным атрибутам класса ко всем атрибутам данного класса.

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

· LOCOM3 (Lack of Cohesion of Methods 3) - измеряет степень различия методов в классе по атрибутам.

Рассмотрим множество методов M1, M2, ... , Mm. Эти методы имеют доступ к набору атрибутов данных класса A1, A2, ... , Aa. Положим a(Mk) = число атрибутов с которым работает метод Mk , а m(Ak) = число методов которые имеют доступ к атрибуту Ak. Тогда LOCOM3 = (1/a * SUM1a(m(Ai)-m))/(1-m)*100. Низкое значение этой меры говорит о хорошей декомпозиции в классе выражаемой в его простоте и понятности и готовности к повторному использованию. Высокое значение отсутствия связности увеличивает сложность, повышает вероятность ошибок в процессе разработки.

Данная метрика была предложена Хендерсоном-Шеллером в 1995.

В эту группу метрик также попадают базовые метрики:

· LOC (Lines Of Code) - количество строк кода

· NOC (Number Of Classes) - количество классов

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

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

Уровень языковых средств и их применения:

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

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

= L2V,

где L - уровень реализации программы, а V - ее объем.

Статистические исследования, проведенные на огромном фактическом материале, показали, что величина действительно зависит только от конкретного языка программирования и практически не зависит от объема программы, так как

Иными словами, =const в пределах одного и того же языка.

5.3 Алгоритм формирования метрик