Complejidad ciclomática
La Complejidad Ciclomática (en inglés, Cyclomatic Complexity) es una métrica del software en ingeniería del software que proporciona una medición cuantitativa de la complejidad lógica de un programa. Es una de las métricas de software de mayor aceptación, ya que ha sido concebida para ser independiente del lenguaje.
Origen
Esta métrica, propuesta por Thomas McCabe en 1976, se basa en el diagrama de flujo determinado por las estructuras de control de un determinado código. De dicho análisis se puede obtener una medida cuantitativa de la dificultad de crear pruebas automáticas del código y también es una medición orientativa de la fiabilidad del mismo.
El nombre “Complejidad Ciclomática” puede resultar engañoso para un programador ya que la idea de esta métrica no es contar los bucles (for, while, do…) en el código de un programa sino en el resultado de contar el número de ciclos diferentes que se siguen en un fragmento de código de un programa habiendo creado una rama imaginaria desde el nodo de salida al nodo de entrada del diagrama de flujo correspondiente a este fragmento de código. Un nombre más adecuado podría ser Complejidad condicional ya que el cálculo de esta métrica se ajusta más al hecho de buscar condiciones que contar ejecuciones de predicados dentro de bucles.
Significado
El resultado obtenido en el cálculo de la complejidad ciclomática define el número de caminos independientes dentro de un fragmento de código y determina la cota superior del número de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez.
La medida resultante puede ser utilizada en el desarrollo, mantenimiento y reingeniería para estimar el riesgo, costo y estabilidad. Algunos estudios experimentales indican la existencia de distintas relaciones entre la métrica de McCabe y el número de errores existentes en el código fuente, así como el tiempo requerido para encontrar y corregir esos errores.
Riesgo
Una vez calculada la complejidad ciclomática de un fragmento de código, se puede determinar el riesgo que supone utilizando los rangos definidos en la siguiente tabla:
| Complejidad Ciclomática | Evaluación del Riesgo |
|---|---|
| 1-10 | Programa Simple, sin mucho riesgo |
| 11-20 | Más complejo, riesgo moderado |
| 21-50 | Complejo, Programa de alto riesgo |
| 50 | Programa no testeable, Muy alto riesgo |
A partir del análisis de muchos proyectos McCabe encontró que un valor 10 es un límite superior práctico para el tamaño de un módulo[cita requerida]. Cuando la complejidad supera dicho valor se hace muy difícil probarlo, entenderlo y modificarlo. La limitación deliberada de la complejidad en todas las fases del desarrollo ayuda a evitar los problemas asociados a proyectos de alta complejidad. El límite propuesto por McCabe sin embargo es fuente de controversias. Algunas organizaciones han utilizado el valor 15 con bastante éxito[cita requerida].
Cálculo de la Complejidad Ciclomática
Primero introducir una sencilla notación para la representación del flujo de control, denominada grafo de flujo de control de un programa.
- M = Complejidad ciclomática.
- E = Número de aristas del grafo. Una arista conecta dos vértices si una sentencia puede ser ejecutada inmediatamente después de la primera.
- N = Número de nodos del grafo correspondientes a sentencias del programa.
- P = Número de componentes conexos, nodos de salida.
Definidos estos conceptos, la Complejidad Ciclomática puede calcularse de la siguiente manera:
M = E − N + 2P
Una versión simplificada para el cálculo de la Complejidad Ciclomática es la siguiente:
M = Número de condiciones + 1
Esta última fórmula hay que retocarla si el código a analizar presenta varios puntos de salida o "returns", pasando a ser:
M = Número de condiciones + Número de retornos o salidas
donde el número de salidas nunca descenderá de 1.
Ámbito de utilización de la Complejidad Ciclomática
La complejidad ciclomática puede ser aplicada en varias áreas incluyendo:
- Análisis de riesgo en desarrollo de código: Mientras el código está en desarrollo, su complejidad puede ser medida para estimar el riesgo inherente.
- Análisis de riesgo de cambio durante la fase de mantenimiento: La complejidad del código tiende a incrementarse a medida que es mantenido durante el tiempo. Midiendo la complejidad antes y después de un cambio propuesto, puede ayudar a decidir cómo minimizar el riesgo del cambio.
- Planificación de Pruebas: El análisis matemático ha demostrado que la complejidad ciclomática indica el número máximo de casos de prueba necesarios para probar cada punto de decisión en un programa.
- Reingeniería: Provee conocimiento de la estructura del código operacional de un sistema. El riesgo involucrado en la reingeniería de una pieza de código está relacionado con su complejidad.
Referencias
- Artículo original de McCabe (1976)
Véase también
- Problemas no resueltos de la ingeniería de software
- Protocolo de Control de Congestión de Datagramas
- Sistema de control de calidad de software
Enlaces externos
Software
- Cobertura Muestra la Complejidad Ciclomática en Java para cada clase y la media de Complejidad Ciclomática para cada paquete y para todo el proyecto.
- El plug-in PMD para eclipse también puede analizar la complejidad ciclomática del código
- PEAR::CodeSniffer Comprobador de código PHP para la verificación de varios estándares que incluye comprobación de Complejidad Ciclomática.
- Perl::Metrics::Simple Analizador de código fuente Perl que comprueba varias métricas, entre ellas, la Complejidad Ciclomática de cada subrutina/método.
- complexity.py Script en Python para comprobar la Complejidad Ciclomática en programas realizados en este lenguaje.
Blogs
- Javier Garzás