Análisis y Diseño Estructurado

Diseño de Sistemas de InformaciónClase : 27 de abril - 2011

©Natividad Grandón

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.

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

CaracterísticasCaracterí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 disponiblesVisible Analyst, Easy Case, S-Designor

ProcessAnalysis

Definiciones de la BD

Visión panorámica AEEsquema resumen

Diccionariode Datos

Diagrama de flujo de datos

PROC

B

Z

Y

X

W

V

APROC

PROC

PROCPROC

FUENTE

DESTINO

D ALMACÉN DE DATOS

Diagrama E-R (o DED)

Diagrama de estructuras

Paso al diseño

Descripcióndel proceso

Definición del FD

Definiciones de los módulos

Descrip.E. E.

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.

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.

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.

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.

Símbolos del DFD(notación Yourdon/De Marco)

PProceso

Entidad Externa

D ALMACÉN DE DATOS

Flujo de eventos

Flujo de datos

Transformaciones o procesos (funciones, cálculo, selección)

Terminadores (Fuentes o Destinos)(personas, entidades)

Flujos de información(inputs-outputs)

Flujos de control (Ward & Mellor 85)

Ficheros o depósitos temporales de información (base de datos, armario, clasificador, etc.)

NOTACIONES

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.

FX

P1 P2Y Z

A

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

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.

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.

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)

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

P BP A

X

X

1.Verificar validez

de pedido

pedidos válidos

D PEDIDOS PENDIENTES

0. Sistema de

Pedidoslibros entregados

pedidosCLIENTE

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.

PDeterminar

estado pedido respuesta estado pedido

petición estado pedido

denegacióncrédito

PAnalizarPeticióncrédito

PAceptar pago solicitud crédito

autorización crédito

recibo

pago

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.

Revisar palabras

Diccionario

palabras

Palabrascorrectas

Palabrasincorrectas

Revisar asientosasiento

Asiento aceptado

Asiento rechazado

DEPTOCONTABLE

Coger sgte asiento

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.

CONEXIONES PERMITIDAS

Ejemplo:

1. Señalar los errores del siguiente DFD

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.

Etapas en la construcción de un DFD

1 identificar los flujos netos de e/sLa 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 contenidosdeben ser conocidos en detalleAplicar FEED-BACK.

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.

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.

Tipos de DFD

En todo conjunto de DFD pueden distinguirsetres 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.

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.”

DFD

Ejemplo Niveles

Diagrama 0 Diagrama 2

Diagrama 1

Diagrama 3

1

2

3

2.1

2.2

1.1

1.2

1.3

3.1

3.2

3.3

3.4

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?

En los DFD padre-hijo deben estar balanceados los flujos de datos de entrada y salida

Algunas consultas que pueden surgir en laprá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?

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.

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.

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.

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))

Pruebas de exactitud (corrección)

Las buenas ideas no germinan, sino que evolucionan. Por ello quees natural que un primer DFD este incorrecto, ya sea por unmalentendido con el usuario, por una mala conversión de ladescripción de las operaciones, o por cualquier otro motivo. ElDFD evolucionara hasta obtener el DFD que refleje fielmente larealidad que aspira a representar. Entre los errores que puedenencontrarse 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.

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 consistenciaDebe 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”

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”

Problemas con Archivos

4

13

2

4.14.3

4.2

ALFA DELTA

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.

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.

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.

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.