Análisis y Diseño Estructurado

Presentación del tema: "Análisis y Diseño Estructurado"— Transcripción de la presentación:

1 Análisis y Diseño Estructurado
Diseño de Sistemas de Información Clase : 27 de abril ©Natividad Grandón

2 Análisis y Diseño Estructurado
Tiene como objetivo descubrir todos los detalles relevantes del sistema en estudio. Además pretende: Que sea fácil de detectar y verificar la omisión de detalles relevantes Que distintos analistas ante el mismo sistema actual determinen los mismos requerimientos. Que los documentos generados sobre el sistema actual sean vehículos eficientes de comunicación.

3 Análisis y Diseño Estructurado
Aparece a finales de los 70 Facilita la comunicación en el proceso de desarrollo de un sistema de información análisis y diseño usuarios y analistas Sencillo, fácil de entender y fácil de aprender

4 Características Amplia difusión Descomposición funcional
(Originariamente) Orientada a procesos (Originariamente) Top/down Presente en numerosas metodologías p.ej. Métrica, SSADM, information engineering, Merise Herramientas CASE disponibles Visible Analyst, Easy Case, S-Designor ProcessAnalysis

5 Visión panorámica AE Esquema resumen
Diagrama de flujo de datos PROC B Z Y X W V A FUENTE DESTINO D ALMACÉN DE DATOS Diagrama de estructuras Paso al diseño Definición del FD Descrip. E. E. Descripción del proceso Diagrama E-R (o DED) En esta visión general se presentan los dos modelos más importantes del AE: el modelo funcional y el modelo de datos. Se obvia el modelo de comportamiento, que se realiza a través de diagramas menos extendidos, como los HVE (Historia de Vida de las Entidades) o los STD (Diagramas de Transición de Estados). El hecho de que en la transparencia el tamaño del DFD sea mayor que el del E-R no quiere decir que el primero tenga mayor importancia: los dos diagramas presentan visiones paralelas, de las funciones y de los datos. Diccionario de Datos Definiciones de la BD Definiciones de los módulos

6 Documentos El producto del análisis es el documento de especificaciones. El producto del diseño es un conjunto de configuraciones de diseño llamado diseño empaquetado.

7 Análisis Estructurado
Permite al analista conocer un sistema o proceso (actividad) en una forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente. El objetivo que persigue el análisis estructurado es organizar las tareas asociadas con la determinación de requerimientos para obtener la comprensión completa y exacta de una situación dada.

8 Análisis Estructurado
Elementos del análisis estructurado: Diagramas de flujo de datos Diccionario de datos Ingles estructurado Tablas de decisión Árboles de decisión Redes de Petri Diagramas de transición de estados.

9 DIAGRAMAS DE FLUJO DE DATOS
Un diagrama de flujo de datos (DFD) es una representación grafica de un sistema, retrata un sistema desde el punto de vista de sus proceso, con indicación de todas las interfases existentes entre los procesos. Componentes DFD Procesos: que son los componentes funcionales del sistema, representados por círculos o burbujas. Almacenes: que representan datos almacenados o en reposo, representados por segmentos de rectas Entidades externas: que representan la fuente y/o el destino de la información del sistema, representados por cuadrados o cajas. Flujos de datos: que representan los datos que fluyen entre las funciones, representados por vectores dirigidos.

10 Símbolos del DFD (notación Yourdon/De Marco)
P Proceso Transformaciones o procesos (funciones, cálculo, selección) Terminadores (Fuentes o Destinos) (personas, entidades) Entidad Externa Flujos de información (inputs-outputs) Flujo de datos Flujos de control (Ward & Mellor 85) Flujo de eventos Ficheros o depósitos temporales de información (base de datos, armario, clasificador, etc.) D ALMACÉN DE DATOS

11 NOTACIONES

12 La interpretación del DFD debe leerse como sigue
X llega desde una fuente F y es transformada en Y por el proceso P1, que requiere accesar al archivo A para realizar su trabajo. Posteriormente Y es trasformado en Z por el proceso P2. F X P1 P2 Y Z A

13 El proceso Un proceso es una transformación de flujo de datos de entrada en flujo de datos de salida. Nombres únicos, significativos y concisos Preferiblemente expresados en función de las entradas y salidas Recomendación: verbo (no ambiguo) + objeto Evitar verbos ambiguos procesar, gestionar, manejar... “objeto” está definido en el DD Los procesos se descomponen en “subprocesos”, hasta llegar a los procesos primitivos

14 El almacén (archivo) Un almacén es un “recipiente” temporal de datos. De la definición dad se deduce que puede ser una cinta, un área de disco, un conjunto de tarjetas, un libro de contabilidad o cualquier elemento de almacenamiento de información. Sus nombres deben ser escogidos de manera de facilitar su lectura y comprensión. Nombre tales como lista-de-precios son suficientemente expresivos; no ocurre lo mismo con el nombre BCDE456 o cualquier otro código tendiente a oscurecer la lectura del DFD. La dirección de las flechas, desde o hacia los archivos, muestran el movimiento de los datos. Si hay un movimiento desde y hacia un archivo, De Marco indica que solo debe incluirse el flujo neto.

15 Fuente o Destino (entidades externas)
Cualquier sistema podría ser descrito mediante un DFD que solo incluye: dato, proceso y archivos. Sin embargo, para incrementar la legibilidad del diagrama es conveniente mostrar de donde vienen los flujos netos de entrada, y hacia donde se dirigen. Una fuente o un destino es una persona u organización que se encuentra fuera del contexto del sistema, que es un generador o receptor neto de datos. Una persona u organización dentro del contexto del sistema se caracteriza por los procesos que realizan.

16 P.ej. Información (fecha-válida) > Información (fecha)
Flujos de datos Los nombres de los FD deben ser únicos, significativos y concisos Son datos, así que nómbralos como datos. Pueden estar indistintamente en singular o en plural, ya que en los DFDs no se representan cantidades (Barranco 95) Los nombres no sirven sólo para identificar los datos, sino también la información que se tiene sobre ellos P.ej. Información (fecha-válida) > Información (fecha)

17 Los Flujos de datos pueden tener lugar:
Entre dos procesos Entre un Proceso y un almacén de datos Entre una entidad externa y un proceso X P A P B X 1. Verificar validez de pedido pedidos válidos D PEDIDOS PENDIENTES CLIENTE pedidos 0. Sistema de Pedidos libros entregados

18 Flujos de datos Flujos de datos interactivos (dialog flows)
Cuando dos FD establecen un diálogo o comparten una acción de estímulo-respuesta, pueden dibujarse como un único FD de doble flecha, donde ambos extremos deben llevar el nombre del FD que representan. P Determinar estado pedido respuesta estado pedido petición estado pedido denegación crédito P Analizar Petición Aceptar pago solicitud crédito autorización crédito recibo pago

19 El flujo de datos (FD) Un flujo de datos representa una interfaz entre componentes de un DFD. Por lo tanto un DFD se puede visualizar como un TUBO o CAÑERIA a través de la cual fluye un conjunto de datos. DEPTO CONTABLE Coger sgte asiento Diccionario Palabras correctas Asiento aceptado Revisar palabras Revisar asientos asiento palabras Palabras incorrectas Asiento rechazado

20 El flujo de datos Si un dato solo existe para iniciar un proceso, entonces debemos pensar que se trata de un elemento de control y no como un flujo de datos. En los DFD no se representan las instancias de control, las cuales quedan diferidas para más adelante.

21 CONEXIONES PERMITIDAS

22 Ejemplo: 1. Señalar los errores del siguiente DFD

23 Etapas en la construcción de un DFD
Para la construcción de un DFD se sugiere seguir los siguientes pasos: identificar los flujos netos de E/S completar el DFD: nominar los flujos de datos nominar los procesos.

24 Etapas en la construcción de un DFD
1 identificar los flujos netos de e/s La determinación de los flujos e/s están en función del contexto del estudio en cuestión al comienzo de la fase de análisis. El problema central aquí consiste en la selección del contexto. 2 completar el DFD Primero debemos concentrarnos en los flujos de datos, los cuales empaquetan datos tal como los visualiza el usuario. Introducir círculos (burbujas) allí donde se requiera algún trabajo de transformación de un flujo (o conjunto de flujos) de datos. Para c/flujo de datos debe formularse las siguientes preguntas: Que se necesita para construir la información que el contiene? De donde provienen tales componentes? Cuales son los procesos requeridos para llevar a efecto la transformación. Incorporar los archivos que el usuario señale. Cuyos contenidos deben ser conocidos en detalle Aplicar FEED-BACK.

25 Etapas en la construcción de un DFD
3.-Nominar los flujos de datos Los nombres que se asigne a los flujos serán esenciales para la lectura del DFD. Debe asegurarse que a cada flujo se le asigne un nombre y que refleje fielmente su contenido. Si se presentan dificultades para nominar los flujos, entonces lo más probable es que se encuentren mal definidos, por lo que se sugiere revisarlos.

26 Etapas en la construcción de un DFD
4 Nominar los procesos. Solo una vez que todos los flujos se encuentren nominados deberá procederse a nominar los procesos. Al igual que para los flujos, los nombres de los procesos deben ser lo suficientemente explícitos y precisos respecto de lo que hacen. Se debe tratar de que estén compuestos por un único verbo que refleje una acción y por un objeto singular. Si existen dificultades para nominar un proceso, entonces corresponde estudiar una posible revisión del problema.

27 Tipos de DFD En todo conjunto de DFD pueden distinguirse
tres tipos de DFD: Diagrama Nivel superior de contexto: Es el DFD que tiene como propósito el dominio de estudios (ámbito del problema) , mostrando el flujo de datos que entran y salen del dominio. Se le denota como el diagrama 0. Diagrama de niveles intermedios: Son aquellas DFD que no se encuentran en ninguno de los niveles anteriores. Diagramas de primitivas funcionales: Son burbujas (procesos) que no pueden ser descom-puestas en niveles inferiores.

28 Ejemplo: Sistema de distribución sin inventario
Se trata de un sistema que sirve pedidos de libros a unos clientes, con la particularidad de que no mantiene un stock o inventario interno. El sistema puede agrupar los pedidos que clientes distintos hacen a un mismo editor, de manera que se puedan conseguir descuentos.”

29 DFD

30 Ejemplo Niveles Diagrama 0 Diagrama 2 1 2 3 Diagrama 3 Diagrama 1 2.1
2.2 3 Diagrama 3 Diagrama 1 3.2 1.1 3.1 1.2 3.3 1.3 3.4

31 Responder Cuál seria el DFD “padre” de los DFD 1 ,2 y 3?
Cuántos son los niveles mostrados Porque cree que fue suspendida la partición Si se decidiera a particionar en 3 la burbuja 1.2 que numeración tendría dicho DFD? Cuales serian los flujos netos de e/s de dicho DFD? Qué numeración tendría c/una de las tres burbujas? Cuantos niveles tendríamos ahora? Es posible que existan sectores de un DFD con mas niveles que otros?, cuantas mini especificaciones se requieren para especificar todos los procesos? Cual es la relación entre el conjunto de mini especificaciones y el DFD? Cuál seria el máximo número de burbujas que admitiría en un DFD?

32 En los DFD padre-hijo deben estar balanceados los flujos de datos de entrada y salida
Algunas consultas que pueden surgir en la práctica pueden estar dadas por: Cual es el número máximo de burbujas que debiera tener un DFD? Hasta cuando particionar/descomponer? Como determinar que se ha llegado al nivel inferior?

33 Las ventajas de Usar DFD por niveles reside en:
Permiten analizar los problemas bajo un enfoque descendente “top down” Tanto implementadores como usuarios pueden leer los DFD desde el nivel superior hasta los inferiores, pudiendo centrar su atención en áreas particulares de interés. No usa conectores de páginas dado que en c/pagina se supone que se encuentra un DFD completo.

34 Consideraciones DFD Lo anterior nos indica que entre los distintos DFD existe una estructura tipo árbol invertido, donde las relaciones son del tipo padre-hijo. El tamaño de un DFD debe ser el suficiente, como para que sea manejable. Para casos triviales su tamaño puede no exceder el espacio disponible en una hoja, pero para casos más complejos en que el DFD es poco manejable, se introduce el concepto de niveles, basado en el particionamiento del problema en subproblemas.

35 Consistencia entre niveles
Todos los flujos de datos que entran en un diagrama hijo deben estar representados en el padre por el mismo flujo de datos entrando en el proceso asociado. Las salidas del diagrama hijo deben ser las misma salidas del proceso padre asociado con una excepción: lo rechazos triviales (caminos de rechazo que no requieren ninguna revisión de la información establecida) no necesitan estar balanceados entre padre e hijo.

36 Refinamiento en DFD Técnicas usadas para probar y mejorar DFD:
Pruebas de exactitud (corrección) Errores relativos a la documentación de los DFD Errores de consistencia Errores de conservación de los datos Problemas con los archivos Errores de concepción Pruebas de efectividad (utilidad (usabilidad))

37 Pruebas de exactitud (corrección)
Las buenas ideas no germinan, sino que evolucionan. Por ello que es natural que un primer DFD este incorrecto, ya sea por un malentendido con el usuario, por una mala conversión de la descripción de las operaciones, o por cualquier otro motivo. El DFD evolucionara hasta obtener el DFD que refleje fielmente la realidad que aspira a representar. Entre los errores que pueden encontrarse en los DFD, se cuentan: Flujos de datos faltantes: un proceso requiere de información que no esta disponible Flujos de datos sobrantes: esta disponible información innecesaria que tan solo sirve para complicarse las interfaces. Proceso y niveles mal definidos. Flujo de control vistos como flujo de datos. Mala concepción del DFD, en el sentido que funciona correctamente , pero no refleja la realidad que debe plasmar.

38 Veamos cuales son las causantes de estos errores:
Nombres en el DFD Un error bastante común consiste en olvidar los flujos de datos. A veces esto se debe a que se deja para más adelante o porque no sabemos que nombre asignarle. Los nombres de procesos pueden revisarse contra las entradas y salidas, al igual que respecto de los niveles inferiores. Errores de consistencia Debe asegurarse que no existan contradicciones, omisiones ni procesos redundantes. Para ello resulta útil aplicar cuidadosamente la siguiente regla de balanceo: “Todos los flujos de datos de entrada en un diagrama hijo deben estar representados en el proceso padre del diagrama asociado. Las salidas de un diagrama hijo deben ser las mismas salidas del proceso padre asociado, con excepción de rechazos no triviales o registros inválidos”

39 Conservación de datos Se detecta un error de conservación de datos, en términos de que se requiere una información de salida que no puede ser emitida por el proceso con la información de entrada recibida. Debe aplicarse la regla de conservación de datos: “Un proceso debe ser capaz de emitir sus salidas a partir de los flujos de entrada explícitamente mostrados en el DFD, mas información constante”

40 Problemas con Archivos
4 4.3 4.1 1 3 ALFA DELTA 2 4.2

41 Problemas con los archivos
La figura nos muestra un aparte de un DFD en dos niveles sucesivos: a un archivo se ingresan datos, pero estos no son usados. El archivo DELTA es un archivo que debiera incluirse en le diagrama padre.

42 Errores conceptuales: revisión del análisis
Los errores de concepción se refieren a la configuración de un modelo que no refleja exactamente el sistema que se desea representar. La única forma de evitar esta clase de errores consiste en trabajar de cerca con el usuario en la tarea de asegurar la validez de los DFD.

43 Pruebas de utilidad Puede ocurrir que un DFD este correcto, pero de poca efectividad o utilidad, debido a son de difícil lectura y/o comprensión. Para verificar la efectividad de un DFD es preciso centra la atención en : La complejidad de las interfaces: esta se ve reducida mientras menor sea el número de flujos de datos de entrada y salida. Los nombres de los procesos: idealmente deben consistir de un verbo que represente una acción seguido por un objeto concreto. Ejemplo: Calcular comisión producir resumen del inventario editar transacción y abonar en registro cliente procesos pedidos manejar entradas Realizar tareas varias.

44 Recomendaciones para revisar el análisis realizado hasta el momento dado.
no enviar DFD a usuarios que no se encuentren debidamente familiarizados con esta metodología a los nuevos usuarios deben mostrárseles tan solo DFD de nivel bajo o intermedio complementar la revisión de los DFD con información física adicional- personas, lugares, documentos, etc. De forma de ayudar al usuario a su comprensión. Cuando se revisa un DFD del nivel “n” los integrantes del equipo revisor deben estar en posesión del DFD del nivel “n-1”. Evitar el uso de tecnicismos. Mientras mas presentable sea un DFD, más fácil será su comprensión por parte del usuario. El uso de proyectores ayuda tal presentación.