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

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

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

Меры

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

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

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

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

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

Типы

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

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

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

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

• Взвешенные методы для каждого класса («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 \}}$
  • With — это набор атрибутов (переменных экземпляра), к которым осуществляется доступ (чтение или запись) с помощью -го метода класса. ${\displaystyle I_{i}}$ ${\displaystyle i}$

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

• Кризис программного обеспечения (и последующие решения парадигмы программирования )
• Метрики программного обеспечения — количественная мера некоторого свойства программы.

Рекомендации

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