Anlisis Estructurado

Juan Pablo Salazar F.

INFO 265
Fuente: Anlisis Estructurado Moderno
Edward Yourdon
Antecedentes
50s y 60s las organizaciones grandes (Fortune 500) en
EEUU desarrollan sistemas operacionales en entornos
Mainframe.
Sistemas en general son manejados por centros de
procesamiento de datos.
Complejidad y costo creciente de mantencin.
Sistemas no documentados o documentacin no actualizada e
inconsistente (creen posible mantener documentacin
desarrollada con mquinas de escribir?)
80s aparecen herramientas de desarrollo ms
modernas, grandes empresas comienzan a trabajar en
reemplazo de sistemas operacionales.
Antecedentes
Comienzan a masificarse los lenguajes de
programacin estructurados (se sataniza
el GOTO!!!).
Aparece el PC y los entornos grficos.
Es ahora posible terminar con la utilizacin de
especificaciones del tipo Novela Victoriana
(Alguien recuerda a Joaqun Edwards Bello
o a Mariano Latorre?).
Es posible realizar y mantener en el tiempo
los diagramas a un costo razonable.
Antecedentes
Qu suceda antes de contar con herramientas
grficas?
Despus de la segunda o tercera revisin, el analista
se tornaba cada vez ms renuente al cambio.
La especificacin generada no alcanzaba el nivel de
detalle necesario y el programador deba refinar el
anlisis.
Exista un desfase entre la llegada de nuevos
requerimientos y su incorporacin en la
especificacin.
La redundancia en la especificacin textual derivaba
en inconsistencias difciles de detectar a tiempo.
Anlisis Estructurado
Tcnica originalmente pensada para sistemas
monolticos.
Tcnica til especialmente para sistemas
operacionales, donde es posible separar
claramente un problema en 3 componentes
principales, existiendo herramientas apropiadas
para especificarlas:
Datos: Modelo Entidad-Relacin y Diccionario de
Datos.
Funciones: Diagrama de Flujo de Datos y
Especificacin de Procesos.
Comportamiento: Diagramas de Transicin de
Estados.
Diagrama de Flujo de Datos (DFD).
Son de gran importancia en sistemas
operacionales donde las funciones tienen mayor
importancia y son ms complejas que los datos
que manejan.
Tcnicas similares han sido utilizadas
prcticamente casi un siglo por otras ramas de
la ingeniera y por la investigacin de
operaciones (modelos de procesos, relaciones
causa-efecto).
Son bastante intuitivos y fcilmente
comprensibles por usuarios y clientes.
Diagrama de Flujo de Datos (DFD).
Los diagramas caben generalmente en
una pgina y son legibles.
Los diagramas hacen ver el sistema
relativamente simple.
No es necesario leer el documento
completo para comprender aspectos clave
del anlisis.
Los diagramas son mantenibles.
Diagrama de Flujo de Datos (DFD)
Componentes Principales
Burbuja:
Denota un proceso.
En general, su nombre
es una frase sencilla,
cuya palabra principal
es un verbo (indica lo
que hace), por
ejemplo
Calcular_Impuesto.
Preparar
Pastel
Diagrama de Flujo de Datos (DFD)
Componentes Principales
Flujo:
Flecha que entra o
sale de un proceso.
Representa
movimiento de datos.
Cada flujo representa
un nico tem de
datos.
Los flujos pueden
converger o diverger.
Preparar
Pastel
Harina
Azcar
Huevos
Leche
Pastel
Diagrama de Flujo de Datos (DFD)
Componentes Principales
Almacn:
Modela un conjunto de
paquetes de datos en
reposo (archivo, tabla
de una base de datos,
krdex, etc.).
Puede existir como
consecuencia de un
requerimiento
especfico del usuario
o para traspaso de
informacin entre
procesos.
Clientes
Diagrama de Flujo de Datos (DFD)
Componentes Principales
Terminador:
Representa una entidad
externa (personas,
organizaciones, reas, otros
sistemas).
No es necesario ni
conveniente mostrar las
relaciones entre
terminadores en un DFD.
Cajero
Construccin de un DFD
Escoger nombres con significado para procesos, flujos,
almacenes y terminadores.
Identificar roles, no personas.
Evitar verbos ambiguos como hacer, manejar, procesar.
Utilizar trminos del espacio del problema.
Numerar los procesos.
Redibujar los DFDs tantas veces como sea necesario
estticamente.
Evitar los DFD excesivamente complejos.
Diagrama debe caber cmodamente en una hoja normal.
Asegurar la consistencia interna y externa.
Burbujas sin entradas o sin salidas son sospechosas.
Todos los flujos y procesos deben ser etiquetados.
Construccin de un DFD
El resultado debe ser un DFD por
niveles.
1. Diagrama de Contexto.
Una nica burbuja identifica al sistema.
2. Diagrama de Nivel 0.
Identifica los 4-6 mdulos principales.
3. Diagrama de Nivel 1,2..N.
Refina uno de los diagramas del nivel anterior.
Construccin de un DFD
Cuntos niveles?

Deben tener todas las partes del sistema el
mismo nivel de detalle?

Cmo se muestran los almacenes de datos en
los diferentes niveles?

Cmo se realiza la particin del DFD en
niveles?
Construccin de DFDs
Problemas del enfoque descendente:
Parlisis del anlisis.

Fenmeno de los 6 analistas.

Particin fsica arbitraria.
Construccin de DFDs
Enfoque Top-Bottom
Identificar funciones principales del sistema.
Identificar entradas y salidas
Realizar nivelaciones ascendentes y
refinamiento segn sea necesario.
Agrupar procesos relacionados.
Esconder almacenes de datos que debiesen
aparecer en un nivel inferior.
Dividir burbujas preliminares cuando el proceso lo
amerite.
Realizar una breve especificacin de cada
burbuja, una vez que se ha logrado el nivel de
detalle esperado.
Diagrama Entidad-Relacin
En sistemas operacionales puede ser
importante revisar las estructuras de datos
y sus relaciones de manera independiente
de los procesos.
La informacin clave de una organizacin
puede ser responsabilidad de personas
distintas a los dueos de los procesos.
Las relaciones entre los datos no son
posibles de ver claramente en un DFD.
Componentes de un diagrama E-R
Conjuntos de
entidades.
Conjuntos de
relaciones.

Relaciones de
clasificacin
(tipo/subtipo)

Cajeros
Compra
Empleado
Es
Empleado por
Horas
Empleado
Asalariado
Diccionario de datos
Es importante identificar los atributos de
cada uno de los almacenes de datos.
Es importante identificar los atributos que
constituyen las claves primarias y
forneas de cada una de las entidades.
Las relaciones N-M conducen a relaciones
que poseen atributos.
Diagramas de transicin de
estados.
Son relevantes cuando existe comunicacin
asncrona entre procesos.
Son utilizados comnmente en el modelamiento
de sistemas en tiempo real.
Los diagramas incluyen los estados por los que
pasa un sistema y las transiciones entre stos.
En general, tienen un estado inicial, uno o ms
estados intermedios, y uno o ms estados
finales.
Es conveniente dividir los diagramas complejos
en niveles (igual que un DFD).
Diagramas de Transicin de
Estados (DTE)
Estado Inicial.

Estado Final.

Estado intermedio.


Transicin
Ingresado
Generado
Terminado
Reglas para validar un DTE
Todos los estados deben ser alcanzables.
Debe ser posible salir de todos los
estados no finales.
El sistema debe responder, dado cada
estado, a todas las condiciones posibles.
Ejemplo: Meses de morosidad.
Balanceo de Modelos
Historia de los 3 ciegos tocando un
elefante.
Riesgo de desarrollar interpretaciones
inconsistentes de la realidad.
Si los modelos son desarrollados por
diferentes analistas, es posible que tengan
acceso a informacin distinta del problema.
Error ms comn: Definiciones faltantes
en alguno de los modelos.
Balanceo de Modelos
Los almacenes de datos en el DFD deben
corresponder a conjuntos de entidades o
conjuntos de relaciones del modelo E-R o
a archivos de interfaz.
Debe existir coincidencia de nombres
entre los diferentes modelos.
Debe existir coincidencia entre los niveles
de los DFDs y DTEs.
Ejemplo. (Utilizar VISIO Software
DataFlow Model Diagram
1. Ingresar
Pedido
Cajero
Clientes
Detalle de Pedidos
Pedidos
Artculos
Pedido
Actualiza stock
3. Enviar
Pedido
Pedidos no despachados
2. Ingresar
Nuevo Cliente
Datos del cliente
Datos del Cliente
Datos del cliente
Lista de artculos
Cliente
Factura, Gua
Ejemplo2
1. Calcular
races
ax2+bx+c=0
Usuario
b
c
a
Usuario
X1
X2
X1
Usuario
a
Usuario
b
c
X2
1.1 Raz(B2 -
4ac)
1.2 -b
b
1.3 (N+m)/2a
m
n
a
1.4 (N-m)/2a m
n
a
Diseo Estructurado
Juan Pablo Salazar F.
INFO 265
Qu es el Diseo?
Proceso mediante el cual se traducen los requisitos
especificados durante la etapa de anlisis en una
representacin de software, con un nivel de detalle
suficiente de modo tal que permita que su
implementacin sea un proceso ms bien mecnico.
El diseo de un sistema debe abarcar los aspectos
arquitectnico, procedimental y de datos, as como
tambin la definicin de la interfaz hombre-mquina,
elemento fundamental en aplicaciones cliente/servidor.
Dicho proceso tcnico permite traducir con precisin los
requisitos del cliente en un producto o sistema acabado,
de modo de asegurar su calidad.
Cartas de Estructura
Describen al sistema como una jerarqua de
partes y lo muestran grficamente como un
rbol.
Documentan cmo se pueden aplicar los
elementos de un diagrama de flujo de datos
como una jerarqua de unidades de programa.
Un diagrama de estructura muestra las
relaciones entre las unidades de programa sin
incluir ninguna informacin acerca del orden de
activacin de dichas unidades.
Cartas de Estructura
Su simbologa consiste en
Unidades de programa
(mdulos), denotadas por
rectngulos.
Conexiones entre mdulos,
denotadas por flechas.
Paso de parmetros entre
mdulos, denotado por flechas
cuyo origen est en el mdulo
que produce el dato y el destino
est en el mdulo que lo recibe.
Fuentes de datos (archivos o
tablas), denotadas por
rectngulos con bordes laterales
dobles.
A
B C
D
x
w y
z
Tareas principales
Diseo Estructurado
Transformar DFDs en Cartas de Estructura.
Flujo de Transaccin
a
b
c
d
e
f
Control de
transaccin
Camino de
Recepcin
Distribuidor
a b
c
d
e
f
Flujo de Transformacin
Flujo entrante Flujo de transformacin Flujo saliente
Tareas principales
Diseo Estructurado
Acercar diagramas E-R y Diccionario de
Datos al lenguaje de implementacin.
Modelo Fsico, definicin de tipos de datos,
restricciones de integridad.
Diseo de Sistemas Cliente
Servidor y Multicapa
Desafos metodolgicos.
Divisin de funcionalidad o abstracciones
entre cada capa.
Ubicar las reglas de negocio en aquella parte del
sistema que tenga mayor conocimiento respecto
del impacto de dichas reglas.
Proveer mecanismos que permitan ocultar dichas
decisiones.
Lo anterior implica realizar extensiones al proceso
de Anlisis y Diseo Estructurados.
Diseo de Sistemas Cliente
Servidor y Multicapa
Extensin para DFD.
Diseo de Sistemas Cliente
Servidor y Multicapa
Extensin para E-R.
Diseo de Sistemas Cliente
Servidor y Multicapa
Extensin para Cartas de Estructura.
Qu problemas tiene lo anterior?
Diseo de Sistemas Cliente
Servidor y Multicapa
Problemas:
Mantenibilidad.
Mtodo no incorpora necesidad de mdulos adicionales de
interfaz (no es posible ocultar localizacin de los mdulos a
nivel de diseo).
Diseo de Sistemas Cliente
Servidor y Multicapa
Desafos metodolgicos.
Mecanismos de manejo de transacciones.
Se recomienda centralizar el manejo de
transacciones en el servidor.
Las cartas de estructura no proveen mecanismos
que permitan centralizar los accesos al servidor,
stos tendern a quedar dispersos en el cdigo.
No se incorpora notacin especial ni se da
tratamiento particular a elementos de conectividad
(ODBC, ADO, etc.).
Diseo de Sistemas Cliente
Servidor y Multicapa
Desafos metodolgicos.
Diseo de aplicaciones cliente.
El Diseo Estructurado fue desarrollado cuando se
daba mayor importancia al diseo de datos y
procesos y no al de la interfaz a usuario.
Las Cartas de Estructura no estn preparadas
para modelar una interfaz dirigida por eventos.
Solucin: No utilizar Cartas de Estructura para
modelar aplicaciones Cliente.
Ejercicio
Suponga que se requiere un sistema de arriendo de
pelculas en un VideoClub. Suponga que la nica
informacin relevante que interesa registrar respecto de
las pelculas es el ttulo y la cantidad de copias.
Suponga que debe implementar el sistema utilizando
una base de datos relacional que soporta
procedimientos almacenados y un lenguaje visual para
la interfaz a usuario.
Se le pide:
Modelo E-R
DFD del proceso de arriendo de pelculas
Carta de Estructura, indicando qu mdulos quedarn en el
cliente y cules en el servidor.