TO

TE C

N OL O GI C O D

TU

TE

PE

GRUPO: T OSEMESTRE: TU TE VI NIVEL CN D E C OL O GI C O

Tuxtepec, Oax; a 15 de Marzo de 2011

TE

INGENIERIA EN SISTEMAS COMPUTACIONALES

PE

IN

ST

IT

PRESENTA: CELESTE YAMIN ZRATE CASTILLO NOMBRE DE LA MATERIA: REDES DE COMPUTADORAS CATEDRTICO: JORGE FRANCISCO MARTINEZ AGUILAR ESPECIALIDAD:

IN

ST

IT

ACOPLAMIENTO Y COHESION

Todo desarrollador de software debe tener en cuenta que se obtienen tantos ms beneficios cuanta ms alta es la cohesin en una unidad de software y ms bajo es el acoplamiento entre las unidades. Esta 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 concretas. 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 siguen teniendo aplicacin, aunque su significado sea ms abstracto. 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 software. 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. Entonces 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. Hay varios tipos de acoplamiento las cuales mencionaremos a continuacin: UNIDADES COMPLETAMENTE DESACOPLADAS Ya lo hemos comentado, dos unidades estn completamente desacopladas cuando hacen su trabajo de manera totalmente independiente. Esto nos permitira tomar una de ellas y utilizarla tal cual en un programa sin necesidad de llevarnos la otra.

ACOPLAMIENTO NORMAL

El acoplamiento ms comn que existe es aquel en el que una unidad de software necesita del trabajo que hace la otra. Probablemente se llama normal, porque si descomponemos la solucin de un problema en varias partes, sta es la forma ms natural y frecuente ("normal"), de recomponer la solucin. En el acoplamiento normal, la comunicacin entre las unidades debe de producirse utilizando puntos de entrada y de salida correctos y de su interfaz. Es decir, en el caso de los mtodos. Toda comunicacin entre un mtodo y otro acoplado normalmente debe producirse exclusivamente por los parmetros (como entrada) y por el retorno (como salida). Por ejemplo, si hablamos de mtodos o funciones, los datos deben pasarse de una a otra a travs 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 y recibindolos a travs de canales normales, como retornos, propiedades, etc. ACOPLAMIENTO DE MARCA O POR ESTAMPADO Ocurre si en la comunicacin entre mdulos se pasan datos con estructura de registro. Este acoplamiento no es deseable si el mdulo que recibe ese registro, necesita slo parte de los elementos que se le pasan.

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

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. ACOPLAMIENTO EXTERNO Las unidades de software estn ligadas a componentes externos, como por ejemplo dispositivos de entrada / salida, protocolos de comunicaciones, etc. 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, descrito arriba, 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. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 int a,b; int resultado; static void metodo1() { a = 5; b = 9; multiplicar(); Console.Out.WriteLine(resultado); } static int multiplicar() { resultado = a * b; }

ACOPLAMIENTO POR CONTENIDO. Este acoplamiento es el ms difcil de definir. Afortunadamente, los lenguajes de programacin ms modernos nos evitan en la mayor parte de los casos caer en l inconscientemente. 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 software acoplada a otra y logramos reducir su nivel de acoplamiento, decimos que las estamos desacoplando, es decir, reduciendo su dependencia. 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 podemos hacer lo mismo sin acoplar los mtodos por los datos, mejor. 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. COHESIN DE DATOS. Cuando todas las unidades agrupadas trabajan sobre el mismo conjunto de datos. COHESIN CASUAL Pues cualquier criterio que no caiga dentro de los anteriores se considera ya puramente casual. Mejor evitarla, ms vale tener un criterio, aunque no estemos seguros de que es bueno, que no tener ningn criterio. 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. 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. 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. COHESIN DE COMUNICACIN (MODERADA A BUENA) Ninguno de los niveles de cohesin discutidos previamente est fuertemente vinculado a una estructura de problema en particular. Cohesin de Comunicacin es el menor nivel en el cual encontramos una relacin entre los elementos de procesamiento que es intrnsecamente dependiente del problema. Decir que un conjunto de elementos de procesamiento estn vinculados por comunicacin significa que todo los elementos operan sobre el mismo conjunto de datos de entrada o de salida.

En el diagrama de la figura podemos observar que los elementos de procesamiento 1, 2, y 3, estn asociados por comunicacin sobre la corriente de datos de entrada, en tanto que 2, 3, y 4 se vinculan por los datos de salida. Los diagramas de flujo de datos (DFD) son un medio objetivo para determinar si los elementos en un mdulo estn asociados por comunicacin. Las relaciones por comunicacin presentan un grado de cohesin aceptable. La cohesin por comunicacin es comn en aplicaciones comerciales. Ejemplos tpicos pueden ser: Un modulo que imprima o grabe un archivo de transacciones Un modulo que reciba datos de diferente fuentes, y los transforme y ensamble en una lnea de impresin.

COHESIN DE PROCEDIMIENTO (MODERADA) Elementos de procesamiento relacionados proceduralmente son elementos de una unidad procedural comn. Estos se combinan en un mdulo de cohesin procedural. Una unidad procedural comn puede ser un proceso de iteracin (loop) y de decisin, o una secuencia linear de pasos. En este ltimo caso la cohesin es baja y es similar a la cohesin temporal, con la diferencia que la cohesin temporal no implica una determinada secuencia de ejecucin de los pasos. Al igual que en los casos anteriores, para decir que un mdulo tiene solo cohesin procedural, los elementos de procesamiento deben ser elementos de alguna iteracin, decisin, o secuencia, pero no deben estar vinculados con ningn principio asociativo de orden superior. La cohesin procedural asocia elementos de procesamiento sobre la base de sus relaciones algortmicas o procedurales. Este nivel de cohesin comnmente se tiene como resultado de derivar una estructura modular a partir de modelos de procedimiento como ser diagramas de flujo, o diagramas NassiShneiderman. 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. 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. COHESIN COINCIDENTAL No existe una relacin significativa entre los elementos del mdulo. Es la peor posible y se produce cuando cualquier relacin entre los elementos del mdulo es una pura coincidencia, es decir, no guardan absolutamente ninguna relacin entre ellos. REFERENCIAS: http://latecladeescape.com/ingenieria-del-software/acoplamiento-y-cohesion.html http://www.chaco.gov.ar/utn/disenodesistemas/apuntes/de/Unidad_5.html http://www.ongei.gob.pe/publica/metodologias/Lib5081/CAP0641.HTM