acoplamiento y cohesion

ACOPLAMIENTO Y COHESIÓNEN LA PROGRAMACIÓN MODULAR

INTRODUCCIÓN:

La programación modular es una técnica de programación que todavía se utiliza tanto para la construcción de algoritmos computacionales básicos así como apoyo al desarrollo de sistemas de gestión (en el diseño de diagramas modulares). La programación modular ha hecho su aparición alrededor de los años 70, según bibliografía consultada.

Definición de Módulo de Programa

Previo a la definición de módulo de programa haremos algunas observaciones.Supongamos un conjunto de sentencias como las que se representan a continuación:

____________________

A1: BEGIN A____________________

B: ______________________________

A2: END AC: __________

__________Diremos que A1 y A2 son los límites del conjunto o agregado de sentencias

llamado A. La sentencia B se encuentra dentro de A, y C se encuentra fuera de A. Las sentencias se encuentran en el orden en que ingresaran a un compilador. Este orden es conocido como orden lexicográfico de un programa. El término lexicográfico siempre significará “como está escrito” o el orden en que aparecen las sentencias de un programa en el listado de un compilador. Volviendo al ejemplo, diremos que la sentencia C está lexicográficamente después que la A2.

Es importante distinguir que el orden lexicográfico casi siempre no se corresponde con el orden de ejecución de las sentencias. Uno de los propósitos de los elementos de límite (A1 y A2 en el ejemplo) es el de controlar el alcance en el que identificadores son definidos y asociados a objetos (variables).

Estamos ahora en condiciones de definir el término módulo de programa o simplemente módulo: Un módulo es una secuencia lexicográficamente contigua de sentencias, encerrada entre elementos de frontera, y que poseen un identificador del conjunto de dichas sentencias. Dicho de otra manera, un módulo es un grupo de sentencias contiguas que poseen un identificador simple por el cual son referenciadas. Esta definición es general y dentro de la misma podemos encontrar implementaciones particulares de lenguajes específicos como ser: “párrafos”, “secciones”, y “subprogramas” de COBOL, “funciones” de C, “procedimientos” de Pascal, etc.

Acoplamiento y Cohesiónen la Programación Modular

Un lenguaje de programación incluye un determinado tipo de módulo, solo si implementa construcciones lingüísticas específicas que realizan las características de definición y activación de dichos módulos.

Interfase de Módulo

Una interface define un límite del módulo, a través del se lo activa y por el cual fluyen datos y control. La interface puede considerarse como residente en el módulo referenciado. Puede pensarse como un enchufe (socket) donde la conexión del elemento referenciante se inserta. Toda interface en un módulo representa cosas que deben ser conocidas, comprendidas, y apropiadamente conectadas por los otros módulos del sistema.

Se busca minimizar la complejidad del sistema/módulo, en parte, minimizando elnúmero y complejidad de las interfaces por módulo. Todo módulo además debe tener al menos una interface para ser definido y vinculado al resto del sistema. Es posible así mismo que un módulo tenga más de una interface.

Una interface puede cumplir las siguientes cuatro funciones:· Transmitir datos a un módulo como parámetros de entrada.· Recibir datos desde un módulo como resultados de salida.· Ser un nombre por el cual ser recibe el control.· Ser un nombre por el cual ser transmite el control.

Un módulo puede ser identificado y activado por medio de una interfaz de identidad simple. También podemos pasar datos al módulo por medio de la misma interfaz sin agregar otras, haciendo a la interfaz de entrada capaz de aceptar datos. Esto requiere que los elementos de datos sean pasados dinámicamente como argumentos (parámetros) como parte de la secuencia de activación que da el control a un módulo.

Se necesita también que la interface de un módulo sirva para transferir el retorno del control al módulo llamador. Esto puede realizarse haciendo que la transferencia de control desde el llamador sea una transferencia condicional. Debe implementarse además un mecanismo para transmitir datos de retorno desde el módulo llamado hacia el llamador. Puede asociarse un valor a una activación particular del modulo llamado, la cual pueda ser usada contextualmente en el llamador. Tal es el caso de las funciones lógicas. Alternativamente pueden transmitirse parámetros para definir ubicaciones donde el módulo llamado retorna valores al llamador.

Conexiones Normales y Patológicas

Diremos que entre dos módulos existe una conexión normal cuando la conexión se produce al nivel del identificador del módulo invocado, es decir a través de alguna interfaz definida formalmente.

2


En oposición si la conexión intermodular se realiza a un identificador de un elemento interno del módulo invocado sin pasar por alguna interface definida, diremos que es una conexión patológica.

DESARROLLO:

ACOPLAMIENTO

Muchos aspectos de la modularización pueden ser comprendidos solo si se examinan módulos en relación con otros. En principio veremos el concepto de independencia. Diremos que dos módulos son totalmente independientes si ambos pueden funcionar completamente sin la presencia del otro. Esto implica que no existen interconexiones entre los módulos, y que se tiene un valor cero en la escala de "dependencia".

En general veremos que a mayor número de interconexiones entre dos módulos, se tiene una menor independencia.

El concepto de independencia funcional es una derivación directa del de modularidad y de los conceptos de abstracción y ocultamiento de la información.La cuestión aquí es: ¿cuanto debe conocerse acerca de un módulo para poder comprender otro módulo?. Cuanto más debamos conocer acerca del módulo B para poder comprender el módulo A, menos independientes serán A de B.

La simple cantidad de conexiones entre módulos, no es una medida completa de la independencia funcional. La independencia funcional se mide con dos criterios cualitativos: acoplamiento y cohesión. Estudiaremos en principio el primero de ellos.Módulos altamente "acoplados" estarán unidos por fuertes interconexiones, módulos débilmente acoplados tendrán pocas y débiles interconexiones, en tanto que los módulos "desacoplados" no tendrán interconexiones entre ellos y serán independientes.

El acoplamiento es un concepto abstracto que nos indica el grado de interdependencia entre módulos.

En la práctica podemos materializarlo como la probabilidad de que en la codificación, depuración, o modificación de un determinado módulo, el programador necesite tomar conocimiento acerca de partes de otro módulo. Si dos módulos están fuertemente acoplados, existe una alta probabilidad de que el programador necesite conocer uno de ellos en orden de intentar realizar modificaciones al otro.

Claramente, el costo total del sistema se verá fuertemente influenciado por el grado de acoplamiento entre los módulos.

Factores que influencian el Acoplamiento

Los cuatro factores principales que influyen en el acoplamiento entre módulos son:

3


Tipo de conexión entre módulos: los sistemas normalmente conectados, tienen menor acoplamiento que aquellos que tienen conexiones patológicas.

Complejidad de la interface: Esto es aproximadamente igual al número de ítems diferentes pasados (no cantidad de datos). Más ítems, mayor acoplamiento.

Tipo de flujo de información en la conexión: los sistemas con acoplamiento de datos tienen menor acoplamiento que los sistemas con acoplamiento de control, y estos a su vez menos que los que tienen acoplamiento híbrido.

Momento en que se produce el ligado de la Conexión: Conexiones ligadas a referentes fijos en tiempo de ejecución, resultan con menor acoplamiento que cuando el ligado tiene lugar en tiempo de carga, el cual tiene a su ver menor acoplamiento que cuando el ligado se realiza en tiempo de linkage-edición, el cual tiene menos acoplamiento que el que se realiza en tiempo de compilación, todos los que a su vez tiene menos acoplamiento que cuando el ligado se realiza en tiempo de codificación.

Tipos de conexiones entre módulos

Una conexión en un programa, es una referencia de un elemento, por nombre, dirección, o identificador de otro elemento.

Una conexión intermodular ocurre cuando el elemento referenciado está en un módulo diferente al del elemento referenciante.

El elemento referenciado define una interface, un límite del módulo, a través del cual fluyen datos y control.

La interface puede considerarse como residente en el elemento referenciado. Puede pensarse como un enchufe (socket) donde la conexión del elemento referenciante se inserta.

Toda interface en un módulo representa cosas que deben ser conocidas, comprendidas, y apropiadamente conectadas por los otros módulos del sistema.

Se busca minimizar la complejidad del sistema/módulo, en parte, minimizando el número y complejidad de las interfaces por módulo.

Todo módulo además debe tener al menos una interface para ser definido y vinculado al resto del sistema.

Pero, es una interface de identidad simple suficiente para implementar sistemas que funcionen adecuadamente?. La cuestión aquí es: A que propósito sirven las interfaces?

Solo flujos de control y datos pueden pasarse entre módulos en un sistema de programación. Una interface puede cumplir las siguientes cuatro únicas funciones:

4


transmitir datos a un módulo como parámetros de entradarecibir datos desde un módulo como resultados de salidaser un nombre por el cual ser recibe el controlser un nombre por el cual ser transmite el control

Un módulo puede ser identificado y activado por medio de una interfaz de identidad simple. También podemos pasar datos a un módulo sin agregar otras interfaces, haciendo a la interfaz de entrada capaz de aceptar datos como control. Esto requiere que los elementos de datos sean pasados dinámicamente como argumentos (parámetros) como parte de la secuencia de activación, que da el control a un módulo; cualquier referencia estática a datos puede introducir nuevas interfaces.

Se necesita también que la interface de identidad de un módulo sirva para transferir el retorno del control al módulo llamador. Esto puede realizarse haciendo que la transferencia de control desde el llamador sea una transferencia condicional. Debe implementarse además un mecanismo para transmitir datos de retorno desde el módulo llamado hacia el llamador. Puede asociarse un valor a una activación particular del modulo llamado, la cual pueda ser usada contextualmente en el llamador. Tal es el caso de las funciones lógicas. Alternativamente pueden transmitirse parámetros para definir ubicaciones donde el módulo llamado retorna valores al llamador.

Si todas las conexiones de un sistema se restringen a ser completamente parametrizadas (con respecto a sus entradas y salidas), y la transferencia condicional de control a cada módulo se realiza a través de una identidad simple y única, diremos que el sistema está mínimamente conectado.

Diremos que un sistema está normalmente conectado cuando cumple con las condiciones de mínimamente conectado, excepto por alguna de las siguientes consideraciones:

existe más de un punto de entrada para un mismo móduloel módulo activador o llamador puede especificar como parte del proceso de activación un punto de retorno que no sea la próxima sentencia en el orden de ejecución.el control es transferido a un punto de entrada de un módulo por algún mecanismo distinto a una llamada explícita (ej. perform thru del COBOL).

El uso de múltiples puntos de entrada garantiza que existirán más que el número mínimo de interconexiones para el sistema. Por otra parte si cada punto de entrada determina funciones con mínima conexión a otros módulos, el comportamiento del sistema será similar a uno mínimamente interconectado.

De cualquier manera, la presencia de múltiples puntos de entrada a un mismo módulo, puede ser un indicativo de que el módulo está llevando a cabo más de una función específica. Además, es una excelente oportunidad que el programador superpondrá parcialmente el código de las funciones comprendidas dentro del mismo módulo, quedando dichas funciones acopladas por contenido.

5


De manera similar, los puntos de retorno alternativo son frecuentemente útiles dentro del espíritu de los sistemas normalmente conectados. Esto se da cuando un módulo continuará su ejecución en un punto que depende del valor resultante de una decisión realizada por un módulo subordinado invocado previamente. En un caso de mínima conexión, el módulo subordinado retornará el valor como un parámetro, el cual deberá ser testeado nuevamente en el módulo superior. Sin embargo, el módulo superior puede indicar por algún medio directamente el punto donde debe continuarse la ejecución del programa, (un valor relativo + o - direcciones a partir de la instrucción llamadora, o un parámetro con una dirección explícita).

Si un sistema no está mínima o normalmente conectados, entonces algunos de sus módulos presentarán conexiones patológicas. Esto significa que al menos un módulo tendrá referencias explícitas a identificadores definidos dentro de los límites de otro módulo.

Complejidad de la interface

La segunda dimensión del acoplamiento el la complejidad. Cuanto más compleja es una conexión, mayor acoplamiento se tiene. Un módulo con una interface de 100 parámetros generará mayor acoplamiento que un que solo necesite tres parámetros.El significado de "complejidad" es el de complejidad en términos humanos, tal lo visto anteriormente.

Flujo de Información

Otro aspecto importante del acoplamiento tiene que ver con el tipo de información que se transmite entre el módulo superior y subordinado. Distinguiremos tres tipos de flujo de información:

datoscontrolhíbrido

Los datos son información sobre la cual una pieza de programa opera, manipula, o modifica.

La información de control (aún cuando está representada por variables de dato) es aquella que gobierna como se realizarán las operaciones o manipulaciones sobre los datos.

Diremos que una conexión presenta acoplamiento por datos si la salida de datos del módulo superior es usada como entrada de datos del subordinado. Este tipo de acoplamiento también es conocido como de entrada-salida.

Diremos que una conexión presenta acoplamiento de control si el módulo superior comunica al subordinado información que controlará la ejecución del mismo. Esta información puede pasarse como datos utilizados como señales o "banderas" (flags) o bien como direcciones de memoria para instrucciones de salto

6


condicional (branch-adress). Estos son elementos de control "disfrazados" como datos.

El acoplamiento de datos es mínimo, y ningún sistema puede funcionar sin él. La comunicación de datos es necesaria para el funcionamiento del sistema, sin embargo, la comunicación de control es una característica no deseable y prescindible, que sin embargo aparece muy frecuentemente en los programas.

Se puede minimizar el acoplamiento si solo se transmiten datos a través de las interfaces del sistema. El acoplamiento de control abarca todas las formas de conexión que comuniquen elementos de control. Esto no solo involucra transferencia de control (direcciones o banderas), si no que puede involucrar el pasaje de datos que cambia, regula, o sincroniza la ejecución de otro módulo.

Esta forma de acoplamiento de control indirecto o secundario se conoce como coordinación. La coordinación involucra a un módulo en el contexto procedural de otro. Esto puede comprenderse con el siguiente ejemplo: supongamos que el módulo A llama al módulo B suministrándole elementos de datos discretos. La función del módulo B es la de agrupar estos elemento de datos en un ítem compuesto y retornárselo al módulo A (superior). El módulo B enviará al módulo A, señales o banderas indicando que necesita que se le suministre otro ítem elemental, o para indicarle que le está devolviendo el ítem compuesto. Estas banderas serán utilizadas dentro del módulo A para coordinar su funcionamiento y suministrar a B lo requerido.Cuando un módulo modifica el contenido procedural de otro módulo, decimos que existe acoplamiento híbrido. El acoplamiento híbrido es una modificación de sentencias intermodular. En este caso, para el módulo destino o modificado, el acoplamiento es visto como de control en tanto que para el módulo llamador o modificador es considerado como de datos.

El grado de interdependencia entre dos módulos vinculados con acoplamiento híbrido es muy fuerte. Afortunadamente es una práctica en decadencia y reservada casi con exclusividad a los programadores en assembler.

Tiempo de ligado de conexiones intermodulares

"Ligado" o "Binding" es un término comúnmente usado en el campo del procesamiento de datos para referirse a un proceso que resuelve o fija los valores de identificadores dentro de un sistema.

El ligado de variables a valores, o más genéricamente, de identificadores a referentes específicos, puede tener lugar en diferentes estadios o períodos en la evolución del sistema. La historia de tiempo de un sistema puede pensarse como una línea extendiéndose desde el momento de la escritura del código fuente hasta el momento de su ejecución. Dicha línea puede subdividirse en diferentes niveles de refinamiento según distintas combinaciones de computador/lenguaje/compilador/sistema operativo.

De esta forma, el ligado puede tener lugar cuando el programador escribe una sentencia en el editor de código fuente, cuando un módulo es compilado o

7


ensamblado, cuando el código objeto (compilado o ensamblado) es procesado por el "link-editor" o el "link-loader" (generalmente este proceso es el conocido como ligado en la mayoría de los sistemas), cuando el código "imagen-de-memoria" es cargado en la memoria principal, y finalmente cuando el sistema es ejecutado.

La importancia del tiempo de ligado radica en que cuando los valores de variables dentro de una pieza de código son fijados más tarde, el sistema es más fácilmente modificable y adaptable al cambio de requerimientos.

Examinaremos ahora la relación existente entre el tiempo de ligado y las conexiones intermodulares, y como el mismo afecta el grado de acoplamiento entre módulos.

Nuevamente, una referencia intermodular fijada a un referente u objeto específico en tiempo de definición, tendrá un acoplamiento mayor a una referencia fijada en tiempo de traslación o posterior aún.

La posibilidad de compilación independiente de un módulo de otros facilitará el mantenimiento y modificación del sistema, que si debiera compilarse todos los módulos juntos. Igualmente, si la link-edición de los módulos es diferida hasta el instante previo a su ejecución, la implementación de cambios se verá simplificada.

Existe un caso particular de acoplamiento de módulos derivado de la estructura lexicográfica del programa. Hablamos en este caso de acoplamiento por contenido.Dos formas de acoplamiento por contenido pueden distinguirse:

Inclusión lexicográfica: se da cuando un módulo está incluido lexicográficamente en otro, y es una forma menor de acoplamiento. Los módulos por lo general no pueden ejecutarse separadamente. Este es el caso en el que el módulo subordinado es activado en línea dentro del contexto del módulo superior.Solapamiento parcial: es un caso extremo de acoplamiento por contenido. Parte del código de un módulo está en intersección con el otro. Afortunadamente la mayoría de los lenguajes modernos de alto nivel no permiten este tipo de estructuras.

8


En términos de uso, mantenimiento, y modificación, las consecuencias del acoplamiento por contenido son peores que las del acoplamiento de control. El acoplamiento por contenido hace que los módulos no puedan funcionar uno sin el otro. No ocurre lo mismo en el acoplamiento de control, en el cual un módulo, aunque reciba información de control, puede ser invocado desde diferentes puntos del sistema.

Acoplamiento de Entorno Común (common-environment coupling)

Siempre que dos o más módulos interactúan con un entorno de datos común, se dice que dichos módulos están en acoplamiento por entorno común.

El acoplamiento de entorno común es una forma de acoplamiento de segundo orden, distinto de los tratados anteriormente. La severidad del acoplamiento dependerá de la cantidad de módulos que acceden simultáneamente al entorno común. En el caso extremo de solo dos módulos donde uno utiliza como entrada los datos generados por el otro hablaremos de un acoplamiento de entrada-salida.

El punto es que el acoplamiento por entorno común no es necesariamente malo y deba ser evitado a toda costa. Por el contrario existen ciertas circunstancias en que es una opción válida.

Desacoplamiento

El concepto de acoplamiento invita a un concepto recíproco: desacoplamiento. Desacoplamiento es cualquier método sistemático o técnica para hacer más independientes a los módulos de un programa.

Cada tipo de acoplamiento generalmente sugiere un método de desacoplamiento. Por ejemplo, el acoplamiento causado por ligado, puede desacoplarse cambiando los parámetros apropiados tal lo visto en el ejemplo de el contador de líneas de los programas impresores.

El desacoplamiento. desde el punto de vista funcional, rara vez puede realizarse, excepto en los comienzos de la fase del diseño.

9


Como regla general, una disciplina de diseño que favorezca el acoplamiento de entrada-salida y el acoplamiento de control por sobre el acoplamiento por contenido y el acoplamiento híbrido, y que busque limitar el alcance del acoplamiento por entorno común es el enfoque más efectivo.

Otras técnicas para reducir el acoplamiento son:

Convertir las referencias implícitas en explícitas. Lo que puede verse con mayor facilidad es más fácil de comprender.Estandarización de las conexiones.Uso de "buffers" para los elementos comunicados en una conexión. Si un módulo puede ser diseñado desde el comienzo asumiendo que un buffer mediará cada corriente de comunicación, las cuestiones temporización, velocidad, frecuencia, etc., dentro de un módulo no afectarán el diseño de otros.Localización. Utilizado para reducir el acoplamiento por entorno común. Consiste en dividir el área común en regiones para que los módulos solo tengan acceso a aquellos datos que les son de su estricta incumbencia.

10


COHESIÓN

Hemos visto que la determinación de módulos en un sistema no es arbitraria. La manera en la cual dividimos físicamente un sistema en piezas (particularmente en relación con la estructura del problema) puede afectar significativamente la complejidad estructural del sistema resultante, así como el número total de referencias intermodulares.

Adaptar el diseño del sistema a la estructura del problema (o estructura de la aplicación, o dominio del problema) es una filosofía de diseño sumamente importante. A menudo encontramos que elementos de procesamiento del dominio de problemas altamente relacionados, son trasladados en código altamente interconectado. Las estructuras que agrupan elementos del problema altamente interrelacionados, tienden a ser modularmente efectivas.

Imaginemos que tengamos una magnitud para medir el grado de relación funcional existente entre pares de módulos. En términos de tal medida, diremos que sistema más modularmente efectivo será aquel cuya suma de relación funcional entre pares de elementos que pertenezcan a diferentes módulos sea mínima. Entre otras cosas, esto tiende a minimizar el número de conexiones intermodulares requeridas y el acoplamiento intermodular.

Esta relación funcional intramodular se conoce como cohesión.

La cohesión es la medida cualitativa de cuan estrechamente relacionados están los elementos internos de un módulo.

Otros términos utilizados frecuentemente son "fuerza modular", "ligazón", y "funcionalidad".

En la práctica un elemento de procesamiento simple aislado, puede estar funcionalmente relacionado en diferentes grados a otros elementos. Como consecuencia, diferentes diseñadores, con diferentes "visiones" o interpretaciones de un mismo problema, pueden obtener diferentes estructuras modulares con diferentes niveles de cohesión y acoplamiento. A esto se suma el inconveniente de que muchas veces es difícil evaluar el grado de relación funcional de un elemento respecto de otro.

La cohesión modular puede verse como el cemento que amalgama juntos a los elementos de procesamiento dentro de un mismo módulo. Es el factor más crucial en el diseño estructurado, y el de mayor importancia en un diseño modular efectivo.

Este concepto representa la técnica principal que posee un diseñador para mantener su diseño lo más semánticamente próximo al problema real, o dominio de problema.

11


Claramente los conceptos de cohesión y acoplamiento están íntimamente relacionados. Un mayor grado de cohesión implica uno menor de acoplamiento. Maximizar el nivel de cohesión intramodular en todo el sistema resulta en una minimización del acoplamiento intermodular.

Matemáticamente el cálculo de la relación funcional intramodular (cohesión), involucra menos pares de elementos a los cuales debe aplicarse la medida, en comparación con el cálculo de la relación funcional intermodular (acoplamiento).

Ambas medidas son excelentes herramientas para el diseño modular efectivo, pero de las dos la más importante y extensiva es la cohesión.

Una cuestión importante a determinar es como reconocer la relación funcional.

El principio de cohesión puede ponerse en práctica con la introducción de la idea de un principio asociativo.

En la decisión de poner ciertos elementos de procesamiento en un mismo módulo, el diseñador, utiliza el principio de que ciertas propiedades o características relacionan a los elementos que las poseen. Esto es, el diseñador pondrá el objeto Z en el mismo módulo que X e Y, porque X, Y, y Z poseen un misma propiedad. De esta manera, el principio asociativo es relacional, y es usualmente verificable en tales términos (p.e. "es correcto poner Z junto a X e Y, porque tiene la misma propiedad que ellos") o en términos de miembro de un conjunto (p.e."es correcto poner Z junto a X e Y, pues todos pertenecen al mismo conjunto").

Debe tenerse en mente que la cohesión se aplica sobre todo el módulo, es decir sobre todos los pares de elementos. Así, si Z está relacionado a X e Y, pero no a A, B, y C, los cuales pertenecen al mismo módulo, la inclusión de Z en el módulo, redundará en baja cohesión del mismo.

Intencionalmente se ha usado el término "elemento de procesamiento" en esta discusión, en lugar de términos más comunes como instrucción o sentencia. Porqué:

Primero, un elemento de procesamiento puede ser algo que debe ser realizado en un módulo pero que aún no ha sido reducido a código. En orden de diseñar sistemas altamente modulares, debemos poder determinar la cohesión de módulos que todavía no existen.

Segundo, elementos de procesamiento incluyen todas las sentencias que aparecen en un módulo, no solo el procesamiento realizado por las instrucciones ejecutadas dentro de dicho módulo, si no también las que resultan de la invocación de subrutinas.

Por ejemplo, las sentencias individuales encontradas en el módulo B, el cual es invocado desde el módulo A, NO figuran dentro de la cohesión del módulo A. Sin

12


embargo el procesamiento global (función) realizado por la llamada al módulo B, es claramente un elemento de procesamiento en el módulo llamador A, y por lo tanto participa en la cohesión del módulo A.

Niveles de Cohesión

Diferentes principios asociativos fueron desenvolviéndose a través de los años por medio de la experimentación, argumentos teóricos, y la experiencia práctica de muchos diseñadores.

Existen siete niveles de cohesión distinguibles por siete principios asociativos. Estos se listan a continuación en orden creciente del grado de cohesión, de menor a mayor relación funcional:

Cohesión Casual (la peor)Cohesión Lógica (sigue a la peor)Cohesión Temporal (de moderada a pobre)Cohesión de Procedimiento (moderada)Cohesión de Comunicación (moderada a buena)Cohesión SecuencialCohesión Funcional (la mejor)

Podemos visualizar el grado de cohesión como un espectro que va desde un máximo a un mínimo.

Cohesión Casual (la peor)

La cohesión casual ocurre cuando existe poca o ninguna relación entre los elementos de un módulo.

La cohesión casual establece un punto cero en la escala de cohesión.

Es muy difícil encontrar módulos puramente casuales. Puede aparecer como resultado de la modularización de un programa ya escrito, en el cual el programador encuentra un determinada secuencia de instrucciones que se repiten de forma aleatoria, y decide por lo tanto agruparlas en una rutina.

Otro factor que influenció muchas veces la confección de módulos casualmente cohesivos, fue la mala práctica de la programación estructurada, cuando los programadores mal entendían que modularizar consistía en cambiar las sentencias GOTO por llamadas a subrutinas

Finalmente diremos que si bien en la práctica es difícil encontrar módulos casualmente cohesivos en su totalidad, es común que tengan elementos casualmente cohesivos. Tal es el caso de operaciones de inicialización y terminación que son puestas juntas en un módulo superior.

13


Debemos notar que si bien la cohesión casual no es necesariamente perjudicial (de hecho es preferible un programa casualmente cohesivo a uno lineal), dificulta las modificaciones y mantenimiento del código.

Cohesión Lógica (sigue a la peor)

Los elementos de un módulo están lógicamente asociados si puede pensarse en ellos como pertenecientes a la misma clase lógica de funciones, es decir aquellas que pueden pensarse como juntas lógicamente.

Por ejemplo, se puede combinar en un módulo simple todos los elementos de procesamiento que caen en la clase de "entradas", que abarca todas las operaciones de entrada.

Podemos tener un módulo que lea desde consola una tarjeta con parámetros de control, registros con transacciones erróneas de un archivo en cinta, registros con transacciones válidas de otro archivo en cinta, y los registros maestros anteriores de un archivo en disco. Este módulo que podría llamarse "Lecturas", y que agrupa todas las operaciones de entrada, es lógicamente cohesivo.

La cohesión lógica es más fuerte que la casual, debido a que representa un mínimo de asociación entre el problema y los elementos del módulo. Sin embargo podemos ver que un módulo lógicamente cohesivo no realiza una función específica, sino que abarca una serie de funciones.

Cohesión Temporal (de moderada a pobre)

Temporal cohesión significa que todos los elementos de procesamiento de una colección ocurren en el mismo período de tiempo durante la ejecución del sistema. Debido a que dicho procesamiento debe o puede realizarse en el mismo período de tiempo, los elementos asociados temporalmente pueden combinarse en un único módulo que los ejecute a la misma vez.

Existe una relación entre cohesión lógica y la temporal, sin embargo, la primera no implica una relación de tiempo entre los elementos de procesamiento. La cohesión temporal es más fuerte que la cohesión lógica, ya que implica un nivel de relación más: el factor tiempo. Si embargo la cohesión temporal aún es pobre en nivel de cohesión y acarrea inconvenientes en el mantenimiento y modificación del sistema.

Un ejemplo común de cohesión temporal son las rutinas de inicialización (start-up) comúnmente encontradas en la mayoría de los programas, donde se leen parámetros de control, se abren archivos, se inicializan variables contadores y acumuladores, etc.

Cohesión de Procedimiento (moderada)

Elementos de procesamiento relacionados proceduralmente son elementos de una unidad procedural común. Estos se combinan en un módulo de cohesión

14


procedural. Una unidad procedural común puede ser un proceso de iteración (loop) y de decisión, o una secuencia linear de pasos. En este último caso la cohesión es baja y es similar a la cohesión temporal, con la diferencia que la cohesión temporal no implica una determinada secuencia de ejecución de los pasos.

Al igual que en los casos anteriores, para decir que un módulo tiene solo cohesión procedural, los elementos de procesamiento deben ser elementos de alguna iteración, decisión, o secuencia, pero no deben estar vinculados con ningún principio asociativo de orden superior.

La cohesión procedural asocia elementos de procesamiento sobre la base de sus relaciones algorítmicas o procedurales.

Este nivel de cohesión comúnmente se tiene como resultado de derivar una estructura modular a partir de modelos de procedimiento como ser diagramas de flujo, o diagramas Nassi-Shneiderman.

Cohesión de Comunicación (moderada a buena)

Ninguno de los niveles de cohesión discutidos previamente están fuertemente vinculados a una estructura de problema en particular. Cohesión de Comunicación es el menor nivel en el cual encontramos una relación entre los elementos de procesamiento que es intrínsecamente dependiente del problema.

Decir que un conjunto de elementos de procesamiento están vinculados por comunicación significa que todos 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, están asociados por comunicación 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 módulo están asociados por comunicación.

Las relaciones por comunicación presentan un grado de cohesión aceptable.

15


La cohesión por comunicación es común en aplicaciones comerciales. Ejemplos típicos pueden ser:

un módulo que imprima o grabe un archivo de transaccionesun módulo que reciba datos de diferentes fuentes, y los transforme y ensamble en una línea de impresión.

Cohesión Secuencial

El siguiente nivel de cohesión en la escala es la asociación secuencial. En ella, los datos de salida (resultados) de un elemento de procesamiento sirven como datos de entrada al siguiente elemento de procesamiento.

En términos de un diagrama de flujo de datos de un problema, la cohesión secuencial combina una cadena linear de sucesivas transformaciones de datos.

Este es claramente un principio asociativo relacionado con el dominio del problema.

Cohesión Funcional (la mejor)

En el límite superior del espectro de relación funcional encontramos la cohesión funcional. En un módulo completamente funcional, cada elemento de procesamiento, es parte integral de, y esencial para, la realización de una función simple.

En términos prácticos podemos decir que cohesión funcional es aquella que no es secuencial, por comunicación, por procedimiento, temporal, lógica, o casual.

Los ejemplos más claros y comprensibles provienen del campo de las matemáticas. Un módulo para realizar el cálculo de raíz cuadrada ciertamente será altamente cohesivo, y probablemente, completamente funcional. Es improbable que haya elementos superfluos más allá de los absolutamente esenciales para realizar la función matemática, y es improbable que elementos de procesamiento puedan ser agregados sin alterar el cálculo de alguna forma.

En contraste un módulo que calcule raíz cuadrada y coseno, es improbable que sea enteramente funcional (deben realizarse dos funciones ambiguas).

En adición a estos ejemplos matemáticos obvios, usualmente podemos reconocer módulos funcionales que son elementales en naturaleza. Un módulo llamado LEER-REGISTRO-MAESTRO, o TRATAR-TRANS-TIPO3, presumiblemente serán funcionalmente cohesivos, en cambio TRATAR-TODAS-TRANS presumiblemente realizará más de una función y será lógicamente cohesivo.

Criterios para establecer el grado de cohesión

16


Una técnica útil para determinar si un módulo está acotado funcionalmente es escribir una frase que describa la función (propósito) del módulo y luego examinar dicha frase. Puede hacerse la siguiente prueba:

1. Si la frase resulta ser una sentencia compuesta, contiene una coma, o contiene más de un verbo, probablemente el módulo realiza más de una función; por tanto, probablemente tiene vinculación secuencial o de comunicación.

2. Si la frase contiene palabras relativas al tiempo, tales como "primero", "a continuación", "entonces", "después", "cuando", "al comienzo", etc., entonces probablemente el módulo tiene una vinculación secuencial o temporal.

3. Si el predicado de la frase no contiene un objeto específico sencillo a continuación del verbo, probablemente el módulo esté acotado lógicamente. Por ejemplo editar todos los datos tiene una vinculación lógica; editar sentencia fuente puede tener vinculación funcional.

4. Palabras tales como "inicializar", "limpiar", etc., implican vinculación temporal.

Los módulos acotados funcionalmente siempre se pueden describir en función de sus elementos usando una sentencia compuesta. Pero si no se puede evitar el lenguaje anterior, siendo aún una descripción completa de la función del módulo, entonces probablemente el módulo no esté acotado funcionalmente.

Es importante notar que no es necesario determinar el nivel preciso de cohesión. En su lugar, lo importante es intentar conseguir una cohesión alta y saber reconocer la cohesión baja, de forma que se pueda modificar el diseño del software para que disponga de una mayor independencia funcional.

Comparación de Niveles de Cohesión

Utilizaremos el problema representado en la siguiente figura para ilustrar una variedad de particionamientos del mismo problema, correspondiente a diferentes niveles de cohesión.

Es fácil presentar ejemplos de cohesión casual y lógica particionando el diagrama de flujo de datos. El módulo "HacerAlgo" es un ejemplo de cohesión casual. Los módulos "FormatearReportes" y "Editar_y_Validar" son ejemplos de cohesión lógica.

Debido a que el DFD es inherentemente no procedural, es un tanto difícil visualizar en él relaciones temporales y procedurales. Dos posibilidades serían los módulos "Comenzar" (temporal) y "SumLoop" (procedural).

Cohesión secuencial y de comunicación es fácilmente visible en un DFD. Los módulos "DoCombo" y "ObtenerMaestroVálido" son ejemplos de cohesión de comunicación y secuencial respectivamente.

17


La identificación de cohesión funcional presenta una vez más dificultades. En un nivel superficial, la cohesión funcional sería equivalente a que cada transformación del DFD se corresponda con un módulo, pero un particular arreglo de estos en una jerarquía influencia la cohesión actual de módulos. Estos problemas pueden comprenderse mejor con los conceptos estratégicos introducidos en el capítulo dedicado a morfologías y metodologías.

HacerAlgo : cohesión casualEditar_y_Validar: cohesión lógicaFormatearReportes: Cohesión lógica

18


Comenzar: cohesión temporalSumLoop: cohesión procedural

ObtenerMaestroVálido: cohesión secuencialDoCombo: cohesión de comunicación

Medición de Cohesión

19


Cualquier módulo, rara vez verifica un solo principio asociativo. Sus elementos pueden estar relacionados por una mezcla de los siete niveles de cohesión. Esto lleva a tener una escala continua en el grado de cohesividad más que una escala con siete puntos discretos.

Donde existe más de una relación entre un par de elementos de procesamiento, se aplica el máximo nivel que alcanzan. Por esto, si un módulo presenta cohesión lógica entre todos sus pares de elementos de procesamiento, y a su vez presenta cohesión de comunicación también entre todos dichos pares, entonces dicho módulo es considerado como de cohesión por comunicación.

Ahora, cuál sería la cohesión de dicho módulo si también contiene algún par de elementos completamente no relacionados? En teoría, debería tener algún tipo de promedio entre la cohesión de comunicación y la casual. Para propósitos de depuración, mantenimiento, y modificación, un módulo se comporta como si fuera "solo tan fuerte como sus vínculos más débiles".

El efecto sobre los costos de programación es próximo al menor nivel de cohesión aplicable dentro del módulo en vez del mayor nivel de cohesión.

La cohesión de un módulo es aproximada al nivel más alto de cohesión que es aplicable a todos los elementos de procesamiento dentro del módulo.

Un módulo puede consistir de varias funciones completas relacionadas lógicamente. Esto es definitivamente más cohesivo que un módulo que liga lógicamente fragmentos de varias funciones.

La decisión de que nivel de cohesión es aplicable a un módulo dado requiere de cierto juicio humano. Algunos criterios establecidos son:

- la cohesión secuencial es más próxima al óptimo funcional que a su antecesor de comunicación.

- similarmente existe un salto mayor entre la cohesión lógica y la temporal que entre casual y lógica.

Podemos asignar la siguiente escala de valores para ayudar al diseñador en la calificación de niveles:

0: casual1: lógica3: temporal5: procedural7: de comunicación9: secuencial10: funcional

20


De cualquier modo, esta escala está basada en la experiencia de los autores, y no es una regla fija, si no una conclusión.

La obligación del diseñador es conocer los efectos producidos por la variación en la cohesión, especialmente en términos de modularidad, en orden de realizar soluciones de compromiso beneficiando un aspecto en contra de otro.

21


FUENTES

http://www.ecomchaco.com.ar/utn/disenodesistemas/apuntes/de/Unidad_4.html.

http://www.ecomchaco.com.ar/utn/disenodesistemas/apuntes/de/Unidad_5.html.

M. Morales. “Modelo Conceptual y semántico && Organización de archivos”.

22

acoplamiento y cohesion

Documents