Tema4 a

INGENIERÍA DEL SOFTWARE I 3º Informática Gestión
ANÁLISIS DE SISTEMAS
Especificación de Requisitos Software.
Modelado de Funciones.
El Diagrama de Flujo de Datos (DFD). Objetivos.
Componentes.
Guías de construcción.
Niveles.
Más Guías de Construcción: Diagrama de Contexto.
Modelado de Datos.
Técnicas de Especificación de Control.
Ejemplo de construcción.
Validación
1. Especificación de Requisitos Software.
La ERS se puede definir como la documentación de los requisitos esenciales (funciones, rendimiento, diseño,
restricciones y atributos) del software y sus interfaces externas. Es un elemento clave dentro de la documentación 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 descripción de lo que hay que desarrollar, no el cómo, el cuándo, ...,
se desarrolla el software.
En definitiva, se trata de especificar lo que desea el usuario sin considerar cómo se va a solucionar, aunque la ERS sí
puede limitar la variedad de soluciones de diseño aceptables.
Existen tres modos de ver (perspectivas) un sistema y es recomendable, para su conocimiento, examinarle bajo estas
tres visiones, utilizando diferentes técnicas:
• Función: qué hace el sistema. El diagrama de flujo de datos (DFD) se utiliza para mostrar las funciones del
sistema y sus interfaces.
• Información: qué información utiliza el sistema. El modelo entidad-relación (ER) se utiliza para señalar las
entidades y las relaciones entre ellas.
• Tiempo: cuándo 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.
Además de estudiar cada dimensión, es interesante ver las relaciones que existen entre ellas para hacer
comprobaciones sobre su consistencia.
Análisis de Sistemas Pág.1

2. Modelado de Funciones.
2.1. El Diagrama de Flujo de Datos.
El objetivo es construir un modelo del sistema que facilite la comprensión 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 abstracción. 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 más 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 técnica son, esencialmente:
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 lógicas de las físicas.
Para conseguir estos objetivos el resultado perseguido debe ser:
Gráfico.
Lógico, nunca referido a entornos físicos.
Preciso y breve.
Comprensible.
Debidamente particionado.
Bien documentado.
Nunca redundante.
No ambiguo.
Establecerá “qué” funciones se deben desarrollar, no “cómo”.
Como resultado se obtendrá un modelo del sistema independiente de las restricciones físicas del entorno, lo que
facilitará su mantenimiento y portabilidad.

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 información.
• Se representa mediante un cuadrado.
b) Proceso
• Qué hace, de qué manera transforma los flujos de entrada de información en flujos de salida de información.
• Se representa mediante un círculo o burbuja. En su interior, se incluyen un número y un nombre.
• Debe cumplirse la regla de conservación de datos.
c) Almacén de Datos
• Representa información en reposo.
• No implica máquina o dispositivo de almacenamiento alguno.
• Los almacenes deben ser necesarios en sí mismos (procesos asíncronos que se comunican) o
• Pueden aparecer por otras razones (seguridad, tecnología, ..etc).
• Se representan mediante dos rectas paralelas o un rectángulo semi-abierto.
d) Flujo
• Representa información en movimiento.
• Tiene un nombre correspondiente a un dato o conjunto de datos del diccionario.
• El movimiento de información tiene una dirección.
• Se representan mediante una flecha.
• El movimiento pueden ser bidireccional, si existe un diálogo.
• La conexión directa entre dos procesos mediante un flujo sólo es posible cuando la información sea síncrona;
sino, debe existir un almacén temporal que guarde los datos del proceso origen.
• Relación con almacenes:
• Se suele omitir el de lectura, cuando sólo 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 teléfono o varios saldos que se suman).
• En actualización, uno o más conjuntos que se borran, añaden o modifican total o parcialmente.
• En cualquier caso, sólo pueden entrar y salir datos que estén en ese almacén.

2.3. Guías de construcción.
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é función 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 específicos, el significado debería entenderlo cualquier persona incluso de fuera (¿Qué
significa ”Sellar y separar 103b y 104b”?).
• Evitar palabras como rutina, función, procedimiento (son nombres para informáticos y que indican una
posible forma de implementación).
• 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 .
• Almacén: El nombre debe ser lo más específico que sea posible (CUENTAS PENDIENTES, CLIENTES).
• RESUMEN: NOMBRES AUTOEXPLICATIVOS
2. Numerar procesos
• de manera consistente, aunque no representan orden
• sirven para la descomposición jerárquica posterior.
3. Evitar DFD complejos
• un folio con, a lo más, una docena de elementos (más flujos)
• si es más complejo, dividir el DFD en varios folios
4. Redibujar el DFD en cuanto sea necesario (ayudado por herramientas CASE)
• por estética y claridad
• para que sea aceptable por el usuario
• técnicamente correcto
5. Asegurar la consistencia interna y con sus DFD asociados
• No puede haber fuentes y sumideros de información:
- procesos con entradas y sin salidas (sumideros infinitos)
- procesos con salidas y sin entradas (generación espontánea)
• 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 relación entre sí.
• El DFD no debe representar el organigrama de la empresa.
• Cuidado con las lecturas y escrituras únicas en almacenes
- excepción admisible: almacenes externos.
• Lógicamente, se mantiene la lectura / actualización 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:
entrada
pet. otra entr.
obtener
siguiente
entrada
sumar
entradas
suma...

• No hay eventos temporales:
x
x>y
x<=y
y
comparar
x, y
facturas
pedidos
fin de
mes
facturar
2.4. Niveles.
Como el modelo de un sistema grande no se puede representar en una sola página mediante un DFD, la idea es
representarlo “por capas” (y cada capa queda definida mediante un DFD). Se sigue así una aproximación descendente (top-
down) en la que cada nivel proporciona una visión más detallada de una parte definida en el nivel anterior.
Se comienza por el nivel más alto de la jerarquía mediante un DFD denominado diagrama de contexto. En este
diagrama sólo hay un proceso que representa el sistema completo. A continuación, 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
continuación, se descomponen cada uno de los procesos en nuevos diagramas que representan funciones más simples. Se
procede de la misma manera hasta que todas las funciones estén lo suficientemente detalladas como para que no sea necesaria
la creación 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 están presentes tanto en los niveles intermedios como en los últimos niveles de la
jerarquía y que se corresponden con procesos que no se explotan en nuevos DFD.
Algunas cuestiones importantes:
♦ ¿Cuántos niveles debe tener un DFD?
• El criterio es que la “especificación del proceso” se exprese en un folio.
• Si un proceso del último nivel no se puede expresar en una hoja, habrá que dividir más.
• En METRICA se exigen, al menos, cinco niveles (contexto, (subsistemas), funciones, (subfunciones), procesos).
• La jerarquía de procesos y subprocesos que se organiza a través de los niveles debe estar “mínimamente” balanceada,
aunque no todas las partes tienen porqué desarrollarse hasta el mismo nivel. Ahora bien, si está muy
desproporcionado, quizás haya algún error en el análisis.
♦ 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 numeración
• Cada diagrama recibe el número 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 número de procesos del diagrama.

• En los restantes niveles, los números de los procesos están formados por la concatenación del número de diagrama en
el que están más un punto y un número entero único para identificarlo dentro del diagrama.
♦ ¿Cuándo aparecen los Almacenes de Datos?
• Hay que mostrar un almacén en el nivel más alto en el que sirve como enlace entre dos procesos o más. Después,
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 construcción del modelo esencial o modelo
conceptual del sistema.
♦ ¿Cómo se muestra al usuario?
• Por partes: los directivos trabajan con el DFD de nivel 1 y el operador con el nivel de proceso más detallado.
• En cualquier caso, para mostrar todo el DFD habrá que trabajar, cada vez, sólo con dos niveles: el actual y el padre.
Técnicas de Descripción de Procesos del Ultimo Nivel
Deberán definirse con más detalle sólo las funciones o procesos primitivos, es decir, aquellos que no se van a
descomponer más.
Cada especificación de proceso (también denominada miniespecificación) debe
• Describir cómo se logra transformar el flujo de datos que llega en los flujos que salen.
• Describir las normas que gobiernan la transformación, no el método de implantar esas normas.
Se pueden llegar a incluir, en la descripción 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).
• Información sobre la frecuencia de ejecución.
• Características del proceso:
− Actualización de datos del sistema.
− Consultas e informes.
− Realización de algoritmos específicos y descripción de los mismos.
A la hora de describir los procesos de último nivel de un DFD, se pueden utilizar las siguientes técnicas:
− Narrativa tradicional
− Tablas o árboles de decisión
− Lenguaje estructurado
− Pre y postcondiciones.
Evitar la narrativa sin más, buscar algo que sea inequívoco y al mismo tiempo entendible por cualquier usuario. Ejemplo:
“Para aplicar el descuento, el cliente debe tener una cifra de compra de más de 3.000.000 de pesetas / año y
un buen historial de pagos o haber sido cliente más de 5 años”.
Tablas o árboles de decisión.
Ya conocidas de los métodos Warnier y Jackson.
Lenguaje estructurado:
− Utilizar verbos precisos sin ambigüedad, del tipo
ORDENAR, SUMAR, ENCONTRAR, VALIDAR, REEMPLAZAR, BORRAR, CALCULAR,
MOSTRAR, ESCRIBIR, etc.
− Evitar verbos como
HACER, TRATAR, PROCESAR, CONTROLAR, ...
− Realizar construcciones típicas si/ si no o para cada..., del lenguaje estructurado:
si el cliente reside en Madrid y > 65 años
sumar un 10% a la póliza
si no
sumar un 5%;

para todos los clientes
enviar una felicitación de Navidad;
Pre y Postcondiciones:
− Describen la situación antes y después de aplicar un algoritmo. Se puede interpretar como un contrato
(condiciones previas y posteriores que han de cumplirse).
pre: existe un número x > 0
post: se obtiene un resultado, factor = x*x
− La precondición puede referirse a la existencia o disponibilidad de un flujo o de la relación entre varios flujos
(condición de sincronización) 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. Más Guías de Construcción: Diagrama de Contexto.
• La construcción del Diagrama de Contexto es más difícil 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 también 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 APARECERÁN 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 construcción práctica:
La idea fundamental es que cada evento requiere un proceso que le dé respuesta y sobre esa base reorganizar después 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 añaden los flujos de entrada y salida necesarios y los almacenes que sirven de comunicación entre los procesos (si
la comunicación es asíncrona).
• Hay que preguntarse qué necesita el sistema para funcionar (e) y cuál 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 través de
almacenes. Es un proceso asíncrono por definición.
(Como:
• la respuesta a un evento puede requerir datos producidos por otro proceso
• no podemos saber cuándo 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 sincronización de eventos tiene que ser a través de almacenes.)
3. Se chequea contra el DFD de contexto para comprobar la consistencia.

4. Se refina el modelo. El criterio es la simplificación y la obtención de varios niveles.
• Reagrupación:
• 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 almacén se transforman en un
proceso único que esconde el almacén dentro).
• Dividir si:
• el proceso hace varias cosas complejas. Construir un proceso por cada función.
• 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 días se hace un pedido a editoriales.
3. Todos los días se preparan los pedidos pendientes y se factura.
4. Los libros llegan de las editoriales.
5. Una vez cada15 días se controlan los pagos y se hacen reclamaciones.

Tema4 a

Más contenido relacionado

La actualidad más candente

Similar a Tema4 a

Tema4 a