Acoplamiento (informática)

La métrica de software de acoplamiento y cohesión fue inventada por Larry Constantine a finales de la década de 1960 como parte del diseño estructurado, basado en características de 'buenas' prácticas de programación que reducen los costos de mantenimiento y modificación. El diseño estructurado, incluyendo cohesión y acoplamiento, se publicó en el artículo Stevens, Myers y Constantine (1974) y en el libro Yourdon y Constantine (1979), el último de los cuales posteriormente se volvió un estándar.

Modelo conceptual de acoplamiento

El acoplamiento puede ser "bajo" (también "débil") o "alto" (también "fuerte").

El bajo acoplamiento entre las unidades de software es el estado ideal que siempre se intenta obtener para lograr una buena programación o un buen diseño. Cuanto menos dependiente sean las partes que constituyen un sistema informático, mejor será el resultado. Sin embargo, es imposible un desacoplamiento total de las unidades.

Por ello, el objetivo final del diseño de software es reducir al mínimo el acoplamiento entre componentes. Para ello, lo más importante es saber eliminar el acoplamiento que no sea funcional o arquitectónico.

El caso del acoplamiento funcional, puede ser por ejemplo que un componente de cálculo de probabilidades dependa de un componente de cálculo matemático básico, ya que para calcular probabilidades será necesario aplicar fórmulas matemáticas.

El bajo acoplamiento permite:

• Mejorar el mantenimiento de las unidades de software.
• Aumentar la reutilización de las unidades de software.
• Evitar el efecto onda, ya que un defecto en una unidad puede propagarse a otras, haciendo incluso más difícil de detectar dónde está el problema.
• Minimiza el riesgo de tener que cambiar múltiples unidades de software cuando se debe alterar una.

Algunos tipos de acoplamiento, de mayor a menor, son los siguientes:

Sistemas estrechamente acoplados tienden a presentar las siguientes características de desarrollo, que a menudo son vistos como desventajas:

1. Un cambio en un módulo usualmente fuerza un efecto dominó de cambios en otros módulos.
2. El ensamble de módulos podría requerir más esfuerzo y tiempo debido a la interdependencia entre módulos.
3. Un módulo particular podría ser más difícil de reutilizar o probar debido a que los módulos dependientes deben incluirse.

Ya sea con alto o bajo acoplamiento, el rendimiento de un sistema se ve afectado la creación de mensajes y parámetros, transmisión, traducción (por ejemplo, el cálculo de referencias) y la interpretación de mensajes (que podría ser una referencia a una cadena, matriz o estructura de datos), o incluso mensajes más complejos como SOAP.

Transmisión de mensajes y rendimiento

Dado que un mensaje debe transmitirse completo para recuperar su información completa, la transmisión de mensajes se debe optimizar. Mensajes más largos requieren más memoria para transmitirse y recibirse. También, cuando es necesario, los receptores deben reensamblar el mensaje a su estado original para completar su recepción. En ese sentido, para optimizar el rendimiento en tiempo de ejecución, el tamaño del mensaje se debe minimizar, y la información contenida se debe maximizar.

Traducción de mensajes y rendimiento

Los protocolos de mensajes y los mensajes mismos muchas veces contienen información extra (por ejemplo, paquete, estructura, definición e información del lenguaje). Por lo tanto, el receptor muchas veces necesita traducir un mensaje en otro más refinado removiendo caracteres extra y estructuras de información y convirtiendo valores de un tipo a otro. Cualquier tipo de traducción incrementa el uso de CPU y memoria. Para optimizar el rendimiento en tiempo de ejecución, los mensajes y sus contenidos se deben reducir y refinar para maximizar la información contenida y reducir la traducción.

Interpretación de mensajes y rendimiento

El receptor debe interpretar todos los mensajes. Mensajes simples como enteros no deberían requerir procesamiento adicional para interpretarse. No obstante, mensajes complejos como mensajes SOAP requieren parseo y transformación de cadenas de caracteres para exhibir su significado interno. Para optimizar el rendimiento en tiempo de ejecución, los mensajes se deben refinar y reducir para minimizar la sobrecarga por interpretación.

Un enfoque para disminuir el acoplamiento es el diseño funcional, el cual busca limitar las resposabilidades de los módulos basándose en su funcionalidad. El acoplamiento se incrementa entre dos clases A y B si:

• A tiene un atributo que refiere a (es del tipo) B.
• A llama a un servicio de un objeto B.
• A tiene un método que referencia a B (vía tipos return o parámetros).
• A es una subclase de (o implementa) la clase B.

El bajo acoplamiento se refiere a una relación en la cual un módulo interactúa con otro vía una simple y estable interfaz y no necesita conocer la implementación interna del otro módulo (ver encapsulamiento (informática)).

Sistemas como CORBA o COM permiten objetos que se comunican con los demás sin tener que saber nada acerca de la implementación de los otros objetos. Estos dos sistemas incluso permiten la comunicación entre objetos escritos en diferentes lenguajes.

Acoplamiento y cohesión son términos que ocurren juntos muy frecuentemente. El acoplamiento se refiere a la interdependencia entre módulos, mientras que la cohesión describe cómo se relacionan las funciones dentro de un módulo independiente. Baja cohesión implica que un módulo dado ejecuta tareas que no están muy relacionadas unas a otras y por tanto pueden crear problemas como que el módulo se vuelva muy grande.

El acoplamiento en ingeniería de software[4] describe una versión de métricas asociadas con este concepto.

Para el acoplamiento de datos y flujo de control:

• d_i: número de parámetros de entrada
• c_i: número de parámetros de control
• d_o: número de parámetros de salida
• c_o: número de parámetros de control de salida

Para el acoplamiento global:

• g_d: número de variables globales usadas como data
• g_c: número de variables globales usadas como control

Para acoplamiento de entorno:

• w: número de módulos llamados (fan-out)
• r: número de módulos llamantes bajo consideración (fan-in)

${\displaystyle \mathrm {Acoplamiento} (C)=1-{\frac {1}{d_{i}+2\times c_{i}+d_{o}+2\times c_{o}+g_{d}+2\times g_{c}+w+r}}}$

Acoplamiento(C) hace que el valor sea más grande cuanto más acoplado esté el módulo. Este número varía de aproximadamente 0,67 (bajo acoplamiento) a 1,0 (altamente acoplado).

Por ejemplo, si un módulo tiene un solo parámetro de entrada y datos de salida,

${\displaystyle C=1-{\frac {1}{1+0+1+0+0+0+1+0}}=1-{\frac {1}{3}}=0.67}$

Si un módulo tiene 5 parámetros de entrada y salida de datos , el mismo número de parámetros de control y accede a 10 elementos de datos globales , con un fan-in de 3 y un fan-out de salida de 4,

${\displaystyle C=1-{\frac {1}{5+2\times 5+5+2\times 5+10+0+3+4}}=0.98}$

• Cohesión (informática)
• Ingeniería de software

• Stevens, W.P.; Myers, G.J.; Constantine, L.L. (1974). IBM Systems Journal 13 (2): 115–139, ed. Structured design (en inglés). doi:10.1147/sj.132.0115.
• Yourdon, Edward; Constantine, Larry L. ((1979) 1975). Yourdon Press, ed. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design (en inglés). ISBN 0138544719.
• Acoplamiento y Cohesión - Blog Disrupción tecnológica