Modelo Estructurado

Ingeniera de Sistemas II
IND-225
Captulo 1
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
Jimmy Camacho Villazn

Docente Titular Ingeniera de Sistemas
FCyT - UMSS
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

FCyT - UMSS
IND-225
Captulo 1
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

FCyT - UMSS
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.
FCyT - UMSS
IND-225
Captulo 1
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,
FCyT - UMSS
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

FCyT - UMSS
IND-225
Captulo 1
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.
FCyT - UMSS
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.
FCyT - UMSS
Mdulo
IND-225
Captulo 1
CALCULAR SALDOS
Nombre del Mdulo

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

FCyT - UMSS
c.
IND-225
Captulo 1
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
FCyT - UMSS
10
IND-225
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
FCyT - UMSS
11
Captulo 1
IND-225
1.10 Estrategias de Transformacin

FCyT - UMSS
12
Captulo 1
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, ...).

FCyT - UMSS
13

FCyT - UMSS
IND-225
14
Captulo 1
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:

FCyT - UMSS
15
IND-225
Resultado Final:

FCyT - UMSS
16
Captulo 1
IND-225
Ejemplo 2
Primer nivel de Factorizacin
Final

FCyT - UMSS
17
Captulo 1
IND-225
Captulo 1
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
Estructurado
DFDs resultantes del

Proceso de Analisis
Anlisis de la Especificacin
del Problema
DFDs sin detalles de ms y sin
ocultar transformaciones de datos
Identificar el Centro
de Transformacin
Marcar el Centro de Transformacin;
Caminos Aferentes y Eferentes
Produccin de un Primer
DE (First-Cut)
Especificacin del Analisis
Funcionalmente
Equivalentes
Mejoramiento del DE
Centro de Transformacin=Raiz
Caminos Aferentes=Izquierda
Caminos Eferentes=Derecha
Cohesin, Acoplamiento, etc
Diseo de buena Calidad
Asegurar la Funcionalidad
del Diseo
Implementacin,
Testeo, etc.
Diseo Estructurado de buena

Calidad(mantenimiento;
eficiencia; claridad; etc)
Fig.1: Pasos del Anlisis de Transformaciones

FCyT - UMSS
18
IND-225
Captulo 1
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.

FCyT - UMSS
19
IND-225
Captulo 1
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.

FCyT - UMSS
20
IND-225
Captulo 1
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 Anlisis 1 ), 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.
FCyT - UMSS
21
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.
Fin de Camino
Eferente
Reunir
Transacciones
Campo
Invalido
Campo
Transaccin
Editar Editado
Campo
Campo
Editado
Campo
Transaccin
Efectuar Vlida
Validacin
Cruzada
Registro
Maestro
Vlido
Registro
Maestro
Invlido
Inicio de Camino
Aferente
Transaccin
Invlida
Registro
Maestro
Validar
Registro
Maestr
Formatear
Linea de
Informe
Transaccin sin
Registro Maestro
Aparear
Transaccin
con Registro
Maestro
Nuevo
Registro
Maestro
Archivo
Linea de
Informe
Registro
Maestro
Juntado
Registro
Maestro sin
Transaccin
Formatear
Nuevo
Registro
Maestro
Transaccin
Aplicada
Actualizar
Registro
Maestro
Registro
Maestro
Actualizado
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).
FCyT - UMSS
22
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
D
h
i
F
j
c
b
e
E
e
d
k
j
q
X
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.

FCyT - UMSS
23
IND-225
Captulo 1
Se deben asociar nombres adecuados a los

mdulos adicionales, dependiendo de la actividad
de lectura (captacin) o escritura (presentacin)
que deben ejecutar.
e
B
c
a
F
f
G
q
Gra
X
Leer
X
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.
D
g
C
e
B
c
Et Er
Em
j
Leer
X
l
m
G
E
n
q
Gra
X
o
H
Or
b
4. Indicar un nico mdulo como raz del a
DE, sea por seleccin de uno de los Ic Ec
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).

FCyT - UMSS
24
o
H
p
IND-225
Captulo 1
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:
Actualizar
Archivo
Maestro
Transaccin
Vlida
FTV
# Cuenta
Obtener
Transaccin
Vlida
Transaccin
Obtener
Registro
Maestro
Leer
Registro
Maestro
Campo
Editado
FCE
Obtener
Campo
Editado
Campo
FC
Obtener
Campo
TV
Juntar
Registro
Maestro
Reg Maestro
Actualizado
Reg Maestro
sinTrans
FT
Campo
Editado
FCE
RMV
Reg Maestro
# Cuenta
Obtener
Transacci
Reg
Maestro
Valido
Transaccin sin
Registro Maestro
Generar
Registro
Maestro
Nuevo Reg
Maestro
Formatear
Nuevo
Registro
Maestro
FC
FCE
FT
FTV
RMV
TV
Transaccin
Aplicada
TV
Transaccin
Aplicada
Grabar
Nuevo
Registro
Maestro
Fin de Campo
Fin de Campo Editado
Fin de Transaccin
RMV
Actualizar
Registro
Maestro
Nuevo Reg
Maestro Fmt
Informar
Transaccin
Errnea
Imprimir
Transaccin
Aplicada
Lnea
de
Error
Lnea
Formatear
Lnea de
Informe
Imprimir
Lnea de
Informe
Fin de Transaccin Vlida

Registro Maestro Vlido
Transaccin Vlida
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.

FCyT - UMSS
25
IND-225
Captulo 1
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.
Aplicar
Transaccin
Tipo de
Transaccin
Obtener
Tipo de
Transaccin
Transaccin
Tipo
A
Transaccin
Tipo
B
Transaccin
Tipo
C
Fig.5: La Estructura Tpica de los DE Generados por Anlisis de Transaccin

FCyT - UMSS
26
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.
Registro del Cliente
Saldo
Generar
Informe de
Movimiento
s
# de Cuenta
Operacin
Deseada
# de Cuenta
# de Cuenta
Iniciar
Operain
Deseada
# de Cuenta
# de Cuenta
Clientes
Movimiento
Cuenta
C i t
Consultar
Saldo
de Cuenta
Movimiento
Saldo
Movimiento
Registrar
Depsito
Movimiento
Registrar
Extracciones
Valor
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.

FCyT - UMSS
27
IND-225
Parmetro de
Direccionamiento
Captulo 1
Direccionar
el Barco
Parmetro de
Curso
Terminal
de Control
ngulo de
Direccionamiento
Timn
Ajustar
Curso
Curso Corriente
Parmetro de
Seguimiento
Localizar
Coordenadas
dcl objetivo
Objetivo
Parmetro de
Disparo
Disparar
Msil
Giroscpo
Misil
Detalle del
Disparo
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 de
Direcionamiento
Direccionar
el Barco
Parmetro de
Curso
Terminal
de Control
ngulo de
Direcionamiento
Timn
Ajustar
Curso
Curso Corriente
Parmetro de
Seguimiento
Seal de
Control
Localizar
Objetivo
Giroscpo
Coordenadas
del Objetivo
Parmetro de
Inv. Op.
Adecuada
Disparo
Disparar
Msil
Detalle del
Disparo
Misil
Fig.9 : Ejemplo de DFD de Transacciones Incorporando el Centro

FCyT - UMSS
28
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.
Registro del Cliente
Saldo
Generar
Reporte de
Movimientos
# de Cuenta
Operacin
Deseada
# de Cuenta
Iniciar
Operacin
Deseada
# de Cuenta
Clientes
Movimiento
Cuenta Corriente
Consultar
Saldo
de Cuenta
Movimiento
Saldo
Movimiento
# de Cuenta
Registrar
Depsito
Movimiento
# de Cuenta
Registrar
Extraccin
Valor
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..

FCyT - UMSS
29
IND-225
Captulo 1
Gobernar
Barco
Seal de
Control
Obtener
Seal de
Control
Controlar
Direccin
del Barco
Ajustar
Curso
Localizar
Objetivo
Disparar
Msil
Transaccin
Bancarias
# de Cuenta
Operacin
Deseada
# de Cuenta
# de Cuenta
Obtener
Operacin
Deseada
Generar
Reporte
de Movims
# de Cuenta
# de Cuenta
Consultar
Saldo
Registrar
Depsito
Registrar
Extraccin
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.

FCyT - UMSS
30

Modelo Estructurado

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelo Estructurado

Uploaded by

Copyright:

Available Formats

Ingeniera de Sistemas II

El Modelo de Programas: Diseo Estructurado

Se llama Diseo Estructurado al proceso de decidir los componentes necesarios, y

Jimmy Camacho Villazn

la otra. Al abordar la etapa de diseo, la persona debe quitarse el sombrero de

Objetivos Del Diseo Estructurado

"El diseo estructurado, tiende a transformar el desarrollo de software de una

"Diseo" significa planear la forma y mtodo de una solucin. Es el proceso que

Jimmy Camacho Villazn

performance y calidad que la mejor implementacin puede alcanzar, y puede

Es el primer paso en el desarrollo del Modelo de Implementacin. Tiene como

Jimmy Camacho Villazn

PROCESADOR, que se encargar de desarrollar el proceso. Esta etapa se

Tiene como objetivo bsico el tratar d enfocar la programacin a travs de

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

Entradas/ Salidas: Datos que recibe cuando lo invocan y datos que

Adems posee otros atributos adicionales cmo:

A simple vista podemos apreciar que el presidente de la empresa tiene

Jimmy Camacho Villazn

Podemos apreciar a simple vista que la tarea de los jefes A, X, Y, es relativamente

En principio diremos que escribir un programa "grande" generalmente lleva ms

Intentaremos tomar dos problemas separados y en lugar de escribir dos

C(P+Q) > C(P) + C(Q)

Nombre del Mdulo

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

Un mdulo puede invocar a varios otros que dependen de l:

A su vez, un mdulo puede ser invocado por varios mdulos

Jimmy Camacho Villazn

Representa a parmetros de informacin que pasan a travs de los mdulos. El

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

1.9 Acoplamiento y Cohesin.

1.10 Estrategias de Transformacin

Jimmy Camacho Villazn

Jimmy Camacho Villazn

Jimmy Camacho Villazn

Ejemplos de transformacin de Diagrama de Flujo de Datos a Diagrama de

Diagrama Intermedio (Alquilar un jefe)

Jimmy Camacho Villazn

Jimmy Camacho Villazn

Primer nivel de Factorizacin

Jimmy Camacho Villazn

Lectura Complementaria: Anlisis de Transformaciones

DFDs resultantes del

Especificacin del Analisis

Diseo de buena Calidad

Diseo Estructurado de buena

Fig.1: Pasos del Anlisis de Transformaciones

Jimmy Camacho Villazn

Anlisis de la Especificacin del Problema

Jimmy Camacho Villazn

Identificar el Centro de Transformacin

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

El diseador podra considerar al proceso Reunir Movimientos del Cliente como la

Jimmy Camacho Villazn

La eleccin del centro de transformaciones no es una actividad simple,

En el ejemplo de la figura 3 se ilustra la actividad descripta arriba. Primero se

Fig. 3: Ejemplo de Anlisis de Transformaciones

La curva tambin indica la finalizacin de los caminos aferentes y el comienzo de

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

Jimmy Camacho Villazn

Se deben asociar nombres adecuados a los