Modularidad, cohesin y acoplamiento

La idea de que un buen diseo debe estar basado en una alta cohesin y un bajo
acoplamiento viene de los aos 1980. Fue uno de los primeros principios proclamados del
diseo estructurado, y pas luego a la orientacin a objetos.
Y a qu llamamos cohesin y acoplamiento? Tiene que ver con la modularidad, as que
empecemos por ella.

Modularidad
El aporte ms importante que hizo el diseo estructurado fue la idea de que, para resolver
un problema complejo de desarrollo de software, conviene separarlo en partes ms
pequeas, que se puedan disear, desarrollar, probar y modificar, de manera sencilla y lo
ms

independientemente

posible

del

resto

de

la

aplicacin.

Esas partes, cuando se quiere usar un nombre genrico, habitualmente se denominan

mdulos. De all que otro nombre para la programacin estructurada, luego cado en
desuso,

fue

programacin

modular.

El diseo estructurado, al plantear la separacin del sistema en mdulos, se bas en las

propias funciones del sistema. Esto es, los mdulos de la programacin estructurada seran
los procedimientos y funciones. Por lo tanto, al modularizar, lo que hacamos era tomar
nuestra solucin del problema, y separarla en partes. Detngase aqu y asegrese de que
entiende lo que le digo: en programacin estructurada modularizamos la solucin, el
cmo

del

desarrollo.

En el diseo orientado a objetos, en cambio, la modularizacin esencial se da a nivel de

clases, que no son funciones del sistema, sino (al menos en una primera aproximacin)
entidades del dominio del problema. Por lo tanto (y asegrese de entender tambin esto),
en el anlisis y diseo orientados a objetos, no modularizamos la solucin, sino primero el
problema (en el anlisis) y luego, partiendo de esas clases conceptuales, del dominio del
problema, modularizamos la solucin (diseo). Bertrand Meyer tiene una frase bastante
acertada al hablar de cmo obtener los mdulos de la orientacin a objetos: no pregunte
qu

hace

el

sistema,

sino

quin

se

lo

hace.

Por supuesto, la orientacin a objetos tambin tiene mdulos funcionales, que seran los
mtodos u operaciones de las clases, pero estos tienen una importancia menor respecto del
mdulo

por

excelencia,

que

es

la

clase.

Finalmente, en el diseo orientado a objetos, suele aparecer otro tipo de mdulo ms, el

paquete, de escasa relevancia semntica, pero importante para agrupar clases en el diseo
de aplicaciones medianas.

Cohesin
La cohesin tiene que ver con que cada mdulo del sistema se refiera a un nico proceso o
entidad. A mayor cohesin, mejor: el mdulo en cuestin ser ms sencillo de disear,
programar,

probar

mantener.

En el diseo estructurado, se logra alta cohesin cuando cada mdulo (funcin o

procedimiento) realiza una nica tarea trabajando sobre una sola estructura de datos. Un
test que se suele hacer a los mdulos funcionales para ver si son cohesivos es analizar que
puedan describirse con una oracin simple, con un solo verbo activo. Si hay ms de un
verbo activo en la descripcin del procedimiento o funcin, deberamos analizar su particin
en

ms

de

un

mdulo,

volver

hacer

el

test.

En el diseo orientado a objetos las cosas son ms complejas. Como dijimos, hay tres tipos
de mdulos: clases, mtodos y paquetes. Con los mtodos, podemos adoptar las mismas
definiciones y recetas que para los procedimientos y funciones del diseo estructurado.
Qu

ocurrira

con

los

otros

dos?

Las clases tendrn alta cohesin cuando se refieran a una nica entidad. Podemos
garantizar una fuerte cohesin disminuyendo al mnimo las responsabilidades de una clase:
si una clase tiene muchas responsabilidades probablemente haya que dividirla en dos o
ms. Y el test a aplicar sera ver si podemos describir a la clase con una oracin simple que
tenga un nico sustantivo en el sujeto. Si la clase estuviera representando alguna
operacin (por la aplicacin de algn patrn de diseo, por ejemplo), tambin habra que
tratar de sustantivarla y aplicarle la prueba para ver si es cohesiva. Una clase con alta
cohesin

suele

cumplir

el principio

de

nica

responsabilidad.

En los paquetes no es usual analizar cohesin. Sin embargo, nadie nos impide aplicarle los
mismos tests que a las clases. Sin embargo, lo crucial en los paquetes es el acoplamiento,
que vamos a ver ahora.

Acoplamiento
El acoplamiento mide el grado de relacionamiento de un mdulo con los dems. A menor
acoplamiento, mejor: el mdulo en cuestin ser ms sencillo de disear, programar,
probar

mantener.

En el diseo estructurado, se logra bajo acoplamiento reduciendo las interacciones entre

procedimientos y funciones, reduciendo la cantidad y complejidad de los parmetros y
disminuyendo al mnimo los parmetros por referencia y los efectos colaterales.

De nuevo, el diseo orientado a objetos nos complica las cosas con sus tres tipos de
mdulos. A los mtodos, como pas con la cohesin, podemos analizarlos con los mismos
criterios

que

los

mdulos

del

diseo

estructurado.

Una clase, en cambio, tendr bajo acoplamiento cuando tenga la menor dependencia
posible de otras clases. Esta dependencia significa que si bien puede haber muchas clases
que dependen de una debera haber pocas dependencias hacia otras clases desde una
sola. Las dependencias que importan son, de mayor a menor: generalizacin/herencia,
composicin, asociacin y dependencia dbil. Para visualizar estas cuestiones, los
diagramas

de

clases

son

herramientas

fundamentales.

Y los paquetes? Un paquete debe cumplir con estos mismos requisitos, en el sentido de
que debe tener vinculaciones mnimas con otros paquetes. Decimos que hay dependencia
entre paquetes cuando hay clases de un paquete que dependen de clases de otro paquete,
sea por herencia, asociacin o simple dependencia dbil. En este caso, podemos ayudarnos
con un diagrama de paquetes, que debido a que nos muestra dependencias entre conjuntos
de clases, nos sirve para eliminar problemas de acoplamiento.
Relacionado

Diseo orientado a objetos: refactorizando mtodos (Carlos Fontela)En "Calidad"

Estilos de codificacin (Carlos Fontela)En "Calidad"
Comentarios en el cdigo (Carlos Fontela)En "Calidad"
Etiquetas: Calidad, Diseo, Programacin, pruebas unitarias

This entry was posted on junio 23, 2009 at 11:33 am and is filed under Diseo,Programacin, Uncategorized. You
can follow any responses to this entry through theRSS 2.0 feed. You can leave a response, or trackback from your
own site.

3 comentarios to Modularidad, cohesin y acoplamiento

(Carlos Fontela)
1.

Diseo orientado a objetos: refactorizando mtodos (Carlos Fontela)

CyS
Ingeniera
de
Software Says:
junio 30, 2009 en 11:26 am | Responder

[...] CyS Ingeniera de Software El blog del rea de Ingeniera de Software de CyS informtica s.a.
Modularidad, cohesin y acoplamiento (Carlos Fontela) [...]

Cesar

2.

Emmanuel

Dominguez Says:

agosto 22, 2011 en 10:10 am | Responder

Modularidad: La idea es resolver un problema complejo separndolo en partes ms pequeas, que

se

puedan

disear,

desarrollar,

probar

modificar

de

manera

sencilla

lo

ms

independientemente posible. Al usar nombres genricos estamos en presencia de mdulos.

En el diseo orientado a objetos la modularizacin esencial se da a nivel de clases, que son
entidades del dominio del problema. Por lo tanto no modularizamos la solucin, sino primero el
problema (en el anlisis) y luego, partiendo de esas clases conceptuales, del dominio del problema,
modularizamos

la

solucin

(diseo).

La POO tiene mdulos funcionales, que seran los mtodos u operaciones de las clases y tambin
paquetes que son importantes para agrupar clases en el diseo de aplicaciones medianas.
Cohesin: Cada mdulo del sistema debe referirse a un nico proceso o entidad. A mayor cohesin
el

mdulo

en

cuestin

ser

ms

sencillo

de

disear,

programar,

probar

mantener.

Con los mtodos se logra alta cohesin cuando cada mdulo realiza una nica tarea trabajando
sobre una sola estructura de datos. Las clases tendrn alta cohesin cuando se refieran a una
nica

entidad.

Podemos

responsabilidades

garantizar

una

fuerte

de

cohesin

disminuyendo
una

al

mnimo

las

clase.

En los paquetes no es usual analizar cohesin, pero podemos aplicarle los mismos tests que a las
clases. Lo crucial en los paquetes es el acoplamiento.
Acoplamiento: mide el grado de relacionamiento de un mdulo con los dems. Para tener un mejor
acoplamiento debemos lograr una independencia para que la relacin entre los metodos, clases y
paquetes sea minima.