Complejidad de la programación

La complejidad de la programación (o complejidad del software ) es un término que engloba las propiedades del software que afectan a las interacciones internas. Diversos expertos distinguen entre los términos «complejo» y «complicado». Complicado implica dificultad de comprensión, pero, en última instancia, conocimiento. Complejo, por el contrario, describe las interacciones entre entidades. A medida que aumenta el número de entidades, el número de interacciones entre ellas crece exponencialmente, lo que hace imposible conocerlas y comprenderlas todas. Del mismo modo, los niveles más altos de complejidad en el software incrementan el riesgo de interferir involuntariamente con las interacciones, aumentando así el riesgo de introducir defectos al modificar el software. En casos más extremos, puede hacer que la modificación del software sea prácticamente imposible.

La idea de vincular la complejidad del software con su mantenibilidad ha sido explorada extensamente por el profesor Manny Lehman , quien desarrolló sus Leyes de la Evolución del Software . Junto con su coautor Les Belady, exploró numerosas métricas de software que podrían utilizarse para medir el estado del software, llegando finalmente a la conclusión de que la única solución práctica es utilizar modelos de complejidad deterministas. ^{[ 1 ]}

La complejidad de un programa existente determina la complejidad de modificarlo. La complejidad del problema se puede dividir en dos categorías: ^{[ 2 ]}

1. La complejidad accidental se refiere a las dificultades que enfrenta un programador debido a las herramientas de ingeniería de software. Seleccionar un conjunto de herramientas mejor o un lenguaje de programación de nivel superior puede reducirla. La complejidad accidental suele ser consecuencia de no utilizar el dominio para definir la forma de la solución. El diseño orientado al dominio puede ayudar a minimizar la complejidad accidental.
2. La complejidad esencial se debe a las características del problema a resolver y no puede reducirse.

Se han propuesto varias medidas de complejidad de software. Muchas de ellas, si bien proporcionan una buena representación de la complejidad, no se prestan a una medición sencilla. Algunas de las métricas más utilizadas son:

• Métrica de complejidad ciclomática de McCabe
• Métricas de ciencia del software de Halstead
• Henry y Kafura introdujeron en 1981 las "Métricas de Estructura de Software Basadas en el Flujo de Información" ^{[ 3 ]} , que miden la complejidad en función del " fan-in " y el "fan-out". Definen el fan-in de un procedimiento como el número de flujos locales hacia ese procedimiento más el número de estructuras de datos de las que ese procedimiento recupera información. El fan-out se define como el número de flujos locales que salen de ese procedimiento más el número de estructuras de datos que el procedimiento actualiza. Los flujos locales se refieren a los datos que se pasan a los procedimientos que llaman o son llamados por el procedimiento en cuestión, y desde ellos. El valor de complejidad de Henry y Kafura se define como "la longitud del procedimiento multiplicada por el cuadrado del fan-in multiplicado por el fan-out" (Longitud × (fan-in × fan-out)²).
• Chidamber y Kemerer presentaron "A Metrics Suite for Object-Oriented Design" en 1994, ^{[ 4 ]} centrándose en métricas para código orientado a objetos. Introducen seis métricas de complejidad OO: (1) métodos ponderados por clase; (2) acoplamiento entre clases de objetos; (3) respuesta para una clase; (4) número de hijos; (5) profundidad del árbol de herencia; y (6) falta de cohesión de métodos.

Se pueden utilizar otras métricas para medir la complejidad de la programación:

• Complejidad de ramificación (Métrica de Sneed)
• Complejidad del acceso a los datos (Métrica de la tarjeta)
• Complejidad de los datos (Métrica de Chapin)
• Complejidad del flujo de datos (Métrica de Elshof)
• Complejidad de la toma de decisiones (Métrica de McClure)
• Complejidad de la ruta (Métrica de Bang)

La ley de Tesler es un adagio en la interacción persona-ordenador que afirma que toda aplicación tiene un grado inherente de complejidad que no se puede eliminar ni ocultar.

Chidamber y Kemerer ^{[ 4 ]} propusieron un conjunto de métricas de complejidad de programación ampliamente utilizadas en mediciones y artículos académicos: métodos ponderados por clase, acoplamiento entre clases de objetos, respuesta para una clase, número de hijos, profundidad del árbol de herencia y falta de cohesión de métodos, que se describen a continuación:

• Métodos ponderados por clase ("WMC")
  • ${\displaystyle WMC=\sum _{i=1}^{n}c_{i}}$
  • n es el número de métodos en la clase
  • ${\displaystyle c_{i}}$es la complejidad del método
• Acoplamiento entre clases de objetos ("CBO")
  • número de otra clase que está acoplada (usando o siendo utilizada)
• Respuesta para una clase ("RFC")
  • ${\displaystyle RFC=|RS|}$dónde
  • ${\displaystyle RS=\{M\}\cup _{all\ i}\{R_{i}\}}$
  • ${\displaystyle R_{i}}$es un conjunto de métodos llamados por el método i
  • ${\displaystyle M}$es el conjunto de métodos en la clase
• Número de niños ("NOC")
  • suma de todas las clases que heredan esta clase o un descendiente de ella
• Profundidad del árbol de herencia ("DIT")
  • profundidad máxima del árbol de herencia para esta clase
• Falta de cohesión de métodos ("LCOM")
  • Mide la intersección de los atributos utilizados en común por los métodos de la clase.
  • ${\displaystyle LCOM={\begin{cases}|P|-|Q|,&{\text{si }}|P|>|Q|\\0,&{\text{en otro caso }}\end{cases}}}$
  • Dónde${\displaystyle P=\{(I_{i},I_{j})|I_{i}\cap I_{j}=\emptyset \}}$
  • Y${\displaystyle Q=\{(I_{i},I_{j})|I_{i}\cap I_{j}\neq \emptyset \}}$
  • Con${\displaystyle I_{i}}$es el conjunto de atributos (variables de instancia) a los que se accede (se leen o se escriben) por el${\displaystyle i}$-ésimo método de la clase

• paradigma de programación
• Crisis del software