INTRODUCCINa)Presentacin y contextualizacinEn esta unidad hablaremossobre la introduccin y la Presentacin de las herramientas de diseo estructurado. Aquellos que estn obligados a guardar una forma convencional. Entre stos tenemos a los administrativos, los cuales son importantes porque sirven para transmitir la informacin entre el tiempo en que los requisitos del usuario son definidos y documentados. Aqu Veremos lastcnicas de cohesin y acoplamiento de mdulos.b)Competencia Reconoce los conceptos y el manejo de las herramientas de diseo dentro del anlisis de diseo.c)Capacidades1.Analiza los conceptos fundamentales sobre las herramientas de diseo estructurados.2.Identifica y explica las principales tcnicas de presentacin de las herramientas de diseo estructurado.3.Conoce y desarrolla las tcnicas de acoplamiento de mdulos.4.Desarrolla las tcnicas de cohesin que se plantean de forma clara.d)ActitudesAplica los conceptos bsicos sobre el diseo estructurado.Muestra inters ante la presentacin de las herramientas que se relacionan con el diseo estructurado.Motiva a resolver las diversas tcnicas de acoplamiento de mdulos y tcnicas de cohesin.e) Presentacin de Ideas bsicas y contenido esenciales de la Unidad:La Unidad de Aprendizaje 02: Utilizacin de las Herramientas de Diseo, comprende el desarrollo de los siguientes temas:TEMA 01:Introduccin de las herramientas de diseo estructurado.TEMA 02:Presentacin de las herramientas de diseo estructurado.TEMA 03:Tcnicasde acoplamiento de mdulos.TEMA 04:Tcnicas de cohesin.ema 01: Introduccin de las Herramientas de Diseo EstructuradoINTRODUCCINEl desarrollo de sistemas pequeos, en la cual participan una o dos personas, es una tarea simple. Los cambios naturales que surgen durante el ciclo de desarrollo del sistema no producen una gran propagacin de cambios en el sistema. Sin embargo, si el sistema es grande y en su desarrollo participan varios grupos de personasdesarrollando una tarea especfica, hay que tener en cuenta no solo la comunicacin con el usuario sino tambin la inter-relacin entre los distintos grupos de trabajo.

Algunos de los problemas comunes que los desarrolladores encuentran en la construccin de software de cierta complejidad son los siguientes:El dominio de aplicacin no es conocido.La comunicacin con el usuario.La comunicacin con el grupo de desarrollo.La carencia de buena documentacin.

Por esta razn, es necesario seguir una serie de pasos sistemticos para que los diferentes grupos de desarrollo posean una buena comunicacin. Estos pasos son brindados por los modelos de ciclo de vida, los cuales estn constituidos por diferentes etapas:Especificacin de requerimientos: Se realizan entrevistas con el usuario identificando los requerimientos y necesidades del usuario.Anlisis: Modela los requerimientos del usuario.Diseo: Se modela la solucin del sistema, teniendo en cuenta el ambiente de implementacin a utilizar, por ejemplo, si el sistema es centralizado o distribuido, la base de datos a utilizar, lenguaje de programacin, performance deseada, etc.Implementacin: Dado el lenguaje de programacin elegido se implementa el sistema.Testeo: En esta etapa se verifica y valida el sistema teniendo en cuenta algunos criterios de- terminados por el grupo correspondiente.Mantenimiento: Es la etapa ms difcil de desarrollo del sistema, actualiza y modifica el sistema si surgen nuevos requerimientos.

Existen varios mtodos para describir el ciclo de vida de un sistema, uno de ellos es el desarrollo estructurado en cascada (Fig. 1).Fig. 1: Modelo de Ciclo de Vida en Cascada

En un principio fue de gran utilidad pero el problema es que para pasar de una etapa a la otra haba queterminar la primera, produciendo un gran problema si algn cambio era requerido. La etapa de Mantenimiento consuma el 80% del costo de produccin.

Debido a los nuevos requerimientos en el desarrollo de software, surgieron muchos otros modelos que trataban de solucionar los problemas existentes, que se basaron en el modelo en Cascada. Por ejemplo, el Modelo en Espiral, en el cual el sistema se desarrolla incrementalmente (Fig. 2).Los modelos propuestos poseen bsicamente las mismas etapas, pero varan en:Los mtodos y herramientas utilizadas en cada actividadLos controles requeridos, paralelismo en las actividadesLas salidas de cada etapa

No es aconsejable elegir un modelo y seguirlo al detalle sino que se debe adaptar a las caractersticas del proyecto que est siendo desarrollado. Los mtodos de desarrollo de software pueden dividirse en dos grupos: funcin/dato y orientados a objetos.

Fig. 2: Modelo de Ciclo de Vida en Espiral

Orientado a Funcin/Dato: Aquellos mtodos en los cuales las funciones y/o los datos son tratados comoentidades independientes. Estos sistemas resultan difciles de mantener. El mayor problema es que las funciones generalmente dependen de la estructura de los datos. A menudo diferentes tipos de datos tienen distintos formatos y se necesita verificar el tipo del dato (con sentencias If-Then o CASE), produciendo programas difciles de leer ymodificar. Si se desea hacer alguna modificacin en la estructura de los datos se debe modificar en todos los lugares donde es utilizado.

Otro problema es que una persona no piensa naturalmente en trminos de una estructura. La especificacin de requerimientos se hace en lenguaje comn, se especifica la funcionalidad que debe tener el sistema y no en cmo se deben estructurar los datos.Orientado a Objetos:Son aquellos mtodos en los cuales datos y funciones estn altamente relacionados.Elnfasis est centrado en la abstraccin de datos. Se piensa en forma natural, los objetos son mapeados aentidades del mundo real. Los programas son fcilmente mantenibles y extensibles por medio de la construccin de subclases.

Varios mtodos de desarrollo de software han sido propuestos para cada uno de este grupo, algunos de los cuales son descriptos en la Fig. 3.Donde:SADT:Structured Analysis and Design Technique [Ross85]RDD:Requirement Driven Design[Alford85]SA/SD:Structured Analysis and Structured Design [Yourdon&Constantine79]OOSE:Object-Oriented Software Engineering[Jacobson94] OOA:Object-Oriented Analysis[Goldberg] OMT:Object Modeling Technique[Rumbaugh93]UP:Unified Process[Booch&Jacobson&Rumbaugh98]Catalysis: Catlisis[DSouza98]

Fig. 3: Mtodos de Desarrollo de Software

En el corriente curso: Metodologas de Desarrollo de Software I nos centraremos en los mtodos de desarrollo de software orientados a funcin/datos y en las herramientas propuestas para el modelado de los diferentes aspectos de un sistema: datos, control y funciones. Adicionalmente, se presentaran mtodos formales, especficamente Z, y mtodos orientados a objetos.

Tema 02:Presentacin de las Herramientas de Diseo EstructuradoPRESENTACIN DE LASHERRAMIENTAS DE DISEO ESTRUCTURADOEl Anlisis se refiere al extremo inicial de un proyecto de desarrollo de sistemas, durante el tiempo en que los requisitos del usuario son definidos y documentados.El Anlisis estructurado introduce el uso de las herramientas de documentacin grficas para producir un tipo diferente de especificacin funcional: la especificacin estructurada.

El anlisis estructurado, como otros mtodos, permite construir modelos de sistemas a partir del anlisis de sus procesos y/o actividades que se ejecutan asociados al sistema. Permite al equipo encargado del estudio del desarrollo o la organizacin conocer de forma lgica un sistema o proceso. El objetivo que persigue el anlisis estructurado es organizar las tareas asociadas con la determinacin de requerimientos para obtener la comprensin completa y exacta de una situacin dada.

Conceptos quese relacionan con el anlisis estructuradoSmbolos grficos; iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.Diccionario de datos; descripciones de todos los datos utilizados en el sistema.Descripciones de procesos y procedimientos; declaraciones formales que emplean tcnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema.Reglas; estndares para describir y documentar el sistema en forma correcta y completa.

Fase de diseo:En esta fase, el diseo estructurado produce el modelo de diseo con los siguientes elementos:Diseo de datos. Transforma el modelo de dominio de la informacin creado durante el anlisis, en las estructuras de datos necesarias para implementar el software. Los objetos de datos y las relaciones definidas en el diagrama entidad-relacin y el contenido detallado de datos del diccionario de datos constituyen la base para el diseo de datos.Diseo arquitectnico. Define la relacin entre los principales elementos estructurales del programa. Se obtiene a partir del modelo de anlisis y de la interaccin de subsistemas definidos dentro del modelo de anlisis.Diseo de interfaz. Describe como se comunica el software consigo mismo, con los sistemas que operan con l y con los operadores que lo emplean. Los diagramas de flujo de datos y control proporcionan la informacin necesaria para el diseo de la interfaz.Diseo procedimental. Transforma elementos estructurales de la arquitectura del programa en una descripcin procedimental de los componentes del software. Se obtiene a partir de la especificacin del proceso, la especificacin del control y el diagrama de transicin de estados.

Componentes:Smbolos grficos: Identifica y describe los componentes de un sistema y las relaciones entre estos.Diccionarios de datos: Describe todos los datos utilizados en el sistema pueden ser manual o automatizado.Descripciones de procesos y procedimientos: descripcin tcnica para describir las actividades que se realizan los procesos.Reglas: Pasos a seguir para describir y documentar el ven forma correcta y completa.

Herramientas:Diagrama de flujo de datos: Es la base para otros componentes y describe como navegan los datos entre procesos y elementos relacionados. Diccionario de Datos: Contiene las caractersticas de los campos y/o descripcin detallada de los diferentes objetos que componen el sistema Diagrama de Estructuras de Datos: describe la relacin entre las entidades y los objetos (conjunta de informacin que contienen las entidades)

CASO PRCTICOAplicar ambos enfoques de anlisis y diseo de sistemas para tratar de optimizar el proceso de generar Copias Certificadas en el Circuito Judicial Penal de Tucupita, Estado Delta Amacuro.El caso en estudio consiste en elaborar una propuesta para optimizar especficamente el proceso de emisin de Copias Certificadas solicitadas a diario por la comunidad ante este despacho jurdico, cabe mencionar que en la actualidad esta actividad se efecta de manera exclusivamente manual, utilizando herramientas bastante obsoletas, como las mquinas de escribir y basndose en informaciones contenidas en los registros de libros de actas que se encuentran archivados en conjunto con otro elevado nmero de libros que representan todas las competencias del ente judicial.Este procedimiento ambiguo por dems, genera prdidas de tiempo en respuesta al pblico y bsqueda y tratamiento de la informacin por parte de los funcionarios que all laboran, inclusive fatiga al tener que transcribir grandes volmenes de datos de acuerdo a lo solicitado y ms an excesivos pasos y procedimientos para completar las actividades.

Segn el modelo estructuradoEl Anlisis Estructurado, fue seleccionado como tcnica de investigacin de requerimientos, ya que permite al analista conocer el sistema o proceso en una forma lgica y manejable, al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle. Este es un mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes.

Aunado a ello y por ser considerados como una herramienta capaz de describir y analizar el movimiento de los datos a travs de un sistema, la representacin grfica de los procesos del sistema estar a cargo de los Diagramas de Flujos de Datos (DFD).

DISEO DEL SISTEMAEl uso de los Diagramas de Flujos de Datos (DFDs), es una herramienta que permite mostrar grficamente y de manera general, el funcionamiento del sistema y los procesos necesarios para su desarrollo. Los DFDs se pueden dibujar con slo cuatro notaciones sencillas, en este caso, la notacin utilizada est basada en el enfoque de Gane y Sarson.Origen/destino de datos:Representan entidades externas al sistema que se comunican con l y que estn fuera de su control. Las relaciones existentes entre las entidades no se representan en el DFD, ya que no son parte del sistema bajo estudio.Para este diseo forman parte de las entidades los Justiciables, la cual incluye a todas aquellas personas que tienen relacin directa con el proceso. Las entidades Secretaria, Juez y Asistente, quienes conforman al rgano jurdico y son los garantes de llevar a cabo el proceso judicial.

Procesos:Muestran la parte del sistema que transforma las entradas de datos en salida; en tal sentido, el diagrama (DFD Propuesto) muestra cinco (5) procesos considerados vitales para el funcionamiento y operatividad de la aplicacin:Solicitar copias certificadas; en el cual se supervisa que las solicitudes a procesar estn conforme a los requisitos establecidos por el Cdigo de Procedimiento Civil, o alguna otra Ley que condicione la puesta en marcha de stas.Verificar existencia de actas en el sistema; en l se constata que el acta que tiene relacin con la copia certificada solicitada est o no en los archivos del circuito y de ese modo se tenga acceso directo a l.

Generar copias certificadas; encargado de procesar los reportes generados por el sistema, en este caso la emisin directa de las Copias Certificadas solicitadas.Registro automtico de libros; en l se almacena una serie de datos proveniente del procesamiento de las solicitudes.Firmar y sellar actas: Proceso manual que se limita a autenticar las Copias Certificadas previa su entrega al solicitanteFlujo de datos: El flujo describe el movimiento de paquetes de datos que viajan desde una parte del sistema a otra. Estn representados por una flecha para mostrar su origen y su destino.Almacn: Representa una coleccin de paquetes de datos que permanecen en estado de reposo. No est referido exclusivamente a medios de almacenamiento electrnico como bases de datos en discos duros, sino tambin a archiveros metlicos o cualquier otro medio que permita guardar datos en carpetas u hojas de papel.

Tema 03:Tcnicas de Acoplamiento de MdulosMuchos aspectos de la modularizacin pueden ser comprendidos solo si se examinan mdulos en relacin con otros. En principio veremos el concepto de independencia. Diremos que dos mdulos son totalmente independientes si ambos pueden funcionar completamente sin la presencia del otro. Esto implica que no existen interconexiones entre los mdulos, y que se tiene un valor cero en la escala de "dependencia".En general veremos que a mayor nmero de interconexiones entre dos mdulos, se tiene una menor independencia.

El concepto de independencia funcional es una derivacin directa del de modularidad y de los conceptos de abstraccin y ocultamiento de la informacin.La cuestin aqu es: cuanto debe conocerse acerca de un mdulo para poder comprender otro mdulo? Cuanto ms debamos conocer acerca del mdulo B para poder comprender el mdulo A, menos independientes sern A de B.La simple cantidad de conexiones entre mdulos, no es una medida completa de la independencia funcional. La independencia funcional se mide con dos criterios cualitativos: acoplamiento y cohesin. Estudiaremos en principio el primero de ellos. Mdulos altamente "acoplados" estarn unidos por fuertes interconexiones, mdulos dbilmente acoplados tendrn pocas y dbiles interconexiones, en tanto que los mdulos "desacoplados" no tendrn interconexiones entre ellos y sern independientes.

El acoplamiento es un concepto abstracto que nos indica el grado de interdependencia entre mdulos.

En la prctica podemos materializarlo como la probabilidad de que en la codificacin, depuracin, o modificacin de un determinado mdulo, el programador necesite tomar conocimiento acerca de partes de otro mdulo.Si dos mdulos estn 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 mdulos.

1.FACTORES QUE INFLUENCIAN EL ACOPLAMIENTOLos cuatro factores principales que influyen en el acoplamiento entre mdulos son:Tipo de conexin entre mdulos: los sistemas normalmente conectados, tienen menor acoplamiento queaquellos que tienen conexiones patolgicas.Complejidad de la interface: Esto es aproximadamente igual al nmero de tems diferentes pasados (no cantidad de datos). Ms tems, mayor acoplamiento.Tipo de flujo de informacin en la conexin: 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 hbrido.Momento en que se produce el ligado de la Conexin: Conexiones ligadas a referentes fijos en tiempo de ejecucin, 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-edicin, el cual tiene menos acoplamiento que el que se realiza realiza en tiempo de compilacin, todos los que a su vez tiene menos acoplamiento que cuando el ligado se realiza en tiempo de codificacin.

1.1.Tipos de conexiones entre mdulosUna conexin en un programa, es una referencia de un elemento, por nombre, direccin, o identificador de otro elemento.Una conexin intermodular ocurre cuando el elemento referenciado est en un mdulo diferente al del elemento referenciante.El elemento referenciado define una interface, un lmite del mdulo, a travs del cual fluyen datos y control. La interface puede considerarse como residente en el elemento referenciado. Puede pensarse como un enchufe (socket) donde la conexin del elemento referenciante se inserta.

Toda interface en un mdulo representa cosas que deben ser conocidas, comprendidas, y apropiadamente conectadas por los otros mdulos del sistema.Se busca minimizar la complejidad del sistema/mdulo, en parte, minimizando el nmero y complejidad de las interfaces por mdulo.Todo mdulo adems 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 cuestin aqu es: A que propsito sirven las interfaces?

Solo flujos de control y datos pueden pasarse entre mdulos en un sistema de programacin. Una interface puede cumplir las siguientes cuatro nicas funciones:Transmitir datos a un mdulo como parmetros de entrada.Recibir datos desde un mdulo 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 mdulo puede ser idetificado y activado por medio de una interfaz de identidad simple. Tambin podemos pasar datos a un mdulo 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 dinmicamente como argumentos (parmetros) como parte de la secuencia de activacin, que da el control a un mdulo; cualquier referencia esttica a datos puede introducir nuevas interfaces.

Se necesita tambin que la interface de identidad de un mdulo sirva para transferir el retorno del control al mdulo llamador. Esto puede realizarse haciendo que la transferencia de control desde el llamador sea una transferencia condicional. Debe implementarse adems un mecanismo para transmitir datos de retorno desde el mdulo llamado hacia el llamador. Puede asociarse un valor a una activacin particular del modulo llamado, la cual pueda ser usada contextualmente en el llamador. Tal es el caso de las funciones lgicas. Alternativamente pueden transmitirse parmetros para definir ubicaciones donde el mdulo 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 mdulo se realiza a travs de una identidad simple y nica, diremos que el sistemas est mnimamente conectado.Diremos que un sistema est normalmente conectado cuando cumple con las condiciones de mnimamente conectado, excepto por alguna de las siguientes consideraciones:Existe ms de un punto de entrada para un mismo mduloEl mdulo activador o llamador puede especificar como parte del proceso de activacin un punto deretorno que no sea la prxima sentencia en el orden de ejecucin.El control es transferido a un punto de entrada de un mdulo por algn mecanismo distinto a una llamada explcita (ej. perform thru del COBOL).

El uso de mltiples puntos de entrada garantiza que existirn ms que el nmero mnimo de interconexiones para el sistema. Por otra parte si cada punto de entrada determina funciones con mnima conexin a otros mdulos, el comportamiento del sistema ser similar a uno mnimamente interconectado.De cualquier manera, la presencia de mltiples puntos de entrada a un mismo mdulo, puede ser un indicativo de que el mdulo est llevando a cabo ms de una funcin especfica. Adems, es una excelente oportunidad que el programador superpondr parcialmente el cdigo de las funciones comprendidas dentro del mismo mdulo, quedando dichas funciones acopladas por contenido.

De manera similar, los puntos de retorno alternativo son frecuentemente tiles dentro del espritu de los sistemas normalmente conectados. Esto se da cuando un mdulo continuar su ejecucin en un punto que depende del valor resultante de una decisin realizada por un mdulo subordinado invocado previamente. En un caso de mnima conexin, el mdulo subordinado retornar el valor como un parmetro, el cual deber ser testeado nuevamente en el mdulo superior. Sin embargo, el mdulo superior puede indicar por algn medio directamente el punto donde debe continuarse la ejecucin del programa, (un valor relativo + o - direcciones a partir de la instruccin llamadora, o un parmetro con una direccin explcita).

Si un sistema no est mnima o normalmente conectados, entonces algunos de sus mdulos presentarn conexiones patolgicas. Esto significa que al menos un mdulo tendr referencias explcitas a identificadores definidos dentro de los lmites de otro mdulo.1.2.Complejidad de la interfaceLa segunda dimensin del acoplamiento en la complejidad. Cuanto ms compleja es una conexin, mayor acoplamiento se tiene. Un mdulo con una interface de 100 parmetros generar mayor acoplamiento que un que solo necesite tres parmetros.El significado de "complejidad" es el de complejidad en trminos humanos, tal lo visto anteriormente.1.3.Flujo de InformacinOtro aspecto importante del acoplamiento tiene que ver con el tipo de informacin que se transmite entre el mdulo superior y subordinado. Distinguiremos tres tipos de flujo de informacin:DatosControlHbrido

Los datos son informacin sobre la cual una pieza de programa opera, manipula, o modifica. La informacin de control (an cuando est representada por variables de dato) es aquella que gobierna como se realizarn las operaciones o manipulaciones sobre los datos. Diremos que una conexin presenta acoplamiento por datos si la salida de datos del mdulo superior es usada como entrada de datos del subordinado. Este tipo de acoplamiento tambin es conocido como de entrada-salida.Diremos que una conexin presenta acoplamiento de control si el mdulo superior comunica al subordinado informacin que controlar la ejecucin del mismo. Esta informacin puede pasarse como datos utilizados como seales o "banderas" (flags) o bien como direcciones de memoria para instrucciones de salto condicional (branch-adress). Estos son elementos de control "disfrazados" como datos. El acoplamiento de datos es mnimo, y ningn sistema puede funcionar sin l.

La comunicacin de datos es necesaria para el funcionamiento del sistema, sin embargo, la comunicacin de control es una caracterstica no deseable y prescindible, que sin embargo aparece muy frecuentemente en los programas.Se puede minimizar el acoplamiento si solo se transmiten datos a travs de las interfaces del sistema. El acoplamiento de control abarca todas las formas de conexin 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 ejecucin de otro mdulo.

Esta forma de acoplamiento de control indirecto o secundario se conoce como coordinacin. La coordinacin involucra a un mdulo en el contexto procedural de otro. Esto puede comprenderse con el siguiente ejemplo: supongamos que el mdulo A llama al mdulo B suministrndole elementos de datos discretos. La funcin del mdulo B es la de agrupar estos elemento de datos en un tem compuesto y retornrselo al mdulo A (superior). El mdulo B enviar al mdulo A, seales o banderas indicando que necesita que se le suministre otro tem elemental, o para indicarle que le est devolviendo el tem compuesto. Estas banderas sern utilizadas dentro del mdulo A para coordinar su funcionamiento y suministrar a B lo requerido.Cuando un mdulo modifica el contenido procedural de otro mdulo, decimos que existe acoplamiento hbrido. El acoplamiento hbrido es una modificacin de sentencias intermodular. En este caso, para el mdulo destino o modificado, el acoplamiento es visto como de control en tanto que para el mdulo llamador o modificador es considerado como de datos.

El grado de interdependencia entre dos mdulos vinculados con acoplamiento hbrido es muy fuerte. Afortunadamente es una prctica en decadencia y reservada casi con exclusividad a los programadores en assembler.1.4.Tiempo de ligado de conexiones intermodulares"Ligado" o "Binding" es un trmino comnmente 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 ms genricamente, de identificadores a referentes especficos, puede tener lugar en diferentes estadios o perodos en la evolucin del sistema. La historia de tiempo de un sistema puede pensarse como una lnea extendindose desde el momento de la escritura del cdigo fuente hasta el momento de su ejecucin. Dicha lnea puede subdividirse en diferentes niveles de refinamiento segn distintas combinaciones decomputador/lenguaje/compilador/sistema operativo.De esta forma, el ligado puede tener lugar cuando el programador escribe una sentencia en el editor de cdigo fuente, cuando un mdulo es compilado o ensamblado, cuando el cdigo objeto (compilado o ensamblado) es procesado por el "link-editor" o el "link-loader" (generalmente este proceso es el conocido como ligado en la mayora de los sistemas), cuando el cdigo "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 cdigo son fijados ms tarde, el sistema es ms fcilmente modificable y adaptable al cambio de requerimientos.Veamos un ejemplo: supongamos que se nos encomienda la escritura de una serie de programas listadores siendo la impresora a utilizar en principio una del tipo matricial de 80 columnas que funciona con papel contino de 12" de largo de pgina.Alternativas:1.Escribimos el literal "72" en todas las rutinas de impresin de todos los programas. (ligado en tiempo de escritura)2.Reemplazamos el literal por la constante manifiesta LONG_PAG a la que asignamos el valor "72" en todos los programas (ligado en tiempo de compilacin)3.Ponemos la constante LONG_PAG en un archivo de inclusin externo a los programas (ligado en tiempo de compilacin)4.Nuestro lenguaje no permite la declaracin de constantes por lo cual definimos una variable global LONG_PAG a la que le asignamos el valor de inicializacin "72" (ligado en tiempo de link-edicin)

5.Definimos un archivo de parmetros del sistema con un campo LONG_PAG al cual se le asigna el valor "72". Este valor es ledo junto con otros parmetros cuando el sistema se inicia. (ligado en tiempo de ejecucin)6.Definimos en el archivo de parmetros un registro para cada terminal del sistema y personalizamos el valor del campo LONG_PAG segn la impresora que tenga vinculada cada terminal. De esta forma las terminales que tienen impresoras de 12" imprimen 72 lneas por pgina, y las que tienen una impresora de inyeccin de tinta que usan papel oficio, imprimen 80. (ligado en tiempo de ejecucin)

Examinaremos ahora la relacin existente entre el tiempo de ligado y las conexiones intermodulares, y como el mismo afecta el grado de acoplamiento entre mdulos.Nuevamente, una referencia intermodular fijada a un referente u objeto especfico en tiempo de definicin, tendr un acoplamiento mayor a una referencia fijada en tiempo de traslacin o posterior an. La posibilidad de compilacin independiente de un mdulo de otros facilitar el mantenimiento y modificacin del sistema, que si debiera compilarse todos los mdulos juntos. Igualmente, si la link-edicin de los mdulos es diferida hasta el instante previo a su ejecucin, la implementacin de cambios se ver simplificada.

Existe un caso particular de acoplamiento de mdulos derivado de la estructura lexicogrfica del programa. Hablamos en este caso de acoplamiento por contenido.Dos formas de acoplamiento por contenido pueden distinguirse:Inclusin lexicogrfica: se da cuando un mdulo est incluidolexicogrficamente en otro, y es una forma menor de acoplamiento. Los mdulos por lo general no pueden ejecutarse separadamente. Este es el caso en el que el mdulo subordinado es activado en lnea dentro del contexto del mdulo superior.Solapamiento parcial: es un caso extremo de acoplamiento por contenido. Parte del cdigo de un mdulo est en interseccin con el otro. Afortunadamente la mayora de los lenguajes modernos de alto nivel no permiten este tipo de estructuras.

En trminos de uso, mantenimiento, y modificacin, las consecuencias del acoplamiento por contenido son peores que las del acoplamiento de control. El acoplamiento por contenido hace que los mdulos no puedan funcionar uno sin el otro. No ocurre lo mismo en el acoplamiento de control, en el cual un mdulo, aunque reciba informacin de control, puede ser invocado desde diferentes puntos del sistema.

2.ACOPLAMIENTO DE ENTORNO COMN (COMMON-ENVIRONMENT COUPLING)Siempre que dos o ms mdulos interactan con un entorno de datos comn, se dice que dichos mdulos estn enacoplamiento por entorno comn.Ejemplos de entorno comn pueden ser reas de datos globales como la DATA divisin del COBOL, un archivo en disco.El acoplamiento de entorno comn es una forma de acoplamiento de segundo orden, distinto de los tratados anteriormente. La severidad del acoplamiento depender de la cantidad de mdulos que acceden simultneamente al entorno comn. En el caso extremo de solo dos mdulos 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 comn no es necesariamente malo y deba ser evitado a toda costa. Por el contrario existen ciertas circunstancias en que es una opcin vlida.

3.DESACOPLAMIENTOEl concepto de acoplamiento invita a un concepto recproco: desacoplamiento. Desacoplamiento es cualquier mtodo sistemtico o tcnica para hacer ms independientes a los mdulos de un programa.Cada tipo de acoplamiento generalmente sugiere un mtodo de desacoplamiento. Por ejemplo, el acoplamiento causado por ligado, puede desacoplarse cambiando los parmetros apropiados tal lo visto en el ejemplo de el contador de lneas de los programas impresores.

El desacoplamiento, desde el punto de vista funcional, rara vez puede realizarse, excepto en los comienzos de la fase del diseo.Como regla general, una disciplina de diseo que favorezca el acoplamiento de entrada-salida y el acoplamiento de control por sobre el acoplamiento por contenido y el acoplamiento hbrido, y que busque limitar el alcance del acoplamiento por entorno comn es el enfoque ms efectivo.

Otras tcnicas para reducir el acoplamiento son:Convertir las referencias implcitas en explcitas. Lo que puede verse con mayor facilidad es ms fcil de comprender.Estandarizacin de las conexiones.Uso de "buffers" para los elementos comunicados en una conexin. Si un mdulo puede ser diseado desde el comienzo asumiendo que un buffer mediar cada corriente de comunicacin, las cuestiones temporizacin, velocidad, frecuencia, etc., dentro de un mdulo no afectarn el diseo de otros.Localizacin. Utilizado para reducir el acoplamiento por entorno comn. Consiste en dividir el rea comn en regiones para que los mdulos solo tengan acceso a aquellos datos que les son de su estricta incumbencia.

4.UNA APLICACINPara clarificar el concepto de acoplamiento veremos una aplicacin. Debe escribirse un programa que realizar lo siguiente:El programa tendr dos corrientes de entrada: una carcter a carcter desde teclado de una terminal, y la otra registro a registro desde una archivo en disco.Se comienza leyendo los caracteres provenientes de tecla hasta que se recibe el carcter "RETURN", entonces se pasa a leer el archivo registro a registro hasta recibir un registro con "//" en su encabezado, lo cual indica que se vuelve a leer desde teclado.El paso anterior se realiza iterativamente, hasta que se recibe una seal de fin-de-transmisin desde la terminal (EOT). Entonces se contina leyendo el archivo hasta el final (EOF).Las corrientes de datos de ambas entradas se analizarn y separarn en palabras las que se pasarn al mdulo existente ProcWord, el que realizar algo con ellas.

Se comisiona en primer lugar al programador Carlitos para que confeccione el programa, quin realiza el siguiente diagrama de estructura:

Cuando se presenta el problema a la programadora Nadine, ella realiza la siguiente solucin:

Ambas estructuras presentan las siguientes caractersticas en comn:Ambas son normalmente conectadas.Cada una consiste de 5 mdulos y 4 conexiones.La lgica de encontrar palabras ha sido aislada en un mdulo especfico en ambos casos.

Sin embargo analizaremos si ambas estructuras presentan el mismo grado de acoplamiento. Para evaluar esto, necesitaremos mirar el tipo de informacin comunicada entre los mdulos. Es importante notar que determinados flujos pueden comportarse como de datos y de control. Por ejemplo carcter de salida del mdulo INKEY normalmente ser un flujo de datos, pero en el caso especial de que el carcter ser RETURN este funcionar como un flujo de control. En tales circunstancias es conveniente a efectos del estudio considerarlo como distintos flujos.

Como se aprecia en la tabla precedente podemos establecer las siguientes comparaciones: el diagrama de Carlitos tiene 13 flujos de control y 6 de datos, en tanto que el diagrama de Nadine tiene 9 flujos de control y 6 de datos. Obviamente el diagrama la estructura de Carlitos presenta un mayor grado de acoplamiento.Por otro lado la interfaz del mdulo FINDWORD de Carlitos ser bastante ms compleja que la de GETWORD de Nadine debido a la cantidad de parmetros que implica.

ema 04:Tcnicas de CohesinTCNICAS PARA COHESINIntroduccin: Relacin funcionalHemos visto que la determinacin de mdulos en un sistema no es arbitraria. La manera en la cual dividimos fsicamente un sistema en piezas (particularmente en relacin con la estructura del problema) puede afectar significativamente la complejidad estructural del sistema resultante, as como el nmero total de referencias inter modulares.Adaptar el diseo del sistema a la estructura del problema (o estructura de la aplicacin, o dominio del problema) es una filosofa de diseo sumamente importante. A menudo encontramos que elementos de procesamiento del dominio de problema altamente relacionado, son trasladados en cdigo 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 relacin funcional existente entre pares de mdulos. En trminos de tal medida, diremos que sistema ms modularmente efectivo ser aquel cuya suma de relacin funcional entre pares de elementos que pertenezcan a diferentes mdulos sea mnima. Entre otras cosas, esto tiende a minimizar el nmero de conexiones intermodulares requeridas y el acoplamiento intermodular.

Esta relacin funcional intramodular se conoce como cohesin.La cohesin es la medida cualitativa de cuan estrechamente relacionados estn los elementos internos de un mdulo.

Otros trminos utilizados frecuentemente son "fuerza modular", "ligazn", y "funcionalidad".En la prctica un elemento de procesamiento simple aislado, puede estar funcionalmente relacionado en diferentes grados a otros elementos. Como consecuencia, diferentes diseadores, con diferentes "visiones" o interpretaciones de un mismo problema, pueden obtener diferentes estructuras modulares con diferentes niveles de cohesin y acoplamiento. A esto se suma el inconveniente de que muchas veces es difcil evaluar el grado de relacin funcional de un elemento respecto de otro.

La cohesin modular puede verse como el cemento que amalgama juntos a los elementos de procesamiento dentro de un mismo mdulo. Es el factor ms crucial en el diseo estructurado, y el de mayor importancia en un diseo modular efectivo.Este concepto representa la tcnica principal que posee un diseador para mantener su diseo lo ms semnticamente prximo al problema real, o dominio de problema. Claramente los conceptos de cohesin y acoplamiento estn ntimamente relacionados. Un mayor grado de cohesin implica uno menor de acoplamiento. Maximizar el nivel de cohesin intramodular en todo el sistema resulta en una minimizacin del acoplamiento intermodular.

Matemticamente el clculo de la relacin funcional intramodular (cohesin), involucra menos pares de elementos a los cuales debe aplicarse la medida, en comparacin con el clculo de la relacin funcional intermodular (acoplamiento).Ambas medidas son excelentes herramientas para el diseo modular efectivo, pero de las dos la ms importante y extensiva es la cohesin. Una cuestin importante a determinar es como reconocer la relacin funcional. El principio de cohesin puede ponerse en prctica con la introduccin de la idea de un principio asociativo. En la decisin de poner ciertos elementos de procesamiento en un mismo mdulo, el diseador, utiliza el principio de que ciertas propiedades o caractersticas relacionan a los elementos que las poseen. Esto es, el diseador pondr el objeto Z en el mismo mdulo 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 trminos (p.e. "es correcto poner Z junto a X e Y, porque tiene la misma propiedad que ellos") o en trminos 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 cohesin se aplica sobre todo el mdulo, 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 mdulo, la inclusin de Z en el mdulo, redundar en baja cohesin del mismo.

Intencionalmente se ha usado el trmino "elemento de procesamiento" en esta discusin, en lugar de trminos ms comunes como instruccin o sentencia. Porqu:Primero, un elemento de procesamiento puede ser algo que debe ser realizado en un mdulo pero que an no ha sido reducido a cdigo. En orden de disear sistemas altamente modulares, debemos poder determinar la cohesin de mdulos que todava no existen. Segundo, elementos de procesamiento incluyen todas las sentencias que aparecen en un mdulo, no solo el procesamiento realizado por las instrucciones ejecutadas dentro de dicho mdulo, sino tambin las que resultan de la invocacin de subrutinas.

Por ejemplo, las sentencias individuales encontradas en el mdulo B, el cual es invocado desde el mdulo A, NO figuran dentro de la cohesin del mdulo A. Sin embargo el procesamiento global (funcin) realizado por la llamada al mdulo B, es claramente un elemento de procesamiento en el mdulo llamador A, y por lo tanto participa en la cohesin del mdulo A.1.NIVELES DE COHESINDiferentes principios asociativos fueron desenvolvindose a travs de los aos por medio de la experimentacin, argumentos tericos, y la experiencia prctica de muchos diseadores.

Existen siete niveles de cohesin distinguibles por siete principios asociativos. Estos se listan a continuacin en orden creciente del grado de cohesin, de menor a mayor relacin funcional:Cohesin Casual (la peor)Cohesin Lgica (sigue a la peor)Cohesin Temporal (de moderada a pobre)Cohesin de Procedimiento (moderada)Cohesin de Comunicacin (moderada a buena)Cohesin SecuencialCohesin Funcional (la mejor)

Podemos visualizar el grado de cohesin como un espectro que va desde un mximo a un mnimo.1.1.Cohesin Casual (la peor)La cohesin casual ocurre cuando existe poca o ninguna relacin entre los elementos de un mdulo.La cohesin casual establece un punto cero en la escala de cohesin.Es muy difcil encontrar mdulos puramente casuales. Puede aparecer como resultado de la modularizacin 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 confeccin de mdulos casualmente cohesivos, fue la mala prctica de la programacin estructurada, cuando los programadores mal entendan que modularizar consista en cambiar las sentencias GOTO por llamadas a subrutinasFinalmente diremos que si bien en la prctica es difcil encontrar mdulos casualmente cohesivos en su totalidad, es comn que tengan elementos casualmente cohesivos. Tal es el caso de operaciones de inicializacin y terminacin que son puestas juntas en un mdulo superior.

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

1.2.Cohesin Lgica (sigue a la peor)Los elementos de un mdulo estn lgicamente asociados si puede pensarse en ellos como pertenecientes a la misma clase lgica de funciones, es decir aquellas que pueden pensarse como juntas lgicamente.Por ejemplo, se puede combinar en un mdulo simple todos los elementos de procesamiento que caen en la clase de "entradas", que abarca todas las operaciones de entrada.Podemos tener un mdulo que lea desde consola una tarjeta con parmetros de control, registros con transacciones errneas de un archivo en cinta, registros con transacciones vlidas de otro archivo en cinta, y los registros maestros anteriores de un archivo en disco. Este mdulo que podra llamarse "Lecturas", y que agrupa todas las operaciones de entrada, es lgicamente cohesivo.

La cohesin lgica es ms fuerte que la casual, debido a que representa un mnimo de asociacin entre el problema y los elementos del mdulo. Sin embargo podemos ver que un mdulo lgicamente cohesivo no realiza una funcin especfica, sino que abarca una serie de funciones.1.3.Cohesin Temporal (de moderada a pobre)Temporal cohesin significa que todos los elementos de procesamiento de una coleccin ocurren en el mismo perodo de tiempo durante la ejecucin del sistema. Debido a que dicho procesamiento debe o puede realizarse en el mismo perodo de tiempo, los elementos asociados temporalmente pueden combinarse en un nico mdulo que los ejecute a la misma vez. Existe una relacin entre cohesin lgica y la temporal, sin embargo, la primera no implica una relacin de tiempo entre los elementos de procesamiento.

La cohesin temporal es ms fuerte que la cohesin lgica, ya que implica un nivel de relacin ms: el factor tiempo. Sin embargo la cohesin temporal an es pobre en nivel de cohesin y acarrea inconvenientes en el mantenimiento y modificacin del sistema.Un ejemplo comn de cohesin temporal son las rutinas de inicializacin (start-up) comnmente encontradas en la mayora de los programas, donde se leen parmetros de control, se abren archivos, se inicializan variables contadores y acumuladores, etc.

1.4.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 Nassi-Shneiderman.

1.5.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 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, 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 mdulo que imprima o grabe un archivo de transaccionesUn mdulo que reciba datos de diferentes fuentes, y los transforme y ensamble en una lnea de impresin.

1.6.Cohesin SecuencialEl siguiente nivel de cohesin en la escala es la asociacin secuencial. En ella, los datos de salida (resultados) de un elemento de procesamiento sirven como datos de entrada al siguiente elemento de procesamiento. En trminos de un diagrama de flujo de datos de un problema, la cohesin secuencial combina una cadena lineal de sucesivas transformaciones de datos. Este es claramente un principio asociativo relacionado con el dominio del problema.

1.7.Cohesin Funcional (la mejor)En el lmite superior del espectro de relacin funcional encontramos la cohesin funcional. En un mdulo completamente funcional, cada elemento de procesamiento, es parte integral de, y esencial para, la realizacin de una funcin simple. En trminos prcticos podemos decir que cohesin funcional es aquella que no es secuencial, por comunicacin, por procedimiento, temporal, lgica, o casual.

Los ejemplos ms claros y comprensibles provienen del campo de las matemticas. Un mdulo para realizar el clculo de raz cuadrada ciertamente ser altamente cohesivo, y probablemente, completamente funcional. Es improbable que haya elementos superfluos ms all de los absolutamente esenciales para realizar la funcin matemtica, y es improbable que elementos de procesamiento puedan ser agregados sin alterar el clculo de alguna forma. En contraste un mdulo que calcule raz cuadrada y coseno, es improbable que sea enteramente funcional (deben realizarse dos funciones ambiguas).

En adicin a estos ejemplos matemticos obvios, usualmente podemos reconocer mdulos funcionales que son elementales en naturaleza. Un mdulo llamado LEER-REGISTRO-MAESTRO, o TRATAR-TRANS-TIPO3, presumiblemente sern funcionalmente cohesivos, en cambio TRATAR-TODAS-TRANS presumiblemente realizar ms de una funcin y ser lgicamente cohesivo.

2.CRITERIOS PARA ESTABLECER EL GRADO DE COHESINUna tcnica til para determinar si un mdulo est acotado funcionalmente es escribir una frase que describa la funcin (propsito) del mdulo y luego examinar dicha frase. Puede hacerse la siguiente prueba:1.Si la frase resulta ser una sentencia compuesta, contiene una coma, o contiene ms de un verbo, probablemente el mdulo realiza ms de una funcin; por tanto, probablemente tiene vinculacin secuencial o de comunicacin.

2.Si la frase contiene palabras relativas al tiempo, tales como "primero", "a continuacin", "entonces", "despus", "cuando", "al comienzo", etc., entonces probablemente el mdulo tiene una vinculacin secuencial o temporal.3.Si el predicado de la frase no contiene un objeto especfico sencillo a continuacin del verbo, probablemente el mdulo est acotado lgicamente. Por ejemplo editar todos los datos tiene una vinculacin lgica; editar sentencia fuente puede tener vinculacin funcional.4.Palabras tales como "inicializar", "limpiar", etc., implican vinculacin temporal.

Los mdulos acotados funcionalmente siempre se pueden describir en funcin de sus elementos usando una sentencia compuesta. Pero si no se puede evitar el lenguaje anterior, siendo an una descripcin completa de la funcin del mdulo, entonces probablemente el mdulo no est acotado funcionalmente.Es importante notar que no es necesario determinar el nivel preciso de cohesin. En su lugar, lo importante es intentar conseguir una cohesin alta y saber reconocer la cohesin baja, de forma que se pueda modificar el diseo del software para que disponga de una mayor independencia funcional.

3.COMPARACIN DE NIVELES DE COHESINUtilizaremos el problema representado en la siguiente figura para ilustrar una variedad de particionamientos del mismo problema, correspondiente a diferentes niveles de cohesin. Es fcil presentar ejemplos de cohesin casual y lgica particionando el diagrama de flujo de datos. El mdulo "HacerAlgo" es un ejemplo de cohesin casual. Los mdulos "FormatearReportes" y "Editar_y_Validar" son ejemplos de cohesin lgica. Debido a que el DFD es inherentemente no procedural, es un tanto difcil visualizar en l relaciones temporales y procedurales. Dos posibilidades seran los mdulos "Comenzar" (temporal) y "SumLoop" (procedural).

Cohesin secuencial y de comunicacin es fcilmente visible en un DFD. Los mdulos "DoCombo" y "ObtenerMaestroVlido" son ejemplos de cohesin de comunicacin y secuencial respectivamente.La identificacin de cohesin funcional presenta una vez ms dificultades. En un nivel superficial, la cohesin funcional sera equivalente a que cada transformacin del DFD se corresponda con un mdulo, pero un particular arreglo de estos en una jerarqua influencia la cohesin actual de mdulos. Estos problemas pueden comprenderse mejor con los conceptos estratgicos introducidos en el captulo dedicado a morfologas y metodologas.

HacerAlgo: cohesin casualEditar_y_Validar: cohesin lgicaFormatearReportes: Cohesin lgica

Comenzar: cohesin temporalSumLoop: cohesin procedural

ObtenerMaestroVlido: cohesin secuencialDoCombo: cohesin de comunicacin

4.MEDICIN DE COHESINCualquier mdulo, rara vez verifica un solo principio asociativo. Sus elementos pueden estar relacionados por una mezcla de los siete niveles de cohesin. Esto lleva a tener una escala continua en el grado de cohesividad ms que una escala con siete puntos discretos.Donde existe ms de una relacin entre un par de elementos de procesamiento, se aplica el mximo nivel que alcanzan. Por esto, si un mdulo presenta cohesin lgica entre todos sus pares de elementos de procesamiento, y a su vez presenta cohesin de comunicacin tambin entre todos dichos pares, entonces dicho mdulo es considerado como de cohesin por comunicacin.

Ahora, cul sera la cohesin de dicho mdulo si tambin contiene algn par de elementos completamente no relacionados? En teora, debera tener algn tipo de promedio entre la cohesin de comunicacin y la casual. Para propsitos de depuracin, mantenimiento, y modificacin, un mdulo se comporta como si fuera "solo tan fuerte como sus vnculos ms dbiles".El efecto sobre los costos de programacin es prximo al menor nivel de cohesin aplicable dentro del mdulo en vez del mayor nivel de cohesin.

La cohesin de un mdulo es aproximada al nivel ms alto de cohesin que es aplicable a todos los elementos de procesamiento dentro del mdulo.

Un mdulo puede consistir de varias funciones completas relacionadas lgicamente. Esto es definitivamente ms cohesivo que un mdulo que liga lgicamente fragmentos de varias funciones.

La decisin de que nivel de cohesin es aplicable a un mdulo dado requiere de cierto juicio humano. Algunos criterios establecidos son:La cohesin secuencial es ms prxima al ptimo funcional que a su antecesor de comunicacin.Similarmente existe un salto mayor entre la cohesin lgica y la temporal que entre casual y lgica.

Podemos asignar la siguiente escala de valores para ayudar al diseador en la calificacin de niveles:0: casual1: lgica3: temporal5: procedural7: de comunicacin9: secuencial10: funcional

De cualquier modo, esta escala est basada en la experiencia de los autores, y no es una regla fija, si no una conclusin.La obligacin del diseador es conocer los efectos producidos por la variacin en la cohesin, especialmente en trminos de modularidad, en orden de realizar soluciones de compromiso beneficiando un aspecto en contra de otro.