Hispanopedia WikiEn informática y diseño de sistemas , un sistema débilmente acoplado es uno
- en el que los componentes están débilmente asociados (tienen relaciones que se pueden romper) entre sí, y por lo tanto, los cambios en un componente afectan mínimamente la existencia o el rendimiento de otro componente.
- en el que cada uno de sus componentes tiene, o utiliza, poco o ningún conocimiento de las definiciones de otros componentes separados. Las subáreas incluyen el acoplamiento de clases , interfaces, datos y servicios. [ 1 ] El acoplamiento débil es lo opuesto al acoplamiento fuerte.
Ventajas y desventajas
En un sistema débilmente acoplado, los componentes pueden reemplazarse por implementaciones alternativas que proporcionen los mismos servicios. Además, los componentes de un sistema débilmente acoplado están menos limitados a la misma plataforma, lenguaje , sistema operativo o entorno de compilación.
Si los sistemas están desacoplados en el tiempo, resulta difícil garantizar la integridad transaccional; se requieren protocolos de coordinación adicionales. La replicación de datos entre diferentes sistemas proporciona un acoplamiento flexible (en cuanto a disponibilidad), pero genera problemas para mantener la coherencia ( sincronización de datos ).
En integración
El acoplamiento flexible en el diseño de sistemas distribuidos más amplios se logra mediante el uso de transacciones, colas proporcionadas por middleware orientado a mensajes y estándares de interoperabilidad. [ 2 ]
Cuatro tipos de autonomía que promueven el acoplamiento flexible son: autonomía de referencia , autonomía de tiempo , autonomía de formato y autonomía de plataforma . [ 3 ]
El acoplamiento flexible es un principio arquitectónico y un objetivo de diseño en las arquitecturas orientadas a servicios . Once formas de acoplamiento flexible y sus contrapartes de acoplamiento rígido se enumeran en: [ 4 ]
- conexiones físicas a través de un mediador,
- estilo de comunicación asíncrona ,
- tipos comunes simples solo en el modelo de datos ,
- sistema de tipos débiles,
- mensajes centrados en datos y autónomos,
- control distribuido de la lógica del proceso,
- vinculación dinámica (de consumidores y proveedores de servicios),
- independencia de la plataforma,
- compensación a nivel empresarial en lugar de transacciones a nivel de sistema,
- despliegue en diferentes momentos,
- actualizaciones implícitas en el control de versiones.
El middleware Enterprise Service Bus (ESB) se inventó para lograr un acoplamiento flexible en múltiples dimensiones. [ 5 ] Sin embargo, los ESB sobrediseñados y mal ubicados también pueden tener el efecto contrario y crear un acoplamiento estrecho no deseado y un punto crítico arquitectónico central.
La arquitectura orientada a eventos también tiene como objetivo promover un acoplamiento flexible. [ 6 ]
Métodos para disminuir el acoplamiento
El acoplamiento flexible de las interfaces se puede mejorar publicando los datos en un formato estándar (como XML o JSON ).
El acoplamiento flexible entre los componentes del programa se puede mejorar utilizando tipos de datos estándar en los parámetros. Para pasar tipos de datos u objetos personalizados, ambos componentes deben conocer la definición de datos personalizada.
El acoplamiento flexible de servicios se puede mejorar reduciendo la información que se pasa a un servicio a los datos clave. Por ejemplo, un servicio que envía una carta es más reutilizable cuando solo se pasa el identificador del cliente y la dirección del cliente se obtiene dentro del servicio. Esto desacopla los servicios, ya que no es necesario llamarlos en un orden específico (por ejemplo, GetCustomerAddress, SendLetter).
En programación
El acoplamiento se refiere al grado de conocimiento directo que un componente tiene de otro. En informática, el acoplamiento flexible se interpreta como encapsulación frente a no encapsulación.
Un ejemplo de acoplamiento fuerte se da cuando una clase dependiente contiene un puntero directo a una clase concreta que proporciona el comportamiento requerido. La dependencia no se puede sustituir, ni su "firma" cambiar, sin modificar la clase dependiente. El acoplamiento débil se produce cuando la clase dependiente contiene un puntero únicamente a una interfaz, que puede ser implementada por una o varias clases concretas. Esto se conoce como inversión de dependencia . La dependencia de la clase dependiente se establece con un "contrato" especificado por la interfaz; una lista definida de métodos y/o propiedades que las clases que la implementan deben proporcionar. Cualquier clase que implemente la interfaz puede, por lo tanto, satisfacer la dependencia de una clase dependiente sin tener que modificarla. Esto permite la extensibilidad en el diseño de software. Se puede escribir una nueva clase que implemente una interfaz para reemplazar una dependencia actual en algunas o todas las situaciones, sin modificar la clase dependiente; las clases nueva y antigua se pueden intercambiar libremente. El acoplamiento fuerte no permite esto.
Este es un diagrama UML que ilustra un ejemplo de acoplamiento flexible entre una clase dependiente y un conjunto de clases concretas, que proporcionan el comportamiento requerido:
A modo de comparación, este diagrama ilustra el diseño alternativo con un fuerte acoplamiento entre la clase dependiente y un proveedor:
Otras formas
Los lenguajes de programación que conciben las funciones como módulo central (véase Programación funcional ) o como objetos ofrecen excelentes ejemplos de programación débilmente acoplada. Los lenguajes funcionales presentan patrones de continuaciones , cierres o generadores. Clojure y Lisp son ejemplos de lenguajes de programación funcional. Los lenguajes orientados a objetos, como Smalltalk y Ruby, utilizan bloques de código, mientras que Eiffel emplea agentes. La idea básica consiste en objetivar (encapsular como objeto) una función independientemente de cualquier otro concepto que la englobe (por ejemplo, desacoplar una función de objeto de cualquier conocimiento directo del objeto que la engloba). Véase Función de primera clase para comprender mejor las funciones como objetos, que se considera una forma de función de primera clase.
Por ejemplo, en un lenguaje orientado a objetos, cuando se hace referencia a una función de un objeto como si fuera otro objeto (liberando así el objeto de su contenedor), la nueva función puede pasarse, almacenarse y llamarse posteriormente. Los objetos receptores (a quienes se les proporcionan estas funciones) pueden ejecutar (llamar) la función contenida de forma segura cuando lo deseen, sin necesidad de conocer directamente el objeto de su contenedor. De esta manera, un programa puede ejecutar cadenas o grupos de funciones, sin depender de ninguna referencia directa al objeto de su contenedor.
Los números de teléfono son una analogía excelente y pueden ilustrar fácilmente el grado de esta disociación.
Por ejemplo, una entidad proporciona a otra un número de teléfono para realizar un trabajo específico. Al llamar a ese número, la entidad que llama está diciendo, en efecto: "Por favor, hagan este trabajo por mí". El desacoplamiento o la falta de conexión resulta evidente de inmediato. La entidad que recibe el número puede desconocer su origen (por ejemplo, quién lo proporcionó). Por otro lado, quien llama desconoce a quién llama, dónde se encuentra y cómo opera internamente la entidad receptora.
Llevando el ejemplo un paso más allá, quien llama podría decirle a quien recibe la llamada: "Por favor, haz este trabajo por mí. Llámame a este número cuando termines". El número que se le ofrece al receptor se denomina "llamada de retorno". Una vez más, se evidencia la naturaleza desacoplada de este objeto funcional. Quien recibe la llamada de retorno desconoce a quién o qué se está llamando. Solo sabe que puede realizar la llamada y decide cuándo hacerlo. En realidad, la llamada de retorno puede incluso no dirigirse a quien la proporcionó inicialmente. Este nivel de indirección es lo que convierte a los objetos funcionales en una excelente tecnología para lograr programas con bajo acoplamiento.
La comunicación entre componentes débilmente acoplados puede basarse en una variedad de mecanismos, como el estilo de comunicación asíncrona mencionado o el estilo de paso de mensajes síncrono [ 7 ].
Acoplamiento de elementos de datos de medición
El grado de acoplamiento débil se puede medir observando la cantidad de cambios en los elementos de datos que podrían ocurrir en los sistemas emisores o receptores y determinando si las computadoras continuarían comunicándose correctamente. Estos cambios incluyen elementos como:
- Agregar nuevos elementos de datos a los mensajes
- Cambiar el orden de los elementos de datos
- Cambiar los nombres de los elementos de datos
- Modificación de las estructuras de los elementos de datos
- Omisión de elementos de datos
Véase también
Referencias
- ↑ Acoplamiento flexible: Las piezas que faltan en los servicios web , por Doug Kaye
- ↑ Pautasso C., Wilde E., ¿ Por qué la Web está débilmente acoplada? Archivado el 12 de octubre de 2021 en Wayback Machine , Actas de WWW 2009
- ↑ F. Leymann Acoplamiento suelto e implicaciones arquitectónicas Archivado el 2 de octubre de 2016 en Wayback Machine , ponencia principal de ESOCC 2016
- ^ N. Josuttis, SOA en la práctica. O'Reilly, 2007, ISBN 978-0-596-52955-0.
- ↑ M. Keen et al, Patrones: Implementación de una SOA mediante un bus de servicios empresariales , IBM, 2004
- ↑ Cómo EDA extiende SOA y por qué es importante Jack van Hoof
- ↑ Mielle, Grégoire. "Patrones de microservicios: comunicación síncrona vs. asíncrona" . Patrones de microservicios: comunicación síncrona vs. asíncrona . greeeg . Consultado el 18 de febrero de 2022 .
- Integración de aplicaciones empresariales
- Orientado a servicios (informática empresarial)
- Principios de programación
- Calidad del software