T.C. & A.M.

Realizar un modelo de desarrollo con las Tcnicas de Cohesin (T.C.) y

Acoplamiento de Mdulos (A.M.). Enva tu actividad a travs de este medio.
Acoplamiento de Mdulos
1. Por ejemplo, estos dos mtodos (en C#), estn totalmente desacoplados. Ninguno de ellos
necesita al otro para hacer su trabajo.

2. Por ejemplo, estos dos mtodos tienen un acoplamiento normal.

metodo1 invoca a metodo2, y no puede realizar su funcin sin l. Decimos que metodo1 tiene un
acoplamiento normal con metodo2. Al reves no es cierto. mtodo2 no est acoplado con respecto
a metodo1, ya que metodo2 puede realizar su trabajo independientemente de metodo1.
3. Por ejemplo, observa estos dos mtodos de la misma clase:

Metodo1 y metodo2 estn acoplados por los datos, ya que ambos comparten el mismo dato local
para trabajar. El acoplamiento de datos es comn entre los mtodos de una clase, producido por
la necesidad de acceder a las variables de instancia. No obstante, en muchos casos, es evitable. Si
podermos hacer lo mismo sin acoplar los mtodos por los datos, mejor.

4. En este ejemplo, metodo1 controla la ejecucin de metodo2, mediante un parmetro. Con el

parmetro c, metodo1 consigue hacer que mtodo2 multiplique o sume a y b. Ojo... no se trata de
que metodo1 vare o configure la forma en la que trabaja metodo2 en algn aspecto, sino que es
metodo1 el que decide cmo debe comportarse metodo2 en su prctica totalidad.

Esto es fcilmente evitable cayendo en un simple acoplamiento normal, de esta manera:

5. Por ejemplo, aqu a, b y resultado se utilizan para que metodo1 y multiplicar se comuniquen...
para eso no hacen falta esas variables... el mecanismo adecuado es el paso de parmetros, y un
acoplamiento normal.

Cohesin
La cohesin tiene que ver con la forma en la que agrupamos unidades de software
en una unidad mayor. Por ejemplo, la forma en la que agrupamos funciones en
una librera, o la forma en la que agrupamos mtodos en una clase, o la forma en
la que agrupamos clases en una librera, etc...
Se suele decir que cuanto ms cohesionados estn los elementos agrupados,
mejor. El criterio por el cual se agrupan es la cohesin.
Veremos los distintos tipos de cohesin, de la que se considera mayor cohesin a
la que se considera menor.
Nuevamente, los nombres no son demasiado importantes, basta saber que a la
hora de decidir por qu criterio agrupar, unos suelen dar mejores resultados que
otros desde el punto de vista de la modularidad.
La cohesin no tiene tanto impacto sobre la modularidad como el acoplamiento.
Es decir, un gran acoplamiento puede ser muy malo a la hora de corregir errores,
integrar partes, hacer mantenimientos... Sin embargo, una cohesin baja puede
ser incmoda, pero no suele plantear grandes problemas. Aunque esto, no es
motivo para descuidarla.

CONCLUSIN
En resumen, mantener el acoplamiento lo ms bajo posible y la cohesin lo ms
alta posible suele ser el objetivo de todo arquitecto, diseador o programador.
Tener unos buenos criterios para agrupar unidades de software (alta cohesin), y
mantener esas unidades lo ms independientes posible (bajo acoplamiento)
garantiza la modularidad, facilitando la reutilizacin del software y gran parte de
las tareas del desarrollo del software.