modelo estructurado

Ingeniera de Sistemas II IND-225 Captulo 1

1 Jimmy Camacho Villazn Docente Titular Ingeniera de Sistemas FCyT - UMSS

Captulo No. 1

Modelo de Implementacin 1.1 Definicin:

Este modelo define cmo se podr en prctica el diseo lgico del sistema, sin perder de vista que "Diseo es el proceso de aplicar distintas tcnicas y principios con el propsito de definir un dispositivo, proceso, o sistema, con los suficientes detalles como para permitir su realizacin fsica" (E.S.Taylor, An Interim Report on Engineering Design, Massachusetts Institute of Technology, 1959) Este modelo se desarrolla en tres etapas: a. Desarrollar el Modelo de Programas (Ingeniera de Software) b. Definir la plataforma de Hardware y el Software de Base sobre los que

funcionar el sistema. c. Desarrollar el Diseo Fsico del Sistema.

1.2 El Modelo de Programas: Diseo Estructurado Se llama Diseo Estructurado al proceso de decidir los componentes necesarios, y la interconexin entre los mismos, para solucionar un problema de software bien especificado". El diseo es una actividad que comienza cuando el analista de sistemas ha producido un conjunto de requerimientos funcionales lgicos para un sistema, y finaliza cuando el diseador ha especificado los componentes del sistema y las relaciones entre los mismos. Por tanto, este modelo tiene como objetivo definir cules de los procesos que forman parte del Modelo Esencial sern automatizados (llevados a un computador) Una vez que esos procesos hayan sido definidos, el Modelo de Programas debe ser capaz de interpretar el lenguaje estructurado y transformarlo en un conjunto de programas, gracias al apoyo de herramientas grficas. Frecuentemente analista y diseador son la misma persona, sin embargo es necesario que se realice un cambio de enfoque mental al pasar de una etapa a

Ingeniera de Sistemas II IND-225 Captulo 1 la otra. Al abordar la etapa de diseo, la persona debe quitarse el sombrero de analista y colocarse el sombrero de diseador. Una vez que se han establecido los requisitos del software (en el anlisis), el diseo del software es la primera de tres actividades tcnicas: diseo, codificacin, y prueba. Cada actividad transforma la informacin de forma que finalmente se obtiene un software para computadora vlido. Las fases del diseo, codificacin y prueba absorben el 75% o ms del costo de la ingeniera del software (excluyendo el mantenimiento). Es aqu donde se toman decisiones que afectarn finalmente al xito de la implementacin del programa y, con igual importancia, a la facilidad de mantenimiento que tendr el software. Estas decisiones se llevan a cabo durante el diseo del software, haciendo que sea un paso fundamental de la fase de desarrollo. La importancia del diseo del software se puede sentar con una nica palabra: calidad. El diseo es el proceso en el que se asienta la calidad del desarrollo del software. El diseo produce las representaciones del software de las que puede evaluarse su calidad. El diseo sirve como base para todas las posteriores etapas del desarrollo y de la fase de mantenimiento. Sin diseo nos arriesgamos a construir un sistema inestable, un sistema que falle cuando se realicen pequeos cambios, un sistema que pueda se difcil de probar, un sistema cuya calidad no pueda ser evaluada hasta ms adelante en el proceso de ingeniera de software, cuando quede poco tiempo y se haya gastado ya mucho dinero.

1.3 Objetivos Del Diseo Estructurado "El diseo estructurado, tiende a transformar el desarrollo de software de una prctica artesanal a una disciplina de ingeniera". Permitir lograr:

Eficiencia Mantenibilidad Modificabilidad Flexibilidad Generalidad Utilidad

"Diseo" significa planear la forma y mtodo de una solucin. Es el proceso que determina las caractersticas principales del sistema final, establece los lmites en




performance y calidad que la mejor implementacin puede alcanzar, y puede determinar a que costos se alcanzar. El diseo se caracteriza usualmente por un gran nmero de decisiones tcnicas individuales. En orden de transformar el desarrollo de software en una disciplina de ingeniera, se debe sistematizar tales decisiones, hacerlas ms explcitas y tcnicas, y menos implcitas y artesanales. Diseo estructurado y calidad del software Un concepto importante a considerar es el de calidad. Dentro de este concepto, se deben tomar encuenta: 9 Eficiencia: Se refiere al incremento de la velocidad de ejecucin y

disminucin de los requerimientos de memoria central. Estos recursos no incluyen solamente procesador y memoria, tambin incluyen almacenamiento secundario, tiempo de perifricos de entrada salida, tiempo de lneas de teleproceso, tiempo de personal, y ms.

9 Confiabilidad. Es importante notar que si bien la confiabilidad del software

puede ser vista como un problema de depuracin de errores en los programas, es tambin un problema de diseo. La confiabilidad se expresa en como MTBF (Mean Time Between Fairules: tiempo medio entre fallas).

9 Mantenibilidad. Se define como:

Mantenibilidad del sistema = ____MTBF___ MTBF + MTTR donde:

MTBF: tiempo medio entre fallas (mean time between fairules) MTTR: tiempo medio de reparacin (mean time to repair)

Diremos que un sistema es mantenible si permite la deteccin, anlisis, rediseo, y correccin de errores fcilmente. 1.3 Identificacin de Procesadores. Es el primer paso en el desarrollo del Modelo de Implementacin. Tiene como propsito asignar cada uno de los procesos que forman parte del sistema a un

Ingeniera de Sistemas II IND-225 Captulo 1 PROCESADOR, que se encargar de desarrollar el proceso. Esta etapa se desarrolla a nivel del DFD: PROCESADOR #1

PROCESADOR #2 PROCESADOR #3 No puede quedar ningn proceso sin asignar. 1.4 Diagramas de Estructura Tiene como objetivo bsico el tratar d enfocar la programacin a travs de MDULOS, de manera que cada uno de ellos pueda ser programado de manera independiente. Caractersticas de los Diagramas de Estructura: 9 Es grfico y, por tanto, conciso, fcil de leer, sencillo de preparar.




9 El diagrama de estructura muestra la descomposicin de un sistema en mdulos.

9 Presenta un formato TOP-DOWN: pasar de la forma global a la detallada. Presenta una estructura jerrquica.

9 Los mdulos se consideran cajas negras de las que se conoce: - Entradas que reciben. - Salidas que generan. - La funcin que lleva a cabo. - Un diagrama de estructura tiene forma de rbol y refleja:

i. Jerarqua de control qu mdulos pueden invocar a otros mdulos.

ii. Parmetros que se pasan en los llamadas. En cambio no muestra:

- Aspectos de procesamiento del software: secuencias, alternativas o bucles.

- Ni datos internos de los mdulos. Debe ser parte de la documentacin del programa y del sistema, as como debe servir de ayuda para el mantenimiento y mejoras del sistema. DEFINICIN DE MDULO Un mdulo se define como un conjunto de sentencias de programa con cuatro atributos bsicos:

- Entradas/ Salidas: Datos que recibe cuando lo invocan y datos que devuelve al mdulo que lo llam.

- Funcin: Qu hace con las entradas para producir las salidas. - Mecnica: La lgica mediante la cual lleva a cabo su funcin. - Datos internos: Zona de datos a los que nicamente puede referirse l.

Adems posee otros atributos adicionales cmo:

- Un nombre, por el cual puede ser referenciado como un todo. - Puede invocar o ser invocado por otros mdulos.

Un mdulo debe manejarse como una caja negra, funcionalmente independiente, que puede entenderse en forma separada. El concepto de Caja Negra: Una caja negra es un sistema (o un componente) con entradas conocidas, salidas conocidas, y generalmente transformaciones conocidas, pero del cual no se conoce el contenido en su interior. En la vida diaria existe innumerable cantidad de ejemplos de uso cotidiano: una radio, un televisor,

Ingeniera de Sistemas II IND-225 Captulo 1 un automvil, son cajas negras que usamos a diario sin conocer (en general) como funciona en su interior. Solo conocemos como controlarlos (entradas) y las respuestas que podemos obtener de los artefactos (salidas). El concepto de caja negra utiliza el principio de abstraccin. Este concepto es de suma utilidad e importancia en la ingeniera en general, y por ende en el desarrollo de software. 1.5 Comparacin entre las estructuras administrativas y el diseo estructurado Uno de los aspectos ms interesantes del diseo de programas es la relacin que puede establecerse con las estructuras de organizacin humanas, particularmente la jerarqua de administracin encontrada en la mayora de las grandes organizaciones. Observemos por ejemplo el siguiente diagrama de organizacin de una empresa

A simple vista podemos apreciar que el presidente de la empresa tiene demasiados subordinados, y consecuentemente su trabajo involucrar el manejo de demasiados datos y la toma de demasiadas decisiones, demasiada complejidad, que lo llevar a cometer posibles errores. Podemos establecer una analoga con la estructura de programas y es razonable pensar que un mdulo que tenga demasiados mdulos subordinados a quienes controlar, sea sumamente complejo, y susceptible a fallas. Veamos otro ejemplo




Podemos apreciar a simple vista que la tarea de los jefes A, X, Y, es relativamente trivial y podra se comprimida en una sola jefatura. Estableciendo un comparacin con la estructura de programas, si tenemos un mdulo cuya nica funcin es llamar a otro, y este a su vez a otro, el cual llama a uno que finalmente realizar la tarea, los mdulos intermedios podrn comprimirse un nico mdulo de control. Podemos decir que en una organizacin perfecta, los administradores no realizan ninguna tarea operativa. Su labor consiste en coordinar informacin entre los subordinados y tomar decisiones. Los niveles inferiores son los que realizan el trabajo operativo. Anlogamente, podemos argumentar que los mdulos de nivel alto en un programa o sistema solamente coordinan y controlan la ejecucin de los mdulos de menor nivel, quienes son los que realizan los cmputos y procesos que el sistema requiere. Finalmente observaremos que los administradores suministran a sus subordinados nicamente la informacin que estrictamente necesitan. Anlogamente los mdulos inferiores solo deben tener acceso a la informacin que necesitan, y no a otras. El establecimiento de un paralelo entre las estructuras organizativas humanas y los programas de computadora nos ser muy til en el estudio del diseo estructurado. 1.6 Manejo de la complejidad En principio diremos que escribir un programa "grande" generalmente lleva ms tiempo que escribir un "pequeo". Esto es valedero si medimos "grande" y "pequeo" en unidades apropiadas. Claramente, el nmero de instrucciones de un programa no es una medida de complejidad ya que existe instrucciones ms complejas que otras, y algoritmos ms complejos que otros. En realidad lo que diremos es que es ms difcil resolver un problema difcil! , e intentaremos realizar un anlisis sobre como disminuir la complejidad de un determinado problema. Si asumimos que hemos podemos medir por algn mtodo la complejidad de un problema P (no importa aqu que mtodo), diremos que la complejidad del mismo ser M(P), y que el costo de realizar un programa que resuelva el problema P ser C(P). Los enunciados previos responder a la siguiente regla: dados dos problemas P y Q observaremos lo siguiente

Si M(P) > M(Q) entonces C(P) > C(Q)

es decir el costo de resolver un determinado problema es directamente proporcional al tamao del mismo.

Ingeniera de Sistemas II IND-225 Captulo 1 Intentaremos tomar dos problemas separados y en lugar de escribir dos programas, crear un programa combinado. Si juntamos los dos problemas, obtendremos uno mayor que si tomamos los dos por separado. La razn fundamental para no combinar los problemas, es que los humanos tenemos inconvenientes para tratar adecuadamente grandes complejidades, y en la medida que esta se incrementa somos susceptibles a cometer un mayor nmero de errores. En virtud de esto podemos afirmar que

M(P+Q) > M(P) + M(Q)

y consecuentemente C(P+Q) > C(P) + C(Q)

Siempre ser preferible crear dos piezas pequeas que una sola ms grande, si ambas solucionan el mismo problema. Este fenmeno no es solo vlida para el campo de la computacin. Es verdadero en cualquier campo de la solucin de problemas (matemtica, fsica, etc.). 1.7 Notacin de los Diagramas de Estructura

a. Mdulo: Representa un grupo de instrucciones que realiza una nica funcin determinada. Un mdulo asocia a uno ms de los procesos definidos en el Diseo Lgico. Cada mdulo tiene cierta informacin de entrada y genera cierta informacin de salida. El mdulo debe tener un nombre dentro el rectngulo que lo representa.


Ingeniera de Sistemas II IND-225 Captulo 1 Mdulo

Nombre del Mdulo

CALCULAR SALDOS

b. Flecha de Invocacin. Se presenta como una flecha que va desde el

mdulo que llama hasta el que es invocado. Como describe una relacin jerrquica, su direccin es siempre hacia abajo:

Mdulo Jefe (Invocador)

Mdulo Subordinado (Invocado) Un mdulo puede invocar a varios otros que dependen de l: A su vez, un mdulo puede ser invocado por varios mdulos



c. Flecha (Cupla) Representa a parmetros de informacin que pasan a travs de los mdulos. El sentido de la flecha indica la direccin del flujo. d. Condicional.- Muestra la existencia de un proceso de seleccin.

1.8. Formato General de un Diagrama de Estructura

En resumen, un Diagrama de Estructura ilustra la particin del sistema en mdulos funcionales independientes, cada uno de los cuales se programar bajo ese concepto



Ejemplos

1.9 Acoplamiento y Cohesin. El Acoplamiento es la medida de la fuerza de relacin entre los mdulos La cohesin es la fuerza de la relacin entre los elementos de un mdulo


Ingeniera de Sistemas II IND-225 Captulo 1 1.10 Estrategias de Transformacin


Ingeniera de Sistemas II IND-225 Captulo 1 Proceso de Transformacin Se deben identificar: Ramas Aferentes: Procesos que leen y validan los datos a la entrada del sistema. Para identificarlas se buscan los puntos de entrada de datos a la transaccin (normalmente Entidades Externas que proporcionan datos al sistema) y se recorre la rama del DFD hasta llegar a un flujo de datos completamente validado. Ramas Eferentes: Procesos que dan el formato adecuado a los datos para ser emitidos (visualizados, impresos, guardados, ...) al exterior. Para identificarlas se buscan los puntos de salida de datos de la transaccin (normalmente Entidades Externas que reciben datos del sistema) y se recorre la rama del DFD hasta llegar a un flujo de datos lgico, antes de ser formateado. Transformacin Central: Los procesos que no son aferentes, ni eferentes pertenecen a la transformacin central (procesos de clculo, procesamiento de datos, actualizacin de datos, ...).


Ingeniera de Sistemas II IND-225 Captulo 1 Ejemplos de transformacin de Diagrama de Flujo de Datos a Diagrama de Estructura Diagrama Intermedio (Alquilar un jefe) Antes de desarrollar el Diagrama de Estructura podemos hacer un diagrama intermedio, entre el DFD y el DE, que sirva como aproximacin. Existen dos maneras de hacerlo: alquilar un jefe o promover un proceso a jefe. En este caso hemos escogido la primera. El proceso alquilado es un proceso que no se corresponde con ningn otro del DFD y que se convertir en el mdulo principal de la transaccin. Del proceso jefe alquilado se cuelgan las ramas aferentes, eferentes y los procesos de la transformacin central, como sigue:


Ingeniera de Sistemas II IND-225 Captulo 1 Resultado Final:


Ingeniera de Sistemas II IND-225 Captulo 1 Ejemplo 2

Primer nivel de Factorizacin

Final



Lectura Complementaria: Anlisis de Transformaciones El principal enfoque del anlisis de transformaciones es convertir un DFD,

resultado del anlisis estructurado, en un diagrama de estructura. La principal ventaja de este enfoque es que, el diagrama de estructura resultante tiene una forma tal que permite un fcil desarrollo y mantenimiento ms barato que la mayora de los diagramas de estructura que podamos construir ad-hoc. Como ser visto mas adelante, cuando los criterios de calidad son aplicados en los diagramas de estructura, el resultado es un DE donde, la mayora de los mdulos son independientes de los dispositivos de entrada y salida, esto es: describe el diseo de un sistema balanceado. La figura 1 describe los pasos realizados durante el anlisis de transformaciones.

Anlisis de la Especificacindel Problema

Identificar el Centrode Transformacin

Produccin de un PrimerDE (First-Cut)

Mejoramiento del DE

Asegurar la Funcionalidaddel Diseo

DFDs sin detalles de ms y sinocultar transformaciones de datos

Marcar el Centro de Transformacin;Caminos Aferentes y Eferentes

Centro de Transformacin=RaizCaminos Aferentes=IzquierdaCaminos Eferentes=Derecha

DFDs resultantes delProceso de AnalisisAnlisis

Estructurado


Especificacin del Analisis

FuncionalmenteEquivalentes Cohesin, Acoplamiento, etc

Diseo de buena Calidad

Implementacin,Testeo, etc.

Diseo Estructurado de buenaCalidad(mantenimiento;eficiencia; claridad; etc)

Fig.1: Pasos del Anlisis de Transformaciones



Anlisis de la Especificacin del Problema

Si un diseo estructurado est siendo desarrollado, luego del anlisis estructurado, entonces habr un conjunto de DFDs que describen el problema, para los cuales se debe disear una solucin. Si el anlisis estructurado no precede al diseo, entonces se pueden reconocer dos situaciones muy diferentes:

Un problema muy simple: Si el problema puede ser representado en la memoria de una persona [DeMarco 86], es muy simple y no precisa mayor esfuerzo que la especificacin. En ese caso las herramientas del Anlisis no son necesrias y el DE puede ser desarrollado ad-hoc. Sin embargo, el anlisis estructurado ofrece una coleccin de tcnicas y criterios que permiten analizar y especificar un problema cuando es muy complejo para ser comprendido y especificado con una simple declaracin narrativa. Segn DeMarco [DeMarco 86], un modelo es una maqueta de una realidad donde algunas caractersticas son estudiadas y, se construyen diferentes modelos de la misma realidad (cada uno de ellos representando diferentes caractersticas) para estudiar diferentes partes del problema por separado.

Un problema complejo: La mayora de las veces, el problema es mayor que la capacidad de nuestra memoria principal y diversos modelos debern ser desarrollados, en el proceso de anlisis estructurado, para conseguir una buena comprensin y especificacin. En ese caso, ser necesario construir algunos DFDs a partir de la narrativa del problema (declaraciones surgidas de las entrevistas con los diversos usuarios involucrados).

Para obtener un buen resultado con el anlisis de transformaciones, los DFDs no deben llegar a un nivel de detalle en el que se tenga demasiada cantidad de procesos. Si un DFD es muy detallado puede ser necesario que se necesite hacer abstraccin de algunos procesos (para reducir la cantidad). El DFD tampoco puede ser demasiado abstracto y ocultar algunas caractersticas que el anlisis de transformaciones debe estudiar. Adems, puede ser necesario descender un nivel (describiendo los flujos de datos y los procesos interiores de algunos procesos mostrados en el DFD) para que, el DFD presente todas las transformaciones de datos producidas para llevar los flujos de entrada en direccin de generar los flujos de salida.


Identificar el Centro de Transformacin El centro de transformacin es la parte del DFD que contiene la funcionalidad principal del sistema y es independiente de la implementacin particular de las entradas y salidas. Por ejemplo, considere el DFD de la figura 2.

Fig. 2: Generacin de Informe de Movimientos de una Cuenta Corriente

El diseador podra considerar al proceso Reunir Movimientos del Cliente como la transformacin principal del DFD, si un proceso tiene mas flujos de entrada que de salida, la pregunta que deber ser respondida es: Qu proceso hace el trabajo principal de la funcionalidad que representa el DFD?. Claramente, el principal trabajo no es hecho por los procesos: Leer Movimiento del Cliente, Leer Informacin del Cliente, Calcular Total o Imprimir Lnea. Tampoco es hecho por alguno de los procesos: Formatear Encabezado, Formatear Lnea del Reporte o Formatear Total por separado. La funcin que el DFD modela, con certeza, no es Reunir Movimientos del Cliente, podra corresponderse con un proceso de abstraccin mayor, tal vez llamado Generar Reporte de Movimientos, que incluya los procesos: Formatear Encabezado, Formatear Lnea de Reporte y Formatear Total.




La eleccin del centro de transformaciones no es una actividad simple, generalmente requiere una interpretacin detallada de la funcionalidad descripta por el DFD, y, en muchos casos, podra incluir mas de un proceso. Para eso existe una estrategia basada en la estructura del DFD, independiente de la interpretacin particular de los procesos, que permite obtener una buena aproximacin de la porcin del DFD que debe incluir el centro de transformaciones. No es un algoritmo, ya que no establece una secuencia de etapas y tampoco garantiza la obtencin acertada del centro de transformaciones. Una vez identificada la porcin del DFD que incluye el centro de transformaciones, se debe interpretar detalladamente la funcin de los procesos incluidos para determinar si alguno de ellos representa la transformacin principal del DFD o si una actividad de abstraccin mayor deber ser escogida.

Estrategia para Determinar el Centro de Transformacin

La estrategia intenta identificar la transformacin central siguiendo los caminos de datos aferentes y eferentes. Este proceso puede ser desarrollado a travs de los tres pasos siguientes:

1. Marcar cada camino aferente partiendo del lado externo del DFD (los flujos provenientes de depsitos de datos, agentes externos o porciones del DFD no incluidas en el Anlisis1), y terminar en cada flujo eferente alcanzado (los flujos dirigidos para depsitos de datos, agentes externos o porciones de DFD no incluidas en el Anlisis).

2. Disear una curva que una los puntos de interseccin de caminos diferentes. Los procesos incluidos en el interior de la curva son candidatos iniciales para el centro de transformacin.

3. Finalmente, analizar los lmites del centro. Generalmente, en el lmite, se puede reconocer la finalizacin del refinamiento de las entradas (para los caminos de entrada o aferentes) y el comienzo del refinamiento de las salidas (para los caminos de salida o eferentes). Si no es as, modifique el contorno, yendo hacia el interior o exterior de forma tal que, el interior, incluya solamente datos en estado lgico (independiente de las fuentes y destinos y totalmente refinados).

1 El DFD analizado es solamente una porcin correspondiente a una transformacin identificable. Como separar un DFD proveniente del Analisis

en porciones correspondientes a transformaciones es una actividad muy intuitiva, quedar mas claro cuando sea presentado el Analisis de Transaccioness.

Ingeniera de Sistemas II IND-225 Captulo 1 En el ejemplo de la figura 3 se ilustra la actividad descripta arriba. Primero se marcan todos los caminos de datos a travs del DFD comenzando por los flujos de comienzo de los caminos aferentes y finalizando en los flujos de finalizacin de los caminos eferentes. En el ejemplo, los flujos de datos Campo y Registro Maestro son flujos de comienzo de caminos aferentes y, Nuevo Registro Maestro y Lnea de Informe son flujos de finalizacin de caminos eferentes. En el segundo paso se hace una curva uniendo los puntos de interseccin de caminos. La curva rene los procesos candidatos para centros de transformacin, en el ejemplo, rene los procesos: Aparear Transaccin con Registro Maestro, Actualizar Registro Maestro y Formatear Nuevo Registro Maestro.

Transaccin sin Registro Maestro

Linea de Informe

Registro Maestro

Nuevo

Registro Maestro sin Transaccin

Registro Maestro Invlido

Registro Maestro Vlido

Registro Maestro

Transaccin Vlida

Campo Editado

Campo Invalido

Editar Campo

Reunir Transacciones

Efectuar Validacin

Cruzada

Validar Registro Maestr

AparearTransaccin

con Registro Maestro

ActualizarRegistro Maestro

FormatearLinea de Informe

Formatear

Registro Maestro

Nuevo

Campo

Campo Editado

Transaccin

Archivo

Registro Maestro Juntado

Registro Maestro

Actualizado

Transaccin Invlida

TransaccinAplicada

Inicio de Camino Aferente

Fin de Camino Eferente

Fin de Camino Eferente

Fig. 3: Ejemplo de Anlisis de Transformaciones

Las lneas punteadas marcan los diferentes caminos de datos a travs del DFD. Hay dos Caminos Aferentes que comienzan en los flujos Campo y Registro Maestro y dos Caminos Eferentes que finalizan en los flujos Nuevo Registro Maestro y Lnea de Informe. Los procesos en el interior de la curva son candidatos a integrar el centro de transformaciones, ellos son Aparear Transaccin con Registro Maestro y Actualizar Registro Maestro.

La curva tambin indica la finalizacin de los caminos aferentes y el comienzo de los caminos eferentes, verificar eso es el objetivo del tercer paso. La primera tarea es verificar que, en el interior de la curva, no haya transformaciones de refinamiento de los flujos de entrada o salida. En el ejemplo, el flujo de datos Transaccin Vlida es la versin mas refinada de los datos que comenzaron con el flujo Campo y, el proceso Aparear Transaccin con Registro Maestro procesan datos de los dos caminos aferentes para crear una salida muy diferente (el Registro Maestro Apareado).


Ingeniera de Sistemas II IND-225 Captulo 1 Con los caminos eferentes no ocurre la misma cosa. El proceso Formatear Nuevo Registro Maestro, aunque sea integrante del selecto grupo de procesos candidatos para centro de transformacin, ejecuta una tarea de refinamiento de datos de salida. La tarea de transformacin real de datos fue realizada por los procesos Aparear Transaccin con Registro Maestro y Actualizar Registro Maestro. El mdulo Formatear Nuevo Registro Maestro simplemente refina el Registro Maestro Actualizado o el Registro Maestro sin Transaccin para generar el Nuevo Registro Maestro. As el proceso Formatear Nuevo Registro Maestro no compone el centro de transformacin e incrementa el camino eferente. Como podemos ver, existe subjetividad en la eleccin de la transformacin central, raramente surgen grandes acuerdos relativos a esa eleccin. El diseador se podr preguntar sobre un proceso aqu o all, sin embargo, eso parece hacer poca diferencia en el diseo final. Por eso, si hubiera dudas sobre un proceso, se no debe pertenecer al centro de transformacin. En sistemas de informacin el centro de transformacin est compuesto por una pequea porcin del DFD y no incluye procesos de edicin, formateo o verificacin y correccin de errores.

Producir un Primer Diagrama de Estructura (First-Cut) Una vez reconocido el centro de transformacin y los caminos aferentes y eferentes, una primera versin del DE puede ser desarrollada aplicando los cuatro pasos siguientes:

1. Convertir el DFD en una jerarqua de mdulos: Tirar el DFD desde los procesos marcados como participantes del centro de transformaciones y dejar caer los otros procesos, por accin de la gravedad.

B

C DE

FG

ef

g

h

kA

a

bc

d

i

j

H

l

m

n

o

p

qX

DE

l

G

m

n

qX

H

o

p

kF

h

i j

C

f

g

A

B

ab

c

d

e

2. Substituir los depsitos de datos por mdulos de lectura o grabacin

(dependiendo de la orientacin del flujo), los agentes externos por mdulos de captacin o presentacin de datos y adicionar mdulos debajo de los flujos sin destinatario u origen.



Se deben asociar nombres adecuados a los mdulos adicionales, dependiendo de la actividad de lectura (captacin) o escritura (presentacin) que deben ejecutar.


3. Convertir los flujos de datos en invocaciones (apuntando al mdulo invocado) y los datos transportados por los flujos en cuplas.

Cada uno de los mdulos deber ser analizado para determinar y adicionar los datos de entrada necesarios. Por ejemplo, el mdulo Leer X debe recibir como entrada la clave de acceso para la lectura del registro.

4. Indicar un nico mdulo como raz del DE, sea por seleccin de uno de los mdulos participantes del centro de transformaciones o, por la incorporacin de un mdulo nuevo.

Mejorar el Diagrama de Estructura Obtenido El diagrama de estructura resultante del paso anterior, con certeza, puede ser mejorado. Eso simplemente es una primera aproximacin y se debe beneficiar con la aplicacin de los criterios de calidad (presentados mas adelante), especialmente Descomposicin, Cohesin y Acoplamiento. Por lo menos, la siguiente revisin debera ser hecha en el diagrama de estructura:

Reorganizar, y descomponer si fuese necesario, los mdulos aferentes y eferentes.

Descomponer la transformacin central, si fuese necesario, usando el DFD como base. Los niveles del DFD son tiles en este caso.

Adicionar los mdulos de manipulacin de errores. Adicionar detalles de inicializacin y terminacin (si son requeridos).

l

mn

q

o

p

kh

i j

g DE

f

C

a b

c d

e F ? GHB

??A ?

? ?

Leer GraXX

l

mn

q

o

p

kh

i jf

g

a b

c d

e

D

G HFC

A

B OrEt Er

Ic Ec

LeerX

E

Em

GraX


Tener certeza que todos los mdulos tengan nombres correspondientes a su representacin en la jerarqua.

Adicionar todas las cuplas necesarias (de datos y de control). Chequear todos los criterios de calidad y mejorar el diseo de acuerdo

con esos criterios.

De esta manera, aplicando los cuatro pasos en el DFD de la figura 3, el DE resultante es el siguiente:

Campo FC

Campo Editado

FCE FCE

Campo Editado

FT Transaccin

# Cuenta

Transaccin Vlida

FTV RegMaestroValido

# Cuenta Reg MaestroReg MaestrosinTrans

Nuevo RegMaestro Nuevo RegMaestro Fmt

RMV

Reg MaestroActualizado

TV

Transaccin Aplicada

RMV

TV

FC Fin de CampoFCE Fin de Campo EditadoFT Fin de Transaccin

FTV Fin de Transaccin Vlida RMV Registro Maestro Vlido TV Transaccin Vlida

TransaccinAplicada Lnea

LneadeError

Transaccin sin Registro Maestro

ActualizarArchivo Maestro

Obtener Transaccin

Vlida

Obtener RegistroMaestro

Leer Registro Maestro

Generar Registro Maestro

Registro Juntar

Maestro

Imprimir Transaccin

Aplicada Obtener

Transacci

Obtener Campo Editado

Obtener Campo

Informar Transaccin Errnea

Formatear

Registro Maestro Nuevo

Grabar

Registro Maestro

Nuevo

Registro Actualizar

Maestro

Formatear

Informe Lnea de

Imprimir

InformeLnea de

Fig. 4: Resultado de Aplicar Anlisis de Transformaciones en el DFD de la figura 3

Garantizar la Funcionalidad del Diseo El paso final es el paso ms importante: tener certeza que el DE es funcionalmente equivalente al DFD de origen. El propsito del anlisis de transformaciones, es obtener rpidamente un DE que implemente correctamente la especificacin del problema y cumpla los criterios de calidad.



Anlisis de Transaccin El anlisis de transformaciones es la principal estrategia para convertir un DFD (de transformacin de datos) en un DE. Sin embargo, una pregunta est sin responder: que criterio puede ser aplicable para particionar un DFD mayor en un conjunto de DFDs de transformacin? Una tcnica suplementaria, llamada anlisis de transaccin es extremadamente valiosa para dividir un DFD de alto grado de complejidad en DFDs de menor complejidad. Esta tcnica divide en distintos DFDs, uno para cada transformacin que el sistema procesa. Esos DFDs menores sern suficientemente simples como para permitir su conversin por medio del anlisis de transformaciones en Diagramas de Estructura (DE). El anlisis de transaccin tambin puede ser usado para combinar los diagramas de estructura individuales (de transacciones separadas) en un diagrama de estructura mayor y ms flexible. Una transaccin, en general, es un estmulo para un sistema que posee un conjunto de actividades a ser realizadas internamente. Ejemplos de transacciones son: incluir un nuevo cliente, generar una factura por venta de mercaderas, actualizar el stock de un producto, disminuir la temperatura de un reactor nuclear, actualizar archivo maestro o generar el reporte de movimientos de cuenta corriente.

TranTipo

saccin de

ObteneTransac

Tipo dr

cine

TransaccinTipo

B

TransaccinTipo

A

TransaccinTipo

C

AplicarTransaccin

Fig.5: La Estructura Tpica de los DE Generados por Anlisis de Transaccin


Ingeniera de Sistemas II IND-225 Captulo 1 Los DE que resultan del anlisis de transaccin tienen la forma descripta por la figura 5. De manera similar al anlisis de transformaciones, la actividad principal para derivar un DE a partir del DFD, en el anlisis de transaccin, es identificar el centro de transaccin. Frecuentemente, es muy fcil reconocer transacciones, centros de transacciones y procesos de transaccin a travs del formato del diagrama. Siempre que un flujo de datos entra en un proceso que determina su tipo y lo enva a un proceso relacionado con el tipo, se puede tener certeza que fue localizado un centro de transacciones. El DFD para un centro de transaccin de operaciones en cuenta corriente est representado en la figura 7.

Valor

Generar

Movimientos

Informe de

Iniciar

Deseada Operain

Registrar Extracciones

Registrar Depsito

# de Cuenta

Cuenta C i t

Clientes Registro del Cliente

Movimiento

Operacin Deseada

Saldo

# de Cuenta

# de Cuenta

# de Cuenta

# de Cuenta

Consultar

de Cuenta Saldo

Movimiento

Saldo

Movimiento

Movimiento

Fig. 7: Ejemplo de DFD de Transacciones

El proceso Iniciar Operacin Deseada contiene el centro de transaccin el cual activa el proceso apropiado dependiendo de la Operacin Deseada. Sin embargo, la manifestacin del centro de transaccin en un DFD es frecuentemente ms sutil.



Parmetro deDireccionamiento

Parmetro deCurso

Parmetro deSeguimiento

Parmetro deDisparo

Curso Corriente

ngulo deDireccionamiento

Coordenadasdcl objetivo

Detalle delDisparo

Direccionarel Barco

LocalizarObjetivo

AjustarCurso

Terminalde Control Giroscpo

Timn

DispararMsil

Misil

Fig.8: Ejemplo de DFD de Transacciones sin Mostrar el Centro

En el DFD de la figura 8, las diferentes transacciones son identificadas claramente pero, dnde est el centro de transaccin?. Una posibilidad es adicionar un proceso que recibe todos los flujos de entrada y determine la transaccin adecuada pero, esa situacin artificial complicara innecesariamente el diseo y tornara el sistema inflexible (ya que un nico proceso debera preocuparse de todos los tipos de transacciones del sistema). La solucin mas adecuada es incorporar un proceso de control que solamente reciba la informacin de control necesaria para determinar la transaccin que tiene que ser ejecutada. En la realidad, un centro de transaccin tiene la mayora de las veces la funcionalidad de un proceso de control. As, el DFD de la figura Error! Marcador no definido., con el centro de transaccin incorporado, es mostrado en la figura 9.

Parmetro deDirecionamiento

Parmetro deCurso

Parmetro deSeguimiento

Parmetro deDisparo

Curso Corriente

ngulo deDirecionamiento

Coordenadasdel Objetivo

Detalle delDisparo

Terminalde Control Giroscpo

Timn

Misil

Direccionarel Barco

LocalizarObjetivo

AjustarCurso

DispararMsil

Inv. Op.Adecuada

Seal deControl

Fig.9 : Ejemplo de DFD de Transacciones Incorporando el Centro


Ingeniera de Sistemas II IND-225 Captulo 1 El ejemplo de las transacciones bancarias de la figura Error! Marcador no definido. es un poco diferente. El centro de transaccin Iniciar Operacin Deseada no fue incluido artificialmente. Eso se muestra en el DFD, tal vez, por algn motivo de modelado y puede traer alguna otra funcionalidad diferente a la de control. Ese es un proceso normal que tiene el rol de control y adems tiene la funcin de control; ese hecho, puede ser modelado de la forma mostrada en la figura 10.

Valor

Generar

MovimientosReporte de

Iniciar

DeseadaOperacin

RegistrarExtraccin

RegistrarDepsito

# de Cuenta

Cuenta Corriente

ClientesRegistro del Cliente

Movimiento

OperacinDeseada

Saldo

# de Cuenta

# de Cuenta

# de Cuenta

# de Cuenta

Consultar

de CuentaSaldo

Movimiento

Saldo

Movimiento

Movimiento

Fig. 10: Ejemplo de DFD de Transacciones

Una vez identificado el centro de transaccin, el DFD original resulta subdividido en un nmero de DFDs menores, uno por cada transaccin, que pueden ser derivados por anlisis de transformaciones o, nuevamente, por anlisis de transaccin. La figura muestra el DE resultante para los ejemplos de las figuras Error! Marcador no definido. y Error! Marcador no definido..



ControlSeal de

AjustarCurso

ControlarDireccindel Barco

LocalizarObjetivo

DispararMsil

GobernarBarco

Obtener

ControlSeal de

DeseadaOperacin

ObteneDeseada

Operacirn ConsultarSaldo

GenerarReporte

de MovimsRegistrarDepsito

RegistrarExtraccin

TransaccinBancarias

# de Cuenta

# de Cuenta # de Cuenta # de Cuenta

# de Cuenta

Fig. 1: DE Para los Ejemplos de las figuras Error! Marcador no definido. y

Error! Marcador no definido.

El anlisis de transacciones genera un esqueleto de diagrama de estructura que deber ser unido (substituyendo las hojas) con los diagramas de estructura de cada una de las transformaciones identificadas.


Captulo No. 1Modelo de ImplementacinDEFINICIN DE MDULOUn mdulo se define como un conjunto de sentencias de programa con cuatro atributos bsicos:1.10 Estrategias de TransformacinEjemplos de transformacin de Diagrama de Flujo de Datos a Diagrama de EstructuraEjemplo 2

Primer nivel de FactorizacinFinal

Lectura Complementaria: Anlisis de TransformacionesAnlisis de la Especificacin del ProblemaIdentificar el Centro de TransformacinEstrategia para Determinar el Centro de Transformacin

Producir un Primer Diagrama de Estructura (First-Cut)Mejorar el Diagrama de Estructura ObtenidoGarantizar la Funcionalidad del Diseo

Anlisis de Transaccin

Documents

modelo estructurado