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 qué tan 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 suele contrastarse con la cohesión . Un acoplamiento bajo suele estar relacionado con una cohesión alta, y viceversa. A menudo se piensa que un acoplamiento bajo es un signo de un sistema informático bien estructurado y de un buen diseño, y que cuando se combina con una cohesión alta, respalda los objetivos generales de alta legibilidad y facilidad de mantenimiento . ^{[ cita requerida ]}

Historia

Las métricas de calidad del software de acoplamiento y cohesión fueron inventadas por Larry Constantine a fines de la década de 1960 como parte de un diseño estructurado , basado en características de prácticas de programación “buenas” 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 Stevens, Myers & Constantine (1974) ^[4] y el libro Yourdon & Constantine (1979), ^[5] y, posteriormente, estos últimos se convirtieron en términos estándar.

Tipos de acoplamiento

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

Programación procedimental

Un módulo aquí se refiere a una subrutina de cualquier tipo, es decir, un conjunto de una o más declaraciones que tienen un nombre y, preferiblemente, su propio conjunto de nombres de variables.

Acoplamiento de contenido (alto): Se dice que el acoplamiento de contenido ocurre cuando un módulo utiliza el código de otro módulo, por ejemplo, una rama. Esto viola el ocultamiento de información , un concepto básico de diseño de software.
Acoplamiento común: Se dice que hay acoplamiento común cuando varios módulos tienen acceso a los mismos datos globales, pero puede provocar una propagación de errores incontrolada y efectos secundarios imprevistos cuando se realizan cambios.
Acoplamiento externo: El acoplamiento externo se produce cuando dos módulos comparten un formato de datos, un protocolo de comunicación o una interfaz de dispositivo impuestos externamente. Esto está básicamente relacionado con la comunicación con herramientas y dispositivos externos.
Acoplamiento de control: El acoplamiento de control es un módulo que controla el flujo de otro, pasándole información sobre qué hacer (por ejemplo, pasando un indicador de qué hacer).
Acoplamiento de sellos (acoplamiento estructurado de datos): El acoplamiento de sellos ocurre cuando los módulos comparten una estructura de datos compuesta y usan solo partes de ella, posiblemente partes diferentes (por ejemplo, pasar un registro completo a una función que solo necesita un campo del mismo).; En esta situación, una modificación en un campo que un módulo no necesita puede llevar a cambiar la forma en que el módulo lee el registro.
Acoplamiento de datos: El acoplamiento de datos se produce cuando los módulos comparten datos a través de, por ejemplo, parámetros. Cada dato es una pieza elemental y estos son los únicos datos compartidos (por ejemplo, al pasar un número entero a una función que calcula una raíz cuadrada).

Programación orientada a objetos

Acoplamiento de subclases: Describe la relación entre un hijo y su padre. El hijo está conectado con su padre, pero el padre no está conectado con el hijo.

Acoplamiento temporal: Es cuando dos acciones se agrupan en un módulo simplemente porque ocurren al mismo tiempo.

En trabajos recientes se han investigado otros conceptos de acoplamiento y se han utilizado como indicadores para diferentes principios de modularización utilizados en la práctica. ^[6]

Acoplamiento dinámico

El objetivo de definir y medir este tipo de acoplamiento es proporcionar una evaluación en tiempo de ejecución de un sistema de software. Se ha argumentado que las métricas de acoplamiento estático pierden precisión cuando se trata de un uso intensivo de la herencia o vinculación dinámica. ^[7] En el intento de resolver este problema, se han tenido en cuenta las medidas de acoplamiento dinámico.

Acoplamiento semántico

Este tipo de métrica de acoplamiento considera las similitudes conceptuales entre entidades de software que utilizan, por ejemplo, comentarios e identificadores y se basan en técnicas como la indexación semántica latente (LSI).

Acoplamiento lógico

El análisis de acoplamiento lógico (o acoplamiento evolutivo o acoplamiento de cambios) explota el historial de lanzamiento de un sistema de software para encontrar patrones de cambio entre módulos o clases: por ejemplo, entidades que es probable que se modifiquen juntas o secuencias de cambios (un cambio en una clase A siempre es seguido por un cambio en una clase B).

Dimensiones del acoplamiento

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

Dependencia de la tecnología
Dependencia de la ubicación
Dependencia de topología
Dependencia de formato y tipo de datos
Dependencia semántica
Dependencia de la conversación
Dependencia de orden
Dependencia temporal

Desventajas del acoplamiento estrecho

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

Un cambio en un módulo generalmente genera un efecto dominó de cambios en otros módulos.
El ensamblaje de módulos puede requerir más esfuerzo y/o tiempo debido a la mayor dependencia entre módulos.
Puede resultar más difícil reutilizar y/o probar un módulo en particular porque se deben incluir módulos dependientes.

Problemas de rendimiento

Ya sea que el acoplamiento sea flexible o fuerte, el rendimiento de un sistema a menudo se ve 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), que requieren menos sobrecarga que la creación de un mensaje complicado, como un mensaje SOAP . Los mensajes más largos requieren más CPU y memoria para producirse. Para optimizar el rendimiento en tiempo de ejecución, se debe minimizar la longitud del mensaje y maximizar su significado.

Rendimiento y sobrecarga de transmisión de mensajes: Dado que un mensaje debe transmitirse en su totalidad para conservar su significado completo, la transmisión del mensaje debe optimizarse. Los mensajes más largos requieren más CPU y memoria para transmitirse y recibirse. Además, cuando es necesario, los receptores deben volver a ensamblar un mensaje en su estado original para recibirlo por completo. Por lo tanto, para optimizar el rendimiento en tiempo de ejecución, se debe minimizar la longitud del mensaje y maximizar su significado.

Gastos generales y rendimiento de la traducción de mensajes: Los protocolos de mensajes y los mensajes mismos a menudo contienen información adicional (es decir, información sobre paquetes, estructura, definición e idioma). Por lo tanto, el receptor a menudo necesita traducir un mensaje a una forma más refinada eliminando caracteres adicionales e información de estructura y/o convirtiendo valores de un tipo a otro. Cualquier tipo de traducción aumenta la sobrecarga de CPU y/o memoria. Para optimizar el rendimiento en tiempo de ejecución, la forma y el contenido del mensaje deben reducirse y refinarse para maximizar su significado y reducir la traducción.

Interpretación de mensajes: sobrecarga y rendimiento: El receptor debe interpretar todos los mensajes. Los mensajes simples, como los números enteros, pueden no requerir procesamiento adicional para su interpretación. Sin embargo, los mensajes complejos, como los mensajes SOAP, requieren un analizador y un transformador de cadenas para que muestren los significados previstos. Para optimizar el rendimiento en tiempo de ejecución, los mensajes se deben refinar y reducir para minimizar la sobrecarga de interpretación.

Soluciones

Un enfoque para disminuir el acoplamiento es el diseño funcional , que busca limitar las responsabilidades de los módulos a lo largo de la funcionalidad. El acoplamiento aumenta entre dos clases A y B si:

A tiene un atributo que se refiere a (es de tipo) B.
A llama a los servicios de unobjeto B.
A tiene un método que hace referencia a B (a través del tipo de retorno o parámetro).
A es una subclase de (o implementa) laclase B.

El bajo acoplamiento 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 (ver Ocultación de información ).

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

Acoplamiento versus cohesión

El acoplamiento y la cohesión son términos que aparecen juntos con mucha frecuencia. 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 cohesión baja implica que un módulo determinado realiza tareas que no están muy relacionadas entre sí y, por lo tanto, puede crear problemas a medida que el módulo se hace más grande.

Acoplamiento de módulos

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

Para el acoplamiento del flujo de datos y control:

d _i : número de parámetros de datos de entrada
c _i : número de parámetros de control de entrada
d _o : número de parámetros de datos de salida
c _o : número de parámetros de control de salida

Para acoplamiento global:

g _d : número de variables globales utilizadas como datos
g _c : número de variables globales utilizadas como control

Para acoplamiento ambiental:

w : número de módulos llamados (fan-out)
r : número de módulos que llaman al módulo en consideración (fan-in)

$\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 más acoplado esté el módulo, mayor será el valor. Este número varía aproximadamente entre 0,67 (acoplamiento bajo) y 1,0 (acoplamiento alto).

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

$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, una cantidad igual de parámetros de control y accede a 10 elementos de datos globales, con un abanico de entrada de 3 y un abanico de salida de 4,

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

Véase también

Referencias

^ ISO/IEC/IEEE 24765:2010 Ingeniería de sistemas y software — Vocabulario
^ ISO/IEC TR 19759:2005, Ingeniería de software: Guía del conjunto de conocimientos sobre ingeniería de software (SWEBOK)
^ ab Hohpe, Gregor. Patrones de integración empresarial: diseño, creación e implementación de soluciones de mensajería . Addison-Wesley Professional. ISBN 978-0321200686.
^ Stevens, Wayne P. ; Myers, Glenford J. ; Constantine, Larry LeRoy (junio de 1974). "Diseño estructurado". IBM Systems Journal . 13 (2): 115–139. doi :10.1147/sj.132.0115.
^ Yourdon, Edward ; Constantine, Larry LeRoy (1979) [1975]. Diseño estructurado: Fundamentos de una disciplina de diseño de programas y sistemas informáticos . Yourdon Press. Bibcode :1979sdfd.book.....Y. ISBN 978-0-13-854471-3.
^ Beck, Fabian; Diehl, Stephan (septiembre de 2011). "Sobre la congruencia de la modularidad y el acoplamiento de código". En Actas del 19.º Simposio ACM SIGSOFT y la 13.ª Conferencia Europea sobre Fundamentos de la Ingeniería de Software (SIGSOFT/FSE '11) . Szeged, Hungría. p. 354. doi :10.1145/2025113.2025162. ISBN . 9781450304436. Número de identificación del sujeto 2413103.{{cite book}}: Mantenimiento de CS1: falta la ubicación del editor ( enlace )
^ Arisholm, Erik; Briand, Lionel C .; Føyen, Audun (agosto de 2004). "Medición de acoplamiento dinámico para software orientado a objetos". IEEE Transactions on Software Engineering . 30 (8). IEEE : 491–506. doi :10.1109/TSE.2004.41. hdl : 10852/9090 . S2CID 3074827.
^ Pressman, Roger S. (1982). Ingeniería de software: un enfoque práctico (4.ª edición). McGraw-Hill. ISBN 0-07-052182-4.

Lectura adicional

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 métrico de software para acoplamiento de módulos". Revista de sistemas y 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 el nivel básico de profesional certificado en arquitectura de software (CPSA)" (PDF) . 3.01. International Software Architecture Qualification Board eV (ISAQB). 2015-05-15 [2009]. Archivado desde el original (PDF) el 2017-03-29 . Consultado el 2019-06-23 .[1] Archivado el 22 de febrero de 2016 en Wayback Machine.