INGENIERA DEL SOFTWARE I 3 Informtica Gestin

ANLISIS DE SISTEMAS
Especificacin de Requisitos Software.
Modelado de Funciones.
El Diagrama de Flujo de Datos (DFD). Objetivos.
Componentes.
Guas de construccin.
Niveles.
Ms Guas de Construccin: Diagrama de Contexto.
Modelado de Datos.
Tcnicas de Especificacin de Control.
Ejemplo de construccin.
Validacin

1. Especificacin de Requisitos Software.

La ERS se puede definir como la documentacin de los requisitos esenciales (funciones, rendimiento, diseo,
restricciones y atributos) del software y sus interfaces externas. Es un elemento clave dentro de la documentacin necesaria
para el desarrollo del software. De alguna manera, la ERS juega un papel similar al que representan en arquitectura los planos
que definen el aspecto de una casa, ya que debe abordar la descripcin de lo que hay que desarrollar, no el cmo, el cundo, ...,
se desarrolla el software.
En definitiva, se trata de especificar lo que desea el usuario sin considerar cmo se va a solucionar, aunque la ERS s
puede limitar la variedad de soluciones de diseo aceptables.

Existen tres modos de ver (perspectivas) un sistema y es recomendable, para su conocimiento, examinarle bajo estas
tres visiones, utilizando diferentes tcnicas:
Funcin: qu hace el sistema. El diagrama de flujo de datos (DFD) se utiliza para mostrar las funciones del
sistema y sus interfaces.
Informacin: qu informacin utiliza el sistema. El modelo entidad-relacin (ER) se utiliza para sealar las
entidades y las relaciones entre ellas.
Tiempo: cundo sucede algo en el sistema. La lista de eventos se utiliza para mostrar cualquier cosa que ocurra y
sobre la que el sistema debe responder.
Adems de estudiar cada dimensin, es interesante ver las relaciones que existen entre ellas para hacer
comprobaciones sobre su consistencia.

Anlisis de Sistemas Pg.1

INGENIERA DEL SOFTWARE I 3 Informtica Gestin

2. Modelado de Funciones.
2.1. El Diagrama de Flujo de Datos.
El objetivo es construir un modelo del sistema que facilite la comprensin del mismo, tanto por parte de los usuarios
como del equipo de desarrollo.
Un DFD es un diagrama en forma de red que representa el flujo de datos y las transformaciones que se aplican sobre
ellos al moverse desde la entrada hasta la salida del sistema. Se utiliza para modelar las funciones del sistema y los datos que
fluyen entre ellas a distintos niveles de abstraccin. El sistema se modelar mediante un conjunto de DFD nivelados en el que
los niveles superiores definen las funciones del sistema de forma general y los niveles inferiores definen estas funciones en
niveles ms detallados.

Se divide el sistema en distintos niveles de detalle para:

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 tcnica son, esencialmente:
Representar grficamente los lmites del sistema en estudio.
Mostrar el movimiento de los datos y la transformacin de los mismos a travs del sistema.
Diferenciar las restricciones lgicas de las fsicas.
Para conseguir estos objetivos el resultado perseguido debe ser:
Grfico.
Lgico, nunca referido a entornos fsicos.
Preciso y breve.
Comprensible.
Debidamente particionado.
Bien documentado.
Nunca redundante.
No ambiguo.
Establecer qu funciones se deben desarrollar, no cmo.
Como resultado se obtendr un modelo del sistema independiente de las restricciones fsicas del entorno, lo que
facilitar su mantenimiento y portabilidad.

Anlisis de Sistemas Pg.2

INGENIERA DEL SOFTWARE I 3 Informtica Gestin

2.2. Componentes.
Los componentes de un DFD son:
a) Entidad Externa
Es una persona o grupo.
Est fuera del sistema (o del dominio del cambio).
Es fuente o receptor de los flujos de informacin.
Se representa mediante un cuadrado.
b) Proceso
Qu hace, de qu manera transforma los flujos de entrada de informacin en flujos de salida de informacin.
Se representa mediante un crculo o burbuja. En su interior, se incluyen un nmero y un nombre.
Debe cumplirse la regla de conservacin de datos.
c) Almacn de Datos
Representa informacin en reposo.
No implica mquina o dispositivo de almacenamiento alguno.
Los almacenes deben ser necesarios en s mismos (procesos asncronos que se comunican) o
Pueden aparecer por otras razones (seguridad, tecnologa, ..etc).
Se representan mediante dos rectas paralelas o un rectngulo semi-abierto.
d) Flujo
Representa informacin en movimiento.
Tiene un nombre correspondiente a un dato o conjunto de datos del diccionario.
El movimiento de informacin tiene una direccin.
Se representan mediante una flecha.
El movimiento pueden ser bidireccional, si existe un dilogo.
La conexin directa entre dos procesos mediante un flujo slo es posible cuando la informacin sea sncrona;
sino, debe existir un almacn temporal que guarde los datos del proceso origen.
Relacin con almacenes:
Se suele omitir el de lectura, cuando slo leemos para actualizar.
En lectura, puede ser un conjunto de datos, varios conjuntos de datos (cliente xx, clientes de Madrid) o parte
del conjunto (un telfono o varios saldos que se suman).
En actualizacin, uno o ms conjuntos que se borran, aaden o modifican total o parcialmente.
En cualquier caso, slo pueden entrar y salir datos que estn en ese almacn.

Anlisis de Sistemas Pg.3

INGENIERA DEL SOFTWARE I 3 Informtica Gestin

2.3. Guas de construccin.

1. Elegir nombres significativos:
Como hay que presentarlo al usuario debe estar claro lo que representa.
Proceso: El nombre debe describir lo que hace el proceso a nivel conceptual: qu funcin realiza este proceso?
Lo mejor, verbo + nombre: recibir pedidos, validar pedidos, asignar alumnos, ...
Evitar los verbos hacer, procesar, ..., que no significan nada en concreto.
Evitar nombres especficos, el significado debera entenderlo cualquier persona incluso de fuera (Qu
significa Sellar y separar 103b y 104b?).
Evitar palabras como rutina, funcin, procedimiento (son nombres para informticos y que indican una
posible forma de implementacin).
Flujo: El nombre debe ser una palabra que represente un dato elemental del diccionario o estar definida como un
conjunto de datos (un agregado) en l.
No deben repetirse.
Se admiten expresiones como NUM_FACT + IMP_FACT .
Almacn: El nombre debe ser lo ms especfico que sea posible (CUENTAS PENDIENTES, CLIENTES).
RESUMEN: NOMBRES AUTOEXPLICATIVOS
2. Numerar procesos
de manera consistente, aunque no representan orden
sirven para la descomposicin jerrquica posterior.
3. Evitar DFD complejos
un folio con, a lo ms, una docena de elementos (ms flujos)
si es ms complejo, dividir el DFD en varios folios
4. Redibujar el DFD en cuanto sea necesario (ayudado por herramientas CASE)
por esttica y claridad
para que sea aceptable por el usuario
tcnicamente correcto
5. Asegurar la consistencia interna y con sus DFD asociados
No puede haber fuentes y sumideros de informacin:
- procesos con entradas y sin salidas (sumideros infinitos)
- procesos con salidas y sin entradas (generacin espontnea)
Ojo con procesos y flujos sin nombre
- generalmente pueden ser debidos a que no se sabe bien lo qu hace un proceso o en qu consiste un
flujo o que se trate de datos sin relacin entre s.
El DFD no debe representar el organigrama de la empresa.
Cuidado con las lecturas y escrituras nicas en almacenes
- excepcin admisible: almacenes externos.
Lgicamente, se mantiene la lectura / actualizacin de todo el conjunto de DFD.
6. Lo que no debe haber en los DFD.
No se incluyen los controles de errores triviales
No hay bucles o construcciones if-else:

obtener entrada
suma...
siguiente sumar
entrada pet. otra entr. entradas

Anlisis de Sistemas Pg.4

INGENIERA DEL SOFTWARE I 3 Informtica Gestin

x comparar x>y
y x, y
x<=y

No hay eventos temporales:

fin de
mes
facturar

facturas
pedidos

2.4. Niveles.
Como el modelo de un sistema grande no se puede representar en una sola pgina mediante un DFD, la idea es
representarlo por capas (y cada capa queda definida mediante un DFD). Se sigue as una aproximacin descendente (top-
down) en la que cada nivel proporciona una visin ms detallada de una parte definida en el nivel anterior.
Se comienza por el nivel ms alto de la jerarqua mediante un DFD denominado diagrama de contexto. En este
diagrama slo hay un proceso que representa el sistema completo. A continuacin, este proceso se descompone en otro DFD
(que a veces se denomina diagrama del sistema) en el que se representan las funciones principales o subsistemas. A
continuacin, se descomponen cada uno de los procesos en nuevos diagramas que representan funciones ms simples. Se
procede de la misma manera hasta que todas las funciones estn lo suficientemente detalladas como para que no sea necesaria
la creacin de nuevos DFD.
Por tanto, un conjunto de DFD queda definido por:
Diagrama de contexto, nico y en la parte superior.
Niveles medios, formado por el resto de diagramas.
Funciones primitivas, que estn presentes tanto en los niveles intermedios como en los ltimos niveles de la
jerarqua y que se corresponden con procesos que no se explotan en nuevos DFD.

Algunas cuestiones importantes:

Cuntos niveles debe tener un DFD?
El criterio es que la especificacin del proceso se exprese en un folio.
Si un proceso del ltimo nivel no se puede expresar en una hoja, habr que dividir ms.
En METRICA se exigen, al menos, cinco niveles (contexto, (subsistemas), funciones, (subfunciones), procesos).
La jerarqua de procesos y subprocesos que se organiza a travs de los niveles debe estar mnimamente balanceada,
aunque no todas las partes tienen porqu desarrollarse hasta el mismo nivel. Ahora bien, si est muy
desproporcionado, quizs haya algn error en el anlisis.
Consistencia entre niveles
Los flujos entrantes y salientes de un proceso deben corresponder a los flujos de E/S globales del diagrama inferior
que lo describe.
Convenciones a la numeracin
Cada diagrama recibe el nmero y el nombre del proceso que descompone (el proceso padre).
Los procesos del diagrama del sistema se enumeran por un entero comenzando por 1 y de forma creciente hasta
completar el nmero de procesos del diagrama.

Anlisis de Sistemas Pg.5

INGENIERA DEL SOFTWARE I 3 Informtica Gestin

En los restantes niveles, los nmeros de los procesos estn formados por la concatenacin del nmero de diagrama en
el que estn ms un punto y un nmero entero nico para identificarlo dentro del diagrama.
Cundo aparecen los Almacenes de Datos?
Hay que mostrar un almacn en el nivel ms alto en el que sirve como enlace entre dos procesos o ms. Despus,
habr que mostrarlo otra vez en cada diagrama del siguiente nivel que describe esos procesos.
Top-down
No es necesario trabajar estrictamente top-down como se ver en la construccin del modelo esencial o modelo
conceptual del sistema.
Cmo se muestra al usuario?
Por partes: los directivos trabajan con el DFD de nivel 1 y el operador con el nivel de proceso ms detallado.
En cualquier caso, para mostrar todo el DFD habr que trabajar, cada vez, slo con dos niveles: el actual y el padre.

Tcnicas de Descripcin de Procesos del Ultimo Nivel

Debern definirse con ms detalle slo las funciones o procesos primitivos, es decir, aquellos que no se van a
descomponer ms.
Cada especificacin de proceso (tambin denominada miniespecificacin) debe
Describir cmo se logra transformar el flujo de datos que llega en los flujos que salen.
Describir las normas que gobiernan la transformacin, no el mtodo de implantar esas normas.
Se pueden llegar a incluir, en la descripcin de los procesos de ltimo nivel, las siguientes consideraciones:
Modo de acceso de los procesos a los datos del sistema.
Tipo de tratamiento (interactivo o por lotes).
Informacin sobre la frecuencia de ejecucin.
Caractersticas del proceso:
Actualizacin de datos del sistema.
Consultas e informes.
Realizacin de algoritmos especficos y descripcin de los mismos.
A la hora de describir los procesos de ltimo nivel de un DFD, se pueden utilizar las siguientes tcnicas:
Narrativa tradicional
Tablas o rboles de decisin
Lenguaje estructurado
Pre y postcondiciones.
Evitar la narrativa sin ms, buscar algo que sea inequvoco y al mismo tiempo entendible por cualquier usuario. Ejemplo:
Para aplicar el descuento, el cliente debe tener una cifra de compra de ms de 3.000.000 de pesetas / ao y
un buen historial de pagos o haber sido cliente ms de 5 aos.
Tablas o rboles de decisin.
Ya conocidas de los mtodos Warnier y Jackson.
Lenguaje estructurado:
Utilizar verbos precisos sin ambigedad, del tipo
ORDENAR, SUMAR, ENCONTRAR, VALIDAR, REEMPLAZAR, BORRAR, CALCULAR,
MOSTRAR, ESCRIBIR, etc.

Evitar verbos como

HACER, TRATAR, PROCESAR, CONTROLAR, ...

Realizar construcciones tpicas si/ si no o para cada..., del lenguaje estructurado:

si el cliente reside en Madrid y > 65 aos
sumar un 10% a la pliza
si no
sumar un 5%;

Anlisis de Sistemas Pg.6

INGENIERA DEL SOFTWARE I 3 Informtica Gestin

para todos los clientes

enviar una felicitacin de Navidad;
Pre y Postcondiciones:
Describen la situacin antes y despus de aplicar un algoritmo. Se puede interpretar como un contrato
(condiciones previas y posteriores que han de cumplirse).
pre: existe un nmero x > 0
post: se obtiene un resultado, factor = x*x
La precondicin puede referirse a la existencia o disponibilidad de un flujo o de la relacin entre varios flujos
(condicin de sincronizacin) o de flujos con almacenes.
pre1: cliente facilita un n c.c. que est registrada y tiene un estado abierta
post1: la cuenta se decrementa con el importe de la factura correspondiente
pre2: no se cumple pre 1
post2: se rechaza el pago a cuenta

2.5. Ms Guas de Construccin: Diagrama de Contexto.

La construccin del Diagrama de Contexto es ms difcil de lo que parece pues debe incluir todas las
interacciones del sistema.

Los flujos en el Diagrama de contexto aparecen si son necesarios:

porque representan un evento (e)
para producir una respuesta (e)
para representar una respuesta (s)

Necesitamos tambin tener claro el objetivo global del sistema y la lista de eventos externos a los que el sistema
debe responder:
En la lista de eventos, se distinguen:
los orientados a flujo (los que suponen un documento de entrada al sistema, del tipo que sea)
los que son de tipo temporal QUE NO APARECERN REPRESENTADOS EN LOS DFD.
Los eventos se describen desde el punto de vista externo: el cliente hace un pedido.
La lista de eventos y el DFD deben cuadrar:
Cada flujo de entrada es necesario para reconocer un evento o para producir una respuesta.
Cada flujo de salida debe ser respuesta a un evento.
Cada evento no temporal debe tener un flujo asociado.
Cada evento temporal, al menos una salida.

Proceso de construccin prctica:

La idea fundamental es que cada evento requiere un proceso que le d respuesta y sobre esa base reorganizar despus los DFD
de diversos niveles.
1. Cada evento origina un proceso (evento 3 proceso 3).
evento = respuesta del sistema
cliente paga factura actualizar facturas pendientes
2. Se aaden los flujos de entrada y salida necesarios y los almacenes que sirven de comunicacin entre los procesos (si
la comunicacin es asncrona).
Hay que preguntarse qu necesita el sistema para funcionar (e) y cul es la respuesta del sistema hacia el exterior (s).
Esto lo habremos obtenido de las entrevistas (lista de eventos).
Existen casos especiales: un mismo evento da origen a varias respuestas o varios eventos originan la misma
respuesta.
En este diagrama, que llamaremos inicial, cada proceso no se comunica con otros directamente, sino a travs de
almacenes. Es un proceso asncrono por definicin.
(Como:
la respuesta a un evento puede requerir datos producidos por otro proceso
no podemos saber cundo ocurren los eventos
tenemos que asegurar que el proceso en el modelo esencial tarda 0 segundos
cada flujo es de velocidad infinita
se deduce que la sincronizacin de eventos tiene que ser a travs de almacenes.)
3. Se chequea contra el DFD de contexto para comprobar la consistencia.
Anlisis de Sistemas Pg.7
INGENIERA DEL SOFTWARE I 3 Informtica Gestin

4. Se refina el modelo. El criterio es la simplificacin y la obtencin de varios niveles.

Reagrupacin:
cada grupo debe agrupar respuestas relacionadas y datos relacionados estrechamente.
esconder los almacenes de datos en lo posible (dos o tres procesos que usan un almacn se transforman en un
proceso nico que esconde el almacn dentro).
Dividir si:
el proceso hace varias cosas complejas. Construir un proceso por cada funcin.
si hay demasiados flujos de entrada o salida
5. Por ltimo, se describe cada proceso no explosionado.

Ejemplo
Un sistema de ventas de libros con
1. Clientes que piden libros.
2. Todos los das se hace un pedido a editoriales.
3. Todos los das se preparan los pedidos pendientes y se factura.
4. Los libros llegan de las editoriales.
5. Una vez cada15 das se controlan los pagos y se hacen reclamaciones.

Anlisis de Sistemas Pg.8