Acoplamiento y cohesin sbado, 11 de noviembre de 2006 Todo desarrollador de software debe tener en cuenta que se obtienen tantos ms beneficios

cuanto ms alta es la cohesin en una unidad de software y ms bajo es el acoplamiento entre las unidades. Esta mxima se debe aplicar tanto en el diseo, la arquitectura y la codificacin. A menudo escuchamos problemas relacionados con dos partes de software que estn fuertemente acopladas, y escuchamos trminos como desacoplar. Tanto el acoplamiento como la cohesin son trminos un tanto abstractos y difciles de medir. Hace algunos aos, cuando slo exista la programacin imperativa, las cosas eran un tanto ms concreta. En la actualidad, con varios paradigmas en marcha (programacin orientada a objetos, a aspectos, extreme programming, etc.. ) y mltiples lenguajes y plataformas, los trminos de acoplamiento y cohesin se hacen ms difciles de concretar, pero siguien teniendo aplicacin, aunque su significado sea ms abstracto.

ACOPLAMIENTO Empezaremos por el acoplamiento. El trmino "acoplamiento" hace alusin al grado de dependencia que tienen dos unidades de software. Tiempo atrs se utilizaba la palabra "mdulo" o "subrutina" en lugar de unidad de sofware. Hoy en da, en opinin del que escribe, la palabra "mdulo" es completamente inadecuada y obsoleta. Mejor utilizaremos "unidad de software", que es un concepto ms amplio. Bien... Qu es una unidad de software? Pues simplemente cualquier pieza de software que realice algn cometido. Por ejemplo: una funcin, un mtodo, una clase, una librera, una aplicacin, un componente, etc... Si hablamos de funciones, el acoplamiento nos da una idea de lo dependientes que son dos funciones entre s. Es decir, en qu grado una funcin puede hacer su trabajo sin la otra. Si hablamos de libreras, el acoplamiento nos dar una idea de en qu medida el contenido de una librera puede hacer su trabajo sin la otra. Cuando dos unidades de software son absolutamente independientes (cada una puede hacer su trabajo sin contar para nada con la otra), encontramos el grado ms bajo de acoplamiento, y decimos que ambas unidades estn totalmente desacopladas. Nuestro objetivo al programar o disear debe ser el de tener un acoplamiento lo ms bajo posible entre dos unidades de software cualesquiera. Por supuesto, es imposible lograr un desacoplamiento total entre las unidades. Sin embargo, manteniendo lo ms bajo posible el acoplamiento lograremos que las distintas "piezas" de nuestro software funcionen sin depender demasiado unas de otras. Eso redunda en una mejora considerable en la deteccin y correccin de errores, en una mayor facilidad de mantenimiento y sobre todo, en la reutilizacin de esas "piezas" de software.

Pues bien... hay varios tipos de acoplamiento... les pegaremos un breve repaso, empezando por los ms deseables y terminando por los que deberamos evitar. Segn quin nos hable del acoplamiento, veremos que se utilizan unos trminos u otros. Es lo de menos. Lo importante es mantenerlo bajo, independientemente de que le pongamos un nombre u otro a cada tipo de acoplamiento. I) Unidades completamente desacopladas Ya lo hemos comentado, dos unidades estn completamente desacopladas cuando hacen su trabajo de manera totalmente independiente. Esto nos permitira coger una de ellas y utilizarla tal cual en un programa sin necesidad de llevarnos la otra. Por ejemplo, estos dos mtodos (en C#), estn totalmente desacoplados. Ninguno de ellos necesita al otro para hacer su trabajo.

static int metodo1(int a, int b) { return a * b; } static int metodo2(int a, int b) { return a + b; }

II) Acoplamiento normal El acoplamiento ms comn que existe es aquel en el que una unidad de software necesita del trabajo que hace la otra. Por ejemplo, estos dos mtodos tienen un acoplamiento normal.
static int metodo1(int a, int b) { int c = metodo2(a, b); ; return 2 * c; } static int metodo2(int a, int b) { return a + b; }

metodo1 invoca a metodo2, y no puede realizar su funcin sin l. 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. En el acoplamiento normal, la comunicacin entre las unidades debe de ser puntos de

entrada y de salida vlidos y paso de datos como parmetros. Por ejemplo, si hablamos de mtodos o funciones, los datos deben pasarse de una a otra a traves de parmetros, y devolverse los resultados como retorno de la funcin o mtodo y no de ninguna otra forma. Si extrapolamos esta definicin a clases o libreras, por ejemplo, una clase est acoplada a otra normalmente si los objetos de una utilizan a los de la otra, y se comunican invocando sus mtodos y pasndoles datos como parmetros exclusivamente. III) Acoplamiento de datos. Una unidad de software est acoplada a otra por los datos cuando ambas necesitan del mismo conjunto local de datos para funcionar. Por ejemplo, observa estos dos mtodos de la misma clase:
class Ejemplo { int compartido=0; void metodo1(int a, int b) { compartido = a * b; } void metodo2(int a, int b) { compartido = a + b; } }

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. IV) Acoplamiento de control. Decimos que un mtodo est acoplado a otro por control cuando de alguna manera un mtodo controla la ejecucin del otro. En general, suele ocurrir cuando un mtodo pasa algn parmetro a otro, y en funcin de l se comporta de una u otra manera. Suele haber discusin acerca de si este acoplamiento es intrnsecamente malo o simplemente poco conveniente. No obstante, y sin entrar en divagaciones, si que est claro que si se puede evitar, mejor que mejor. 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.
static int metodo1(int a, int b) { if (a > 5) return metodo2(a, b, true); else return metodo2(a, b, false); } static int metodo2(int a, int b, bool c) { if (c) return (a * b); else return (a + b); }

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

static int metodo1(int a, int b) { if (a > 5) return multiplicar(a, b); else return sumar(a, b); } static int multiplicar(int a, int b) { return (a * b); } static int sumar(int a, int b) { return (a + b); }

V) Acoplamientos no deseados Los comentados hasta ahora son acoplamientos que se producen habitualmente, simplemente, debemos tener en cuenta a la hora de disear o programar que mejor cuanto menos acoplamiento. En este ltimo apartado comentaremos un par de acoplamientos que hay que evitar a toda costa. 1.- Acoplamiento global. Decimos que dos unidades estn globalmente acopladas cuando se pasan datos entre s a travs de una estructura global. Ojo, no confundir con el acoplamiento de datos, en el cual, ambas unidades trabajan sobre el mismo conjunto de datos. En este caso, hablamos de utilizar una estructura global para pasarse datos, sin que esta estructura tenga otra finalidad.

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.
int a,b; int resultado; static void metodo1() { a = 5; b = 9; multiplicar(); Console.Out.WriteLine(resultado); } static int multiplicar() { resultado = a * b; }

2.- Acoplamiento por contenido. Este acoplamiento es el ms dificil de definir. Afortunadamente, los lenguajes de programacin ms modernos nos evitan en la mayor parte de los casos caer en l insconscientemente. Podemos decir que una unidad est acoplada a otra por contenido cuando para programar la primera es necesario conocer cualquier detalle del interior de la segunda. Es decir, en general, cuando programamos una unidad que est acoplada a otra, de la segunda slo necesitamos conocer sus puntos de entrada y los resultados que nos va a devolver. No debe ser necesario conocer ningn detalle de la implementacin de la segunda. Si vemos que lo necesitamos, estaremos incurriendo en un acoplamiento por contenido. DESACOPLAR. Por ltimo, comentar que cuando revisamos una unidad de sofware acoplada a otra y logramos reducir su nivel de acoplamiento, decimos que las estamos desacoplando, es decir, reduciendo su dependencia.

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. 1) Cohesin funcional. Se produce cuando agrupamos unidades de software teniendo en cuenta que todas ellas contribuyen a realizar un mismo fin. Es decir, cuando todas las unidades agrupadas, trabajando juntas consiguen un objetivo. En general, es el criterio de agrupacin ms deseable. Adems, entre este tipo de unidades suele haber un acoplamiento relativamente alto, as que mejor que estn juntas. 2) Cohesin secuencial. Cuando agrupamos unidades que cumplen que los resultados que produce una son los que utiliza otra para continuar trabajando. Es decir, los datos de salida de una sirven de entrada para otras. Es una forma de agrupar muy relacionada con el problema que se est tratando de resolver. 3) Cohesin de datos. Cuando todas las unidades agrupadas trabajan sobre el mismo conjunto de datos. 4) Cohesin lgica. Cuando todas las unidades agrupadas realizan trabajo en una misma categora lgica, pero no necesariamente tienen relacin unas con otras. Por ejemplo, libreras de funciones matemticas... se agrupan simplemente porque realizan clculos matemticos, pero no necesariamente tienen relacin unos con otros. 5) Cohesin temporal. Este criterio empieza a ser algo peor. Significa que agrupamos una serie de unidades simplemente porque tienen que ejecutarse ms o menos en el mismo periodo de tiempo, pero sin que tengan una relacin mayor entre ellas... es decir, sin que contribuyan al mismo fin (funcional), sin que se pasen datos en secuencia (secuencial) y sin que ni tan siquiera trabajen sobre los mismos datos (de datos) ni caen dentro de una misma categora (lgica). Simplemente, tienen que ejecutarse cerca unas de otras. 6) Cohesin casual. Pues cualquier criterio que no caiga dentro de los anteriores se considera ya puramente casual. Mejor evitarla a toda costa.

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 sofware.