Complejidad de programación

La complejidad de programación (o complejidad del software ) es un término que incluye las propiedades del software que afectan las interacciones internas. Varios comentaristas distinguen entre los términos "complejo" y "complicado". Complicado implica ser difícil de entender, pero en última instancia cognoscible. 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 aumenta exponencialmente, lo que hace imposible conocerlas y comprenderlas todas. De manera similar, los niveles más altos de complejidad en el software aumentan el riesgo de interferir involuntariamente con las interacciones, lo que aumenta el riesgo de introducir defectos al cambiar el software. En casos más extremos, puede hacer que modificar el software sea prácticamente imposible.

La idea de vincular la complejidad del software con su capacidad de mantenimiento ha sido explorada extensamente por el profesor Manny Lehman , quien desarrolló sus Leyes de la evolución del software . Él y su coautor Les Belady exploraron numerosas métricas de software que podrían usarse para medir el estado del software, y finalmente concluyeron que la única solución práctica es usar modelos de complejidad deterministas. ^[1]

Tipos

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 relaciona con las dificultades que enfrenta un programador debido a las herramientas de ingeniería de software. La selección de un mejor conjunto de herramientas o un lenguaje de programación de nivel superior puede reducirla. La complejidad accidental a menudo resulta de no usar el dominio para enmarcar la forma de la solución. ^{[ cita requerida ]} El diseño impulsado por el dominio puede ayudar a minimizar la complejidad accidental.
2. La complejidad esencial es causada por las características del problema a resolver y no puede reducirse.

Medidas

Se han propuesto varias medidas de complejidad del software. Muchas de ellas, aunque ofrecen 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 la ciencia del software de Halstead
• Henry y Kafura introdujeron en 1981 "Métricas de la estructura del software basadas en el flujo de información", ^[3] que mide la complejidad como una función de "fan-in" y "fan-out". Definen el fan-in de un procedimiento como la cantidad de flujos locales que entran en ese procedimiento más la cantidad de estructuras de datos de las que ese procedimiento recupera información. El fan-out se define como la cantidad de flujos locales que salen de ese procedimiento más la cantidad de estructuras de datos que el procedimiento actualiza. Los flujos locales se relacionan con los datos que se pasan a, y desde, los procedimientos que llaman o son llamados por, el procedimiento en cuestión. El valor de complejidad de Henry y Kafura se define como "la longitud del procedimiento multiplicada por el cuadrado de fan-in multiplicado por fan-out" (Longitud × (fan-in × fan-out)²).
• Chidamber y Kemerer introdujeron "A Metrics Suite for Object-Oriented Design" en 1994, ^[4] centrándose en las métricas para el código orientado a objetos. Presentaron seis métricas de complejidad orientada a objetos: (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 los 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 (Card Metric)
• Complejidad de datos (Métrica de Chapin)
• Complejidad del flujo de datos (métrica de Elshof)
• Complejidad de decisión (Métrica McClure)
• Complejidad de la trayectoria (métrica de Bang)

La Ley de Tesler es un adagio en la interacción humano-computadora que establece que cada aplicación tiene una cantidad inherente de complejidad que no se puede eliminar ni ocultar.

Métricas de Chidamber y Kemerer

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 (que usa o que está siendo usada)
• 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 de la clase
• Número de hijos ("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 clase.
  • ${\displaystyle LCOM={\begin{cases}|P|-|Q|,&{\text{if }}|P|>|Q|\\0,&{\text{otherwise }}\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 es el conjunto de atributos (variables de instancia) a los que se accede (se leen o se escriben) mediante el método -ésimo de la clase. ${\displaystyle I_{i}}$ ${\displaystyle i}$

Véase también

• Paradigma de programación
• Crisis del software

Referencias

1. MM Lehmam LA Belady; Evolución del programa: procesos de cambio de software 1985
2. En ingeniería de software, un problema puede dividirse en su complejidad accidental y esencial [1].
3. Henry, S.; Kafura, D. IEEE Transactions on Software Engineering Volumen SE-7, Número 5, septiembre de 1981 Página(s): 510 - 518
4. Chidamber, SR; Kemerer, CF IEEE Transactions on Software Engineering Volumen 20, Número 6, junio de 1994 Página(s): 476 - 493