Grado de interdependencia entre módulos de software.
En ingeniería de software , el acoplamiento es el grado de interdependencia entre módulos de software ; una medida de cuán estrechamente conectadas están dos rutinas o módulos; [1] la fuerza de las relaciones entre módulos. [2] El acoplamiento no es binario sino multidimensional. [3]
Generalmente se contrasta el acoplamiento con la cohesión . Un bajo acoplamiento a menudo se correlaciona con una alta cohesión y viceversa. A menudo se piensa que un bajo acoplamiento es un signo de un sistema informático bien estructurado y un buen diseño, y cuando se combina con una alta cohesión, respalda los objetivos generales de alta legibilidad y mantenibilidad . [ cita necesaria ]
Historia
Las métricas de calidad del 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, incluyendo la cohesión y el acoplamiento, se publicaron en el artículo Stevens, Myers & Constantine (1974) [4] y en el libro Yourdon & Constantine (1979), [5] y estos últimos se convirtieron posteriormente en términos estándar.
Tipos de acoplamiento
Modelo conceptual de acoplamiento.
El acoplamiento puede ser "bajo" (también " flojo " y "débil") o "alto" (también "estrecho" y "fuerte"). Algunos tipos de acoplamiento, en orden de mayor a menor, son los siguientes:
Programación procesal
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 usa 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 el acoplamiento común ocurre cuando varios módulos tienen acceso a los mismos datos globales. Pero puede provocar una propagación incontrolada de errores y efectos secundarios imprevistos cuando se realizan cambios.
Acoplamiento externo
El acoplamiento externo ocurre 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 una bandera de qué hacer).
Acoplamiento de sello (acoplamiento estructurado de datos)
El acoplamiento de sello 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 necesita solo 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, 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 niño y su padre. El niño está conectado con su padre, pero el padre no está conectado con el niño.
acoplamiento temporal
Es cuando dos acciones se agrupan en un módulo simplemente porque ocurren al mismo tiempo.
En trabajos recientes se han investigado y utilizado varios otros conceptos de acoplamiento como indicadores de 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 del 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 vinculación dinámica o herencia. [7] En el intento de resolver este problema, se han tenido en cuenta medidas de acoplamiento dinámico.
acoplamiento semántico
Este tipo de métrica de acoplamiento considera las similitudes conceptuales entre entidades de software utilizando, por ejemplo, comentarios e identificadores y basándose 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 lanzamientos de un sistema de software para encontrar patrones de cambios entre módulos o clases: por ejemplo, entidades que probablemente se cambiarán juntas o secuencias de cambios (un cambio en una clase A es siempre seguido de un cambio en una clase B).
Dimensiones del acoplamiento
Según Gregor Hohpe, el acoplamiento es multidimensional: [3]
Dependencia tecnológica
Dependencia de la ubicación
Dependencia de topología
Formato de datos y dependencia del tipo
Dependencia semántica
Dependencia de la conversación
Dependencia del pedido
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 normalmente provoca un efecto dominó de los cambios en otros módulos.
El montaje de módulos puede requerir más esfuerzo y/o tiempo debido a la mayor dependencia entre módulos.
Un módulo en particular puede ser más difícil de reutilizar y/o probar porque se deben incluir módulos dependientes.
Problemas de desempeño
Ya sea que esté acoplado de manera flexible o estrecha, el rendimiento de un sistema a menudo se ve reducido por la creación, transmisión, traducción (por ejemplo, clasificación) e interpretación de mensajes y parámetros (que podrían ser una referencia a una cadena, matriz o estructura de datos), lo que requiere menos gastos generales que la creación. 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 el significado del mensaje.
Gastos generales y rendimiento de la 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 sea 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 el significado del mensaje.
Gastos generales y rendimiento de la traducción de mensajes
Los protocolos de mensajes y los propios mensajes a menudo contienen información adicional (es decir, información de paquete, 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 estructural 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.
Gastos generales y rendimiento de la interpretación de mensajes
Todos los mensajes deben ser interpretados por el receptor. Es posible que los mensajes simples, como los números enteros, no requieran procesamiento adicional para ser interpretados. Sin embargo, los mensajes complejos, como los mensajes SOAP, requieren un analizador y un transformador de cadena para que muestren el significado deseado. Para optimizar el rendimiento del tiempo de ejecución, los mensajes deben refinarse y reducirse 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 hace referencia a (es de tipo) B .
A solicita los servicios de un objeto B .
A tiene un método que hace referencia a B (mediante 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 (consulte Ocultación de información ).
Sistemas como CORBA o COM permiten que los objetos se comuniquen entre sí sin tener que saber nada sobre la implementación del otro objeto. Ambos sistemas incluso permiten que los objetos se comuniquen con objetos escritos en otros idiomas.
Acoplamiento versus cohesión
Acoplamiento y 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 qué tan relacionadas están las funciones dentro de un solo 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, pueden crear problemas a medida que el módulo crece.
Acoplamiento de módulos
Coupling in Software Engineering [8] describe una versión de métricas asociadas con este concepto.
Para acoplamiento de flujo de control y datos:
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)
Coupling(C)hace que el valor sea mayor cuanto más acoplado esté el módulo. Este número oscila entre aproximadamente 0,67 (bajo acoplamiento) y 1,0 (altamente acoplado).
Por ejemplo, si un módulo tiene un solo parámetro de datos de entrada y salida
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 una entrada de 3 y una salida de 4,
^ ISO/IEC/IEEE 24765:2010 Ingeniería de software y sistemas - Vocabulario
^ ISO/IEC TR 19759:2005, Ingeniería de software: guía para los conocimientos de 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 . Profesional de Addison-Wesley. ISBN 978-0321200686.
^ Beck, Fabián; Diehl, Stephan (septiembre de 2011). "Sobre la congruencia de modularidad y acoplamiento de códigos". En actas del 19.º Simposio ACM SIGSOFT y de la 13.ª Conferencia europea sobre fundamentos de la ingeniería de software (SIGSOFT/FSE '11) . Szeged, Hungría. pag. 354. doi :10.1145/2025113.2025162. ISBN9781450304436. S2CID 2413103.{{cite book}}: Mantenimiento CS1: falta el editor de la ubicación ( enlace )
^ Arisholm, Erik; Briand, Lionel C .; Føyen, Audun (agosto de 2004). "Medición de acoplamiento dinámico para software orientado a objetos". Transacciones IEEE sobre ingeniería de software . 30 (8). IEEE : 491–506. doi :10.1109/TSE.2004.41. hdl : 10852/9090 . S2CID 3074827.
Myers, Glenford J. (1974). Software confiable a través del diseño compuesto . Nueva York: Mason and Lipscomb Publishers.
Offutt, A. Jefferson; Harrold, María 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). La 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 profesionales certificados en arquitectura de software (CPSA): nivel básico" (PDF) . 3.01. Junta Internacional de Calificación de Arquitectura de Software eV (ISAQB). 2015-05-15 [2009]. Archivado desde el original (PDF) el 29 de marzo de 2017 . Consultado el 23 de junio de 2019 .[1] Archivado el 22 de febrero de 2016 en Wayback Machine.