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.

La descripcin del comportamiento de un mdulo permite

establecer el grado de cohesin:

Si es una frase compuesta y contiene ms de un verbo la

cohesin ser MEDIA

Si contiene expresiones secuenciales (primero, entonces,

cuando), ser temporal o secuencial

Si la descripcin no se refiere a algo especfico (Ej. Todos los

errores), cohesin lgica

Si aparece inicializar, preparar, configurar, probablemente

sea temporal.

ALTA

COHESIN ABSTRACCIONAL, se logra cuando se disea el mdulo

como tipo abstracto de datos o como una clase de objetos

COHESIN FUNCIONAL, el mdulo realiza una funcin concreta y

especfica

MEDIA

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

elementos que operan con le mismo conjunto de datos de

entrada o de salida

Cohesin procedimental

Es cuando las funciones se agrupan en un mismo componente

para asegurar un orden previsto.

Por ejemplo: los datos deben ser ingresados antes de

chequearlos o de manipularlos , tres funciones en una secuencia
especifica.

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.

BAJA

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

es la peor y se produce cuando los elementos de un mdulo no

guardan relacin alguna

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

Pues cualquier criterio que no caiga dentro de los anteriores se

considera ya puramente casual. Mejor evitarla, si se puede... ms
vale tener un criterio, aunque no estemos seguros de que es
bueno, que no tener ningn criterio.

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