Анализ когнитивной сложности с использованием метрики цикломатической сложности программного обеспечения

Wijendra D., Hewagamage K. Analysis of Cognitive Complexity with Cyclomatic Complexity Metric of Software // International Journal of Computer Applications. — 2021. — Vol. 174. — P. 14–19. — DOI: 10.5120/ijca2021921066.

Dinuka R. Wijendra

Институт информационных технологий Шри-Ланки

Шри-Ланка

K.P. Hewagamage

Школа вычислительной техники Университета Коломбо

Шри-Ланка

Аннотация

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

1. Введение

Метрика сложности программного обеспечения — это количественная характеристика, которую можно получить из самого ПО, связанной документации и процессов, которым предполагается следовать. IEEE определяет сложность программного обеспечения как степень, в которой система или компонент имеет такую архитектуру или реализацию, которые трудно понять и проверить [1]. Измерение сложности с помощью различных метрик даёт возможность снижать сложность, а также поддерживать качество и контролировать стоимость. Чем выше значение сложности, тем больше ПО подвержено ошибкам, тем труднее его сопровождать, тем ниже становится качество и тем выше — стоимость. «Сложность» может оцениваться с использованием метрик размера, структурных метрик и объектно-ориентированных метрик, поскольку её можно определять относительно других атрибутов ПО. Поэтому многие метрики сложности были стандартизованы так, чтобы их значения вычислялись в соответствии с рассматриваемым атрибутом программного обеспечения. В связи с этим было приложено немало усилий к выявлению методов и метрик для измерения сложности ПО [2].

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

2. метрика когнитивной сложности программного обеспечения

Понятие «когнитивная сложность» относится к области когнитивной информатики, изучающей внутренние механизмы обработки информации человеческим мозгом, а также их программные приложения [3]. Поэтому когнитивная сложность призвана измерять человеческие усилия, необходимые для выполнения задачи или понимания логики данного программного обеспечения [4]. Требуемые усилия на понимание или разработку конкретного ПО всегда различаются от человека к человеку, поэтому такую оценку можно считать субъективной. Один и тот же программный продукт может быть количественно проанализирован разными группами людей, так что вычисление когнитивной сложности может выполняться с учётом различных аспектов. В результате многие исследователи предлагали способы вычисления когнитивной сложности ПО, опираясь на различные аспекты, отличающиеся от ранее предложенных подходов. Поскольку выработать единую методологию вычисления когнитивной сложности крайне трудно, стандартного способа её расчёта до сих пор не существует.

Одно из исследований по вычислению когнитивной сложности было выполнено A. K. Misra и D. S. Kushwaha [3] в русле идей когнитивной информатики, согласно которым функциональная сложность программного обеспечения зависит от внутреннего потока архитектуры и его входов/выходов [5], [6]. Соответственно ПО представлялось как совокупность информации, где информация описывается множеством операторов и операндов, а базовым управляющим структурам (Basic Control Structures, BCS) в исходном коде назначаются определённые когнитивные веса. Этот подход далее был расширён с учётом вложенных BCS: когнитивная сложность вычислялась по назначенным весам с умножением в соответствии с уровнем вложенности [7].

Другой метод вычисления когнитивной сложности предложил S. Misra [4]: мера «сложности когнитивного веса» была определена как когнитивный вес простейшего компонента программного обеспечения — линейно структурированной BCS. Соответственно когнитивная сложность рассчитывалась по весам, назначенным BCS, и по когнитивным «весовым единицам» внутри данного исходного кода. Следовательно, объём информации в программном обеспечении оценивался в соответствии с когнитивными весами, назначенными для каждой определённой категории информации.

В качестве ещё одного подхода к выводу когнитивной сложности J. K. Chhabra [8] предложил оценивать её с учётом «рассеяния» внутренней информации в терминах числа строк кода (LOC) внутри исходного текста. Было показано, что когнитивные усилия человека возрастают по мере увеличения расстояния между местом объявления модуля и его использованием по сравнению с ситуацией, когда это происходит непосредственно, без большого разрыва. Сюда включается количество строк кода между объявлением переменной или метода, их инициализацией и фактическим использованием. Совместив рассчитанный пространственный аспект с оценкой внутренней информации посредством назначения когнитивных весов (как в предыдущих исследованиях), автор суммировал оба аспекта и получил общую когнитивную сложность данного ПО. Этот же пространственный аспект был развит с учётом «пространственных» особенностей рекурсивных функций [9]. Основываясь на отношениях между структурами, Y. Choe, C. Jong и S. Han предложили способ вычисления когнитивной сложности программного обеспечения [10]; по сути, в их подходе величина сложности главным образом зависит от области видимости переменных, используемых в программе. Кроме того, был предложен ещё один способ вычисления когнитивной сложности с учётом значения LOC и идентификаторов в исходном коде [11].

Ряд исследований был посвящён вычислению когнитивной сложности для объектно-ориентированного кода, а не только для процедурного. Так, U. Chhillar и S. Bhasin предложили способ расчёта когнитивной сложности объектно-ориентированного кода с учётом уровня наследования в классах, типов управляющих структур, их вложенности и размера программы [12]. В другом подходе D. S. Kuashwaha и A. K. Misra учли число методов на класс, обращения к другим объектам, количество независимых функций, выполняемых методами класса, число строк кода на метод, вероятность использования переменных экземпляра и степень функционального перекрытия классов в рассматриваемом объектно-ориентированном коде [13]. Ещё один вариант пространственного аспекта для ОО-кода был предложен с учётом рейтинга расположения метода, меры связей между классами и меры связей между объектами [9].

Любая метрика сложности ПО должна быть валидирована относительно стандартных метрик сложности, чтобы подтвердить её практическую применимость и интерпретируемость в реальных приложениях. Среди существующих рамок оценки можно выделить свойства Вейюкера (Weyuker) и свойства во фреймворке Брианда (Briand). Вейюкер определил девять свойств метрик программной сложности [14], тогда как во фреймворке Брианда сформулировано пять свойств [15]. Соответствие большинству свойств хотя бы одного из этих подходов позволяет применять предлагаемую метрику сложности на практике. Поэтому большинство предложенных метрик когнитивной сложности валидировались на соответствие указанным рамкам, чтобы подтвердить корректность их использования [16–20].

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

3. Метрика цикломатической сложности программного обеспечения

Метрика цикломатической сложности была предложена Маккейбом [21]; она количественно отражает структурную сложность модуля, исходя из потока управления в заданном методе или модуле программы. Эта метрика широко применяется в промышленности для вычисления сложности. Проще говоря, цикломатическая сложность измеряет число линейно независимых путей в исходном коде; следовательно, чем выше значение сложности, тем труднее понимать код и тем больше требуется тестовых случаев для его изменения. Это, в свою очередь, ведёт к росту затрат и трудоёмкости. В основе вычисления лежит теория графов: процедурные операторы исходного кода преобразуются в граф потока управления [22]. Граф потока управления описывает логическую структуру модулей ПО: вершины соответствуют вычислительным операторам или выражениям, а рёбра — передаче управления между вершинами [23–24]. Таким образом, метрика цикломатической сложности (CC) определяется как

\[CC=e-n+2\]

где:

CC — значение цикломатической сложности графа потока управления (G), построенного для данной программы;

e — число рёбер в G;

n — число вершин в G.

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

\[CC=d+1\]

где:

d — количество операторов принятия решений внутри программы.

К операторам принятия решений относятся: операторы if, число ветвей (case) в конструкции switch, все виды циклов, а также конструкции try–catch.

Вычисление значения цикломатической сложности по рёбрам и вершинам графа потока управления, показанного на рис. 2, на основе операторов принятия решений в исходном коде на рис. 1, приведено ниже.

						void IsNumber (String S)
						{
							boolean b= true;
							for (i=0,i value) & (ASCI(CharAT(i)) < value))
								b=true;
							else
								break;
							}
						} 
						

\[CC(вручную)=e-n+2=5-4+2=3\] \[CC(вручную)=d+1=2+1=3\] \[CC(RSM)=3+1 (составные условия)=4\]

Тем временем были проведены исследования, анализирующие проблемы цикломатической сложности. Было выявлено, что значение цикломатической сложности, вычисленное вручную по формулам, отличается от значения, получаемого с помощью Resource Standard Metric (RSM) — коммерческого инструмента анализа качества кода: при ручном подсчёте множественные условия в одном операторе обычно не учитываются, тогда как RSM их учитывает. Ряд работ предложил усовершенствования существующей метрики цикломатической сложности, адресующие эти проблемы. Одним из решений стало дополнение текущей метрики уровнем взаимодействия модулей и величиной их связности (coupling) [23]. Это же исследование было расширено введением двух формул для учёта разнообразия модулей с разными типами связности. Несмотря на подобные модификации и расширения способов вычисления цикломатической сложности, по-прежнему применяется стандартный метод расчёта согласно двум базовым формулам.

4. Взаимосвязь между цикломатической сложностью и когнитивной сложностью

Важно проанализировать взаимосвязь цикломатической сложности со стандартными метриками сложности. Большинство исследований сопоставляли классическую цикломатическую сложность с другими стандартизованными метриками, чтобы установить взаимосвязи между ними. В частности, была изучена связь цикломатической сложности со значением LOC, и сделан вывод о линейной зависимости между ними при наличии ряда статистических оговорок, прежде всего связанных с распределением значений обеих метрик [25]. Что касается вычисления когнитивной сложности для заданного ПО, результаты большинства работ позволяют заключить, что она по сути количественно определяет объём внутренней информации в исходном коде путём назначения соответствующих когнитивных весов, а также учитывает пространственный аспект — то, как эта информация «рассеивается» по программе в терминах LOC.

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

Исходный код, содержащий множество переменных, структур, типов данных и BCS, даёт высокий суммарный когнитивный вес, то есть большой объём информации. Более того, если расстояние между объявлением переменных, инициализацией и определениями функций и их фактическим использованием велико, то и их «пространственная ёмкость» также возрастает. Поэтому когнитивная сложность такого кода будет высокой. Цикломатическая сложность этого кода полностью зависит от числа BCS в нём, вне зависимости от объёма информации и её пространственных характеристик. Таким образом, у программ с высокой когнитивной сложностью цикломатическая сложность может быть низкой, средней или высокой — в зависимости от того, сколько BCS присутствует в исходном коде. Возможные сочетания значений цикломатической сложности относительно когнитивной с учётом архитектурных и пространственных аспектов показаны в таб. 1.

Чтобы проанализировать взаимосвязь между когнитивной сложностью и цикломатической сложностью, были выбраны пятнадцать программ на C из книги Э. Балагурусвами Programming in ANSI C [26]. Мера когнитивной информационной сложности (CICM), вычисленная по подходу D. Kushwaha и A. K. Misra [3], приведена в таб. 2.

Уровни зависимости значений CICM, LOC и CC для этих пятнадцати исходных текстов графически представлены на рис. 3.

Значения CICM, приведённые в таб. 2, отражают когнитивную сложность данного исходного кода с точки зрения взвешенного объёма информации, который определяется значением LOC, общим числом идентификаторов и операторов, а также когнитивными весами, назначенными BCS [3]. Вычисление цикломатической сложности ограничивается лишь количеством линейно независимых путей, определяемых на основе BCS, независимо от объёма информации, стоящей за исходным кодом. Поэтому закономерно, что значение когнитивной сложности в таб. 2 всегда выше соответствующего значения цикломатической сложности. Поскольку в данном случае когнитивная сложность рассматривается в одном из возможных вариантов по результатам предыдущих исследований, необходимо проанализировать ситуацию, когда когнитивная сложность оказывается высокой относительно её цикломатической сложности.

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

Когнитивная сложность определяется как объём усилий, которые человек затрачивает, чтобы понять данное программное обеспечение, тогда как цикломатическая сложность определяет число линейно независимых путей в исходном коде. Усилия на понимание ПО — величина субъективная, поскольку разные пользователи склонны понимать программу по-разному. Это также зависит от бэкграунда пользователя: используемого языка программирования, прошлого опыта и знаний о вычислительной среде. Объём информации играет ключевую роль в определении трудоёмкости понимания: чем больше информации, тем больше усилий требуется для осмысления кода. Ещё один фактор — пространственная ёмкость исходного кода, то есть число строк кода (LOC) между объявлением сегмента и его использованием. Пространственная ёмкость высока, когда расстояние между объявлением и использованием велико, что ведёт к высокой когнитивной сложности. Кроме того, инструменты среды программирования — такие как интегрированная среда разработки (IDE) — и доступная документация (руководства, комментарии в коде) снижают усилия на понимание, что приводит к меньшей когнитивной сложности. Также может существовать множество иных факторов, которые следует учитывать при определении когнитивной сложности в зависимости от конкретных пользователей. Значение цикломатической сложности — объективная величина, не зависящая от участия человека в работе с кодом. Поэтому вывести точную зависимость между этими двумя метриками трудно: их значения меняются по-разному в разных сценариях.

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

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

Заключение

Метрика когнитивной сложности описывает, как человеческий мозг проходит через внутреннюю логику заданного программного обеспечения, опираясь на теорию когнитивной информатики. Это субъективная мера: уровень понимания зависит от человека, поэтому стандартный способ определения метрики когнитивной сложности всё ещё находится в разработке. Согласно предыдущим исследованиям, когнитивная сложность количественно охватывает объём информации в исходном коде путём назначения соответствующих когнитивных весов и учитывает, как эта информация «рассеивается» по программе. В данной работе проанализировано, как вычисление когнитивной сложности одним из методов — CICM — соотносится с цикломатической сложностью, которая считает число линейно независимых путей в коде. По полученным результатам можно заключить, что значение CICM для программного обеспечения всегда выше его цикломатической сложности. Поскольку CICM — лишь один из способов вычисления когнитивной сложности, анализ когнитивной сложности должен выходить за рамки этого подхода и опираться на её определение. Следовательно, для этих двух вычислений нельзя задать единственную специфическую зависимость: при определённых обстоятельствах возможны разные отношения между ними в зависимости от присутствующих в коде базовых управляющих структур (BCS). Это объясняется тем, что обе метрики оценивают сложность одного и того же ПО с двух разных точек зрения, хотя и направлены на оценку сложности.

Будущая работа

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

Благодарности

Завершение данного анализа было бы невозможно без постоянной мотивации и руководства со стороны проф. K. P. Hewagamage (University of Colombo School of Computing, Sri Lanka).

Литература

1. IEEE Computer Society: IEEE Standard Glossary of Software Engineering Terminology, IEEE Standard 610.12-1990.
2. J. C. Munsona and T. M. Khoshgoftaar, “The dimensionality of program complexity,” Proceedings of the 11th International Conference on Software Engineering, pp. 245–253, 1989.
3. D. S. Kushwaha and A. K. Misra, “A Modified Cognitive Information Complexity of Software”, ACM SIGSOFT Software Engineering Notes, vol. 31, no. 1, January 2006.
4. S. Misra, “A Complexity Measure Based on Cognitive Weights”, International Journal of Theoretical and Applied Computer Sciences, vol. 1, pp. 1-10, 2006.
5. Y. Wang and J. Shao, “Measurement Of The Cognitive Functional Complexity of Software”, IEEE International Conference on Cognitive Informatics, 2003.
6. Y. Wang, “The Real-Time Process Algebra (RTPA)”, Annals of Software Engineering: An International Journal, Vol. 14, USA, pp. 235 – 274, 2002.
7. D. S. Kushwaha and A. K. Misra, “Improved Cognitive complexity Measure: A Metric that Establishes Program Comprehension Effort”, ACM SIGSOFT Software
Engineering Notes, vol. 31, no. 5, September 2006
8. J. K. Chhabra, “Code Cognitive complexity: A New Measure”, World Congress on Engineering, vol. 2, July 6-8 2011.
9. C. R. Douce, P. J. Layzell and J. Buckley, “Spatial measures of software complexity”, in Proceedings of 11th meeting of Psychology of Programming Interset Group, Leeds, January 1999.
10. Y. Choe, C. Jong and S. Han, “Software Cognitive Information Measure based on Relation between Structures”, 2013.
11. T. Klemola and J. Rilling, “A Cognitnve Complexity metric based on Category learning”, in Prceeding of the 2 nd IEEE International Conference of Cognitnve Informatics (ICCI’03), 2003.
12. U. Chhillar and S. Bhasin, “A New Weighted Composite Complexity Measure for Object-Oriented Systems”. International Journal of Information and Communication Technology Research.vol.1, no. 3, July 2011.
13. D. S. Kushwaha and A. K. Misra, “Cognitive Information Complexity measure of Object Oriented Software – A Practitioner’s Approach”, in Proceedings of the 5th WSEAS International Conference on Software Engineering, Parallel and Distributed Systems, pp174- 179, February 15-17, 2006.
14. E. Weyuker, “Evaluating Software Complexity Measure”, IEEE Transaction on Software Complexity Measure, 14 (9), pp. 1357 – 1365, 1988.
15. L. Briand and S. Morasca, “Property Based Software Engineering Measurement”, IEEE Transactions on Software Engineering, vol. 22, no. 1, January 1996.
16. D. S. Kushwaha and A. K. Misra, “ Robustness Analysis of Cognitive Information Complexity Measure using Weyuker Properties” , ACM SIGSOFT Software Engineering Notes, vol. 31, no. 1, January 2006.
17. S. Misra and A. Misra, “Evaluation and Comparison of Cognitive complexity Measure”, ACM SIGSOFT Software Engineering Notes, vol. 32, no. 2, March 2007.
18. S. Misra, “Validating Modified Cognitive complexity Measure”, ACM SIGSOFT Software Engineering Notes, vol. 32, no. 3, May 2007.
19. J. K. Chhabra and V. Gupta, “Evaluation of ObjectOriented Spatial Complexity Measures”, ACM SIGSOFT Software Engineering Notes, vol. 34, no. 3, May 2009.
20. S. Misra and A. Misra, “Evaluating Cognitive complexity Measure with Weyuker Properties”, Third IEEE International Conference on Cognitive Informatics (ICCI’04), 2004.
21. T. McCabe, “A Complexity Measure”, IEEE Transactions on Software Engineering, December 1976.
22. T. McCabe, “Structured Testing: A Testing Methodology Using the Cyclomatic complexity Metric,” NIST Special Publication, pp. 500-235, September 1996.
23. A. Madi, O. K. Zein and S. Kadry, “ On the Improvement of Cyclomatic complexity Metric”, International Journal of Software Engineering and its Applications, vol 7, No 2, March 2013.
24. G. K. Gill and C. F. Kemerer, “Cyclomatic complexity Density and Software Maintainance Productivity”, IEEE Transactions of Software Engineering, vol 17, No 2, December 1991.
25. J. Graylin, R. K. Smith, N. A. Kraft, J. E. Hale and D. Hale, “Cyclomatic complexity and Lines of Code: Empirical Evidence of a Stable Linear Relationship”, International journal of Software Engineering and Applications, pp. 2: 137-143, October 2009.
26. E. Balagurusamy,Programing in ANSI - C, Tata McGraw-Hill Publishing Company Limited, New Delhi,Second edition, 1992.