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

Не путать с теорией сложности вычислений .

Сложность программирования (или сложность программного обеспечения ) — это термин, включающий свойства программного обеспечения, влияющие на внутренние взаимодействия. Некоторые комментаторы различают термины «сложный» и «сложный». Сложность подразумевает, что ее трудно понять, но в конечном итоге познать. Комплекс, напротив, описывает взаимодействие между сущностями. По мере увеличения числа сущностей число взаимодействий между ними увеличивается в геометрической прогрессии, что делает невозможным узнать и понять их все. Аналогичным образом, более высокий уровень сложности программного обеспечения увеличивает риск непреднамеренного вмешательства во взаимодействие, тем самым увеличивая риск возникновения дефектов при изменении программного обеспечения. В более крайних случаях модификация программного обеспечения становится практически невозможной.

Идея связать сложность программного обеспечения с его ремонтопригодностью широко исследовалась профессором Мэнни Леманом , который разработал свои «Законы эволюции программного обеспечения» . Он и его соавтор Лес Белади исследовали многочисленные показатели программного обеспечения , которые можно использовать для измерения состояния программного обеспечения, и в конечном итоге пришли к выводу, что единственным практическим решением является использование детерминированных моделей сложности.

Типы

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

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

Меры

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

• Метрика цикломатической сложности Маккейба
• Показатели науки о программном обеспечении Холстеда
• Генри и Кафура представили «Метрики структуры программного обеспечения, основанные на информационном потоке» в 1981 году. который измеряет сложность как функцию «разветвления» и «разветвления». Они определяют разветвление процедуры как количество локальных потоков в этой процедуре плюс количество структур данных, из которых эта процедура извлекает информацию. Разветвление определяется как количество локальных потоков, выходящих из этой процедуры, плюс количество структур данных, которые обновляет процедура. Локальные потоки относятся к данным, передаваемым в процедуры, которые вызывают рассматриваемую процедуру или из нее. Значение сложности Генри и Кафуры определяется как «длина процедуры, умноженная на квадрат разветвления, умноженный на разветвление» (Длина × (вход × разветвление)²).
• Чидамбер и Кемерер представили «Набор метрик для объектно-ориентированного проектирования» в 1994 году. сосредоточив внимание на метриках объектно-ориентированного кода. Они вводят шесть показателей объектно-ориентированной сложности: (1) взвешенные методы для каждого класса; (2) связь между классами объектов; (3) ответ для класса; (4) количество детей; (5) глубина дерева наследования; и (6) отсутствие согласованности методов.

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

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

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

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

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

• Взвешенные методы для каждого класса («WMC»)
  • $WMC=\sum _{i=1}^{n}c_{i}$
  • n — количество методов в классе
  • $c_{i}$сложность метода
• Связь между классами объектов («CBO»)
  • номер другого класса, который связан (используется или используется)
• Ответ для класса («RFC»)
  • $RFC=|RS|$ где
  • $RS=\{M\}\cup _{all\ i}\{R_{i}\}$
  • $R_{i}$ набор методов, вызываемых методом i
  • $M$ это набор методов в классе
• Количество детей («НОК»)
  • сумма всех классов, наследующих этот класс или его потомка
• Глубина дерева наследования («DIT»)
  • максимальная глубина дерева наследования для этого класса
• Отсутствие связности методов («LCOM»)
  • Измеряет пересечение атрибутов, используемых совместно методами класса.
  • $LCOM={\begin{cases}|P|-|Q|,&{\text{if }}|P|>|Q|\\0,&{\text{otherwise }}\end{cases}}$
  • Где $P=\{(I_{i},I_{j})|I_{i}\cap I_{j}=\emptyset \}$
  • И $Q=\{(I_{i},I_{j})|I_{i}\cap I_{j}\neq \emptyset \}$
  • С $I_{i}$ — это набор атрибутов (переменных экземпляра), к которым осуществляется доступ (чтение или запись) $i$-й метод класса

См. также

• Парадигма программирования
• Программный кризис