Un diagrama de estado es una representación gráfica que muestra los diferentes estados por los que puede pasar un objeto o sistema a lo largo de su ciclo de vida, así como los eventos que causan los cambios de estado y las acciones que se realizan en cada estado. Permite visualizar de forma secuencial la ejecución de procesos y describir el comportamiento de un sistema.

1. Un diagrama de estado es un diagrama utilizado para identificar cada una de las rutas
o caminos que puede tomar un flujo de información luego de ejecutarse cada proceso.
Permite identificar bajo qué argumentos se ejecuta cada uno de los procesos y en qué
momento podrían tener una variación.
El diagrama de estados permite visualizar de una forma secuencial la ejecución de cada
uno de los procesos. Los diagramas de estado describen gráficamente los eventos y los
estados de los objetos. Los diagramas de estado son útiles, entre otras cosas, para
indicar los eventos del sistema en los casos de uso.
Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un
estado es la condición de un objeto en un momento determinado: el tiempo que
transcurre entre eventos. Una transición es una relación entre dos estados, e indica que,
cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.
Los diagramas de estados son una técnica conocida para describir el comportamiento de un
sistema. Describen todos los estados posibles en los que puede entrar un objeto particular y la
manera en que cambia el estado del objeto, como resultado de los eventos que llegan a él. En
la mayor parte de las técnicas OO, los diagramas de estados se dibujan para una sola clase,
mostrando el comportamiento de un solo objeto durante todo su ciclo de vida.
Comenzamos en el punto de partida y mostramos una transición inicial al estado de
Comprobación. Esta transición está etiquetada como "/obtener el primer artículo". La
sintaxis de una etiqueta de transición tiene tres partes, las cuales son optativas: Evento
{Guard Guardia} / Acción. En este caso, sólo tenemos la acción "obtiene primer
artículo." Una vez realizada tal acción, entramos al estado de Comprobación. Este
estado tiene una actividad asociada con él, la cual se indica mediante una etiqueta con la
sintaxis hace/actividad. En este caso, la actividad se llama" comprueba artículo".

2. DIAGRAMAS DE FLUJO DE DATOS
OBJETIVOS
Construir un modelo lógico del sistema que facilite la comprensión del mismo, tanto por parte de los
usuarios como del equipo de desarrollo.
Para ello se dividirá el sistema en distintos niveles de detalle. Esta división permitirá:
Simplificar la complejidad del sistema, representando los diferentes procesos sencillos de que
consta un sistema complejo.
Repartir el trabajo entre los diferentes miembros del equipo de desarrollo. Facilitar el
mantenimiento del sistema.
Los fundamentos de la técnica del Diagrama de Flujo de Datos (DFD) son los siguientes:
Representar gráficamente los límites del sistema en estudio.
Mostrar el movimiento de los datos y la transformación de los mismos a través del sistema.
Diferenciar las restricciones físicas de las lógicas.
Para conseguir estos objetivos el resultado del análisis debe ser:
GRÁFICO.
LÓGICO, nunca referido a entornos físicos.
PRECISO Y BREVE.
COMPRENSIBLE.
DEBIDAMENTE PARTICIONADO.
BIEN DOCUMENTADO.
NUNCA REDUNDANTE.
ESTABLECERÁ "QUÉ" FUNCIONES SE DEBEN DESARROLLAR, SIN IMPLICAR "CÓMO".
NO AMBIGUO.
Como resultado se obtendrá un modelo del sistema completamente independiente de las restricciones
físicas del entorno, lo que facilitará su mantenimiento y portabilidad.
En los Diagramas de Flujo de Datos, no se deberán modelizar:
PROCEDIMIENTOS.
PUNTO DE INICIO Y DE TERMINACIÓN DEL DFD.
CONDICIONES.
TRATAMIENTOS DE ERRORES POCO RELEVANTES.
ELEMENTOS BÁSICOS DE LOS DIAGRAMAS DE FLUJO DE DATOS
En cualquier Diagrama de Flujos de Datos, aparecerán los objetos siguientes:
ENTIDAD EXTERNA.
PROCESO.
ALMACÉN DE DATOS.
FLUJO DE DATOS.
Algunos de ellos podrán tener alguna restricción con respecto únicamente al nivel en el cual pueden o
deben aparecer. Esto ya se detallará más adelante.
La técnica de representación dará lugar a un DFD (Diagrama de Flujo de Datos) en el que se irán
detallando los principales procesos o acciones a desarrollar y que se irán detallando en mayor medida
según se vaya bajando de nivel (EXPLOSIONANDO) cada uno de esos procesos.
La comunicación existente entre esas actividades se representa entre el resto de los elementos.

3. DIAGRAMA DE FLUJO DE DATOS
El DIAGRAMA DE FLUJO DE DATOS (DFD) proporciona una representación del sistema a nivel lógico y
conceptual. Utiliza una notación y unas reglas predeterminadas.
ENTIDAD EXTERNA
Las Entidades Externas representan entes ajenos a nuestra aplicación, pero que aportan o reciben
información de la misma. Se representa mediante una elipse o un rectángulo con un nombre significativo
dentro.
Reglas de construcción:
1. Representa personas, organizaciones o sistemas que no pertenecen al sistema.
2. En el caso de que las entidades externas se comunicasen entre sí, esto no se contemplaría en el
diagrama, por estar fuera del ámbito de nuestro sistema.
3. Puede aparecer en los distintos niveles de DFD.
4. Puede aparecer varias veces en un mismo diagrama, para evitar entrecruzamientos de líneas.
5. Suministra información acerca de la conexión del sistema con el mundo exterior.
PROCESO
Es una actividad que transforma o manipula datos. Se representa mediante un rectángulo, de la
siguiente manera:
En la parte de PROCESO se expresa el nombre del proceso correspondiente. Dependiendo del nivel de
detalle en que nos encontremos dentro de un DFD, el nombre del proceso simbolizará bien el sistema
concreto (nivel sistema), bien el subsistema de que se trate (nivel subsistema), o bien acciones
concretas y detalladas en niveles inferiores.
En la parte superior izquierda se coloca un número identificativo del proceso. Este número permitirá
además indicar el nivel del DFD en que nos encontramos; esto se explicará más en detalle cuando se
hable de la descomposición por niveles.
Es importante hacer énfasis en que este número no indica secuencia de realización del proceso, dado
que los DFD no representan una secuencialidad en el tratamiento de los datos.
La parte de localización expresa la Unidad o área dentro de la organización donde se realiza este
proceso.
Reglas de construcción:
1. Cuando un Flujo de datos entra en un proceso sufre una transformación. Un proceso no es ni origen ni
final de los datos, sólo lugar de transformación de los mismos. Por ello, cualquier flujo de datos que
entre en un proceso ha de transformarse (ver Figura DFD3).
2. Un proceso puede transformar un dato en varios.
3. Es necesario un proceso como intermediario entre una Entidad Externa y un Almacén de Datos.
ALMACÉN DE DATOS
Un almacén de datos representa un depósito de información dentro del sistema.
Se representa dentro del DFD con la siguiente Figura:
En la parte derecha se indica el nombre del almacén de datos. En la parte izquierda se representa la
identificación de dicho almacén dentro del DFD.
En el caso de que dentro de un DFD aparezca repetido el mismo almacén de datos, se puede representar
de la siguiente forma:
Es conveniente distinguir las diferentes utilidades que presentan los almacenes de datos. En primer
lugar, el almacenamiento permanente de datos, donde se guardan los datos que sirven de referencia de
uso del sistema, es decir, los datos permanentes, sobre los que el sistema necesita guardar información
(ALMACENES PRINCIPALES).

4. Por otra parte, el almacenamiento transitorio de los datos antes de ser usados por un proceso. Para
entender el significado de estos almacenes transitorios, se puede imaginar la situación del ejemplo de la
Figura DFD5.
En este ejemplo el proceso RECOGER SOLICITUDES, que se ejecuta continuamente a lo largo de la
jornada, genera los datos de salida representados por el flujo de datos SOLICITUDES. Estos datos
constituyen los datos de entrada al proceso VALIDAR SOLICITUD, que se ejecuta al final de la jornada,
en el intervalo esos datos de solicitud "reposarían" en el almacén SOLIC-PROV, cuya utilidad básica es
establecer una sincronización en el funcionamiento de ambos procesos.
Los almacenes transitorios suelen representar restricciones físicas del sistema y por tanto en un DFD,
que expresa la lógica de los tratamientos realizados por el sistema, en muchos casos no será necesario
representarlos. Sin embargo hay ocasiones en que estos almacenes simbolizan "ficheros de
movimientos", donde se guardan los datos porque el proceso siguiente necesita manejarlos todos al
mismo tiempo (por ejemplo, en un proceso que compara un conjunto de registros, será necesario
mantenerlos guardados en un almacén transitorio, para que dicho proceso los lea todos al mismo
tiempo). En este caso sí será conveniente representarlos.
Por último, para asegurar la consistencia entre todas las técnicas utilizadas en la Fase de Análisis, se
establecerá una relación precisa entre los almacenes de datos "principales" de un DFD y las entidades de
los Diagramas de Estructura de Datos (DED): cada almacén principal de un DFD representa un conjunto
completo de entidades del DED (una o varias entidades), y cada entidad de un DED pertenece a un único
almacén principal de un DFD; esto facilitará las validaciones cruzadas entre los dos diagramas.
Reglas de construcción:
1. Representa la información en reposo.
2. No puede crear, destruir ni transformar datos.
3. No puede estar comunicado directamente con otro Almacén o Entidad Externa.
4. El flujo de datos (Entrada o Salida) no lleva nombre cuando incide sobre su contenido completo.
5. El almacén de datos aparecerá por vez primera en aquel nivel en que sea accedido por dos o más
procesos y en modo lectura y/o escritura.
6. No debe estar referido al entorno físico y por tanto, no se diferencian los ficheros convencionales de
las Bases de Datos.
7. No se representa la clave de acceso a ese almacén sino sólo la operación que se realiza (lectura,
escritura, actualización)
FLUJO DE DATOS
Los Flujos de Datos establecen la comunicación entre procesos, almacenes y entidades externas, y
llevan información necesaria para esos objetos.
Reglas de construcción:
1. El concepto de flujo de datos es similar al de una "tubería" a través de la cual fluye una información
de estructura conocida.
2. Los datos no pueden ser creados ni destruidos por un flujo de datos.
3. Sirve para conectar el resto de los componentes del DFD.
4. No es un activador de procesos.
5. Cuando un proceso almacena datos, la flecha de flujo de datos se indica en la dirección del almacén
de datos y a la inversa si es el proceso el que lee datos en el almacén.