# data[].attributes.headline
A mayor cohesión de los módulos individuales en el sistema, menor será el acoplamiento

# data[].attributes.subject
A mayor cohesión de los módulos individuales en el sistema, menor será el acoplamiento

# data[].attributes.body
No son medidas independientes, sino correlacionadas en la práctica.

# data[].attributes.body
Atributo de un módulo individual y representa el grado en el que los componentes dentro del módulo están relacionados.

Se focaliza en conocer porqué los elementos de un módulo están juntos en ese módulo.

# data[].attributes.body
Cada módulo del sistema se refiere a un único proceso o entidad. A mayor cohesión, mejor: el módulo en cuestión será más sencillo de diseñar, programar, probar y mantener.

# data[].attributes.body
Atributo de un par de módulos y representa el grado de interconexión entre los módulos.

# data[].attributes.body
Entre más dependencias tenga una parte del software esta se vuelve más propensa a cambiar puesto que los cambios en las partes en las que depende pueden provocar cambios al modificar las entradas o salidas.

# data[].attributes.body
Mide el grado de relacionamiento de un módulo con los demás. A menor acoplamiento, mejor: el módulo en cuestión será más sencillo de diseñar, programar, probar y mantener.

# data[].attributes.body
El acoplamiento caracteriza su interdependencia con otros subsistemas.

La cohesión caracteriza sus interdependencias internas.

# data[].attributes.body
Estás creando un chatbot, un programa que, usando las API’s de los aplicaciones de comunicación te permite interactuar con tus usuarios en forma de chat, en lugares como WhatsApp, Messenger o Slack. El sistema tiene como requerimiento que la lógica de conversación sea fácil de reemplazar y mantener y que funcione independientemente del canal.

# data[].attributes.body
Una aplicación de e-commerce, que consiste de un catálogo, un carrito de compras y la parte del pago. Estos tres elementos pueden estar muy acoplados entre sí, en el sentido de que cualquier cambio en el catálogo afecta al carrito de compras y al pago, o al revés. Si puedes cambiar cualquiera de los tres módulos sin tener que tocar los otros, hay un bajo acoplamiento.

# data[].attributes.body
Facilita la comprensión y el mantenimiento del código.

Componentes cohesivos tienden a ser más reutilizables.

Ayuda a reducir los efectos secundarios involuntarios.

# data[].attributes.body
Mayor complejidad en el diseño y la implementación si no se gestiona adecuadamente.

Excesiva cohesión puede dificultar la adaptación de cambios en los requisitos.

# data[].attributes.body
Bajo acoplamiento facilita la modificación de uno sin afectar a los demás.

Menor acoplamiento hace que el sistema sea más fácil de mantener.

Con bajo acoplamiento es más escalable, los módulos pueden ser modificados sin afectar todo el conjunto.

# data[].attributes.body
E. B. Allen, T. M. Khoshgoftaar, Y. Chen. (2001). Measuring coupling and cohesion of software modules: an information-theory approach. Proceedings Seventh International Software Metrics Symposium, London, UK, pp. 124-134.

# data[].attributes.body
Bajo acoplamiento puede llevar a una comunicación ineficiente entre módulos.

Reducir el acoplamiento en exceso puede resultar en una complejidad global del sistema.

# data[].attributes.body
Farley, D. (2022). Modern software engineering: Doing what works to build better software faster. Addison Wesley.

# data[].attributes.body
Funcional. Lo tienen sobre todo las operaciones; este nivel de cohesión ocurre cuando un componente realiza un cálculo y luego devuelve el resultado.

De capa. Lo tienen los paquetes, componentes y clases; ocurre cuando una capa más alta accede a los servicios de otra más baja, pero ésta no tiene acceso a las superiores.

De comunicación. Todas las operaciones que acceden a los mismos datos se definen dentro de una clase. En general, tales clases se centran únicamente en los datos en cuestión, acceden a ellos y los guardan.

# data[].attributes.body
La cohesión y el acoplamiento son principios de diseño que buscan optimizar la estructura y la relación entre los componentes de un sistema.

# data[].attributes.body
Roldan, R. A. (1986). Ingeniería de software. Universidad Autónoma de Nuevo León.

# data[].attributes.body
Al construir sistemas a partir de piezas discretas mas pequeñas, serán más comprensibles y comprobables. Se necestian técnicas que permitan "separar aún más las cosas no relacionadas", pero también la necesidad de "acercar las cosas relacionadas".

# data[].attributes.body
Pagade, G. (2022). Difference Between Cohesion and Coupling. Baeldung.

# data[].attributes.body
Woodward, M.R. (1993). Difficulties using cohesion and coupling as quality indicators. Software Qual J 2, 109–127.

# data[].attributes.attachment_link.readable_text
Abstract

The benefits of decomposing a software system at the design stage into a collection of modules have long been recognized, especially if the activities within each module contribute to performing one single goal, and also if the modules have, as far as possible, minimal interaction with each other. In the so-called structured design approach, qualitative scales, or spectra, for cohesion and coupling capture these notions a little more rigorously and provide a means of assessing the quality of a design.

In practice the ideas of cohesion and coupling are difficult to apply. A case study with a medium-sized Fortran program is described, in which 163 students were asked to categorize the cohesion and coupling of its modules. The subjective nature of the cohesion and coupling scales is exemplified by the diversity of opinions that resulted. The evidence of other empirical studies also illustrates the problem, since researchers have attempted to assess cohesion and coupling in a variety of different ways, often with quite primitive levels of discrimination. The fundamental difficulty is that there are no agreed objective measures for the quantities, nor the means to obtain any measures. Some proposals are reviewed, as well as recent developments of the ideas to cope with abstract data types.

References

Embley, D.W. and Woodfield, S.N. (1988) Assessing the quality of abstract data types written in Ada, in Proceedings of the Tenth International Conference on Software Engineering, IEEE, Singapore, 11-15 April 1988, pp. 144-53.

Emerson, T.J. (1984) A discriminant metric for module cohesion, in Proceedings of the Seventh International Conference on Software Engineering, IEEE, Orlando, USA, 26-29 March 1984, pp. 294-303.

Myers, G.J. (1973) Composite Design-The Design of Modular Programs. IBM Technical Report, TR 00.2406, Jan. 1973, Poughkeepsie Laboratory.

Ott, L.M. and Thuss, J.T. (1989) The relationship between slices and module cohesion, in Proceedings of the Eleventh International Conference on Software Engineering, IEEE, Pittsburgh, USA, 15-18 May 1989, pp. 198-204.

Shepperd, M. (1992) Algebraic models and metric validation, in Formal Aspects of Measurement ( Proceedings of the BCS-FACS Workshop on Formal Aspects of Measurement, South Bank University, London, 5 May 1991), Denvir, T., Herman, R. and Whitty, R.W. (eds) (British Computer Society, Springer-Verlag, London) pp. 157-75.

Google Scholar

Download references

Author information

Authors and Affiliations

Department of Computer Science, University of Liverpool, P.O. Box 147, L69 3BX, Liverpool, UK

M. R. Woodward

About this article

Cite this article

Woodward, M.R. Difficulties using cohesion and coupling as quality indicators. Software Qual J 2, 109-127 (1993). https://doi.org/10.1007/BF00590439
Download citation

Share this article

Anyone you share the following link with will be able to read this content:

Get shareable link

Provided by the Springer Nature SharedIt content-sharing initiative

Keywords

# data[].attributes.attachment_link.title
Difficulties using cohesion and coupling as quality indicators - Software Quality Journal

# data[].attributes.attachment_link.description
The benefits of decomposing a software system at the design stage into a collection of modules have long been recognized, especially if the activities within each module contribute to performing one single goal, and also if the modules have, as far as possible, minimal interaction with each other.

# data[].attributes.body
Pressman, R. (2005). Ingeniería de software: Un enfoque práctico (7ma ed.).

# data[].attributes.body
Daniel P., Luís B. (2015). Aplicaciones Modulares en JavaScript. TIA Tecnología, investigación y academia, vol. 3, no. 1, pp. 17.

# data[].attributes.body
Un diseño bien cohesionado y con bajo acoplamiento es más fácil de entender, mantener, modificar y escalar, lo que contribuye a la calidad y la eficiencia del desarrollo de software.

# data[].attributes.body
Acoplamiento de contenido. Las instrucciones de dos módulos se superponen de modo que comparten físicamente alguna sección de código.

Acoplamiento común. Dos módulos están vinculados en virtud del acceso compartido a datos globales.

Acoplamiento externo. Un módulo invoca a otro y el módulo subordinado hace referencia a un símbolo declarado externamente en el módulo que llama.

Acoplamiento de control. Un módulo invoca a otro y pasa uno o más parámetros que afectan el flujo de control en el módulo subordinado.

Acoplamiento Stamp. Un módulo invoca a otro y la información se pasa al módulo subordinado como una gran estructura de datos, parte de la cual no será necesaria para el módulo subordinado.

# data[].attributes.body
Patricio, H. (2021). Entendiendo la cohesión y el acoplamiento en el software. The Dojo MX Blog.

# data[].attributes.attachment_link.readable_text
Siempre se dice que una buena base de código tiene alta cohesión, pero bajo acoplamiento. ¿Cómo se puede entender esto? ¿Cómo podemos llevar este principio a la práctica?

En este artículo vamos a definir cada uno de esos términos de manera sencilla, y con ejemplos de cómo llegar a la aplicación real de estos términos.

Un poco de historia

Estos dos conceptos y otros relacionados fueron desarrollados por Larry Constantine en la década de los 60's y publicados en los años siguientes, junto con el nacimiento del diseño estructurado de sistemas. Estos conceptos han sido aceptados y han sido objeto de muchos estudios sobre cómo afectan a la calidad del software realmente. Lo que se ha descubierto es que efectivamente, las dependencias infinitas (alto acoplamiento y baja cohesión) crean problemas que son casi imposobles de resolver en las bases de código y es cuando terminamos diciendo: "Es más fácil hacerlo de nuevo."

Ahora sí, hablemos de lo que quisiéramos lograr con nuestro software, para no terminar queriéndolo rehacer de nuevo en poco tiempo.

Cohesión

La cohesión de los módulos se refiere al grado en que los componentes de cierto módulo se relacionan entre sí. Es decir, un módulo tiene alta cohesión si todos, o la mayoría de sus componentes trabajan para un mismo objetivo y no para cosas dispares o no relacionadas.

Una buena cohesión permitirá que el componente utilice menos otros módulos externos, ya que la mayoría de lo que requiere para realizar su trabajo está en el mismo módulo.

Para lograr esto, normalmente tienes que reducir las tareas de las que el módulo es responsable al menor grado posible, tratando de seguir el principio de responsabilidad única.

Pongamos un ejemplo: imagina que estás creando un chatbot, un programa que, usando las API's de los aplicaciones de comunicación te permite interactuar con tus usuarios en forma de chat, en lugares como WhatsApp, Messenger o Slack. El sistema tiene como requerimiento que la lógica de conversación sea fácil de reemplazar y mantener y que funcione independientemente del canal.

Para implementar este sistema los rompemos por lo menos en tres módulos: el manejo de usuarios, la lógica de conversación y la conexión son los canales de comunicación.

Una buena cohesión se refiere a que, por ejemplo, la lógica de conversación y todo lo necesario para decidir cómo conversar con un usuario exista dentro de este mismo módulo. Así, cuando tengas que actualizarla no tienes que tocar todo el sistema o muchas partes del código. Esto mismo aplicaría para los otros módulos, imagínate que tienes que agregar un canal nuevo, por ejemplo, Telegram. Tu módulo de conexión a canales debería tener todo lo necesario para que no tengas que modificar ni el módulo de usuarios, ni el de la lógica de conversación.

Una forma efectiva de crear módulos cohesivos es mediante agrupar todas las partes que tienen que ver con el mismo tema abstracción o decisión en el mismo módulo o clase. Esto casi nunca se puede lograr perfectamente, pero es una buena meta que te ahorrará dolores de cabeza.

Acoplamiento

El acoplamiento consiste en el grado de dependencia de las diferentes partes de un sistema entre ellas. La pregunta clave para entender el acoplamiento es: ¿Cuánto se necesita saber de un módulo para entender otro módulo?

Mientras más necesites saber de A para entender B, más A relacionados, o acoplados están.

Por ejemplo, imagina una aplicación de e-commerce, que consiste de un catálogo, un carrito de compras y la parte del pago. Estos tres elementos pueden estar muy acoplados entre sí, en el sentido de que cualquier cambio en el catálogo afecta al carrito de compras y al pago, o al revés. Si puedes cambiar cualquiera de los tres módulos sin tener que tocar los otros, hay un bajo acoplamiento.

El acoplamiento ideal sería cero, pero como te imaginarás esto es imposible.

Los módulos pueden depender entre ellos de diferentes formas, tanto conceptualmente como en implementación. Constantine menciona que los siguientes cuatro factores pueden afectar el grado de acoplamiento de los módulos:

1. Tipo de conexión entre los módulos. ¿Escriben a las mismas variables globales? ¿Uno usa al otro? ¿Uno es la especialización de otro?

2. Complejidad de la interfaz: ¿Qué tan intrincada es la conexión entre los módulos?

3. Tipo de información que pasa entre la conexión: ¿se pasan grandes estructuras de datos que procesan de manera secuencial? O, ¿un módulo modifica la forma de trabajar de otro?

4. Tiempo en el que sucede la conexión: ¿depende uno de que el otro corra para poder ejecutarse?

Tener en cuenta estos factores puede ayudar a reducir el acoplamiento de los módulos.

Relación entre cohesión y acoplamiento

Constantine menciona que mientras más cohesión tengan los módulos, menos acoplamiento tendrán entre ellos. Esto suena lógico porque mientras más "autocontenido" sea un módulo (más cohesión) menos va a necesitar de otros para poder funcionar.

"A mayor cohesión de los módulos individuales en el sistema, menor será el acoplamiento" - Structured Design by Yourdon and Constantine

Como podrás ver, no son medidas independientes, sino correlacionadas en la práctica.

Cómo lograr alta cohesión y bajo acoplamiento

La principal forma de lograr esta buena estructura es dedicando tiempo al diseño del software,prestando especial atención a la forma en la que se modulariza el sistema, es decir, la forma en la que se divide el problemas en otros más pequeños.

Constantine y Yourdon afirman que la única forma de lograr esto es con práctica, práctica y más práctica.

Conclusiones

El principio de "Alta cohesión y bajo acoplamiento" sin duda es útil para que nuestro software sea más claro, más fácil de mantener y de cambiar. No hay manera de aprender cómo dividir el sistema en módulos si no es mediante la práctica de diseño e implementación de sistemas reales. Así que, ya sabes, manos a la obra.

# data[].attributes.attachment_link.title
Entendiendo la cohesión y el acoplamiento en el software

# data[].attributes.attachment_link.description
En este artículo intentamos establecer de manera sencilla qué son la cohesión, el acomplamiento y cómo afectan al diseño de tu software y el código

# data[].attributes.body
Ana Georgina Rejón Osorio

Brayan Gabriel Fernández Tlapa

Ángel Jonathan Puch Hernández

Cruz Antonio Molina Montero