Análisis Estructurado

© Maximiliano Odstrcil 2008

Análisis Estructurado

UNIVERSIDAD NACIONAL DE TUCUMÁNFacultad de Ciencias Exactas y TecnologíaIngeniería Industrial

Introducción Diagramas de flujo de datos Ampliaciones para sistemas de tiempo real

Modelización del comportamientoLa mecánica del análisis estructurado

Ejemplo de DFD: Agenda Personal DiccionariosConclusiones

Contenido

Evolución del análisis según Yourdon: – El análisis de sistemas convencional, anterior a los años 70´s,

caracterizado por especificaciones tipo novela.

– El análisis estructurado clásico, de mediados de los años 70´s, a mediados de los años 80´s. Esto se caracterizó por primeras versiones de modelos gráficos.

– El análisis estructurado moderno, en el cual se introducen mejoras sobre todo para modelar sistemas de tiempo real.

En la actualidad las técnicas modernas están siendo fusionadas, para lograr hacerle frente a las fases del ciclo de vida del sistema. De está manera se logran mejores resultados (interpretación mas rápida y precisa).

Introducción (1)

¿Qué es el análisis estructurado?

Técnica de modelado del flujo, contenido y transformación de la información que fluye por un sistema.

Nació como complemento al diseño estructurado. El término “análisis estructurado” fue popularizado por

DeMarco, a fines de los 70, quien presentó y dominó los símbolos gráficos que permiten crear los modelos de flujo de información.

Yourdon, Gane y otros presentaron variaciones a la propuesta original.

A mediados de los 80, Ward y Mellor proponen ampliaciones para su aplicación en sistemas de tiempo real.

Introducción (2)

Qué herramientas utiliza el análisis estructurado ?

Diagramas de flujo de datos (DFD).

Diccionario de datos.

Especificación de procesos.

Diagramas Entidad-Relación.

Diagramas de transición de estados.

Introducción (3)

Diccionario de datos: contiene definiciones de todos los objetos de datos consumidos y producidos por el software.

Diagrama entidad-relación: representa las relaciones entre entidades de datos. Los atributos de cada entidad se pueden describir mediante la Descripción de datos.

Diagrama de flujo de datos (DFD), sirve para dos propósitos: indica como se transforman los datos a medida que se avanza en el sistema, y representa las funciones que transforman el flujo de datos. En la Especificación de proceso se encuentra una descripción de cada función representada en el DFD.

Diagrama de transición de estados (DTE), indica como se comporta el sistema como consecuencia de sucesos externos. La Especificación de control detalla más información sobre los aspectos de control del software.

Introducción (4)

El DFD representa un modelo del flujo de información. Se caracteriza porque:Muestra el flujo de la información.Muestra las transformaciones aplicadas a los datos desde la

entrada hasta la salida.Especifica QUÉ hace el sistema.Es gráfico.Es comprensible por los usuarios.

Diagrama de flujo de datos DFD (1)

Notación DFD básica:

Proceso

Entidad externa

Un elemento de datos o una colección de elementos de datos; la dirección de la flecha indica la dirección del flujo de datos.

Un productor o consumidor de la información que reside fuera de los límites del sistema a ser modelado. Ej, Hardware, una persona, u otro programa.

Un transformador de información que reside dentro de los limites del sistema, a ser modelado.

Un depósito de datos que se guardan para ser usados por uno o más procesos; puede ser tan sencillo como un buffer o una cola, o tan sofisticado como una base de datos relacional.

Almacén de datos

Elementos de datos


Ejemplo de Modelo de flujo de información:


ElSistema

Entidad externa

Entidad externa

Entidad externa

Entidad externa

Entidad externa

Informaciónde entrada

Informaciónde entrada

Informaciónde salida



Entidades Procesos Almacenes

Entidades NO SI NO

Procesos SI SI SI

Almacenes NO SI NO

Un DFD muestra:• Procesos.• Flujos de datos.• Almacenes de datos.• Entidades externas.

Un DFD muestra:• Procesos.• Flujos de datos.• Almacenes de datos.• Entidades externas.

Consideraciones sobre los DFD:


Un DFD no muestra:• Composición del flujo de datos.• Relaciones de acceso.• Decisiones.• Cálculos.• Cantidades.

Un DFD no muestra:• Composición del flujo de datos.• Relaciones de acceso.• Decisiones.• Cálculos.• Cantidades.

Consiste en desagregar un proceso padre en un nuevo DFD de mayor detalle.

Se produce a medida que se conocen más actividades internas a dicho proceso.

Normas a seguir al explosionar un proceso: Numeración: al explosionar el proceso “n”, se enumeraran los

procesos hijos como n.1,n.2, … DFD Balanceado: todos los flujos que entraban y salían del proceso

padre deberán entrar y salir del conjunto de procesos hijos. Del DFD obtenido por explosión pueden surgir nuevos flujos

correspondientes al tratamiento de errores y excepciones. Asimismo pueden aparecer almacenes de datos privados.

Explosión de un Proceso:


F

f1

f3

f2

f4

f5

f6

f7

f41 f43 X1

f45

X2X

f42 f44 Y1Y2

Y

Z

BA

W

VX

Y

Z Z1

Z3

Z2

A

B

Ejemplo del Refinamiento del flujo de información:


Diagrama de Contexto (Nivel 0) Es un resumen genérico del problema Un único proceso y las entidades externas.

DFD 0 (Nivel 1) Modelo con toda la funcionalidad del sistema.

DFD 1,…,DFD2,… (Nivel 2) DFD que corresponden a la explosión de cada procesos padre del nivel 1.

Niveles Adicionales (3,4,...) DFDs que representan la explosión de procesos contenidos en los DFDs del nivel

inmediatamente superior.

Niveles de un DFD:


El DFD de contexto da una imagen global, que es la que interesa al usuario. Se identifican todos los interfaces de nuestro sistema con el exterior.

Para tratar sistemas complejos, se utilizan los niveles, que da como resultado la aparición de jerarquías de DFDs. Un DFD no debe contener mas de 7-9 procesos para ser comprensible.

Los almacenamientos de datos se pueden representar a distintos niveles tantas veces como sea necesario.

A un proceso de un determinado nivel se le llama padre, y mediante la explosión da lugar a un diagrama hijo, situado un nivel por debajo. Este diagrama resultante especifica y descompone la globalidad anterior.

La explosión se va ejecutando para todos los elementos que la requieren hasta alcanzar un nivel de especificación mínimo sencillo, que haga totalmente comprensibles todos y cada uno de los mini sistemas.

Conclusiones:


La modelización del comportamiento es uno de los principios fundamentales de todos los métodos de análisis de requisitos, aunque solo algunas versiones ampliadas del análisis estructurado proporcionan una notación para este tipo de modelización. El diagrama de transición de estados (DTE) representa el comportamiento de un sistema, mostrando los sucesos que hacen que el sistema cambie de estado.

El DTE consta de: Rectángulos: Representan estados del sistema. Flechas: Transiciones entre estados. Etiquetas: Expresión en forma de fracción, la parte superior indica

el suceso que hace que se produzca la transición y la parte inferior indica la acción que se produce como consecuencia del suceso.

Modelización del comportamiento (1)

Leyendo ordenes

Diagnósticoproblema

Realizandocopias

Recargando papel

Llena y comienzoInvocar gestión de copiado

Copias hechasInvocar leer-ord-op

LlenaInvocar leer-ord-op

VacíaInvocar recarga papel

AtascadoInvocar realizarDiagnóst. del prob.

No atascadoInvocar leer-ord-op

Diagrama de transición de estados: ejemplo de la fotocopiadora.

Modelización del comportamiento (2)

Vimos que los Diagramas de Flujo de Datos constan de cuatro componentes: Procesos, Flujos, Almacenes y Terminaciones.

Armados con estas herramientas, puede comenzar a entrevistar a los usuarios y a construir modelos de DFD de Sistemas.

Existen un número de reglas adicionales que se requieren para poder utilizar DFD con éxito.

Las reglas incluyen las siguientes: Escoger nombres con significado para los Procesos, Flujos, Almacenes y Terminadores. Numerar los Procesos. Redibujar el DFD tantas veces como sea necesario estéticamente. Evitar los DFD excesivamente complejos. Asegurarse de que el DFD sea internamente consistente y que también lo sea con

cualesquiera DFD relacionados con el.

La mecánica del Análisis Estructurado (1)

Es muy importante etiquetar con precisión el proceso. Si el Proceso lo hace una sola persona, se recomienda que identifique el

papel que dicha persona está representando, mas que su nombre o identidad.

Un buen sistema que se pude utilizar para nombrar Procesos es usar un Verbo y un Objeto. Por ejemplo: PRODUCIR INFORME DE INVENTARIO VALIDAR NÚMERO TELEFÓNICO ASIGNAR ESTUDIANTE A CLASE

Los nombres de los Procesos (al igual que los nombres de Flujos y de Terminadores), deben provenir de un vocabulario que tenga significado para el usuario.

1. Escoger Nombres con significado para los Procesos, Flujos, Almacenes y Terminadores.


2. Numerar el Proceso

Como una forma conveniente de referirse a los procesos en un DFD, muchos analistas numeran cada burbuja.

No importa mucho como se haga esto, (de izquierda a derecha, de arriba abajo, o de cualquier otra manera) servirá mientras haya constancia en la forma de aplicar los números.

Se debe tener en cuenta que el sistema de numeración implicará, para algunos lectores casuales de su DFD (un usuario, otros analistas, programadores) una cierta secuencia de ejecución.

Esto no es así en absoluto, el modelo DFD es una red de Procesos asincrónica que se intercomunican, algunas secuencias pudiera implicarse por la presencia o ausencia de datos, pero el sistema de numeración no tiene nada que ver con eso.


El propósito de un DFD es modelar de manera precisa las funciones que debe llevar a cabo un sistema y las interacciones entre ellos.

Otro propósito del DFD es ser leído y comprendido, no solo por el analista (que construyó el modelo) sino por los usuarios que son los expertos en la materia de aplicación.

No cree un DFD con demasiados Procesos, Flujos, Almacenes y Terminadores, el DFD debe caber en la hoja normal.

Una excepción importante a esto: un DFD especial llamado DIAGRAMA DE CONTEXTO, que representa al sistema entero como un solo proceso y destaca las interfaces entre el sistema y los terminadores externos.

3. Evitar los DFD demasiados Complejos.


En un Proceso Real de Análisis de Sistemas, el DFD que se analiza en este capítulo, tendrá que dibujarse y volverse a dibujar, a menudo hasta 10 veces o más, antes de: Ser técnicamente correcto. Ser aceptable para el usuario. Estar lo suficientemente bien dibujado, como para que no sea embarazoso mostrarlo a

la dirección de la Organización. ¿Que hace estéticamente agradable a una DFD?.

Cualquier cosa que el usuario encuentre agradable debe determinar la manera en la que se dibuje el diagrama (aún cuando el analista pudiera tener una opinión un tanto diferente).

Asuntos que surgen a ser tratados en esta área: Tamaño y forma de las burbujas. Flujos Rectos vs. Flujos Curvos. Diagramas hechos a mano vs. diagrama generados a máquina.

4. Redibujar el DFD tantas veces como sea necesario


Como se verá luego, existen reglas que ayudan a asegurar la consistencia del DFD con los otros modelos de sistemas (Diagramas Entidad Relación, Diagrama de Transición de Estados, Diccionario de datos, Especificación de Procesos.

Sin embargo existen algunas reglas respecto a como asegurar que el DFD mismo sea consistente.

Las principales reglas de consistencia son: Evite los Sumideros Infinitos Evite las Burbujas de Generación espontánea Tenga cuidado con los Flujos y Procesos no etiquetados Tenga cuidado con los almacenes de “solo lectura” o “solo

escritura”.

5. Asegúrese de que su DFD sea lógicamente Consistente


Pedidos

Información de Cuentas

Ejemplo: DFD Típico

Nombre del Cliente, Detalles de la Factura

CLIENTES

PEDIDOS

BODEGA

CLIENTES

CLIENTES

FACTURAS

RECEPCIÓN DE PEDIDOS

COBRANZAS

CONTABILIDAD DE ENVÍO

Pedidos Cancelados

Detalles del Pedido

Detalles del Envío

Nombre del Cliente, Dirección del Cliente Nombre del Cliente,

Dirección del Cliente

Facturas, declaraciones

Cobros, Indagaciones

Contabilidad

Contabilidad


Hasta ahora solo hemos visto DFDs sencillos, pero los DFDs que veremos en proyectos reales son considerablemente mayores y más complejos.

En secciones anteriores se sugirió evitar diagramas como el de la figura. Pero ¿Cómo? Si el sistema es intrínsecamente complejo y tiene docenas o incluso cientos de funciones que modelar.

DFD por Niveles:


La Respuesta es organizar el DFD global en una serie de niveles de modo que cada una proporcione sucesivamente mas detalles sobre una porción de Nivel anterior.

El DFD de 1º Nivel consta de una sola Burbuja que representa el sistema completo. Este DFD especial se conoce como Diagrama de Contexto.

El DFD que sigue del Diagrama de Contexto se conoce como Figura 0. representa la vista de mas alto nivel de las principales funciones del Sistema, al igual que sus principales Interfaces.

Como se discutió anteriormente cada una de las Burbujas debiera numerarse para una referencia conveniente.

Los números sirven como una manera adecuada de relacionar una burbuja con el siguiente nivel de DFD que la describe mas a fondo.

Si una Burbuja tiene nombre (que en realidad debiera tenerlo), entonces dicho nombre se utiliza en la figura del nivel inmediato inferior.

DFD por Niveles:


FIGURA 0

1 2

3 4

EL SISTEMA

DIAGRAMA DE CONTEXTO

3.13.2

3.3 3.4

FIGURA 3

DFD por Niveles:


Fragmento Balanceado de un DFD:

EL SISTEMA

1 2

3 4

3.1 3.2

3.3 3.4

DIAGRAMA DE CONTEXTO

FIGURA 0

FIGURA 3

A B

C A B

C

YXZ

X

YZ


1. ¿Cómo saber cuantos niveles debe haber en un DFD?Se sugirió, cuando dijimos que cada DFD debe tener menos de media docena de Burbujas, Almacenes, Flujos, Terminadores.

2. ¿Existen Reglas acerca del número de niveles que deberían esperarse en un Sistema Típico?En un Sistema simple probablemente se encontrarán 2 o 3 niveles, uno mediano tendrá generalmente de 3 a 6 niveles, uno grande de 5 a 8 niveles.

3. ¿Deben partirse todas las Partes del sistema con el mismo nivel de detalle?La respuesta es NO, algunas partes del sistema pueden ser más complejo que otras y pueden requerir uno o mas niveles de partición.

4. ¿Cómo se muestran estos Niveles al Usuario?Muchos usuarios solo querrán ver un diagrama, resulta útil tener 2 diagramas juntos en el escritorio cuando esté haciendo esto: el diagrama en cual está particularmente interesado y el diagrama progenitor que provee un contexto de alto nivel.

Diversas cosas que además debemos añadir a esta descripción de Niveles:


5. ¿Cómo asegurar que cada figura sea consistente con la de más alto nivel?Se sigue una regla sencilla: los Flujos de Datos que salen y entran de una Burbuja en un nivel dado deben corresponder con los que entran y salen de toda la figura en el nivel inmediato inferior que la describe.

6. ¿Cómo se muestran los almacenes en los diversos niveles?Mostrar un almacén en el nivel mas alto donde primeramente sirve de interfaz entre 2 o mas burbujas, luego mostrarlo de nuevo en cada diagrama de nivel inferior que describa mas a fondo dichas burbujas de interfase.El corolario de esto es que los almacenes locales, que utilizan solo burbujas en una figura de menor nivel, no se mostrará en niveles superiores, dado a que incluyen de manera implícita en un proceso del nivel inmediato superior.

7. ¿Cómo se realiza la partición de los DFD en Niveles?A pesar que ciertamente los DFD deben presentarse al público usuarios de una manera descendente, no es necesariamente cierto que el Analista deba desarrollarlo así.

La mecánica del Análisis Estructurado (13)Diversas cosas que además debemos añadir a esta descripción de Niveles:

USUARIO PERSONAS

AGENDA

Datos Llamado

Listado Personas

Mensaje

Listado Cumpleaños

Mensaje Cumpleaños

Llamando/Ocupado

Datos Personas

Diagrama de Contexto: Agenda Personal

Ejemplo de DFD: Agenda Personal (1)

Figura 0: Agenda Personal

Listar Personas

3

Dato Llamado

Listado Personas

Llamando/Ocupado

Listado Cumpleaños

Mensaje Cumpleaños

MensajesDatos Persona

Generar Llamada

2

Listar Cumpleaños

4

Generar Mensaje de Cumpleaños

5

GestionarPersona

1

PERSONAS


Descripción de Entidades Externas:

Usuario: Quien interactúa con el sistema.

Personas: Quienes aportan sus datos al sistema

Diccionario:

PERSONAS={persona}

persona = @identificación de Persona +nombre +apellido + domicilio + fecha_nacimiento + 0{teléfono}N

teléfono = *Número telefónico de la persona* = 5{D}14

D = {0,1,2,3,4,5,6,7,8,9}

Dato Persona= *Datos introducidos por el usuario acerca de las personas, que serán almacenados en el Sistema* = nombre +apellido + domicilio +

fecha_nacimiento + 0{teléfono}N


Dato Llamado = *datos necesarios para establecer un llamado* = nombre + apellido

Mensajes = *respuesta del Sistema cuando se agrega, borra o modifica los datos de una persona* = [Esta Persona ya existe|Datos almacenados con éxito|

Error]

Listado de Personas = *listados de las personas almacenadas, con sus respectivos datos* = {nombre +apellido + domicilio + fecha nacimiento + 0{teléfono}N}

Llamando/Ocupado = *respuesta del Sistema cuando se realiza una Llamada* = [Llamando|Ocupado]

Listado de Cumpleaños = *Listado de las Personas en orden alfabético con sus respectivas Fecha de Nacimiento* = {nombre +apellido +fecha nacimiento}

Mensaje de Cumpleaños = *Muestra las Personas que cumplen años en la fecha actual* = {nombre + apellido + teléfono + cantidad de años}


Descripción de Procesos: Proceso 2: GENERAR LLAMADA

BUSCAR Persona en almacén PERSONAS, si la Persona existe y si tiene número telefónico, MARCAR número telefónico.

Proceso 3: LISTAR PERSONAS

MOSTRAR todas las Personas del almacén PERSONAS, con sus respectivos datos.

Proceso 4: LISTAR CUMPLEAÑOS

CALCULAR para cada Persona la edad MOSTRAR todas las Personas del almacén PERSONAS, con sus respectivas fechas de nacimiento y edad.

Proceso 5: GENERAR MENSAJE DE CUMPLEAÑOS

BUSCAR en almacén PERSONAS, aquellas cuya fecha de nacimiento coincida con la fecha actual, si se encuentra, MOSTRAR dicha/s Persona/s con sus datos correspondientes.


Describe el contenido de los objetos definidos durante el análisis estructurado.

Es un listado organizado de todos los elementos de datos que son pertinentes para el sistema,con definiciones precisas y rigurosas

Permite que usuario y analista tengan una misma comprensión de las entradas, de las salidas, de las componentes de los almacenes y de los cálculos intermedios.

Describe:• El significado de los flujos y almacenes en los DFD• La composición de los paquetes como una agregación de paquetes más

elementales. • Valores y unidades relevantes de datos elementales.• Las relaciones entre almacenes, enfatizadas en un diagrama entidad-

relación.

Diccionario de Datos (1)

Tres formas fundamentales de construcción:

Como una secuencia de elementos de datos.

Como una selección entre un conjunto de elementos de datos.

Como una agrupación repetitiva de elementos de datos.

Notación usada en el diccionario de datos


= está compuesto de Secuencia + y

[ ] selecciona una de varias alternativas Selección

| separa opciones alternativas Repetición { }n n repeticiones de

( ) datos opcionales * * delimita comentarios Símbolos

varios @ identificador (campo clave) para un almacén

Ejemplo: Definición de un nombre

nombre = título de cortesía + nombre + (segundo nombre) + apellido

título de cortesía = [Sr. | Srta. | Sra.]

nombre = {caracter legal}

segundo nombre = {caracter legal}

apellido = {caracter legal}

caracter legal = [A-Z | a-z | 0-9 | ‘ | - | | ]


Para definir por completo un dato, se debe incluir: El significado dentro del contexto de la aplicación. Se incluye como un

comentario usando la notación “* *”.

La composición del dato, si se compone de partes elementales con significado.

Los valores que puede tomar el dato, si es un dato elemental que no puede descomponerse más.

Ejemplo: Construcción de un sistema médico que siga la evolución de los pacientes.

peso = *peso del paciente al ser admitido al hospital*

*unidades: kilogramos; gama 1-200*

estatura = *estatura del paciente al ser admitido al hospital*

*unidades: centímetros; gama 20-200*

Definiciones


Aquellos sin descomposición con significado para el usuario. La granularidad necesaria es dependiente de la aplicación.

Deben introducirse al diccionario, junto con una breve narrativa. La notación “* *” indica “sin comentarios”

Ejemplo:peso actual = * *

*unidades: libras; escala: 1-400*

estatura actual = * *

*unidades: pulgadas; escala: 1-96*

sexo= * *

*valores: [M | F]*

Elementos de datos Básicos


Aquellos que pueden o no estar presentes en un dato compuesto.

Deben documentarse con exactitud. Por ejemplo:

domicilio cliente = (domicilio de envío) + (domicilio para cuentas)

Es probablemente errónea. Más adecuada sería:

domicilio cliente = [(domicilio de envío) | (domicilio para cuentas) |

domicilio de envío + domicilio para cuentas ]

Datos opcionales


Indica la ocurrencia repetida de un componente de dato.

Se lee como “cero o más ocurrencias de”

El usuario quizá quiera especificar límites inferiores y/o superiores a la iteración

solicitud = [nombre del cliente + domicilio de envío + 1{artículo}10]

Es correcto especificar sólo el límite superior, sólo el límite inferior o ambos.

Iteración


Es una alternativa de nombre para un dato.

Común cuando el grupo de desarrollo trata con diversos grupos de usuarios en diferentes departamentos o ubicaciones geográficas.

Se incluyen en el diccionario de datos. Ejemplo:

comprador = *alias de cliente*

No muestra su descomposición. Estos detalles sólo deben darse para el nombre primario del dato.

Debe evitarse el uso de alias hasta donde sea posible.

Alias


Ejemplo: Especificación del elemento de datos “número de teléfono” para el sistema Hogar Seguro

nombre: número de teléfonoalias: ningunodónde/cómo se usa: comprobar ajustes iniciales (salida)

marcar número (entrada)descripción:

número de teléfono = [extensión local | número exterior]número de teléfono = [extensión local | número exterior]extensión local = [2001|2002| ... |2999]número exterior = (0) + [no. local | no. larga distancia]no. local = prefijo + no. accesono. larga distancia = código de área + no. localprefijo = [725|474|255|394]no acceso = *cualquier cadena de 4 dígitos*


Un sistema sencillo tendrá un diccionario con cientos de entradas. No son raros diccionarios con varios miles de entradas.

Si se usa una base de datos como herramienta de implementación, debe tener cuidado con las siguientes limitaciones:

Verse forzado a limitar la longitud de los nombres.

Limitaciones artificiales para el nombre (caracteres no válidos, prefijos o sufijos en todos los nombres, etc.)

Verse obligado a asignar atributos físicos a un dato (número de bytes, redondeo de decimales, etc.) que no surjan del usuario.

Esto hace atractivas las herramientas CASE.

Implementación del diccionario de datos


Este tipo de análisis es el método más usado en la modelización de requisitos.

Se basa en el modelo de flujo como primer elemento de representación gráfica.

Usando como base los diagramas de flujo, de datos y de control, el analista separa las funciones que transforman el flujo.

Después crea un modelo de comportamiento usando el diagrama de transición de estados y un modelo de contenido de los datos como un diccionario de requisitos. Las especificaciones de los procesos y del control proporcionan una elaboración adicional de los detalles.

Cabe destacar que el DFD es tan solo una de las herramientas de modelado disponibles y que únicamente proporciona un punto de vista de un sistema, el orientado a las funciones.

Conclusiones (1)

Conclusiones (2) Si se está desarrollando un sistema en dónde las relaciones entre datos

son más importantes que las funciones, tal vez se de menos importancia al DFD, para concentrarse más bien en desarrollar un conjunto de diagramas de entidad-relación.

De otra manera, si el comportamiento dependiente del tiempo de un sistema domina sobre cualquier otro factor, tal vez nos concentremos más en el diagrama de transición de estados.

Análisis Estructurado

Documents

Transcript of Análisis Estructurado