Coherencia de software (cohesión)
La cohesión 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 librería, o la forma en la que agrupamos métodos en una clase, o la forma en la que agrupamos clases en una librería, etc.
Se suele decir que cuanto más cohesionados estén los elementos agrupados, mejor. El criterio por el cual se agrupan es la cohesión.
Veremos los distintos tipos de cohesión, de la que se considera mayor cohesión 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 cohesión 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 cohesión baja puede ser incómoda, pero no suele plantear grandes problemas. Aunque esto, no es motivo para descuidarla.
1) Cohesión 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 agrupación más deseable. Además, entre este tipo de unidades suele haber un acoplamiento relativamente alto, así que mejor que estén juntas.
2) Cohesión 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) Cohesión de datos. Cuando todas las unidades agrupadas trabajan sobre el mismo conjunto de datos.
4) Cohesión lógica. Cuando todas las unidades agrupadas realizan trabajo en una misma categoría lógica, pero no necesariamente tienen relación unas con otras. Por ejemplo, librerías de funciones matemáticas… se agrupan simplemente porque realizan cálculos matemáticos, pero no necesariamente tienen relación unos con otros.
5) Cohesión temporal. Este criterio empieza a ser algo peor. Significa que agrupamos una serie de unidades simplemente porque tienen que ejecutarse más o menos en el mismo periodo de tiempo, pero sin que tengan una relación 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 categoría (lógica). Simplemente, tienen que ejecutarse cerca unas de otras.
6) Cohesión 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 más bajo posible y la cohesión lo más alta posible suele ser el objetivo de todo arquitecto, diseñador o programador. Tener unos buenos criterios para agrupar unidades de software (alta cohesión), y mantener esas unidades lo más independientes posible (bajo acoplamiento) garantiza la modularidad, facilitando la reutilización del software y gran parte de las tareas del desarrollo del sofware.
fuente:
http://latecladeescape.com/w0/ingenieria-del-software/acoplamiento-y-cohesion.html
