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

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

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

Типы

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

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

Меры

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

• Метрика цикломатической сложности Маккейба
• Метрики науки о программном обеспечении Холстеда
• Генри и Кафура представили «Метрики структуры программного обеспечения на основе информационного потока» в 1981 году ^[3] , которые измеряют сложность как функцию «разветвления по входу» и «разветвления по выходу». Они определяют разветвление по входу процедуры как количество локальных потоков в эту процедуру плюс количество структур данных, из которых эта процедура извлекает информацию. Разветвление по выходу определяется как количество локальных потоков из этой процедуры плюс количество структур данных, которые обновляет процедура. Локальные потоки относятся к данным, передаваемым в процедуры и из них, которые вызывают или вызываются рассматриваемой процедурой. Значение сложности Генри и Кафуры определяется как «длина процедуры, умноженная на квадрат разветвления по входу, умноженного на разветвление по выходу» (длина × (разветвление по входу × разветвление по выходу)²).
• Чидамбер и Кемерер представили "A Metrics Suite for Object-Oriented Design" в 1994 году, ^[4] сосредоточившись на метриках для объектно-ориентированного кода. Они вводят шесть метрик сложности OO: (1) взвешенные методы на класс; (2) связь между классами объектов; (3) ответ для класса; (4) количество потомков; (5) глубина дерева наследования; и (6) отсутствие связности методов.

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

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

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

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

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

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

Смотрите также

• Парадигма программирования
• Кризис программного обеспечения

Ссылки

1. ММ Лехмам ЛА Белади; Эволюция программ - Процессы изменения программного обеспечения 1985
2. В программной инженерии проблему можно разделить на случайную и существенную сложность [1].
3. Генри, С.; Кафура, Д. Труды IEEE по программной инженерии, том SE-7, выпуск 5, сентябрь 1981 г. Страницы: 510–518
4. Chidamber, SR; Kemerer, CF IEEE Transactions on Software Engineering Том 20, Выпуск 6, июнь 1994 г. Страницы: 476 - 493