Сложность программирования - Programming complexity

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

Меры

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

Цикломатическая метрика сложности Маккейба
Метрики Halsteads Software Science
Генри и Кафура в 1981 году представили метрики структуры программного обеспечения, основанные на информационном потоке, которые измеряют сложность как функцию разветвления и разветвления. Они определяют разветвление процедуры как количество локальных потоков в эту процедуру плюс количество структур данных, из которых эта процедура извлекает информацию. Разветвление определяется как количество локальных потоков, исходящих из этой процедуры, плюс количество структур данных, которые обновляет процедура. Локальные потоки относятся к данным, передаваемым в процедуры и из них, которые вызывают или вызываются данной процедурой. Значение сложности Генри и Кафуры определяется как «длина процедуры, умноженная на квадрат входящего разветвления, умноженного на разветвление» (Длина × (входное разветвление × разветвление) ²).
Пакет Metrics Suite для объектно-ориентированного дизайна был представлен Чидамбером и Кемерером в 1994 году и, как следует из названия, сосредоточил внимание на показателях специально для объектно-ориентированного кода. Они вводят шесть объектно-ориентированных показателей сложности; взвешенные методы на класс, связь между классами объектов, ответ для класса, количество потомков, глубина дерева наследования и отсутствие связности методов

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

Сложность ветвления (Sneed Metric)
Сложность доступа к данным (метрика карты)
Сложность данных (метрика Chapin)
Сложность потока данных (метрика Эльсхофа)
Сложность принятия решения (метрика МакКлюра)

Закон TESler в это изречение в взаимодействие человека с компьютером о том , что каждое приложение имеет присущий количество сложности , которые не могут быть удалены или скрыты.

Типы

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

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

Метрики Чидамбера и Кемерера

Чидамбер и Кемерер предложили набор показателей сложности программирования, широко используемых во многих измерениях и научных статьях. Это WMC, CBO, RFC, NOC, DIT и LCOM, описанные ниже:

WMC - взвешенные методы на класс
- ${\ Displaystyle WMC = \ сумма _ {я = 1} ^ {п} с_ {я}}$
- n - количество методов в классе
- ${\ displaystyle c_ {i}}$ сложность метода
CBO - связь между классами объектов
- номер другого класса, который связан (использует или используется)
RFC - ответ для класса
- ${\ Displaystyle RFC = | RS |}$ где
- ${\ Displaystyle RS = \ {M \} \ чашка _ {все \ i} \ {R_ {i} \}}$
- ${\ displaystyle R_ {i}}$ это набор методов, вызываемых методом i
- ${\ displaystyle M}$ это набор методов в классе
NOC - количество детей
- сумма всех классов, которые наследуют этот класс или его потомков
DIT - глубина дерева наследования
- максимальная глубина дерева наследования для этого класса
LCOM - отсутствие сплоченности методов
- Измеряет пересечение атрибутов, используемых совместно методами класса.
- ${\ displaystyle LCOM = {\ begin {cases} | P | - | Q |, & {\ text {if}} | P |> | Q | \\ 0, & {\ text {else}} \ end {case }}}$
- куда ${\ displaystyle P = \ {(I_ {i}, I_ {j}) | I_ {i} \ cap I_ {j} = \ emptyset \}}$
- А также ${\ displaystyle Q = \ {(I_ {i}, I_ {j}) | I_ {i} \ cap I_ {j} \ neq \ emptyset \}}$
- With - это набор атрибутов (переменных экземпляра), к которым осуществляется доступ (чтение или запись) -м методом класса. ${\ displaystyle I_ {i}}$ ${\ displaystyle i}$