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

Programming complexity

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

Меры

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

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

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

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

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

Типы

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

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

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

Чидамбер и Кемерер^[3] предложил набор показателей сложности программирования, широко используемых во многих измерениях и академических статьях. Это 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 }}$
- С участием ${ displaystyle I_ {i}}$ - это набор атрибутов (переменных экземпляра), к которым осуществляется доступ (чтение или запись) ${ displaystyle i}$ -й метод класса

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

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

использованная литература

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

[1] М.М. Лехмам, Л.А. Белады; Эволюция программы - процессы изменения программного обеспечения 1985 г.

[2] Генри, S .; Кафура, Д. Транзакции IEEE по разработке программного обеспечения Том SE-7, выпуск 5, сентябрь 1981 г. Страницы: 510 - 518

[:0-3] а ^б Chidamber, S.R .; Кемерер, К.Ф. IEEE Transactions on Software Engineering, том 20, выпуск 6, июнь 1994 г. Стр .: 476 - 493

[4] В программной инженерии проблему можно разделить на случайную и существенную [1].

[1]

[2]

[3]

[4]

Navigation