Жукова

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

Koh Tieng Wei, Mohd Hasan bin Selamat, перевод с английского – Жукова Д.К.

Краткий реферат

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

1. Введение

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

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

Эта статья организована следующим образом. Раздел 2 представляет собой очень краткий на обзор литературы по теме. Раздел 3 описывает 6 метрик предложенныч Чидамбером и Кемиререом [11, 12]. Раздел 4 представляет еще один новый показатель для объектно-ориентированного программирования, и краткое описание 6 показателей предложенных Ли [14]. Заключительные замечания представлены в разделе 5.

2. Обзор литературы

Некоторые подходы к прогнозированию программного обеспечения предлагались в литературе начиная с 70-х годов. Большинство исследователей предполагают, что сложность и размер модели очень связанны со значением усилий при реализации. В самом деле, большинство объектно-ориентированных метрик основаны на этом предположении. В общем, объектно-ориентированные метрики могут быть разделены на две категории: 1) адаптация изерений классических метрик и 2) объектно-ориентированный показатели сложности метрик.

Мы рассмотрим эти категории в следующем подразделе.

2.1 Адаптация классических метрик

Laranjeira [5] представил метод оценки модели программного обеспечения и утверждал, что модель обладает потенциалом для обеспечения более точной оценки по сравнению с существующими методами, которые еще не являются достаточно надежными для последовательного использования. Этот метод заключается в том, что функциональная модель имеет преимущественно характеристики объектно-ориентированных систем, естественные соответствия между спецификацией и реализацией, с тем чтобы дать пользователям возможность придумать лучшие методы оценки на ранних этапах цикла разработки программного обеспечения. Заметим, что нет очевидного сравнения этой модели и существующих методов.

Еще один подобный вывод сообщает Кондори-Фернандес и др. [8], описывая измерения протокола карты памяти, используемые в объектно-ориентированном подходе. Этот протокол описывает набор измерений операций моделирования и измерения объектно-ориентированных программных систем, полученные в рамках объектно-ориентированного метода. Это расширенный набор правил, который позволяет оценить функциональные размеры объектно-ориентированной системы раннего развития жизненного цикла. Бриан и др. [6] эмпирически исследовали связь между классом и усилиями в области развития использования регрессии техники. Antoniol и др. [1] определели степень адаптации традиционных точкек функции, называемых «объектными точками функции» для измерения объектно-ориентированного анализа и проектирования спецификаций. Кроме того, Costagliola и др. [2] представили точки классов и точки функции, как подход, который был задуман, чтобы оценить размер объектно-ориентированных продуктов.

С другой стороны, Браз и Vergilio [7] ввели 2 новые показатели, основанные на использовании Use Case: 1) Использование размера точки в случае, если внутренняя структура Use Case лучше отражает его функциональность. 2) Нечеткийразмер точки в Use Case, считает понятия нечеткой теории множеств, для создания постепенной классификации, которая более удобна в условиях неопределенности. Неси и Querci предложили новые метрики сложности и размера для оценки усилий и прогнозирования [10]. Эти показатели были сопоставлены с наиболее важными классическими метриками в литературе. Там сообщалось также о проверке этих показателей. В это время Шериф и Сандерсон [4] изучали объектно-ориентированные метрики на двух программных проектах разработаных в лаборатории реактивного движения (JPL).

2.2 Объектно-ориентированные метрики размера

Наиболее впечатляющими разработками, связанными с объектно-ориентированными калибровками метрик, были предложенные Чидамбером и Кемирером. Предложенные ранее 6 метрик [11], другие исследователи старались проверить опытным путем. Ли и Генри [15] провели эмпирическое исследование для метрик используя их при работе с данными, а Базили и др. [13] подтвердили жизнеспособность метрик с помощью дефектов программного обеспечения собранных от студентами. В 1994 году Чидамбер и Кемирер пересмотрели оригиналы метрик, которые были предложены в 1991, используяи теоретические расчеты и эмпирические данные [12]. Chucher и Шепперд указали на некоторые замечания и высказались о возможных двусмысленностях в работе некоторых из этих метрик [9]. На основе этих метрик Ли сообщил еще о 6 новых объектно-ориентированные метриках [14].

3. Метрики по Чидамберу и Кемереру

Новый набор программных метрик для объектно-ориентированного проектирования разработали и внедрили Чидамбер и Кемирер [11, 12]. Эти показатели были основаны на теории измерений, а также отражают точку зрения опытных объектно-ориентированных разработчиков. В частности, это набор из шести метрик, представленных как первая попытка развития формальных показателей для объектно-ориентированного проектирования. Авторы утверждали, что это предложение должно заложить основу для формального языка, на базе которой будут описываться метрики для объектно-ориентированного проектирования. В следующем подразделе рассмотрены предлагаемые метрики.

3.1 Вес методов в классе (WMC)

Вес методов в классе (WMC) – метрика определяется, как сумма сложности локальных методов класса и предназначена для подсчета комбинированных сложностей локальных методов в данном классе. По данным Jones [3], этот показатель все еще находится в разработке и в настоящее время активно изучается. Ли [14] утверждал, что метрика подразделяется на две, соответственно, и может быть использована с двумя целями: 1) количество локальных методов, и 2) сумма внутренней сложности всех локальных методов. Проблема заключается в том, что число локальных методов и внутренней структурной сложности локальных методов это 2 независимых атрибута класса, и есть возможность двойного толкования WMC. Ли [14] в связи с этим предложил два новых показателя: 1) Количество локальных методов (NLM) и 2) Сложность метода класса (CMC), чтобы измерить два атрибута, которые старались охватить метрикой WMC. Эти две метрики рассмотрены в разделе 4.

3.2 Глубина дерева наследования (DIT)

По словам Ли [14], глубина дерева наследования (DIT) также имеет неоднозначности в своем определении: 1) максимальная длина от узла к корневой становится непонятно, когда дерево наследования имеет несколько корней и 2) противоречивые цели, изложенные в определении, теоретические основы и точки зрения для DIT, где указано, что DIT метрическая мера числа класс-предок класса, но в определении DIT утверждается, что оно должено измерить длину пути наследования дерева, расстояние между двумя узлами в графе. Ли [14] предложил новый показатель: Число предков класса (NAC) в качестве альтернативы DIT.

3.3 Ответ на класс (RFC)

Ответ для класса (RFC) это число методов, которые могут выполнить какое либо действие в ответ на сообщение, отправленное объектом в этом классе, используя один уровень вложенности [3]. Для этого показателя не найдено двусмысленности или неадекватности. Методом вычисления RFC является непосредственный расчет RFC для заявленного класса. [12]

3.4 Количество потомков (NOC)

Количество потомков (NOC) – метрика определяется как ряд непосредственных подклассов подчиненых данному классу в иерархии.

3.5 Отсутствие единства методов (LCOM)

Этот показатель является подсчетом числа непересекающихся пар методов минус количество подобных пар метода. Непересекающиеся методы не имеют общих переменных, например, в то время как аналогичные методы, по крайней мере одну общую [3, 13]. Были выявлены и обсуждается различными определениями метрики отсутствия единства методов (LCOM) [11, 13, 14].

3.6 Связь между объектами (CBO)

Связь между объектами (CBO) – метрика определяется как число связанных пар классов без потомков. Ли [14] заявил, что элемент «класс», используемый в этой метрике трудно определить, и предложили другие формы классовой связи: наследование, абстрактные типы данных и сообщений прохождения, которые доступны в объектно-ориентированном программировании. Ли [14] предложил еще два новых показателя: 1) Связь через абстрактный тип данных (CTA) и 2) Связь через сообщения (CTM), как альтернативы. Они будут представлены в разделе 4.

4. Метрики Ли

В ходе определения модели оценки метрик были обнаружены некоторые проблемы, связанных с некоторыми из метрик Чидамбера и Кемирера. Автором предлагается альтернативный набор объектно-ориентированных метрик, решающий существующие проблемы [14].

4.1 Количество наследников класса (NAC)

Количество предков класса (NAC) – эта метрика предлагается в качестве альтернативы метрики DIT, для измерения этого атрибута класса. Ли определил NAC как сумму числа предков классов, из которых класс наследуется в классовой иерархии наследования. Теоретическое обоснование метрики и точка зрения такие же, как и для метрики DIT. Устройством для метрических показателей NAC является класс, Ли [14] обосновал, что атрибут, который фиксирует NAC, это число других классов, из которых происходит наследование. Это устройство определяется со ссылкой на стандарт, класса в отношении наследования в объектно-ориентированном программировании.

4.2 Количество предков класса (NDC)

Количество потомком классов (NDC) предлагается в качестве альтернативы метрики NOC. Она определяется как общее число потомков класса (подкласса). Теоретическое обоснование остается тем же, что и для NOC. Ли [14] сообщили, что атрибут класса NOC метрических фиксирует это число классов, которые потенциально могут быть под влиянием класса из-за отношений наследования. Ли заявил, что NDC метрических охватывает атрибуты классов лучше, чем NOC.

4.3 Количество локальных методов (NLM)

Это одна из предложенных метрик Ли [14], измеряющая атрибуты класса, которые охватывала метрика WMC. Количество локальных методов (NLM) определяется как число локальных методов, определенных в классе, которые доступны за пределами класса.

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

Ли [14] высказал три точки зрения на метрику NLM:

1. Метрический показатель NLM непосредственно связан с пониманием усилий программиста, когда класс может использоваться только в OO конструкции. Более локальные методы класса потребуют больше усилий для использования.
2. Чем больше локальных интерфейсов в классе, тем больше усилий необходимо для проектирования, реализации, тестирования и использования класса.
3. Чем больше локальных интерфейсов в классе, тем большее влияние класса на классы потомка.

4.4 Сложность метода класса (CMC)

Сложность метода класса (СМС) определена как суммирование внутренней структурной сложности, всех локальных методов. Независимо от того, видны они за пределами класса или нет. Это определение существенно так же, как и первое определение метрического показателя WMC в работе [12]. Тем не менее, метрика CMC своим теоретическим обоснованием существенно отличается от метрики WMC. Метрики NLM и CMC принципиально отличаются тем, что они захватывают два независимых атрибута класса. Тем не менее, есть некоторые общности в точках зрения на эт метрики – они влияют на усилия , необходимых для разработки, реализации, тестирования и использования класса.

4.5 Связь через абстрактный тип данных (CTA)

Связь через абстрактный тип данных (СТА) определяется как общее число классов, которые используются в качестве абстрактных типов данных в дата-атрибут декларации класса. Два класса связаны, когда один класс использует другой класс, в качестве абстрактного типа данных [14]. Теоретическое обоснование в соответствии с Ли [14]: матрика CTA касается самого понятия классовой связи с помощью абстрактных типов данных. Этот показатель дает объем, сколько классов обслуживает, потребности иных классов с тем, чтобы обеспечить собственную службу.

Точка зрения Ли [14]:

1. Инженер-программист должен тратить больше времени на понимания интерфейсов используемых классами для того, чтобы создать класс с более высоким показателем CTA.
2. Для инженера-испытателя, необходимы более активные усилия для разработки тестов и выполнения тестирования высшего класса, в связи с тем, что поведение класса во время работы должно быть проверено.
3. Для инженера поддержки, понимание класс с высоким CTA займет больше времени, поскольку низкие CTA.

4.6 Связь путем передачи сообщений (CTM)

Связь путем передачи сообщений (CTM) определяется, как число различных сообщений отправленных классом к другим классам, исключающим сообщения, отправленные объектам, созданным как локальные объекты в локальных методах класса. Два класса могут быть связаны, потому что один класс отправляет сообщение объекту другого класса, без вовлечения двух классов через наследование или абстрактного типа данных [14].

Метрических CTM относится к понятию передачи сообщений объектно-ориентированного программирования. Метрика говорит о том, как много методов других классов, необходимые для выполнения классом собственной функциональности. Теоретические основы в соответствии с Ли [14]:

1. Конструктор класса затрачивает больше усилий на понимание услуг, предоставляемых другими классами с высоким значением CTM, чем классами с низким CTM.
2. Инженер-испытатель должен тратить больше усилий и дизайн больше тестов для классов с высоким CTM, чем для низких показателей CTM класса, потому что высокое значение CTM значит, что больше методов класса принимают участие в логических действиях класса.
3. FДля инженера поддержки, чем выше метрическое значение CTM, тем больше конкретных методов в других классах существует для понимания инженером для того, чтобы диагностировать и устранить проблемы, или для выполнения других видов обслуживания.

5. Выводы и подведение итогов

Вы прочли обзор материалов и сравнений метрик, связанных с объектно-ориентированной парадигмой, предложенные Чидамбером и Кемирером и дополненные Ли. Чидамбер и Кемирер оценили метрические оценки, предложенные Kichenham и его коллегами [11]. Ли и другие исследователи сделали усилия для проверки 6 метрик теоретически и эмпирически. Позже был предложен новый пакет объектно-ориентированных метрик, не имеющий недостатков.

6 метрик Ли призваны дополнить и укрепить 4 метрики предложенные Чидамбером и Кемирером. Тем не менее, мы выяснили, что есть некоторые недостатки в некоторых пердложенных показателях. Исследования метрик обсуждаются в разделе 5.1.

5.1 WMC, CMC и NLM

Метрика WMC, предложенная Чидамбером и Кемирером сложили о себе впечатление как ортажающая независимых атрибута класса: 1) количество местных методов и 2) сумма внутренних сложностей всех локальных методов. Этот вопрос был освещен Ли, и он предложил метрики CMC и NLM.

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

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

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

В связи с метрическим определением, предложенным Ли, не полностью соблюдающим все теоретические основы, мы предположили, что NLM должны быть разделены на две более полные метрики 1) Количество локальных Методов и 2) Число общих методов, соответствующее распределение веса через эмпирические проверки.

5.2 DIT и NAC

The attribute of a class that DIT metric intends to capture is the number of classes that have potential influence on the class because of the inheritance relations. However, there are some ambiguous factors lie in 1) When multiple inheritance and multiple roots, classes that do not inherit from any other classes, are present at the same time, and 2) Conflicting goals stated in the definition, the theoretical basis, and the viewpoints.

Атрибут класса DIT охватывает число классов, которые имеют влияние на класс из-за наследственных отношений. Однако есть некоторые неоднозначные факторы: 1) При множественном наследовании и кратных корней, классы не наследуют от любых других, существующих в то же время, классов и 2) противоречащие друг другу цели указаны в определении метрики. Показатель NAC был предложен для преодоления двусмысленности метрики DIT. Ли [14] утверждает, что число предков класса может быть самым лучшим показателем захвата классовых отношений наследования, независимо от числа корней или нескольких наследований. Это является в настоящее время, по сравнению с метрикой DIT, мерой глубины наследования класса.

Заметим, что DIT и NAC и выполняют те же цели – мера наследования отношений между классов. Предложение метрики NAC не является обязательным, поскольку мы можем пересмотреть определение DIT, с тем чтобы решить двусмысленности. С другой стороны, мы считаем, что частности из метрик DIT или NAC даст полезную информацию о сложности меры для класса в процессе дизайна объектно-ориентированной системы.

5.3 NOC и NDC

NOC определяется как ряд неотложных подклассов, подчиненых классу в иерархии. Тем не менее Ли [14] утверждал, что показатели должны измерять количество непосредственно подклассов класса, влияние на все его подклассы. Метрика NDC уточняет дефицит NOC с учетом того, какие есть непосредственные подклассы. Мы согласились с этой точкой. Тем не менее, мы утверждаем, что пересмотреть определение NOC все же необходимо и достаточно. Более конструктивную работу следует сосредоточить на типе наследования, который осуществляется в двух формах: данные атрибуты и методы, наследуемые от класса его подклассом. Если мы изучим подробно эти два метрических атрибута, это может повысить точность сложности мер по наследству отношений между классов.

5.4 CBO, CTA и CTM

Мера CBO – количество не связанных наследованием пар с другими классами вцелом. Ли [14] утверждал, что единицы измерения уровня трудно оправдать. Ли предлагает 2 новых метрики, основанных на различных формах классовой связи: через данные и передачу сообщений CTA определяется как общее число классов, которые используется в качестве абстрактных типов данных в хранилище данных атрибутов декларации класса. Ли [14] предложил этот показатель за счет разрушения сочетания типа класса: наследование, абстрактный тип и передача сообщений. Мы выяснили, что определение и теоретические основы метрик не исключают ненаследуемых связанных пар. Это может привести к возникновению двойного счета, когда класс, имеющий различные отношения наследования, захватывает те же атрибуты.

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

Литература

1. G. Antoniol, C. Lokan, G. Caldiera and R. Fiutem, «A Function Point-Like Measure for Object-Oriented Software», Empirical Software Engineering, Vol. 4, Issue 3, September 1999, pp. 263-287.
2. G. Costagliola, F. Ferrucci, G. Tortora, and G. Vitiello, «Class Point: An Approach for the Size Estimation of Object- Oriented Systems», IEEE Transaction on Software engineering, Vol. 31, No. 1, January 2005, pp. 52-74
3. Jones, C., Estimating Software Costs: Bringing Realism to Estimating, 2nd Edition, Mc Graw Hill, New York, 2007.
4. J. S. Sherif and P. Sanderson, «Metrics for Object-oriented Software Projects», The Journal of System and Software 44, 1998, pp. 147-154.
5. L. A. Laranjeira, «Software Size Estimation of Object- Oriented Systems», IEEE Transaction on Software Engineering, Vol. 16, No. 5, May 1990, pp. 510-522.
6. L. C. Briand and J. Wust, «Modeling Development Effort in Object-Oriented Systems Using Design Properties», IEEE Transactions on Software Engineering, Vol. 27, No. 11, November 2001, pp. 963-986.
7. M. R. Braz and S. R. Vergilio, «Software Effort Estimation Based on Use Cases», Proceedings of 30th Annual International Computer Software and Applications Conference (COMPASAC ’06), IEEE Computer Society, September 2006, pp. 221-228.
8. N. Condori-Fernandez, S. Abrahao, and O. Pastor, «Towards a Functional Size Measure for Object- Oriented Systems from Requirements Specifications», Proceedings of the Fourth International Conference on Quality Software (QSIC ’04), IEEE Computer Society, September 2004, pp. 94-101
9. N.I. Chucher and M.J. Shepperd, «Comments on a metrics Suite for Object-oriented Design» IEEE Transaction on Software Engineering, Vol. 21, No.3, 1995, pp. 263-265.
10. P. Nesi and T. Querci, «Effort Estimation and Prediction of Object-oriented Systems», The Journal of Systems and Software, Vol. 42, Issue 1, July 1998, pp. 89-102.
11. S. R. Chidamber and C. F. Kemerer, «A Metrics Suite for Object Oriented Design», IEEE Transactions on Software Engineering, Vol. 20, No. 6, June 1994, pp. 476-493.
12. S. R. Chidamber and C. F. Kemerer, «Towards a Metrics Suite for Object Oriented Design», Proceeding on Object Oriented Programming Systems, Languages and Applications Conference (OOPSLA’91), ACM, Vol. 26, Issue 11, Nov 1991, pp. 197-211.
13. V. L. Basili, L. Briand and W. L. Melo, «A validation of object-oriented Metrics as Quality Indicators», IEEE Transaction Software Engineering. Vol. 22, No. 10, 1996, pp. 751-761.
14. W. Li, «Another Metric Suite for Object-oriented Programming», The Journal of System and Software, Vol. 44, Issue 2, December 1998, pp. 155-162.
15. W. Li and S. Henry, «Object-oriented Metrics which Predict Maintainability», The Journal of Systems and Software, Vol. 23, Issue 2, November 1993, pp. 111-122.