Diagrama de flujo

del Sistema
El diagrama de flujo de datos (DFD)
El diagrama de flujo de datos (DFD), es una herramienta que
permite visualizar un sistema como una red de procesos
funcionales, conectados entre s por "conductos" y "tanques de
almacenamiento" de datos.
Es una de las herramientas ms usadas, sobre todo por
sistemas operacionales en los cuales las funciones del sistema
son de gran importancia y son ms complejos que los datos
que ste maneja.
Es importante tener en mente: los DFD no slo se pueden
utilizar para modelar sistemas de sistemas de proceso de
informacin, sino tambin como manera de modelar
organizaciones enteras, es decir, como una herramienta para
la planeacin estratgica y de negocios.
El diagrama de flujo de datos (DFD)
Componentes de un diagrama tpico de flujo
de datos:
Proceso.
Flujo.
Almacn.
Terminador.
Proceso
Es el primer componente del DFD
Los sinnimos comunes son burbuja,
funcin, transformacin.
El proceso muestra una parte del sistema
que transforma entradas en salidas.
Proceso
El proceso se representa grficamente como un
crculo.
Algunos analistas prefieren usar un valo o un
rectngulo con esquinas redondeadas, otros
prefieren usar un rectngulo.
Las diferencias entre estas tres formas son
puramente cosmticas, aunque obviamente es
importante usar la misma forma de manera
consistente para representar todas las funciones de
un sistema.
Ejemplos de procesos
Ejemplos de procesos
El proceso se nombra o describe con una sola
palabra, frase u oracin sencilla.
Un buen nombre para un proceso generalmente
consiste en una frase verbo-objeto tal como validar
entradas o calcular impuesto.
En algunos casos, el proceso contendr el nombre
de una persona o un grupo (por ejemplo, un
departamento o una divisin de una organizacin), o
de un ordenador.
Flujo
Los flujos realmente representan datos, es
decir, bits, caracteres, mensajes, nmeros
de punto flotante y los diversos tipos de
informacin que podemos tratar.
El nombre representa el significado del
paquete que se mueve a lo largo del flujo.
El flujo slo lleva un tipo de paquete, como lo
indica su nombre.
Ejemplo de un flujo.
Flujo
Los flujos muestran tambin la direccin: una
cabeza de flecha en cualquier extremo (o
posiblemente ambos) del flujo indica si los
datos (o el material) se est moviendo hacia
adentro o hacia fuera de un proceso (o
ambas cosas).
Los datos que se mueven a lo largo de dicho
flujo viajarn ya sea a otro proceso (como
entrada) o a un almacn o a un terminador.
Flujo
El flujo de dos cabezas es un dilogo, es
decir, dos paquetes de datos (una pregunta
y una respuesta) el mismo flujo.
En el caso de un dilogo, los paquetes de
cada extremo de la flecha deben nombrarse.
Flujo
Flujo de entrada.
Flujo
Flujo de salida.
Flujo
Flujo de dilogo.
Almacn.
El almacn se utiliza para modelar una
coleccin de paquetes de datos en reposo.
Se denota por dos lneas paralelas
De modo caracterstico el nombre que se
utiliza para identificar al almacn es el plural
del que se utiliza para los paquetes que
entran y salen del almacn por medio de
flujos.
Almacn.
Representacin grfica de un almacn
Almacn.
Para el analista con conocimiento de
proceso de datos es tentador referirse a los
almacenes como archivos o base de datos;
Un almacn tambin pudiera consistir en
datos almacenados en otros dispositivos,
nombres y domicilios en un directorio,
diversos archivos
Almacn.
Aparte de la forma fsica que toma el almacn,
tambin existe la cuestin de su propsito:
Existe el sistema por causa de un requerimiento
fundamental del usuario o por algn aspecto
conveniente de la realizacin del sistema?.
En el primer caso, la base de datos existe como un
rea de almacenamiento diferida en el tiempo,
necesaria entre dos procesos que ocurren en
momentos diferentes.
Almacn.
Los almacenes se conectan por flujos a los
procesos.
El contexto en el que se muestra en un DFD
es uno de los siguientes (o ambos):
Un flujo desde un almacn.
Un flujo haca un almacn.
Terminador.
El terminador grficamente se representa como un rectngulo.
Los terminadores representan entidades externas con las
cuales el sistema se comunica.
Comnmente, puede ser una persona, o un grupo, por ejemplo,
una organizacin externa o una agencia gubernamental, o un
grupo o departamento que est dentro de la misma compaa u
organizacin, pero fuera del control del sistema que se est
modelando.
En algunos casos, un terminador puede ser otro sistema, como
algn otro sistema con el cual se comunica ste.
Terminador.
Representacin grfica de un terminador
Terminador.
Existen tres cosas importantes que debemos
recordar acerca de los terminadores:
Son externos al sistema que se est modelando.
Es evidente que ni el analista ni el diseador del
sistema estn en posibilidades de cambiar los
contenidos de un terminador o la manera en que
trabaja.
Las relaciones que existan entre los terminadores no
se muestran en el modelo de DFD.
Gua para la construccin de DFD.
Adems de la regla bsica que existen para
la elaboracin de DFD: proceso (burbuja)
flujo, almacenes y terminadores.
Existen otras reglas adicionales que nos
permitirn no elaborar DFD errneos.
Gua para la construccin de DFD.
Las reglas:
Escoger nombres con significado para los procesos, flujos,
almacenes y terminadores
Numerar los procesos.
Evitar los DFD excesivamente complejos
Redibujar el DFD tantas veces como sea necesario estticamente.
Asegurarse de que el DFD sea lgicamente consistente y que
tambin sea con cualesquiera DFD relacionados con l.
Extensiones del DFD para sistemas de tiempo real
Escoger nombres con significado
Un proceso en un DFD puede representar una
funcin que se est llevando a cabo, o pudiera
indicar cmo se est llevando a cabo, identificando a
la persona, grupo o mecanismo involucrado.
Un buen sistema que se puede utilizar para nombrar
procesos es usar un verbo y un objeto. Es decir,
escoja un verbo activo (un verbo transitivo que tenga
objeto) y un objeto apropiado para formar una frase
descriptiva para el proceso.
Escoger nombres con significado
Ejemplos de nombres de procesos:
Producir informe de inventario.
Validar nmero telefnico.
Asignar estudiante a la clase.
Los nombres de los procesos (al igual que los
nombres de flujos y de terminadores) deben provenir
de un vocabulario que tenga algn significado para
el usuario.
Numerar los procesos.
Una forma conveniente de referirse a los procesos
en un DFD, muchos analistas numeran cada
burbuja.
No importa mucho como sea haga esto, de izquierda
a derecha, de arriba abajo o de cualquier otra
manera servir, mientras haya constancia en la
forma de aplicar los nmeros.
La nica cosa que se debe tener en mente es que el
sistema de numeracin implicar, una cierta
secuencia de ejecucin.
Numerar los procesos.
Cuando se muestre el DFD a un usuario, l
pudiera preguntar: Acaso la burbuja
nmero 1 sucede primero, luego la 2 y luego
la 3?.
Y esto no es as en absoluto. El modelo de
DFD es una red de procesos asincrnicos
que se intercomunican, lo cual es, de hecho,
una representacin precisa de la manera en
la que en realidad muchos sistemas operan.
Numerar los procesos.
Un ejemplo de la funcionalidad de enumerar
las burbujas:
Es ms fcil en una discusin sobre un DFD
decir " burbuja 1" en lugar de "Editar
transaccin y reportar errores" .
Pero de mayor importancia an es el hecho
de que los nmeros se convierten en base
para la numeracin jerrquica.
Evitar los DFD excesivamente
complejos.
El propsito de un DFD es modelar de
manera precisa las funciones que debe
llevar a cabo un sistema y las interacciones
entre ellas.
Pero otro propsito del DFD es ser ledo y
comprendido, no slo por el analista que
construy el modelo, sino por los usuarios
que sean los expertos en la materia de
aplicacin.
Evitar los DFD excesivamente
complejos.
Existe una regla principal para la elaboracin
de un DFD, que se debe tener en mente: no
cree un DFD con demasiados procesos,
flujos, almacenes y terminadores.
En la mayora de los casos, esto significa
que no debera haber ms de media docena
de procesos y almacenes, flujos y
terminadores relacionados en un solo
diagrama.
Evitar los DFD excesivamente
complejos.
Existe una excepcin importante a esto, un
diagrama especial conocido como diagrama
de contexto, que representa el sistema
entero como un solo proceso y destaca las
interfaces entre el sistema y los
terminadores externos.
Redibujar el DFD tantas veces como
sea necesario
En un proyecto real de anlisis de sistemas
el DFD debe dibujarse y volver a dibujar a
menudo hasta 10 veces o ms, antes de
1) ser tcnicamente correcto,
2) ser aceptable para el usuario y
3) estar lo suficientemente bien dibujado como
para mostrarlo a la direccin de la organizacin.
Redibujar el DFD tantas veces como
sea necesario
Qu hace estticamente agradable a un DFD?.
Es una cuestin de gustos y puede determinarse por
normas dispuestas por su organizacin o por las
caractersticas particulares de cualquier paquete que
utilice de diseo de diagramas.
Y la opinin de usuario pudiera ser un tanto
diferente a la nuestra.
Asegrese de que el DFD sea
lgicamente consistente.
Principales reglas de consistencia:
Evite burbujas que tienen entradas pero no salidas.
Evite las burbujas de generacin espontnea, que tienen
salidas sin tener entradas, porque son sumamente
sospechosas y generalmente incorrectas.
Tenga cuidado con los flujos y procesos no etiquetados. Esto
suele ser un indicio de falta de esmero, pero puede esconder
un error an ms grave: a veces el analista no etiqueta un flujo
o un proceso porque simplemente no se le ocurre algn
nombre razonable.
Extensiones del DFD para sistemas de
tiempo real.
Para los sistemas de tiempo real necesitamos
alguna manera de modelar flujos de control (es decir
seales o interrupciones).
Y se requiere una manera de mostrar procesos de
control (esto es, burbujas cuya nica labor es
coordinar y sincronizar las actividades de otras
burbujas del DFD). Se muestran grficamente con
lneas punteadas en el DFD.
Diagramas de Entidad -Relacin
El diagrama de entidad-relacin (tambin
conocido como DER, o diagrama E-R) es un
modelo de red que describe con un alto nivel
de abstraccin la distribucin de datos
almacenados en un sistema.
Diagramas de Entidad -Relacin
Porque podramos estar interesados en modelar los datos de
un sistema?.
Primeramente, porque las estructuras de datos y las relaciones
pueden ser tan complejas que se desear enfatizarlas y
examinarlas independientemente del proceso que se llevar a
cabo.
De hecho, esto se da sobre todo si mostramos el modelo del
sistema correspondiente a los usuarios ejecutivos quienes se
preocupan ms por los datos: Qu dato requerimos para
manejar nuestro negocio? Quin lo tiene? Quin tiene
acceso a ellos?.
Diagramas de Entidad -Relacin
Para el analista, el DER representa un gran
beneficio: porque enfatiza las relaciones entre
almacenes de datos en el DFD que de otra forma se
hubiera visto slo en la especificacin de procesos.
Por ejemplo, un DER tpico se muestra en la figura
siguiente. Cada una de las cajas rectangulares
corresponden a un almacn de datos en DFD y
puede verse que hay relaciones que normalmente
no se aprecian en un DFD.
Diagramas de Entidad -Relacin
Diagrama de entidad-relacin tpico.
Diagramas de Entidad -Relacin
Hay cuatro componentes principales en un
diagrama de entidad-relacin:
Tipos de objetos.
Relaciones.
Indicadores asociativos de tipo de objeto.
Indicadores de supertipo/subtipo.
Tipos de objetos
El tipo de objeto se representa en un
diagrama de entidad-relacin por medio de
una caja rectangular;
Representa una coleccin de objetos (cosas)
del mundo real cuyos miembros individuales
o instancias tienen las siguientes
caractersticas:
Tipos de objetos
Caractersticas
Cada una puede identificarse de manera
nica por algn medio.
Por ejemplo, si se tiene un tipo de objeto
conocido como cliente, debemos ser
capaces de distinguir uno de otro (tal vez por
un nmero de cuenta, por su apellido, o por
su nmero de Seguro Social).
Tipos de objetos
Un tipo de objeto
Tipos de objetos
caractersticas
Cada uno juega un papel necesario en el sistema
que se construye. Es decir, para que el tipo de
objeto sea legtimo, debe poder decirse que el
sistema no puede operar sin tener acceso a esos
miembros.
Cada uno puede describirse por uno o ms datos.
Es decir, un cliente puede describirse por medio de
datos tales como nombre, domicilio, lmite de crdito
y nmero telefnico.
Tipos de objetos
En muchos de los sistemas, los tipos de objetos
sern la representacin del sistema de algo material
del mundo real.
Esto significa que los clientes, artculos de
inventario, empleados, partes manufacturadas, etc.,
son objetos tpicos.
El objeto es algo material del mundo real, y el tipo
de objeto es su representacin en el sistema. Sin
embargo, un objeto pudiera ser algo no material: por
ejemplo, horarios, planes, estndares, estrategias y
mapas.
Tipos de objetos
Una persona (o cualquier cosa material)
pudiera ser diversos tipos de objetos
distintos en distintos modelos de datos, o
incluso en un mismo modelo.
J uan Prez, por ejemplo puede ser
empleado en un modelo de datos y cliente
en otro. Tambin pudiera ser empleado y
cliente dentro del mismo modelo.
Relaciones
Una relacin representa un conjunto de
conexiones entre objetos, y se representa
por medio de un rombo.
Relacin sencilla, que pudiera existir entre
dos o ms objetos.
Relaciones
Cada instancia de la relacin representa una
asociacin entre cero o ms ocurrencias de un
objeto y cero o ms ocurrencias del otro.
En la figura anterior, la relacin etiquetada como
compras puede contener las siguientes instancias
individuales:
Instancia 1: el cliente 1 compra el artculo 1
Instancia 2: el cliente 2 compra los artculos 2 y 3.
Instancia 3: el cliente 3 no compra ningn artculo.
Relaciones
La relacin representa algo que debe ser recordado
por el sistema: algo que no pudo haberse calculado
ni derivado mecnicamente.
As, el modelo de datos de la figura indica que existe
alguna razn relacionada con el usuario para
recordar el hecho de que el cliente 1 compra el
artculo 1, etc.
Y tambin indica que no existe nada priori que
hubiera permitido determinar que el cliente 1 compr
el artculo 1 y nada ms.
Relaciones
Notacin alternativa para relaciones
El diagrama E-R son multidireccionales, esto es,
puede leerse siguiendo cualquier direccin.
No muestran cardinalidad, es decir, no muestran el
nmero de objetos que participan en la relacin.
Una notacin alternativa utilizada por algunos
analistas muestra tanto la cardinalidad como la
ordinalidad.
Indicadores asociativos de tipo de
objeto
El indicador asociativo de tipo de objeto representa algo que
funciona como objeto y como relacin.
Por ejemplo, un cliente que adquiere un artculo. En donde la
relacin de compra no hace ms que asociar un cliente con
uno o ms artculos.
Pero suponga que existen datos que deseamos recordar
acerca de cada instancia de una compra (por ejemplo a qu
hora del da se hizo). Dnde se podra almacenar dicha
informacin? "Hora del da" no es un atributo de cliente, ni de
artculo. Ms bien, se asocia "Hora del da" con la compra
misma.
Indicadores asociativos de tipo de
objeto
Indicador asociativo de tipo objeto
Indicadores asociativos de tipo de
objeto
Compra ahora se escribe dentro de una caja rectangular
conectada por medio de lneas dirigidas, a un rombo de
relacin sin nombre. Esto pretende indicar que compra
funciona como:
Un tipo de objeto, algo acerca de lo cual se desea almacenar
informacin. En este caso la hora en la cual se realiz la
compra y el descuento, que se dio al cliente.
Una relacin que conecta los dos tipos de objetos cliente y
artculo. Lo que significa aqu es que cliente y artculo se
mantienen solo. Existiran con o sin la compra.
Indicadores de subtipo/supertipo
Los tipos de objetos de subtipo/supertipo
consisten en tipos de objeto de una o ms
subcategoras, conectados por una relacin.
Indicadores de subtipo/supertipo
La categora general es empleado y las
subcategorias son empleados asalariados y
empleado por horas.
Ntese que los subtipos se conectan al
supertipo por medio de una relacin sin
nombre. Note tambin que el supertipo se
conecta con una lnea que contiene una
barra.
Indicadores de subtipo/supertipo
El primer DER se crear a partir de entrevista
iniciales con el usuario, y de su conocimiento de
la materia en cuanto al negocio del usuario.
Despus de desarrollar el primer DER, el
siguiente paso es asignar los datos del sistema a
los diversos tipos de objetos. Se supone, que se
sabe cuales son los datos.
Reglas para la construccin de
diagramas de Entidad- Relacin.
Esto puede suceder en cualquier de tres
maneras:
1. Si el modelo del proceso (DFD) ya se ha
desarrollado o se est desarrollando
paralelamente al modelo de datos,
entonces el diccionario de datos ya
existir.
Reglas para la construccin de
diagramas de Entidad- Relacin.
2. Si el modelo del proceso no se ha desarrollado o
no tiene intencin de desarrollarse, entonces
pudiera tener que empezar por entrevistar a todos
los usuarios apropiados para construir una lista
exhaustiva de datos y sus definiciones.
3. Si est trabajando con un grupo de administracin
de datos, hay una buena probabilidad de que ya
exista un diccionario de datos, que podra obtener
durante el proyecto.
Reglas para la construccin de
diagramas de Entidad- Relacin.
Existe un nmero de situaciones en las que los
refinamientos del DER llevan a la eliminacin de tipos
de objetos y relaciones redundantes o errneas. Las
ms comunes son:
1. Tipos de objetos que consisten en un identificador.
2. Tipos de objetos para los cuales existe una sola instancia.
3. Tipos asociativos de objetos flotantes.
4. Relaciones derivadas.
Diagramas de transicin de estados.
El diagrama de transicin de estado (tambin
conocido como DTE) enfatiza el comportamiento
dependiente del tiempo del sistema.
Este tipo de modelo slo importaba para una
categora de sistemas conocido como sistemas de
tiempo-real; como ejemplo de estos sistemas se
tienen el control de procesos, sistemas de
conmutacin telefnica, sistemas de captura de
datos de alta velocidad y sistemas de control y
mando militares.
Diagramas de transicin de estados.
Diagrama de transicin de estados
Diagramas de transicin de estados.
Este diagrama muestra el comportamiento
de un contestador de telfono normal.
Los principales componentes del diagrama
son estados, y flechas que representan los
cambios de estado.
Diagramas de transicin de estados.
Cada rectngulo representa un estado en el que se
puede encontrar el sistema:
Esperar a que el usuario d su contrasea.
Calentar una mezcla de sustancias qumicas.
Esperar la siguiente orden.
Acelerar el motor.
Mezclar los ingredientes.
Esperar datos del instrumento.
Llenar el tanque.
Aguardar en reposo.
Cambios de estado
Cmo cambia un sistema de un estado a otro?.
S se tienen reglas ordenadas que gobiernan su
comportamiento, entonces generalmente slo
algunos tipos de cambio de estado sern
significativo y vlidos.
Se muestran los cambios de estado vlidos en el
DTE conectando pares relevantes de estado con
una flecha. que el sistema puede ir del estado 1 al
estado 2. Tambin muestra que cuando el sistema
se encuentra en el estado 2 puede ir al estado 3 o
regresar al 1.
Cambios de estado
El sistema puede ir
del estado 1
al estado 2.
Tambin muestra
que cuando el
sistema se encuentra
en el estado 2 puede
ir al estado 3 o
regresar al 1.
Cambios de estado
A pesar de que la figura proporciona
informacin interesante acerca del
comportamiento dependiente del tiempo de
un sistema, no dice cuales son los estados
inicial y final del sistema.
La mayora de los sistemas tienen un estado
inicial reconocible y estado final reconocible;
Cambios de estado
Estados inicial y final.
Cambios de estado
Lo que identifica al estado 1 como inicial es la flecha
"desnuda" que no est conectada a ningn otro
estado, y lo que identifica al estado 5 como final es
la ausencia de una flecha que salga de l.
El sentido comn dice que un sistema slo puede
tener un estado inicial; sin embargo, puede tener
mltiples estados finales. Los estados finales son
mutuamente excluyentes, lo cual significa que slo
uno de ellos puede ocurrir durante alguna ejecucin
del sistema.
Condiciones y acciones.
Para completar nuestro DTE necesitamos
aadir dos cosa ms: las condiciones que
causan un cambio de estado y las acciones
que el sistema toma cuando cambia de
estado.
Condiciones y acciones.
Muestra de condiciones y acciones
las condiciones y acciones
se muestran junto a la flecha
que conecta dos estados
relacionados.
Condiciones y acciones.
Una condicin es un acontecimiento en el
ambiente externo que el sistema es capaz
de detectar; tpicamente es una seal, una
interrupcin o la llegada de un paquete de
datos.
Esto usualmente hace que el sistema
cambie de un estado de espera X a un
estado de espera Y; o de llevar a cabo la
actividad X a llevar acabo la actividad Y.
Condiciones y acciones.
Como parte del cambio de estado,
normalmente har una o ms acciones:
producir una salida, desplegar una seal
en la terminal del usuario, llevar a cabo un
clculo, etc.
Construccin del diagrama de
transicin de estados.
As como en los DFD se utiliz la particin
tambin es recomendable usarla en los DTE
en donde los sistemas son muy complejos.
Construccin del diagrama de
transicin de estados.
Para la construccin de DTE se puede seguir cualquiera de
dos enfoques:
1. Se puede comenzar por identificar todos los posibles
estados del sistema y representar cada uno como una caja
separada en una hoja de papel. Luego, se pueden explorar
todas las conexiones con significado (es decir, los cambios de
estado) entre las cajas.
2. Como alternativa, se puede comenzar por el estado inicial, y
luego metdicamente ir siguiendo un camino hasta el o los
estados restantes; luego de los estados secundarios, proseguir
a los terciarios; etc.
Construccin del diagrama de
transicin de estados.
Cuando se termina de construir el DTE
preliminar, deben seguirse las siguientes
reglas para verificar la consistencia:
Se han definido todos los estados?.
Se pueden alcanzar todos los estados?.
Se han definido estados que no tengan caminos
que lleven a ellos?
Se puede salir de todos los estados?
Construccin del diagrama de
transicin de estados.
El sistema responde adecuadamente a todas las condiciones
posibles?
El DTE representa una especificacin de proceso para una
burbuja de control en DFD.
Como herramienta de modelado de alto nivel, el DTE puede
servir incluso como especificacin de proceso para todo el
sistema. Si se representa todo el sistema como un diagrama de
una burbuja, puede usarse el DTE para mostrar la secuencia
de actividades en el sistema.
Preguntas?