ANÁLISIS DE SISTEMAS. 1. Especificación de Requisitos Software.

Transcripción

1 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. Pág.1

2 2. Modelado de Funciones 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. Pág.2

3 2.2. Componentes. Los componentes de un DFD son: a) Entidad Externa b) Proceso 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. 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 d) Flujo 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. 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. Pág.3

4 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: obtener siguiente entrada entrada pet. otra entr. sumar entradas suma... Pág.4

5 x y comparar x, y x<=y x>y No hay eventos temporales: facturar fin de mes pedidos facturas 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 (topdown) 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. Pág.5

6 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 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%; Pág.6

7 Pre y Postcondiciones: para todos los clientes enviar una felicitación de Navidad; 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. Pág.7

8 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. Pág.8