Acoplamiento (programación informática)


De Wikipedia, la enciclopedia libre
  (Redirigido desde la dependencia de software )
Saltar a navegación Saltar a búsqueda

En la ingeniería de software , el acoplamiento es el grado de interdependencia entre los 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]

Acoplamiento y cohesión

El acoplamiento suele contrastarse con la cohesión . El bajo acoplamiento a menudo se correlaciona con una alta cohesión y viceversa. A menudo se piensa que el 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, apoya 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 "buenas" prácticas de programación que redujeron los costos de mantenimiento y modificación. El diseño estructurado, incluida la cohesión y el acoplamiento, se publicaron en el artículo Stevens, Myers & Constantine (1974) [3] y el libro Yourdon & Constantine (1979), [4] y este último se convirtió 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 "apretado" 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 usa el código de otro módulo, por ejemplo, una rama. Esto viola la ocultación 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 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 una bandera 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 necesita solo un campo).
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 ocurre 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 subclase
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 solo porque ocurren al mismo tiempo.

En un trabajo reciente, se han investigado varios otros conceptos de acoplamiento y se han utilizado como indicadores para diferentes principios de modularización utilizados en la práctica. [5]

Acoplamiento dinámico

El objetivo de 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 enlace dinámico o herencia. [6] En el intento de solucionar este problema, se han tenido en cuenta medidas de acoplamiento dinámico.

Acoplamiento semántico

Este tipo 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 acoplamiento lógico (o el acoplamiento evolutivo o el acoplamiento de cambios) explota el historial de versiones de un sistema de software para encontrar patrones de cambio entre módulos o clases: por ejemplo, entidades que probablemente se cambiarán juntas o secuencias de cambios (un cambio en una clase A siempre es seguido de un cambio en una clase B).

Desventajas del acoplamiento apretado

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

  1. Un cambio en un módulo generalmente fuerza un efecto dominó de los cambios en otros módulos.
  2. El ensamblaje de módulos puede requerir más esfuerzo y / o tiempo debido a la mayor dependencia entre módulos.
  3. 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 débil o estrecha, el rendimiento de un sistema a menudo se reduce por la creación, transmisión, traducción (p. Ej., Clasificación) de mensajes y parámetros, e interpretación del mensaje (que puede ser una referencia a una cadena, matriz o estructura de datos), que requieren 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 del tiempo de ejecución, se debe minimizar la longitud del mensaje y se debe maximizar el significado del mensaje.

Rendimiento y gastos generales 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 transmitir y recibir. 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 del tiempo de ejecución, se debe minimizar la longitud del mensaje y maximizar el significado del mensaje.
Rendimiento y gastos generales de traducción de mensajes
Los protocolos de mensajes y los mensajes mismos a menudo contienen información adicional (es decir, información de 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 del tiempo de ejecución, la forma y el contenido del mensaje deben reducirse y perfeccionarse para maximizar su significado y reducir la traducción.
Rendimiento y gastos generales de 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 los significados previstos. 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 se refiere a (es de tipo) B .
  • Un llamamiento a los servicios de un objeto 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 implementos) 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 (ver Ocultar información ).

Los 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 lenguajes.

Acoplamiento versus cohesión

Acoplamiento y cohesión son términos que ocurren juntos con mucha frecuencia. El acoplamiento se refiere a las interdependencias entre módulos, mientras que la cohesión describe cuán relacionadas están las funciones dentro de un solo módulo. La 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 se agranda.

Acoplamiento de módulo

Coupling in Software Engineering [7] describe una versión de métricas asociadas con este concepto.

Para acoplamiento de 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 medioambiental:

  • 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)aumenta el valor cuanto más acoplado está el módulo. Este número varía de aproximadamente 0,67 (acoplamiento bajo) a 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 un abanico de entrada de 3 y un abanico de salida de 4,

Ver también

  • Cohesión (informática)
  • Connascence (ciencias de la computación)
  • Acoplamiento (física)
  • Eliminación de código muerto
  • Infierno de la dependencia
  • Acoplamiento eferente
  • Inversión de control
  • Lista de términos de programación orientada a objetos
  • Bajo acoplamiento
  • Hacer (software)
  • Análisis de código estático

Referencias

  1. ^ ISO / IEC / IEEE 24765: 2010 Ingeniería de software y sistemas - Vocabulario
  2. ^ ISO / IEC TR 19759: 2005, Ingeniería de software - Guía del cuerpo de conocimientos de ingeniería de software (SWEBOK)
  3. ^ Stevens, Wayne P .; Myers, Glenford J .; Constantine, Larry LeRoy (junio de 1974). "Diseño estructurado". Revista de sistemas de IBM . 13 (2): 115-139. doi : 10.1147 / sj.132.0115 .
  4. ^ 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. ISBN 0-13-854471-9 . 
  5. ^ Beck, Fabián; Diehl, Stephan (septiembre de 2011). "Sobre la congruencia de modularidad y acoplamiento de código". In Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering (SIGSOFT / FSE '11) . Szeged, Hungría. doi : 10.1145 / 2025113.2025162 .
  6. ^ 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 . IEEE . 30 (8): 491–506. doi : 10.1109 / TSE.2004.41 . hdl : 10852/9090 .
  7. ^ Pressman, Roger S. (1982). Ingeniería de software - Enfoque de un practicante (4 ed.). ISBN 0-07-052182-4.

Otras lecturas

  • Myers, Glenford J. (1974). Software confiable a través del 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 el acoplamiento de módulos". Revista de sistemas y software . 20 (3): 295-308.
  • 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). 15 de mayo de 2015 [2009] . Consultado el 23 de junio de 2019 . [1]
Obtenido de " https://en.wikipedia.org/w/index.php?title=Coupling_(computer_programming)&oldid=1036694630 "