Acoplamiento (programación informática)

En ingeniería de software , el acoplamiento es el grado de interdependencia entre módulos de software , una medida de cuán estrechamente conectados están dos rutinas o módulos, ^{[ 1 ]} y la fuerza de las relaciones entre módulos. ^{[ 2 ]} El acoplamiento no es binario sino multidimensional. ^{[ 3 ]}

El acoplamiento se suele contrastar con la cohesión . Un bajo acoplamiento a menudo se correlaciona con una alta cohesión, y viceversa. Un bajo acoplamiento suele considerarse un signo de un sistema informático bien estructurado y un buen diseño, y cuando se combina con una alta cohesión, favorece los objetivos generales de alta legibilidad y mantenibilidad . ^{[ 4 ]}

Las métricas de calidad de software de acoplamiento y cohesión fueron inventadas por Larry Constantine a finales de la década de 1960 como parte de un diseño estructurado , basado en características de buenas prácticas de programación que reducían los costos de mantenimiento y modificación. El diseño estructurado, que incluye la cohesión y el acoplamiento, se publicó en el artículo de Stevens, Myers y Constantine (1974) ^{[ 5 ]} y en el libro de Yourdon y Constantine (1979) ^{[ 6 ]} , y este último se convirtió posteriormente en un término estándar.

El acoplamiento y la cohesión son términos que suelen aparecer juntos. El acoplamiento se refiere a las interdependencias entre módulos, mientras que la cohesión describe el grado de relación entre las funciones dentro de un mismo módulo. Una baja cohesión implica que un módulo realiza tareas poco relacionadas entre sí, lo que puede generar problemas a medida que el módulo crece.

El acoplamiento puede ser "bajo" (también " flojo " y "débil") o "alto" (también "estrecho" y "fuerte"). Algunos tipos de acoplamiento, ordenados de mayor a menor, son los siguientes:

Según Gregor Hohpe, el acoplamiento es multidimensional: ^{[ 3 ]}

• Dependencia tecnológica
• Dependencia de la ubicación
• Dependencia topológica
• Dependencia del formato y tipo de datos
• Dependencia semántica
• Dependencia de la conversación
• Dependencia del orden
• Dependencia temporal

Los sistemas estrechamente acoplados tienden a presentar las siguientes características de desarrollo, que a menudo se consideran desventajas:

1. Un cambio en un módulo suele provocar un efecto dominó de cambios en otros módulos.
2. El ensamblaje de módulos podría requerir más esfuerzo y/o tiempo debido a la mayor dependencia entre ellos.
3. Un módulo en particular podría ser más difícil de reutilizar y/o probar porque es necesario incluir módulos dependientes.

Ya sea con un acoplamiento flexible o estricto, el rendimiento de un sistema suele verse reducido por la creación, transmisión, traducción (por ejemplo, serialización) e interpretación de mensajes y parámetros (que puede ser una referencia a una cadena, matriz o estructura de datos), procesos que requieren menos recursos que la creación de un mensaje complejo como un mensaje SOAP . Los mensajes más largos requieren más CPU y memoria para su producción. Para optimizar el rendimiento en tiempo de ejecución, la longitud del mensaje debe minimizarse y su significado debe maximizarse.

Sobrecarga y rendimiento de la transmisión de mensajes

Dado que un mensaje debe transmitirse íntegramente para conservar su significado completo, es necesario optimizar la transmisión. Los mensajes más largos requieren más CPU y memoria para su transmisión y recepción. Además, cuando es necesario, los receptores deben reconstruir el mensaje a su estado original para recibirlo por completo. Por lo tanto, para optimizar el rendimiento, la longitud del mensaje debe minimizarse y su significado debe maximizarse.

Sobrecarga y rendimiento de la traducción de mensajes

Los protocolos y los mensajes en sí mismos suelen contener información adicional (como información sobre paquetes, estructura, definición e idioma). Por lo tanto, el receptor a menudo necesita traducir un mensaje a un formato más refinado, eliminando caracteres y estructura innecesarios o convirtiendo valores de un tipo a otro. Cualquier tipo de traducción aumenta el consumo de CPU y/o memoria. Para optimizar el rendimiento, el formato y el contenido del mensaje deben simplificarse y refinarse para maximizar su significado y minimizar la traducción.

Sobrecarga y rendimiento de la interpretación de mensajes

Todos los mensajes deben ser interpretados por el receptor. Los mensajes simples, como los números enteros, podrían no requerir procesamiento adicional para su interpretación. Sin embargo, los mensajes complejos, como los mensajes SOAP, requieren un analizador sintáctico y un transformador de cadenas para que muestren el significado previsto. Para optimizar el rendimiento en tiempo de ejecución, los mensajes deben refinarse y simplificarse para minimizar la sobrecarga de interpretación.

Un enfoque para disminuir el acoplamiento es el diseño funcional , que busca limitar las responsabilidades de los módulos según su funcionalidad. El acoplamiento aumenta entre dos clases Asi B:

• Atiene un atributo que hace referencia a (es de tipo) B.
• Arealiza llamadas a los servicios de un objeto B.
• Atiene un método que hace referencia B(a través del tipo de retorno o parámetro).
• Aes una subclase de (o implementa) la clase B.

El acoplamiento bajo se refiere a una relación en la que un módulo interactúa con otro módulo a través de una interfaz simple y estable y no necesita preocuparse por la implementación interna del otro módulo (véase Ocultación de información ).

Sistemas como CORBA o COM permiten que los objetos se comuniquen entre sí sin necesidad de conocer la implementación del otro objeto. Ambos sistemas incluso permiten que los objetos se comuniquen con objetos escritos en otros lenguajes.

El acoplamiento describe el grado y la naturaleza de la dependencia entre componentes de software, centrándose en lo que comparten (por ejemplo, datos, flujo de control , tecnología) y cuán estrechamente están vinculados. Evalúa dos dimensiones clave: la fuerza, que mide la dificultad de cambiar la dependencia, y el alcance (o visibilidad), que indica cuán expuesta está la dependencia a través de módulos o límites. Los tipos de acoplamiento tradicionales suelen incluir el acoplamiento de contenido, el acoplamiento común, el acoplamiento de control, el acoplamiento de marca de tiempo, el acoplamiento externo y el acoplamiento de datos. ^{[ 10 ] [ 11 ] [ 12 ]}

Connascence , introducido por Meilir Page-Jones, proporciona un marco sistemático para analizar y medir las dependencias de acoplamiento. Evalúa las dependencias en función de tres dimensiones: fuerza, que mide el esfuerzo necesario para refactorizar o modificar la dependencia; localidad, que considera cuán cerca física o lógicamente están los componentes dependientes en el código ; y grado, que mide cuántos componentes se ven afectados por la dependencia. Connascence se puede categorizar en formas estáticas (detectables en tiempo de compilación) y dinámicas (detectables en tiempo de ejecución). Connascence estático se refiere a dependencias en tiempo de compilación, como firmas de métodos, mientras que Connascence dinámico se refiere a dependencias en tiempo de ejecución, que pueden manifestarse en formas como Connascence de tiempo, valores o algoritmo. ^{[ 10 ] [ 11 ] [ 12 ]}

Cada tipo de acoplamiento puede presentar múltiples tipos de connascencia, un tipo específico o, en casos excepcionales, ninguno, dependiendo de cómo se implemente la dependencia. Los tipos comunes de connascencia incluyen la connascencia de nombre, tipo, posición y significado. Ciertos tipos de acoplamiento se alinean naturalmente con tipos de connascencia específicos; por ejemplo, el acoplamiento de datos suele implicar la connascencia de nombre o tipo. Sin embargo, no todas las combinaciones de acoplamiento y connascencia tienen sentido práctico. Las dependencias que dependen del orden de los parámetros en la firma de un método demuestran la connascencia de posición, que es frágil y difícil de refactorizar porque reordenar los parámetros rompe la interfaz. Por el contrario, la connascencia de nombre, que depende de los nombres de los campos o parámetros, suele ser más resistente a los cambios. Los tipos de connascencia en sí mismos presentan una jerarquía natural de fuerza, considerándose la connascencia de nombre generalmente más débil que la connascencia de significado. ^{[ 10 ] [ 11 ] [ 12 ]}

Las dependencias que abarcan los límites de los módulos o los sistemas distribuidos suelen tener mayores costos de coordinación, lo que aumenta la dificultad de la refactorización y la propagación de cambios a través de límites distantes. Las prácticas modernas, como la inyección de dependencias y la programación basada en interfaces, se emplean a menudo para reducir la fuerza de acoplamiento y mejorar la mantenibilidad de las dependencias. ^{[ 10 ] [ 11 ] [ 12 ]}

Mientras que el acoplamiento identifica lo que se comparte entre los componentes, la connascencia evalúa cómo se comportan esas dependencias, cómo se propagan los cambios y cuán difícil es refactorizarlas. La fuerza, la localidad y el grado están interrelacionados; las dependencias con alta fuerza, amplio alcance y que abarcan límites distantes son significativamente más difíciles de refactorizar y mantener. En conjunto, el acoplamiento proporciona una visión general de alto nivel de las relaciones de dependencia, mientras que la connascencia ofrece un marco granular para analizar la fuerza, la localidad, el grado y la resiliencia al cambio de las dependencias, lo que apoya el diseño de sistemas robustos y mantenibles. ^{[ 10 ] [ 11 ] [ 12 ]}

El acoplamiento en la ingeniería de software ^{[ 13 ]} describe una versión de las métricas asociadas con este concepto.

Para el acoplamiento del flujo de datos y control:

• ${\displaystyle d_{i}}$: número de parámetros de datos de entrada
• ${\displaystyle c_{i}}$: número de parámetros de control de entrada
• ${\displaystyle d_{o}}$: número de parámetros de datos de salida
• ${\displaystyle c_{o}}$: número de parámetros de control de salida

Para el acoplamiento global:

• ${\displaystyle g_{d}}$: número de variables globales utilizadas como datos
• ${\displaystyle g_{c}}$: número de variables globales utilizadas como control

Para el acoplamiento ambiental:

• ${\displaystyle w}$: número de módulos llamados (distribución)
• ${\displaystyle r}$: número de módulos que llaman al módulo en cuestió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}}}$

Coupling(C)Cuanto mayor sea el acoplamiento del módulo, mayor será el valor. Este número oscila aproximadamente entre 0,67 (acoplamiento bajo) y 1,0 (acoplamiento alto).

Por ejemplo, si un módulo tiene un único parámetro de datos de entrada y 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 datos de entrada y salida, un número igual de parámetros de control y accede a 10 elementos de datos globales, con un fan-in de 3 y un fan-out de 4,

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

• Connascencia (informática)
• Acoplamiento (física)
• Eliminación de código muerto
• El infierno de la dependencia
• Acoplamiento eferente
• Inversión del control
• Lista de términos de programación orientada a objetos
• Acoplamiento suelto
• Hacer (software)
• Análisis de código estático

• Myers, Glenford J. (1974). Software confiable mediante diseño compuesto . Nueva York: Mason and Lipscomb Publishers.
• Offutt, A. Jefferson; Harrold, Mary Jean ; Kolte, Priyadarshan (marzo de 1993). "Un sistema de métricas de software para el acoplamiento de módulos". Journal of Systems and Software . 20 (3): 295– 308. doi : 10.1016/0164-1212(93)90072-6 .
• Page-Jones, Meilir (1980). Guía práctica para el diseño de sistemas estructurados . Nueva York: Yourdon Press. ISBN 978-8-12031482-5.
• Glosario estándar de terminología de ingeniería de software . Nueva York: IEEE . 1990. ISBN 0-7381-0391-8. 610.12_1990.
• "Plan de estudios para Profesional Certificado en Arquitectura de Software (CPSA) - Nivel Básico" (PDF) . 3.01. International Software Architecture Qualification Board eV (ISAQB). 15 de mayo de 2015 [2009]. Archivado del original (PDF) el 29 de marzo de 2017. Consultado el 23 de junio de 2019 .Archivado el 22 de febrero de 2016 en Wayback Machine.