INTRODUCCINa)Presentacin y contextualizacinEn esta unidad aprender los conceptos principales sobre anlisis de transaccin transformacin. Para poder entender y aplicar los conceptos de anlisis de transaccin y transformacin debemos saber las estrategias que se utilizan, la obtencin del diagrama de flujo de datos ylos pasos a seguir tambin veremos empaquetamiento y optimacin.b)CompetenciaDisea sistemas eficaces utilizando el mnimo de tiempo para su construccin yseleccionando los temas necesarios.c)Capacidades1.Comprende y aplica los conceptos de transaccin.2.Disea base de datos utilizando el mtodo de transformacin.3.Explica la importancia del empaquetamiento de diseo en un sistema.4.Utiliza adecuadamente la optimizacin en los diseos que realiza.d) ActitudesMuestra habilidad para las matemticas y la lgica.Posee capacidad de identificar y analizar problemas.Se interesa por conocer y disear nuevos programas sistemticos.e) Presentacin de Ideas bsicas y contenido esenciales de la unidad:La Unidad de Aprendizaje 03: Mtodos de anlisis de diseo estructurado, comprende el desarrollo de los siguientes temas:TEMA 01:Anlisis de transaccin.TEMA 02:Anlisis de transformacin.TEMA 03:Empaquetamiento (packaging).TEMA 04:Optimizacin.Tema 01:Anlisis de transaccin1. INTRODUCCINEn este captulo exploramos la estrategia del anlisis de transaccin como la estrategia principal para el diseo de programas y sistemas bien estructurados. En verdad, el anlisis de transformacin, servir de gua en el diseo de la mayora de los sistemas. Sin embargo hay numerosas situaciones en las cuales estrategias adicionales pueden utilizarse para suplementar, y an reemplazar, el enfoque bsico del anlisis de transformacin.Una de estas estrategias suplementarias principales se conoce como Anlisis de Transaccin.

El anlisis de transaccin es sugerido por un DFD del siguiente tipo:

En este DFD existe una transformacin que bifurca la corriente de datos de entrada en varias corrientes de salida discretas. En muchos sistemas tal transformacin puede ocurrir dentro de la transformacin central. En otros, podremos encontrarla tanto en las ramas aferentes como eferentes del diagrama de estructura.

La frase anlisis de transaccin sugiere que construiremos un sistema alrededor del concepto de "transaccin", y para muchos la palabra transaccin est asociada con sistemas administrativos. Esto si bien es cierto, es comn encontrar centros de transaccin en los sistemas administrativos, tambin pueden encontrarse en otro tipo de sistemas como ser los de tiempo real, aplicaciones de ingeniera, etc.Un factor importante es como definimos el trmino transaccin. En el sentido ms general podemos decir:Una transaccin es cualquier elemento de datos, control, seal, evento, o cambio de estado, que causa, dispara, o inicia alguna accin o secuencia de acciones.

Acorde a esta definicin, un gran nmero de situaciones encontradas en aplicaciones de procesamiento de datos comunes pueden ser consideradas transacciones. Por ejemplo cualquiera de los siguientes casos pueden considerarse transacciones:El operador presiona el botn de inicio de un dispositivo de entrada.Algn tipo de datos de entrada que designe un ingreso en el inventario.Un carcter de escape desde una terminal, indicando la necesidad de un procesamiento especial.Una interrupcin de hardware ante un ndice fuera de los rangos definidos dentro de un programa de aplicacin.Un cuelgue o descuelgue de telfono para un sistema de control de llamadas telefnicas.

1.Estrategia del Anlisis de Transaccin1.1 Centro de transaccinLa estrategia del anlisis de transaccin, simplemente reconoce que los DFD de la forma planteada previamente pueden mapearse en una estructura de programa particular.

Un centro de transaccin de un sistema debe ser capaz de:oObtener o responder a transacciones en forma "cruda"oAnalizar cada transaccin para determinar su tipooDespachar acorde al tipo de transaccinoCompletar el procesamiento de cada transaccin

En la forma ms factorizada, el centro de transaccin puede ser modularizado de la siguiente manera:

La raz de esta estructura (transaccin), puede estar subordinada a cualquier parte de un sistema mayor. Cada un de los mdulos "Obtener Trans.", "Analizar Trans.", "Hacer tipo 1", "Hacer tipo n", pueden ser en s mismas races de subsistemas enteros.

En forma ortodoxa, la subestructura debajo del mdulo de despacho puede ser modelada en un sistema de cuatro niveles. Estos niveles son los siguientes:Procesador de transaccin (o nivel P)Nivel de Transaccin (o nivel T)Nivel de Accin (o nivel A)Nivel de Detalle (o nivel D)

En la forma ortodoxa, el procesador de transacciones (Despachador) esperar recibir una transaccin desde su subordinado cuando sea activado. Un sistema puede incluir cualquier nmero de centros de transaccin. Un centro de transaccin puede estar ubicado en una rama aferente, de transformacin, o eferente.

Las salidas del centro de transaccin pueden consistir de:Una versin convertida o formateada de la transaccinentrante, las cuales pueden ser pasadas hacia arriba para alimentar niveles superiores de procesos aferentes.Una simple bandera indicando cuando la transaccin entrante fue vlida. Podemos esperar encontrar este tipo de forma de validacin frecuentemente en las ramas aferentes.Resultados computados basados en el procesamiento de la transaccin entrante. Los resultados pueden pasarse hacia arriba al mdulo superior para ser utilizados en otras transformaciones centrales , o hacia abajo hacia los niveles inferiores de procesos eferentes.Una forma actualizada (modificada) de un elemento o elementos de datos base, internos o externos.

1.2 La estrategiaUtilizando las figuras previas como modelos, podemos resumir los pasos de la estrategia del anlisis de transaccin como sigue:1.Identificar las fuentes de transaccin. En muchos casos, las transacciones sern mencionadas explcitamente en la definicin del problema, en cuyo caso ser usual asumir que las transacciones provienen de un medio fsico de entrada. En otros casos, el diseador puede tener que reconocer mdulos aferentes, eferentes, o de transformacin que generen transacciones. Esto puede hacerse ms obvio luego de los primeros pasos de factorizacin de un diseo centrado en la transformacin. Ms de una corriente de transaccin puede alimentar el mdulo de nivel P, las cuales pueden mezclarse desde diferentes direcciones (p.e. aferentes y eferentes). Las corrientes de transaccin pueden tambin mezclarse con corrientes de datos no transaccionales.2.Especificar la organizacin centrada en la transaccin apropiada. La figura planteada puede ser un buen modelo, pero el diseador deber sentirse libre de alterarla como considere necesario, basndose en la teora y las heursticas vistas.3.Identificar las transacciones y sus acciones definidas. De nuevo, a menudo encontraremos que todos los requisitos de informacin sern provistos por la definicin del problema mismo. Si las transacciones son generadas internamente por el sistema, el diseador deber definir cuidadosamente el proceso a realizar para cada transaccin.

4.Identificar situaciones potenciales en que puedan combinarse mdulos. Como en el caso del anlisis de transformacin, podemos encontrar situaciones en las que un mdulo de nivel intermedio pueda ser creado desde un grupo funcionalmente cohesivo de mdulos de bajo nivel. Esta combinacin puede ser apropiada en situaciones en las que la sintaxis o semntica de varias transacciones es similar.5.Para cada transaccin, o coleccin cohesiva de transacciones, especificar un mdulo de transaccin para procesarlo completamente. Debido a que las transacciones en un sistema son a menudo similares, existe una tentacin a agrupar el procesamiento de varias transacciones en un mdulo. Esto deber evitarse si el mdulo resultante tiene baja cohesin. Trataremos evitar mdulos con solo cohesin de comunicacin, o lgica.6.Para cada accin en una transaccin, especificar un mdulo de accin subordinado al mdulo de transaccin correspondiente. En esencia esto es un paso de factorizacin tal como se vio anteriormente. Debe notarse que pueden existir muchas oportunidades para que mdulos de transaccin compartan mdulos de accin comunes.7.Para cada paso detallado en un mdulo de accin, especificar un mdulo de detalle subordinado a algn mdulo de accin que lo necesite. Claramente esto es una continuacin del proceso de factorizacin. Para un sistema grande con transacciones complejas, podremos tener varios niveles de mdulos de detalle. En adicin, debe tenerse en mente que mdulos de accin similares pueden compartir mdulos de detalle siempre que sea posible.A travs de este proceso, el diseador ser guiado por los principios de cohesin, acoplamiento, y las heursticas de diseo. Adems el diseador deber recordar el principio fundamental mencionado repetidamente: La estructura del sistema deber reflejar lo ms cercanamente posible la estructura del problema.

2.Ejemplo de anlisis de transaccinEjemplo: Liquidacin de sueldos.Se debe realizar liquidacin de haberes de sueldo del personal. Para ello se dispone de tres archivos que contienen los datos necesarios, Empleados, Escalafones, y DatosBases.

La estructura de estos almacenes es la siguiente:EMPLEADOS = {Empleado}Empleado = n_legajo + cod_escalafon + datos_personalesESCALAFONES = {Escalafn}Escalafn = @cod_escalafon + descripcin + {cod_cpto}DATOSBASES = {DatoBase}DatoBase = @cod_cpto + datos_bsicosEl proceso debe generar la liquidacin en dos archivos: Liq_Cabeceras y Liq_Detalles, cuyas estructuras son las siguientes:LIQ_CABECERAS = {Liq_Cabecera}Liq_Cabecera = n_legajo + tot_cptosLIQ_DETALLES = {Liq_Detalle}Liq_Detalle = n_legajo + cod_cpto + imp_cpto

Diagrama de flujo de datos

Primer nivel de Factorizacin

Final

3.Consideraciones especiales en el Procesamiento de TransaccionesLas ideas de la estrategia del anlisis de transaccin son muy familiares a la mayora de profesionales de EDP. Muchos han intentado utilizar estos principios para organizar sistemas enteros. La experiencia ha establecido que dichos sistemas son ms sencillos de organizar en principio, pero son ms difciles de modificar y mantener posteriormente.

En el caso lmite, el mdulo ejecutivo de mayor nivel puede ser el centro de transaccin. Por lo tanto, todas las transacciones sern consolidadas en el mdulo ejecutivo en una organizacin input-driven. Esto puede mezclar tambin transacciones de diferentes tipos y niveles de importancia, para el sistema. Esto llevar a que el mdulo ejecutivo sea poco cohesivo.Un ejecutivo, el cual es el centro de transaccin, no controla el flujo general del proceso, sino que est involucrado en detalles procedurales para realizar alguna parte de la tarea general.

3.1 Estado de dependencia en Procesadores de TransaccinUn caso especial se tiene cuando el procesamiento de transaccin incorpora un proceso de decisin estado-dependiente, esto ocurre cuando la salida de una determinada decisin depende no solo de los datos de entrada, sino adems de los valores ingresados anteriormente. Por ejemplo una transaccin tipo X podr ser procesada como tipo X o tipo Y, dependiendo de que una transaccin del tipo A haya sido procesada correctamente antes.

3.2 Procesamiento de Transacciones Sintctico y SemnticoEntenderemos por elementos sintcticos, aquellos aspectos de procesamiento relacionados a la forma que toma la transaccin. Entenderemos por semntico, las acciones resultantes: el "que" y el "como".

Validando el formato de la transaccin proveniente de la rama aferente (Obtener y Analizar), y convirtindola a un cdigo interno, el resto del sistema Transaccin, Despachar, y los superiores a Transaccin, pueden ser escritos para que operen independientemente de la forma que la transaccin tome.De esta manera es sencillo cambiar la apariencia y el procesamiento de la transaccin de modo independiente uno de otro. En adicin, los mdulos de procesamiento de transaccin, pueden ser usados correctamente con transacciones obtenidas en otros formatos desde fuentes completamente diferentes.

3.3 Efecto de colocar centros de transaccin a diferentes niveles en la jerarquaEn algunos casos, el diseador se encuentra diseando un sistema con solo un centro de transaccin, pero con varias opciones concernientes a la ubicacin del centro de transaccin dentro de la jerarqua. Es posible, y a veces tentador, ubicar el centro de transaccin en el mdulo ejecutivo de mximo nivel. Esto es generalmente una idea pobre, por razones de acoplamiento y cohesin. Entonces, dnde debe ubicarse el centro de transaccin? Finalmente, acoplamiento y cohesin son los mejores criterios para decidir dnde ubicarlo.

De cualquier modo, existe un aspecto filosfico de esta decisin que el diseador debe tener en mente: ubicar el centro de transaccin alto en la jerarqua, refleja la decisin del diseador de permitir que el entorno (aquello que existe fuera del sistema de computadora) controle al sistema. Contrariamente, ubicar el centro de transaccin en los niveles bajos de la jerarqua, refleja el deseo del diseador de que el sistema control el entorno.

Por qu esto es as? Debe recordarse que el centro de transaccin es un punto a partir del cual distintos tipos de procesamientos tendrn lugar, dependiendo de la naturaleza precisa de un elemento de datos. Por lo tanto, es el centro de transaccin (el mdulo de nivel P) est en el tope de la jerarqua, es anlogo a que el presidente de una compaa diga: "No conozco a qu tipo de situaciones se enfrentar la corporacin en los prximos milisegundos, pero yo quiero responder apropiadamente".

Si el centro de transaccin se ubica cerca del nivel inferior de la jerarqua, entonces el tope de la jerarqua se organizar de modo acorde a las recomendaciones del mtodo de Anlisis de Transformacin. En este caso, el mdulo ejecutivo es anlogo a un administrador que conoce precisamente que datos espera de sus subordinados, y exactamente qu hacer con dichos datos. Esto es ms aproximado al caso en que el administrador controla el entorno, ms que el caso en que el entorno lo controle a l.

Algunos diseadores piensan que la cuestin del control sobre el entorno es meramente un reflejo de opcin entre un sistema batch o un sistema en-lnea o en tiempo real. Esto NO es as. Un sistema en lnea puede tener sus centros de transaccin cerca del tope y en el nivel inferior de la jerarqua. Si es ubicado cerca del tope de la jerarqua, refleja el deseo del diseador de hacerlo tan interactivo como sea posible.

Esto es como decir en un sistema en lnea: "no tengo idea de qu es lo que el usuario va a tipear en la terminal, pero voy a realizar sus comandos". Un sistema en lnea que tenga su centro de transaccin cerca del nivel bajo de la jerarqua, refleja el deseo del diseador de guiar al usuario de terminal a travs de un dialogo ordenado para que realice lo que el sistema quiere que realice. Los mdulos de nivel superior de este tipo de sistema forzarn al usuario a que suministre las entradas que el sistema desea.

De modo similar los sistemas batch (en lote) pueden tener el centro de transaccin alto o bajo en la jerarqua segn la filosofa del diseador.Sin emanar juicios de valoracin sobre que filosofa utilice el diseador, diremos que finalmente los principios de acoplamiento y cohesin sern los rbitros finales de lo bueno o malo que sea el sistema.Un buen ejemplo de un sistema en lnea en el cual el entorno controla al sistema son los monitores de teleproceso en los sistemas mainframe, o los shell de comandos en Unix.

Tema 02:Anlisis de transformacinINTRODUCCINEn el captulo anterior hemos visto que los sistemas cuya morfologa o forma est centrada en la transformacin, tienden a ser asociados con bajos costos de desarrollo, mantenimiento, y modificacin. Hemos visto tambin que los sistemas altamente factorizados tienden a ser econmicos.Los mdulos de alto nivel toman la mayora de las decisiones, y los mdulos inferiores realizan el trabajo de detalle:El anlisis de transformacin, o diseo centrado en la transformacin, es una estrategia para derivar diseos estructurados que son bastante buenos (con respecto a su modularidad) y que necesitan solo una modesta reestructuracin para arribar al diseo final.

Es una forma particular de la estrategia descendente (top-down), que toma ventaja de la perspectiva global. Aplicado rigurosamente, el anlisis de transaccin conduce a estructuras que son altamente factorizadas. Produce un nmero variable de mdulos en los niveles intermedios de la jerarqua, los cuales representan composicin de funciones bsicas.Siempre se trata de evitar que los mdulos intermedios realicen cualquier "trabajo" excepto el de control y coordinacin de sus subordinados.

El propsito de la estrategia es el de identificar las funciones de procesamiento primarias del sistema, las entradas de alto nivel de dichas funciones, y las salidas de alto nivel. Se crean mdulos de alto nivel dentro de la jerarqua que realizan cada una de estas tareas: creacin de entradas de alto nivel, transformacin de entradas en salidas de alto nivel, y procesamiento de dichas salidas.El anlisis de transformacin es un modelo de flujo de informacin ms que un modelo procedural.

La estrategia de anlisis de transformacin consiste de cuatro pasos principales:1.plantear el problema como un diagrama de flujo de datos2.identificar los elementos de datos aferentes y eferentes3.factorizacin del primer nivel4.factorizacin de las ramas aferente, eferente, y de transformacin

1. El primer paso: obtencin del diagrama de flujo de datos del problemaEn orden de llevar adelante la estrategia del anlisis de transformacin, es necesario estudiar el flujo de datos a travs del sistema. Para esto debemos dibujar un diagrama de flujo de datos (DFD) del sistema que estamos diseando.Una cuestin de importancia es como debe realizarse el diagrama de flujo. Hay varios enfoques para este proceso analtico.Ante todo debemos tener en cuenta que un DFD no es un modelo procedural.Algunos diseadores experimentados en el uso de DFDs, generalmente comienzan con las entradas fsicas (p.e. un mensaje desde una terminal) y trabajan dichas entradas "corriente abajo" a travs de las sucesivas transformaciones hasta llegar a las salidas fsicas.Otra estrategia, es partir de las salidas y seguir el flujo "hacia arriba", hasta llegar a las entradas fsicas.

La adopcin de uno de los dos enfoques es ms cuestin de preferencia del diseador que una cuestin tcnica.Desafortunadamente, muchos novatos en el uso de DFDs encuentran que estos dos enfoques tienden a "perderlos" en los detalles procedurales, los cuales deben dejarse de lado en este momento.

Una estrategia es comenzar con una burbuja de alto nivel, e ir explotndola en sucesivos refinamientos. Esto es un ejercicio til de pensamiento descendente.La cantidad de detalle mostrada depender del problema y del diseador, aunque es aconsejable llegar a un considerable nivel de detalle en la etapa de diseo.En el dibujo de un DFD es esencial no enmaraarse en aspectos de procedimiento o toma de decisiones. El diagrama no debe mostrar cosas como iteraciones, inicializacin, terminacin, decisiones, o procedimientos de recuperacin.

SUGERENCIAS PARA LA REALIZACIN DE DFDS:Desarrolle consistentemente el problema, desde las corrientes de entrada hacia las salidas o viceversa, dependiendo de su preferencia. Utilice el pensamiento descendente para descomponer tareas no triviales.Nunca intente mostrar lgica de control. Si se encuentra pensando en trminos de iteraciones o decisiones, est en el rumbo equivocado. Recordar siempre que las flechas representan flujos de datos, no de control.Ignore los procedimientos de inicializacin y terminacin en este momento.Omita el tratamiento de errores simples.Etiquete cuidadosamente los flujos que entran y salen de las burbujas.Asegrese de que el uso de los operadores * y + es el correcto.Asegrese de que el flujo de datos es el correcto para el nivel de detalle que est mostrando. En caso de duda es preferible mucho detalle a poco detalle.

2.El Segundo Paso: Identificar los Elementos de Datos Aferentes y EferentesEn la discusin de morfologa de sistemas, introducimos los conceptos de flujo de datos aferente y flujo de datos eferente. Vimos tambin que los mdulos pueden categorizarse en funcin de sus tipos de flujos en mdulos aferentes y mdulos eferentes.

Definiremos ahora elementos aferentes de datos: son aquellos elementos de datos de alto nivel que habiendo sido removidos de sus entradas fsicas, todava pueden considerarse entradas al sistema.Por lo tanto, los elementos aferentes de datos son el nivel ms alto de abstraccin para el trmino "entradas al sistema". Representan el ms alto nivel de entradas.

En general, los elementos de dato aferentes deben tener la menor resemblanza posible con lo datos de entrada "crudos" obtenidos de sus entradas fsicas. Esto es, el bloqueo fsico, los caracteres de control, debe ser removido. Solo datos limpios para el proceso deben permanecer.Identificaremos los elementos aferentes de dato comenzando en las entradas fsicas al sistema, y siguiendo los flujos de datos en el diagrama hasta que identifiquemos que la corriente de datos no pueda ser considerada como entrante. Esto implica un juicio de valor por parte del diseador; la idea es llegar lo ms lejos posible de las entradas fsicas.Este proceso se realizar para cada corriente de entrada. A menudo encontraremos que varias corrientes fsicas de entrada finalizarn en el mismo elemento de dato eferente.

Comenzando en el extremo opuesto con las salidas fsicas, trataremos de identificar los elementos eferentes de datos. Esto lo realizaremos siguiendo los elementos de datos desde sus salidas fsicas a travs de los flujos, hasta que no puedan seguir siendo considerados como datos de salida del sistema.Estos elementos pueden ser considerados como "datos lgicos de salida", que han sido producido por el "proceso central" del sistema, y los cuales sern convertido en "datos fsicos de salida". Realizaremos este proceso con cada corriente de salida.

Este proceso tambin implica un juicio de valor por parte del diseador; la idea es llegar lo ms lejos posible de las salidas fsicas.Este proceso de identificar elementos aferentes y eferentes dejar algunas transformaciones en el medio entre dichos elementos. Estas son denominadas transformaciones centrales.Ellas son el trabajo principal del sistema. Ellas transforman las entradas principales del sistema, en las mayores salidas.Ocasionalmente los elementos aferentes y eferentes de datos pudieran ser los mismos. En tal caso no existen transformaciones centrales.Podra pensarse este paso es un intento de modelizar todos los sistemas con un flujo IPO trivial. En verdad, la mayora de los sistemas pueden pensarse de esta manera, al fin todos tienen alguna entrada, realizan alguna transformacin, y emiten alguna salida. Sin embargo la importancia de este enfoque radica en que muchos diseadores tienden a concentrarse demasiado en las corrientes de entrada generar sistemas input-driven. Este enfoque permite obtener sistemas balanceados.

3.El tercer paso: Factorizacin del primer nivelHabiendo identificado los elementos aferentes y eferentes de datos del sistema, especificaremos un mdulo principal, el cual al ser activado, realizar todas las tareas del sistema invocando a sus subordinados.Para cada elemento de datos aferente que alimente a la transformacin central, se especificar un mdulo aferente como subordinado inmediato del mdulo principal. Su funcin final ser la de suministrar al mdulo principal el elemento aferente de datos.

Similarmente, para cada elemento eferente de datos, definiremos un mdulo eferente subordinado al mdulo principal. Dicho mdulo transformar el elemento eferente de datos en las salidas fsicas finales.

Finalmente, para cada transformacin central, o composicin funcionalmente cohesiva de transformaciones centrales, especificaremos un mdulo de transformacin subordinado al mdulo principal, el cual aceptar desde el mdulo principal los datos de entrada apropiados y los transformar en los datos de salida apropiados, los cuales sern devueltos al mdulo principal.Por lo general veremos que existe una correspondencia simple (usualmente uno a uno) entre el diagrama de flujo de datos y el nivel de factorizacin inicial.El mdulo principal en el controlador principal o ejecutivo del proceso. Su funcin es controlar y coordinar los mdulos aferentes, de transformacin, y eferentes, tratando con los datos de mximo nivel del sistema.Este mdulo llamar a los mdulos aferentes para obtener las principales entradas del sistema, pasar dichas entradas a mdulos de transformacin, entregar los resultados de estos a otros mdulos de transformacin, y finalmente a los mdulos eferentes. Este proceso de invocaciones involucrar las mayores decisiones e iteraciones lgicas del proceso general del sistema.

4. El cuarto paso: Factorizacin de los flujos aferentes, eferentes y de transformacinTres estrategias distintas son usadas para factorizar los tres tipos de mdulos subordinados (aferente, eferente, y de transformacin) en mdulos subordinados de bajo nivel.No existe una razn particular para comenzar con la porcin aferente del sistema, pero muchos diseadores lo encuentran una forma ms natural de proceder.No es necesario factorizar completamente una rama hasta el menor nivel de detalle antes de continuar con otra rama, pero si es importante identificar todos los mdulos subordinados de un mdulo dado antes de comenzar con otro mdulo.

Factorizacin del mdulo aferente: para factorizar un mdulo aferente, debe considerarse que este provee a su mdulo superior informacin elaborada a travs de algn tipo de transformacin. Por esto el mdulo aferente tendr como subordinado uno o ms mdulos de transformacin. A su vez esta transformacin recibir sus datos de algn(os) mdulo(s) aferentes subordinados al mdulo aferente principal. Cada uno de estos nuevos mdulos aferentes puede ser descompuesto de igual manera a la indicada.Factorizacin del mdulo eferente: la factorizacin del mdulo eferente principal, es esencialmente simtrica a la del mdulo aferente. Para un mdulo eferente dado, buscamos la siguiente transformacin a ser aplicada que nos aproximar los datos a su forma ltima de salida. Por lo tanto existir un mdulo de transformacin subordinado al mdulo eferente principal. La salida de este mdulo de transformacin alimentar la entrada de un nuevo mdulo eferente. Naturalmente, puede haber ms de una "siguiente transformacin" y ms de un mdulo eferente siguiente.Factorizacin de los mdulos de transformacin central: poco es conocido acerca del la factorizacin ptima de los mdulos de transformacin central. Obviamente, para cada transformacin, buscaremos sub transformaciones que compondrn la transformacin total. Buscaremos tambin composiciones o grupos de funciones mostradas como transformaciones centrales en el DFD original. Estas se insertarn como mdulos intermedios en la jerarqua entre el nivel superior y las funciones que componen el grupo.El juicio y la experiencia del diseador, son guiados en este proceso, por consideraciones de cohesin y acoplamiento como as tambin por varias heursticas que se estudiarn posteriormente.

5. El quinto paso: DesviacionesLa estrategia descripta asume una estructura ortodoxa en la cual el flujo de datos es entrante o saliente en cualquier rama, pero nunca los ambos a la vez. Consecuentemente, se espera que los mdulos aferentes tengan solo subordinados aferentes y de transformacin. Similarmente, los mdulos eferentes tendrn solo subordinados eferentes y de transformacin, y los mdulos de transformacin (ms all de donde se encuentren en la estructura) solo tendrn subordinados de transformacin.

Sin embargo, los problemas del mundo real, frecuentemente requieren excepciones a estas reglas para evitar procesos torpes.Por ejemplo, si un determinado mdulo aferente produce un flujo que es utilizado solo en casos muy especiales, ser normal ubicar este mdulo ms abajo en la estructura subordinado al mdulo que requiera dicho flujo de excepcin, ya que hacerlo depender directamente del mdulo superior resultara artificial.Debe tenerse en mente que el objetivo, tal lo planteado anteriormente, es tratar que la estructura de programa refleje la estructura del problema lo ms cercanamente posible. Un DFD detallado es una gua para la estructura del problema, y si los requerimientos del problema necesitan una desviacin de la organizacin centrada en la transformacin ortodoxa, esta debe aparecer en el diagrama.

6.Como finalizar la factorizacinVarios criterios pueden utilizarse para determinar cuando la factorizacin funcional de mdulos debe terminarse. El fin puede alcanzarse cuando para una transformacin es difcil distinguir claramente subtareas.Cuando un mdulo de terceras partes (funcin de biblioteca) es alcanzado, no puede continuarse factorizando.Similarmente cuando se alcanza un mdulo con interfaces directas a seales fsicas de entrada / salida, significa el fin de la factorizacin.Finalmente, cuando identificamos mdulos muy pequeos, puede ser un indicativo de que se ha alcanzado el nivel ms bajo de la estructura.

Tema 03:Empaquetamiento (packaging)INTRODUCCINTrataremos ahora dos pasos prcticos en el diseo de un sistema modular funcional. Finalmente, debemos lograr que el sistema "entre" en el espacio de memoria fsica disponible, y por otro lado deben implementarse los procesos de entrada-salida en los dispositivos fsicos actuales. Estos dos pasos conciernen a la implementacin fsica del sistema en el recurso computacional que se dispone.El empaquetado se refiere a la asignacin de mdulos del sistema en secciones manejadas como distintas unidades fsicas de ejecucin sobre la mquina.Cada una de estas unidades se llama unidades de carga, y sern consideradas como una porcin del sistema procesadas como una unidad por el sistema operativo.Dependiendo del sistema computacional, las unidades de carga toman diferentes denominaciones: "programas", "overlays", "mdulo de carga", "paso de trabajo" (job step), etc.

Histricamente las limitaciones de memoria y velocidad de ejecucin, condicionaron el diseo. Esto produca como consecuencia una disminucin de la modularidad del sistema.Como regla general, no podemos minimizar simultneamente tamao de memoria y tiempo de ejecucin. El objetivo es obtener un arreglo de empaquetados que minimice el tiempo de ejecucin del programa satisfaciendo las limitaciones de espacio.El empaquetado de esta manera podr ser realizado luego que la estructura modular completa haya sido diseada.

Difiriendo el empaquetado hasta el final del proceso de diseo, podemos mejorar la eficiencia y la modularidad tcnica del sistema.Utilizaremos una estrategia conocida como anlisis procedural, para estudiar el problema de organizacin del sistema en unidades de carga eficientes.

1.Anlisis ProceduralEl anlisis procedural consiste de un conjunto de criterios para determinar que mdulos deben pertenecer a la misma unidad de carga en por de maximizar la eficiencia.No existen reglas fijas para realizar el empaquetado de mdulos en unidades de carga, y ser el criterio del diseador el que deber determinar como se compongan las unidades de carga.El anlisis procedural involucra tres pasos fundamentales:Determinar el tamao aproximado de cada mdulo en la estructura.Aplicar alguno de los criterios que se discuten ms abajo para determinar agrupamientos preferidos y prioridades entre preferencias.Encontrar agrupamientos de mdulos tales que quepan dentro del tamao de la unidad de carga, minimizando la cantidad de agrupamientos que deban partirse en ms de una unidad de carga.El concepto general es muy simple: deben incluirse en una misma unidad de carga aquellos mdulos que se conectarn muchas veces durante la ejecucin del sistema.

IteracionesDeben incluirse en la misma unidad de carga mdulos conectados por referencias iterativas. Este criterio se aplica a las estructuras iterativas o loops. La regla de pensamiento es que, siempre que sea posible, debe incluirse en la misma unidad de carga al mdulo referenciado y al referenciante.VolumenDeben incluirse en la misma unidad de carga mdulos con alto volumen de referencias de conexin entre ellos. Para esto debe estimarse la cantidad de veces que un mdulo invocar a otro durante la ejecucin. Si el volumen de veces que esta invocacin se producir es alto, es conveniente entonces que los mdulos pertenezcan a la misma unidad de carga.

FrecuenciaCuando la frecuencia de referencia es un criterio observable, la regla de pensamiento es que los mdulos relacionados por referencias altamente frecuentes deben ubicarse en al misma unidad de carga. Debe observarse que las invocaciones condicionales reducen la frecuencia de invocacin.

IntervaloDeben incluirse en la misma unidad de carga los mdulos con intervalos breves de tiempo entre activaciones. Podemos observar adems que existen situaciones en las que ser deseable que dos mdulos no pertenezcan a la misma unidad de carga. Los siguientes criterios se verifican en tales circunstancias:

Funciones OpcionalesDebe ubicarse en una unidad de carga por separado cualquier funcin opcional.Funciones por nica vezDeben ubicarse en una unidad de carga por separado las funciones que se utilicen una nica vez en el sistema.SortsDeben ubicarse los mdulos aplicados a la entrada y a la salida de un proceso de sort en unidades de carga separadas.

Tema 04:Optimizacin1.Filosofas de OptimizacinLa eficiencia de un sistema depende de la Competencia del DiseadorEn muchos casos, el camino ms simple es el ms eficienteSolo una pequea parte de un sistema tpico tiene impacto sobre la eficiencia general, Sistemas Modulares Simples pueden ser optimizados fcilmenteEl sobre nfasis en la optimizacin va en detrimento de otros objetivos del diseoLa optimizacin es irrelevante si el programa no funciona.

2.Un Enfoque para la Optimizacin de MdulosExisten dos enfoques para optimizar un sistema:Optimizar el cdigo dentro de los mdulosCambiar la estructura del sistema para mejorar su performanceLas tcnicas para optimizar cdigo son tcnicas especficas de programacin fuera del alcance de esta discusin, y dependen en la mayora de los casos de los lenguajes, compiladores, y entornos de desarrollo que se utilicen.Sin embargo puede plantearse un esquema general de ataque para optimizar mdulos. En primer lugar debe tenerse en cuenta que por lo general, no todos los mdulos de un sistema debern ser optimizados. Por el contrario, se conoce que mejorando un 5% de mdulos crticos que insumen la mayor parte del tiempo de un sistema, se puede mejorar la performance global del mismo. El esquema general de optimizacin implica los siguientes pasos:

1.Determinar el tiempo de ejecucin para cada mdulo o unidad de carga. Para esto se utilizan monitores de hardware y paquetes para la medicin de performance. Por simplicidad denotaremos como i al tiempo de ejecucin del mdulo Ti.

2.Examinar cada mdulo para estimar su potencial mejora. Este paso implica un proceso de estimacin y depende del conocimiento y la experiencia del programador en el lenguaje, sistema operativo y hardware. Denotaremos este potencial de mejora como Ii. 3.Estimar el costo que involucra cada mejora. Por costo entenderemos, salario del programador o analista, tiempo de computador, y otros costos involucrados en la produccin de una versin optimizada del sistema. Denotaremos este costo como Ci. 4.Establecer prioridades para realizar las mejoras. Podremos establecer esta prioridad Pi con la siguiente expresin:Pi = A * Ii * Ti - B * Ci, donde A y B son factores de peso apropiado. 5.Optimizar los mdulos con mayor prioridad.

3.Cambios estructurales por EficienciaEn un determinado nmero de casos, la optimizacin del cdigo dentro de los lmites de un mdulo puede no ser suficiente para alcanzar el nivel de eficiencia deseado. Ser necesario entonces, modificar la estructura del sistema. Antes de realizar este tipo de optimizacin, es importante que el diseador identifique las fuentes o causas de la ineficiencia. Es importante que el diseador obtenga estadsticas concernientes a los tiempos de transicin intermodulares, como as de los tiempos de ejecucin intramodulares.

Existe solo un pequeo nmero de modificaciones estructurales que pueden mejorar notablemente la velocidad de ejecucin y quiz los requerimientos de memoria. Discutiremos estas en los prrafos siguientes.

3.1. Macros o cdigo incluido lexicogrficamenteAntes de realizar modificaciones en la estructura actual, el diseador de considerar la posibilidad de cambiar el tipo de mdulo preservando la estructura.En particular, el diseador debe recordar que las macros (rutinas lexicogrficamente incluidas en el cuerpo de su mdulo superior) y subrutinas representan compromisos entre tiempo de ejecucin y requerimientos de memoria. La "transmisin" de parmetros a una macro es realizada durante el tiempo de compilacin o ensamble, y el cambio de contexto (conocido tambin como prlogo/eplogo, o salvado y restaurado del estado de la mquina) puede ser optimizado por el compilador/ensamblador. Tambin, debido a que el cuerpo de la macro se incluye lexicogrficamente en la secuencia de cdigo de su superior, cualquier optimizacin de los registros de hardware, realizada por el compilador/ensamblador, se aplicar a travs de los lmites de la macro.

Finalmente, si el mdulo es referenciado solo una vez, o un pequeo nmero de veces dentro de la estructura, o bien si el tamao del cuerpo del mdulo es pequeo comparado con el tamao de prlogo/eplogo para la carga del mismo, el uso de macros, probablemente ahorrar tiempo de ejecucin y espacio de memoria. La transmisin de parmetros, el cambio de contexto, y otros tipos de sobrecargas producidas por las invocaciones intermodulares, consumen memoria y tiempo de CPU.

3.2. Estructuras panquequeComo regla general se tiene que las estructuras muy profundas (muchos niveles) tienen una gran sobrecarga debido a los procedimientos de invocacin intermodulares. Sin embargo existen numerosas excepciones a esta regla que no siempre puede ser aplicada con seguridad. Solo si luego de un anlisis pertinente se detecta que "aplastando" la estructura se puede obtener una mejora substancial, se deben aplicar tcnicas en pos de lograrlo.

Consideremos una estructura de dos niveles consistentes de un mdulo de control y sus subordinados. Cada invocacin a dichos subordinados, representan una sobrecarga. Si dichas invocaciones se encuentra dentro de un proceso iterativo, la sobrecarga puede llegar a ser considerable. Si la lgica de control del mdulo superior no es compleja, una estructura de este tipo puede convertirse en un nivel homlogo vinculado por transferencias de control incondicionales.La estructura "panqueque" resultante siempre tendr menor cohesin y mayor acoplamiento.

Esta tcnica generalmente funciona con lenguajes "antiguos", debido a que las transferencias de control incondicionales se implementan en ellos con gran eficiencia. Sin embargo la mayora de los lenguajes de programacin "modernos" no permiten transferencias incondicionales, por lo cual esta tcnica es inaplicable en dichos casos.

3.3 CompresinLa ms ubicua de todas las manipulaciones estructurales para mejorar la eficiencia puede ser llamada "demodularizacin", ya que esta consiste en comprimir todo o parte de un mdulo en otro. En el caso ms simple, esto se realiza a travs de la inclusin lexicogrfica de un mdulo en otro. La ganancia en eficiencia en esta maniobra simple es equivalente a la diferencia de sobrecarga entre la llamada a un subordinado lexicogrficamente incluido y una llamada a un subordinado externo.

El cdigo del subordinado puede embeberse en el cdigo del superior quitndole los elementos de lmite y los elementos de ligado, o simulndolos. Si el cuerpo del subordinado es copiado en-lnea en cada llamada dentro del superior, entonces se incrementarn los requerimientos de memoria, y el anlisis es similar la realizado con las macros.

El efecto de realizar la compresin antes o despus que el sistema se implemente es importante. Por lo general si la compresin se realiza previo a la implementacin, es posible que el mdulo resultante de la compresin oculte para siempre la funcionalidad independiente del mdulo que se comprimi, y cada vez que se necesite una funcin similar, esta sea reescrita.Por el contrario cuando se pospone la compresin hasta el momento de la implementacin, se mantiene la estructura intacta durante el diseo, lo cual permite la reutilizacin de los mdulos involucrados.