tema 5: análisis y diseño de los sistemas de …si-2010... · 17/03/2011 sistemas de información...

17/03/2011 Sistemas de Información 1

Sistemas de Información

Tema 5: Análisis y Diseño de los Sistemas de Información


Bibliografía

� Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión. Piattini et al., RA-MA, 1996.

� Análisis Estructurado Moderno. Yourdon, Prentice-Hall, 1985.


Temario

� Análisis Estructurado� Diagrama de Flujo de Datos� Diccionario de Datos� Especificación de Procesos

� Diseño Estructurado� Diagrama de estructura� Estrategias de diseño (análisis de

transformación y de transacción)


Introducción

ERS

Modelo lógico de datos Arquitectura de procesos

Modelo físico de datosEstructura detallada:

programas y módulos

Enfoque de datos Enfoque funcional

DFDE-R

Esquema de BDy ficheros

Cuadernos decarga

Codificación/Programación

Análisis (Qué)Lenguaje comprensiblepara el usuario/cliente

Diseño dealto nivel(arquitectónico)

Diseño debajo nivel(detallado)

ImplementaciónLenguaje comprensiblepor la máquina

Diseño (Cómo)

Decisiones generalesy abstractas (organiza-ción lógica)

Decisiones concretasy específicas (optimiza-ción y rendimiento)


Análisis Estructurado


Diagrama de Flujos de Datos (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.

� Es la técnica más difundida dentro del análisis estructurado.

� Se apoya en otras técnicas de descripción textual:� diccionario de datos� especificaciones de proceso.

� Se utiliza para modelar las funciones del sistema y los datos que fluyen entre ellas a distintos niveles de abstracción.

� Niveles superiores: funciones del sistema de forma general� Niveles inferiores: funciones del sistema de forma detallada



Componentes de un DFD

� Procesos: componentes funcionales del sistema

� Almacenes: representan datos almacenados o en reposo

� Entidades externas: representan la fuente y/o el destino de la información del sistema

� Flujos de datos: representan los datos que fluyen entre las funciones



Notaciones de un DFD

Yourdon, DeMarco Gane y Sarson

Flujos de datos

Procesos

Almacenes dedatos

Entidades externas

SSADMMÉTRICA


Diagrama de Flujos de Datos (DFD): Procesos

Procesos (Funciones o Transformaciones)

Representa una función que transforma los flujos de datos de entrada en uno o varios flujos de datos de

salida.

� No define un programa en ejecución.� El proceso debe ser capaz de generar flujos de datos

de salida a partir de flujos de datos de entrada más una información local:

� Error de conservación de datos

� Pérdida de información


Diagrama de Flujos de Datos (DFD): Procesos

Representación gráfica (Yourdon):� Un Círculo. � Incluye un número y un nombre (únicos en el conjunto

de DFD que representan el sistema)

� Características de los nombres:

� Lo más representativo posible. � Dar un nombre que englobe a toda la función� Suprimir nombres con poca significación (Ej: REALIZAR

OPERACIÓN, GESTIONAR ACCIÓN, etc.)� Verbo seguido de un sustantivo (Ej.: GENERAR PEDIDO).

� Existen DFD lógicos y físicos


Diagrama de Flujos de Datos (DFD): Almacenes

Almacenes de Datos:

Representa información del sistema

almacenada de forma temporal

� datos en reposo (flujos: datos en movimientos)� cualquier dato temporalmente almacenado

independientemente del dispositivo utilizado� Ejemplos: un cajón con papeles, un archivador

manual, un fichero o una base de datos, etc.� Su contenido se define en diccionario de datos.


Diagrama de Flujos de Datos (DFD): Almacenes

Características de los almacenes:

� Nombre:� Lo más representativo posible� No asociado a connotaciones físicas� En plural (Ej: “clientes”) .

� Se puede representar varias veces en un DFD� Se puede representar en distintos niveles de DFD� Si es local a un proceso, se representará en el DFD

en el que se especifique dicho proceso. � Almacén de estructura simple (es de tipo registro)

� Si tiene una estructura compleja (diagrama entidad/interrelación)


Diagrama de Flujos de Datos (DFD): Entidades Externas

Entidades Externas (Terminadores):

Es el componente del DFD que representa un generador o consumidor de información del sistema y que

no pertenece al mismo.

Ejemplos: subsistemas, personas, departamentos, organizaciones, otras aplicaciones o sistemas, etc.

� Son externas al sistema que se está modelando� Los flujos que parten o llegan a ellas definen la interfaz

entre el sistema y el mundo exterior. � Relaciones entre las entidades externas no son objeto

del estudio del modelo.


Diagrama de Flujos de Datos (DFD): Entidades Externas

Representación Gráfica:

� El nombre debe ser representativo. � Se pueden dibujar varias veces en un DFD (con un

asterisco).� Normalmente las entidades externas sólo van a

aparecer en el DFD de mayor nivel llamado diagrama de contexto.

DEPARTAMENTOCOMPRAS

CLIENTE

*

Representación de una entidad externa de cardinalidad simple y repetida en un DFD

Representación opcional de entidades externas de cardinalidad N


Diagrama de Flujos de Datos (DFD): Flujos de Datos

Flujos de Datos:

Representan los datos en movimiento en un momento y con una cardinalidad determinados.

� A través de ellos los datos viajan de una parte del sistema a otra.

� Es el medio de conexión de los restantes componentes del DFD.

� Se representan por arcos dirigidos. � Según la persistencia en el tiempo de los datos que fluyen por

el flujo, estos pueden ser discretos o continuos.

Flujo de datos discreto

Flujo de datos continuo



Conexiones permitidas:

NoNo*SiEntidad Externa

No*NoSiAlmacén

SiSiSiProceso

Entidad Externa

Almacén ProcesoDestinoFuente



Formas de Paso de Datos entre procesos:

ALMACEN TEMPORAL

PROCESO

A

PROCESO

A

PROCESO

B

PROCESO

B

Paso síncrono de informaciónentre procesos

Paso asíncrono de informaciónentre procesos



Conexiones entre procesos y Almacenes:

FLUJO DE CONSULTA

FLUJO DE ACTUALIZACION

FLUJO DEDIALOGO



Ejemplos de Flujo de Dialogo:

GESTIONAR PETICIONES DE

USUARIO

USUARIO

LIBROS

PRESTAMOS

Petición de libro

GESTIONAR PETICIONES DE

USUARIO

CLIENTE INFORMES

Petición de informe

Informe aCliente

CLIENTES

Par dialogo



Caso Particular de Flujo entre Almacenes y Entidades Externas:

GESTIONAR

PRESTAMOS DE

BIBLIOTECA

USUARIO

Petición de libro

SISTEMA DE

MANTENIMIENTO

DE PUBLICACIONES

LIBROS

Resguardo de

aceptación


Características de los Flujos de Datos:

� Deben tener un nombre representativo (excepto aquellos que entren o salgan de almacenes que tengan una estructura simple).

� Si los datos que viajan por el flujo de dato tienen distintos propósitos o no viajan juntos, entonces estos datos constituyen dos o más flujos de datos.

� No indican el control de ejecución de los procesos.� El contenido de un flujo puede ser de varios tipos:

� Elemento� Grupo� Par de diálogo� Múltiple



� Ejercicio 10:



Descomposición en Niveles de un DFD

� El modelo de un sistema grande es representado “por capas”.

� Se sigue una aproximación descendente (top-down)

Ventajas de la descomposición en niveles:� Ayuda a construir la especificación de arriba abajo. � Distintos niveles pueden ir dirigidos a personas

diferentes (directivos y usuarios). � Facilita el trabajo de los analistas (trabajo paralelo de

modelado). � Facilita la documentación del sistema.



Descomposición en Niveles de un DFD

� Diagrama de Contexto: En este diagrama sólo hay un proceso que representa el sistema completo

� Niveles Medios� Diagrama de Sistema: representan

las funciones principales o subsistemas� Otros diagramas cada vez más

detallados

� Funciones Primitivas: están presentes tanto en los niveles intermedios como en los últimos niveles de la jerarquía y se corresponden con procesos que no se explotan en nuevos DFD.


GESTIONSISTEMA

X

DIAGRAMA DE CONTEXTO

E1

E2

E3

AB

C

D

E

0

1 2

A1

A2

A

B

E

D

CDIAGRAMA 0: GESTION SISTEMA X

DIAGRAMA 1: DIAGRAMA 2:A2A1

A

E

BA3

1.1 1.2

1.3

A1

A2

A3

B

1.2.1 1.2.2

1.2.3

DIAGRAMA 1.2:


Convenciones sobre la numeración:

� Cada diagrama recibe el número y el nombre del proceso que descompone (proceso padre).

� El proceso del diagrama de contexto siempre es numerado como cero.

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



Diagrama de Contexto (Diagrama de Nivel 0):

El objetivo de este diagrama es delimitar la frontera entre el sistema con el mundo exterior, y definir sus

interfaces (flujos de datos de entrada y salida del sistema con el entorno o contexto).

Está formado por:� Un proceso que representa una “caja negra” del

sistema completo. � Un conjunto de entidades externas� Un conjunto de flujos de datos



Diagrama de Sistema (Diagrama 0, Diagrama de Nivel 1):

Es la descomposición del diagrama de contexto y en él se representan las funciones principales del

sistema, así como la relación entre ellas.

� Es importante que las funciones de este diagrama sean conceptualmente independientes entre sí.

� Facilita la descomposición de cada una por personas (analistas) diferentes.



Procesos primitivos:

Son aquellos procesos de un DFD que ya no se descomponen en más diagramas de nivel inferior.

� Por cada función primitiva habrá una especificación que la describa.

� La decisión de no descomponer más es una responsabilidad del analista (decisión subjetiva).

� Algunas reglas:� Cuando un requisito funcional se puede especificar en

menos de una página.� Cuando los procesos del diagrama tienen pocos flujos de

datos de entrada y salida.� Cuando al descomponer una función de un nivel

determinado, se pierde el significado de lo que tiene que hacer esa función.



Consistencia entre niveles (Balanceo):

� Es necesario comprobar la consistencia entre los distintos niveles de DFD.

� Regla del balanceo entre niveles:� Todos los flujos de datos que entran a un diagrama hijo

deben estar representados en el padre por el mismo flujo de datos entrando al proceso asociado.

� Las salidas del diagrama hijo deben ser las mismas salidas del proceso padre asociado. Excepción: los rechazos triviales (caminos de rechazo que no requieren ninguna revisión de la información establecida) no necesitan estar balanceados entre padre e hijo.

� Puede ser que no veamos exactamente los mismos flujos de datos en el proceso padre que el diagrama hijo y que estén balanceados (flujos de datos múltiples).



Recomendaciones en la creación de un DFD:

Diagrama de contexto:� Localizar las entidades externas que van a proporcionar y/o consumir

información.� Localizar los flujos de datos.Diagrama de sistema: � Identificar sus funciones principales. � Por cada procesos:

� Señalar sus entradas y salidas (que son recogidas del diagrama de contexto) � Hacer una partición de los flujos de datos múltiples en los flujos en los que se

descompone� Identificar las interfaces entre funciones (mediante flujo directo o a través de un

almacén) � Identificar almacenes

Resto de diagramas:� No descomponer al máximo. � Identificar las principales subfunciones de la función del nivel superior. � Recoger todos las interfaces del proceso de nivel superior y se asignan a

cada subfunción (desglose de flujos múltiples)� Identificar las interfaces entre los procesos de este nivel (mediante flujo

directo o a través de un almacén)



Problema de redes desconectadas: Un diagrama de nivel inferior con dos subconjuntos de DFD’s que no se comunican entre sí � reorganizar los diagramas:

� Construir un diagrama expandido mediante la combinación de todos los hijos.

� Intentar dividir el diagrama expandido en un número manejable de subconjuntos.

� Volver a crear el nivel superior, asignando un círculo a cada conjunto.

� Volver a crear el nivel inferior, cortando la versión expandida por los límites de los conjuntos.

� Renumerar y renombrar cada componente.

Particionamiento desigual: Uno de los procesos en un nivel alto es primitivo y otro necesita ser particionado en tres o cuatro niveles más.

� En lo posible, evitarlo.



Modificaciones de un DFD:

� No resulta difícil si la independencia funcional está bien conseguida.

� Ante la aparición de una nueva funcionalidad:

� Estudiar el nivel de abstracción en el que se encuentra

� Incluirla en el diagrama correspondiente� Asociar las interfaces con el resto de

componentes del DFD




� Ejercicio 11:

Construir el Diagrama de Contexto para el caso del ejercicio 10.



� Ejercicio 12:


Diccionario de Datos (DD)

Un diccionario de datos (DD) es una lista organizada de los datos utilizados por el sistema

que gráficamente están representados por los flujos de datos y almacenes presentes sobre el conjunto

de DFD.

� El DD se crea a la vez que los DFD� Las entradas son realizadas cada vez que se

identifica un elemento. � El DD define:

� Flujos de datos� Almacenes� Datos elementales



Definición de los Flujos de Datos:

Sigue una aproximación "top-down“ (hasta obtener datos elementales).

Ejemplo:Si sabemos que un flujo de datos A está compuesto por uno B y uno C y que B está compuesto de B1, B2 y B3, mientras que el C es siempre C1 y C2, podríamos escribir la definición así:

A = B1 + B2 + B3 + C1 + C2

Es mejor definirlos en función de sus componentes subordinados:

A = B + CB = B1 + B2 + B3C = C1 + C2



Símbolos utilizados para las definiciones

en el DD:

SIMBOLO SIGNIFICADO = Composición : está compuesto de, o es equivalente a + Inclusión: y [ ] Selección: selección una de la opciones encerradas entre corchetes, y separadas por

el símbolo “|” { } Iteración: iteraciones del componente encerrado entre llaves ( ) Opción: significa que el componente encerrado es opcional (puede estar presente o

ausente) * texto * Comentario: el texto entre asteriscos es un comentario aclarativo de una entrada del

DD @ Identificador: se utiliza para señalar un campo o conjunto de campos que

identifican cada ocurrencia de un almacén



Composición e inclusión:� La composición o definición del flujo se

introduce con el símbolo “=”

A = B + C � (flujo de datos múltiple A, compuesto de un flujo B y uno C)

Ejemplos:

PETICIÓN LIBROS = CARNET BIBLIOTECA + FICHA LIBROS

CARNET BIBLIOTECA = NUM. CARNET + APELLIDOS + NOMBRE + TIPO CARNET



Selección:

� La selección de un componente (sea un elemento o un conjunto de elementos) se representa entre corchetes, separando cada opción mediante el símbolo “ | ”.

� Indica una selección entre campos alternativos distintos.

Ejemplo:

SOCIO = NOMBRE + DOMICILIO + [NIF | CIF]



Iteración:� La iteración representa la repetición de los

elementos incluidos entre paréntesis.

Ejemplo:

FICHA LIBROS = { LIBROS }LIBROS = SIGNATURA + TÍTULO + AUTOR

� Es posible representar los límites inferior y superior sobre las ocurrencias de una estructura repetitiva:

FICHA LIBROS = 1{LIBROS}5



Opción:

� El dato opcional indica que puede o no estar presente.

Ejemplo:

CARNET BIBLIOTECA = NUM. CARNET + APELLIDOS + NOMBRE + TIPO CARNET + (NÚMERO TELÉFONO)



Definición de los almacenes:

� Se definen como entidades repetitivas de datos y/o grupos de datos (no es necesario indicar la estructura repetitiva con llaves).

� Se selecciona uno Identificador: uno o más datos para organizar la colección de entradas en un almacén.

Ejemplo:

LIBROS DISPONIBLES = @ SIGNATURA + TITULO + AUTOR + NUMERO UNIDADES * la signatura identifica cada ocurrencia del almacén *



Alias:� Dato que se nombran de distinta forma y que, en realidad,

representan el mismo dato.� Es un sinónimo de una entrada del DD ya sea un flujo de datos o

un elemento de datos.� No es conveniente su utilización.� Motivos para la existencia de alias:

� Distintos usuarios que llaman al mismo elemento de dos maneras diferentes.

� Distintos analistas que trabajan independientemente en el diseño del modelo del mismo sistema, utilicen nombres distintos para el mismo concepto.

� Los alias se documentan en el DD, aunque aumentemos la redundancia.

Ejemplo:

PETICIÓN LIBRO = CARNET BIBLIOTECA + FICHA LIBROS PETICIÓN LIBRO = PETICIÓN DE PRESTAMO



� Ejercicio 13: Construir el DD para el Sistema de Gestión de Préstamos de Libros (Ejer. 12)


Especificaciones de Procesos (EP)

La especificación de procesos (o también denominada miniespecificación) es una técnica que define el procedimiento que realiza un proceso primitivo.

� Describe cómo se obtienen los flujos de datos de salida a partir de los flujos de datos de entrada, más una información local al proceso.

� Alternativas para describir este procedimiento son las siguientes:� Lenguaje estructurado� Árboles de decisión� Tablas de decisión� Precondiciones y poscondiciones


Especificaciones de Procesos (EP): Lenguaje Estructurado

� Es un lenguaje formado por un subconjunto de palabras (del idioma elegido, español, inglés, etc.):

� Las utilizadas para formar las construcciones propias de la programación estructurada.

� Un conjunto de verbos que reflejan acciones simples: LEER, ESCRIBIR, BORRAR, ENCONTRAR, CALCULAR, VALIDAR, etc.

Alternativa

SI condición bloque SI NO

bloque

F FIN SI Repetitiva

MIENTRAS condición

bloque FIN MIENTRAS

REPETIR bloque HASTA condición

Secuencia Está formada por un conjunto de sentencias (bloque) donde cada una puede ser o una acción sencilla o una estructura de las anteriores.


Especificaciones de Procesos (EP): Árboles de Decisión

Es una representación en forma de árbol que representa:� Los valores de las variables� Las acciones tomadas para cada valor� El orden en que se realiza la decisión

Se suele utilizar cuando el número de condiciones no es muy grande.

Ejemplo:Supongamos la política de descuentos que realiza una empresa sobre los pedidos de sus clientes dependiendo del volumen de compras del año anterior. Si estos son clientes con más de 5 años de antigüedad se le aplica un descuento del 25% si el valor de los pedidos anuales es superior a 50.000 €. Si el montante de los pedidos está entre los valores 50.000 € y 30.000 €el descuento efectuado será del 15% y si no se alcanza la cifra de 30.000 €se aplicará el 10%. Para clientes entre 5 y 3 años de antigüedad se aplicará el 11% para compras por valor superior a 40.000 € y el 5% por valor igual o inferior. Si tienen menos años de antigüedad se aplicará el 9% si el valor de compras es superior a 40.000 €. A los clientes clasificados como especiales se le aplicará un descuento de 25% si el volumen de compras supera los 50.000 € siendo del 20% en caso contrario.


Especificaciones de Procesos (EP): Árboles de Decisión

CLIENTEESPECIAL

Sí

No

VOLUMENDE COMPRAS

> 50.000€

<= 50.000€

Aplicar 25% descuento


AÑOS ANTIGÜEDAD

> 5

<= 5 y >= 3

< 3

VOLUMEN DE COMPRAS

> 50.000€

<= 50.000€ y >= 30.000€

< 30.000€

> 40.000€

<= 40.000€

> 40.000€

<= 40.000€


Aplicar 15 % descuento

Aplicar 10 % descuento




Sin descuento


Especificaciones de Procesos (EP): Tablas de Decisión

Es un modelo alternativo que muestra la función en forma tabular o matricial.

Definir:� La parte de condición (un conjunto de

condiciones y entradas de condiciones)� La parte de acción (un conjunto de acciones y

entradas de acciones)


Especificaciones de Procesos (EP): Tablas de Decisión

Ejemplo:CONDICIONES Cliente especial Vol. compras > 50.000 € Vol. compras <= 50.000 € 50.000 € >= Vol. compras >= 30.000 € Vol. compras < 30.000 € Vol. compras > 40.000 € Vol. compras <= 40.000 € Años ant. > 5 5 >= Años ant. >= 3 Años ant. < 3

SÍ SÍ - - - - - - - -

SÍ -

SÍ - - - - - - -

NO SÍ - - - - -

SÍ - -

NO -

NO SÍ - - -

SÍ - -

NO - - -

SÍ - -

SÍ - -

NO - - - -

SÍ - -

SÍ -

NO - - - - -

SÍ -

SÍ -

NO - - - -

SÍ - - -

SÍ

NO - - - - -

SÍ - -

SÍ

ACCIONES Aplicar 25 % descuento. Aplicar 20% descuento. Aplicar 15% descuento. Aplicar 11% descuento. Aplicar 10% descuento. Aplicar 9% descuento. Aplicar 5% descuento. Sin descuento.

X

X

X

X

X

X

X

X

X


Especificaciones de Procesos (EP): Precondiciones y poscondiciones

� Se centra en la relación entre las entradas y las salidas (no el algoritmo)

� Sólo se indican:� Precondiciones: las condiciones que se tienen que

cumplir para que el proceso pueda comenzar.� Postcondiciones: las condiciones que deben cumplirse

cuando el proceso ha concluido.

Existen, además, otras técnicas que se utilizan para especificar los procesos como, por ejemplo, el lenguaje narrativo, los diagramas de flujo, etc.


Especificaciones de Procesos (EP)

� Ejercicio 14: Realizar las EP’s para los procesos primitivos del Sistema de Gestión de Préstamos de Libros.


Diseño Estructurado


Diseño Estructurado

� Objetivo:

Desarrollar la estructura de programas, así como las relaciones entre los elementos (módulos) que componen esta estructura.


Diagrama de Estructuras� Elementos Principales:

LEERPETICION

PRESTAMO

GESTIONARPETICIONES

PET_ACEPTADAINFORME

PRESTAMOPET_ACEPTADA

INFORMARPETICION

TRATARPETICION

CONSULTARSTOCK

PET_PRESTAMOPET_RECHAZADA

RECHAZARPETICION

INFORMEPRESTAMO

Módulos

Conexiones entre módulos

Comunicación entre módulos

(estructuras de datos o de control “flags”)

Módulos “predefinidos”


Diagrama de Estructuras: Módulos� Arquitectura implica modularidad. � El software debe dividirse en elementos (módulos)

que se integran entre sí para, con su ejecución, satisfacer los requisitos del sistema.

� Módulo: una unidad claramente definida y manejable, con interfaces modulares perfectamente definidas.

� La modularidad mejora la calidad del diseño:� Facilitando la implementación, depuración, pruebas,

documentación y mantenimiento de un producto software.


Diagrama de Estructuras: Módulos� Un modulo se entiende como la unidad más pequeña de

código que puede ser compilada independientemente.

� Otras definiciones:� Según la IEEE [IEEE, 1990], un módulo es (1) una parte lógica

separable de un programa; (2) una unidad de programa discreta e identificable respecto de la compilación, combinación con otras unidades y la carga de memoria.

� Según Yourdon [YOURDON y CONSTANTINE, 1979], un módulo es una secuencia contigua de sentencias de programa, limitada por delimitadores y que tiene un identificador global.

� Según Fenton [FENTON, 1991], un módulo puede ser cualquier objeto que, en un nivel de abstracción dado, queramos considerar como un concepto simple.

� En la teoría del diseño estructurado [PAGE-JONES, 1988], un módulo es aquella parte de código que se puede llamar.


Diagrama de Estructuras: Módulos

� Un modulo es un conjunto de sentencias que realizan una actividad. � Puede tener aproximadamente entre

unas 40 o 50 líneas de código.

� Es posible dividir el software indefinidamente� Esfuerzo requerido para cada módulo �� Esfuerzo requerido para las interfaces entre

módulos �


Diagrama de Estructuras: Módulos

Esfuerzo requerido para desarrollar módulos

Nº Módulos

Coste o Coste deinterfaz

Coste pormódulo

Coste Totaldel Software

Región de costemínimo

Esfuerzo

¿Qué elegiríamos un módulo con 1000 líneas o

1000 módulos de 1 línea?

Nº Módulos

Coste o Coste deinterfaz

Coste pormódulo

Coste Totaldel Software

Región de costemínimo

Esfuerzo

20 Módulos de 50

líneas cada uno


Diagrama de Estructuras: Conexión entre módulos

� Un sistema está compuesto por módulos organizados jerárquicamente, cooperando y comunicándose entre sí para realizar una tarea.

� La llamada de un módulo se representa con una flecha


Diagrama de Estructuras: Conexión entre módulos

� Un Diagrama de Estructuras no es un Diagrama de Flujo.

A

B

C

El orden de llamadas en un

Diagrama de Estructuras es

de arriba hacia abajo y de

izquierda a derecha.


Diagrama de Estructuras: Comunicación entre módulos

� La comunicación en un diagrama de estructuras se realiza a través de los datos y los flags.

� Diferencias entre datos y flags:

sólo importan para la comunicación de información.

Comunican condiciones entre módulos

Flags

están relacionados con el problema y son importantes para el mundo exterior

Se procesanDatos

Representación ImportanciaFinalidad


Diseño estructurado: Estrategias de Diseño

Estrategias que sirven para una creación rápida de un buen diseño a partir de un DFD.

� Análisis de Transformación� Análisis de Transacción

� El diseño estructurado permite una transición de las representaciones de la información (DFD) a una descripción de diseño de la estructura de programas.

� Variación en los pasos a seguir en función del tipo de flujo de información que se trate



Flujo de Transformación

FLUJO DESALIDA

FLUJO DELLEGADA

FLUJO DETRANSFORMACIÓN

1.1

2.1

1.2

2.2

3

4.1

4.2

DFD con características de Transformación

Caminos de datos que entran en el

Sistema

Caminos de datos de salida

Sistema

Ocurre una transformación

de los datos



Flujo de Transacción

1

2.1

4.1

3.1

2.2

3.2

4.2

CENTRO DETRANSACCIÓN

Camino de acción 3

Camino de acción 2

Camino de acción 1

DFD con características de

Transacción Un dato determina

caminos alternativos por los que puede transitar el flujo de información

Caminos Alternativos y

exclusivos


exclusivos


exclusivos



Pasos del análisis de transformación/transacción:1. Revisión del modelo fundamental del sistema2. Determinar si el DFD tiene características de transformación

o de transacción3. En el caso de análisis de transformación, aislar el centro de

transformación, especificando los límites del flujo de llegada y de salida

4. En el caso de análisis de transacción, identificar el centro de transacción y las características del flujo de cada camino de acción

5. Realizar el primer corte del diagrama de estructuras6. Ejecución del segundo nivel de factorización7. Refinar la estructura del sistema utilizando medidas y guías

de diseño8. Asegurarse del trabajo realizado por el diseño obtenido



1. Revisión del modelo fundamental del sistema:

� Habrá que tener DFD’s.� Para aplicar diseño estructurado del sistema es

necesario que el análisis de dicho sistema se haya realizado aplicando análisis estructurado.

� Para aplicar el diseño estructurado con suficiente detalles se han de tener como mínimo 3 niveles de profundidad.



2. Determinar si el DFD tiene características de transformación o de transacción:

� Elegir para el análisis de trasformación sólo aquellos DFD’s con claras caraterísiticas de tipo transformación.

� Seleccionar la característica global del flujo basándose en la naturaleza que prevalece en el DFD.

� Si existe un proceso que tienes salidas exclusivas entre sí, probablemente estemos ante un problema de transacción.



3. En el caso de análisis de transformación, aislar el centro de transformación, especificando los límites del flujo de llegada y de salida:

� El centro de transformación es la parte del DFD que contiene las funciones esenciales del sistema.

� Los límites del flujo de llegada y de salida están abiertos a interpretación (dependen del diseñador).

� Pueden derivarse soluciones de diseño alternativas.



4. En el caso de análisis de transacción, identificar el centro de transacción y las características del flujo de cada camino de acción:

� Puede descubrirse inmediatamente en un DFD. � Está ligado al origen de varios caminos de información que

fluyen radialmente de él. � Normalmente el proceso del DFD que corresponde a la

transacción no se refleja en dicho DFD (reflejan procesos de control)

� Es preciso conocer bien el sistema para darse cuenta que tenemos entradas al sistema que son exclusivas entre sí y que se corresponden con cada una de las entradas a los caminos de acción.

� El camino de llegada y los caminos de acción deben aislarse también.



5. Realizar el primer corte del diagrama de estructuras:

� Análisis de Transformación: � La aplicación del análisis de transformación da como

resultado una estructura del sistema en la que:� Módulos de nivel superior: toman decisiones de

ejecución � Módulos del nivel inferior: ejecutan la mayoría del

trabajo de entrada, de cálculo y de salida. � Módulos de nivel intermedio: ejecutan algún

control y realizan moderadas cantidades de trabajo.




� Análisis de Transformación:

Entrada Salida Transformación

Cm

Ce Ct Cs

1.1

2.1

1.2

2.2

3

4.1

4.2



� Cm: Módulo principalCoordina los módulos colocados en el primer nivel:

� Ce: Módulo controlador del procesamiento de la información de llegada al sistema

� Coordina la recepción de todos los datos que llegan� Ct: Módulo controlador del centro de transformación

� Supervisa todas las operaciones sobre los datos� Cs: Módulo controlador del procesamiento de la

información de salida al sistema � Coordina la producción de la información de salida




� Análisis de Transacción: � Hay que convertir un flujo de transacción en una

estructura con una bifurcación de entrada y otra de salida.

� Entrada: Igual que el análisis de transformación. � Salida: Se añade un módulo controlador por cada

camino de flujo de acción.


Diseño estructurado: Estrategias de Diseño5. Realizar el primer corte del diagrama de

estructuras:

� Análisis de Transacción:

Camino 3

Cm

Ce D

C1 C2 C3

A

D

R

P

Q

Camino 1Camino 2

a

z

b

Centro de Transacción Centro de

Transacción

Refleja la exclusividad de los diferentes caminos



6. Ejecución del segundo nivel de factorización:

� Análisis de Transformación: � Se realiza mediante la conversión de las

transformaciones individuales de un DFD (procesos) en módulos correspondientes del diagrama de estructura.

� Se empieza en el límite del centro de transformación. � Yendo hacia fuera a lo largo de los caminos de llegada

y salida, los procesos del DFD, se convierten en módulos subordinados de la estructura del sistema.

� Además se introducen módulos predefinidos que nos den las entradas y/o salidas que necesita y/o genera el sistema.



6. Ejecución del segundo nivel de factorización:

� Análisis de Transformación:

Entrada Salida

Transformación

Cm

Ce Ct Cs

1.1

2.1

1.2

2.2

3

4.1

4.2

1.2 2.2

2.11.1

3 4.1

4.2

escribir zleer a leer b

a

b z


Diseño estructurado: Estrategias de Diseño6. Ejecución del segundo nivel de factorización:

� Análisis de Transacción: � Se desarrolla cada camino de acción dependiendo de su tipo de

flujo.

A

D

R

P

Q

Camino 1

Camino 3

Camino 2

Cm

Ce D

C1 C2 C3

P Q R

A

a

Leeraz

b

Leerb Escribirz

Flujo de transformación



7. Refinar la estructura del sistema utilizando medidas y guías de diseño:

� Se puede aumentar o disminuir el número de módulos para producir una factorización lógica.

� De buena calidad.� Con una estructura que se implemente sin dificultad.� Que la estructura se pruebe sin confusión. � Que la estructura se mantenga sin problemas.

� ¿Cómo hacemos los refinamientos?� Teniendo en cuenta consideraciones prácticas y de

sentido común y por los requisitos del software.




� Ejemplo de un refinamiento

Entrada Salida

Transformación

Cm

Ce Ct Cs

1.1

2.1

1.2

2.2

3

4.1

4.2

1.2 2.2

2.11.1

3 4.1

4.2

escribir zleer a leer b

a

b z




� Representar los parámetros que cada módulo necesita para poder ejecutarse (datos y/o flags).

� Se obtienen del DFD realizado en la fase de análisis. � Datos:

� Se corresponden con los flujos de información de los DFD’s.� Se han de reflejar como datos que se pasan entre módulos.

� Flags: � Se obtienen de las descripciones de los procesos del DFD. � Se refleja en el módulo correspondiente del diagrama de

estructura cuando se necesita una variable de control.




� Cuando un proceso del DFD acceda a un almacén (lectura/escritura):

� En el módulo correspondiente del diagrama de estructura se colgará un módulo predefinido que corresponda a la lectura/escritura.

� Se busca que el acceso a la Base de Datos de algunos módulos se refleje en el diagrama de estructura, facilitando la programación.



8. Asegurarse del trabajo realizado por el diseño obtenido:

� Comprobar que la funcionalidad que realiza el diseño creado es la correcta

� Por ejemplo: Revisando que el orden de ejecución de los módulos sea el correcto.



� Ejemplo de análisis de transformación:

ALMACÉN

PROVEEDOR

0GESTIONAR

CENTRAL DECOMPRAS

ALMACÉN

PROVEEDOR

DOCUMENTOSALMACEN

CATALOGO

PEDIDO GLOBAL

NOTIFICACIÓNPEDIDO

1

SELECCIONARMEJORESOFERTAS

CATALOGO

MEJORES OFERTAS

2HACER

PEDIDOSSEGUN

OFERTAS

DOCUMENTOSALMACEN

PEDIDO GLOBAL

NOTIFICACIÓNPEDIDO


Diseño estructurado: Estrategias de Diseño� Ejemplo de análisis de transformación:

2.1RECIBIR

HISTORICOVENTAS

HISTORICOVENTAS

HISTORICO

HISTORICOVENTASRECIBIDO

2.2RECIBIRPEDIDOS

RELLENADOS

PEDIDORELLENADO

PEDIDOS

PEDIDORELLENADORECIBIDO

1.1RECIBIR

CATALOGO

CATALOGO CATALOGOS

CATALOGORECIBIDO

2.3AJUSTARPEDIDOS

ALMACEN

HISTORICOVENTASRECIBIDO

PEDIDORELLENADORECIBIDO

1.2CALCULARMEJORESOFERTAS

CATALOGORECIBIDO

2.4HACERPEDIDOGLOBAL

MEJORESOFERTAS

PEDIDOSCORREGIDOS

CORREGIDO

CORREGIDO

MEJOROFERTA

MEJOROFERTA

PEDIDOGLOBAL

NOTIFICACIONPEDIDO



GestiónCentral

Compras

RecibirDocumenta-

ciónAlmacen

RecibirHistóricoVentas

RecibirPedidos

Rellenados

LeerHistóricoVentas

LeerPedidos

Rellenados

RecibirCatálogo

LeerCatálogo

AjustarPedidosAlmacén

CalcularMejoresOfertas

HacerPedidoGlobal

ImprimirNotificación

Pedido

ImprimirPedidoGlobal

H_V P_R

H_V_RP_R_R Catálogo

P_R_RH_V_R

C_RP_R_R

H_V_R C_R

Corre-gido M_O

M_OCorregido

NotificaciónPedido

PedidoGlobal

H_V = Historico_VentasH_V_R = Histórico_Ventas_RecibidoP_R = Pedido_RellenadoP_R_R = Pedido_Rellenado_RecibidoC_R = Catálogo RecibidoM_O = Mejores_Ofertas



GestiónCentral

Compras

RecibirDocumenta-

ciónAlmacen

RecibirHistóricoVentas

RecibirPedidos

Rellenados

LeerP_R

RecibirCatálogo

AjustarPedidosAlmacen

CalcularMejoresOfertas

HacerPedidoGlobal

ImprN_P

ImprP_G

H_V P_R

Cat

M_O

N_PP_G

LeerH_V

LeerCat

EscH

H_V_R

EscP

P_R_R

EscCat

C_R

LeerH

LeerCat

EscPCo

H_V_RP_R_R

Cgdo

LeerCat

E/LMO

C_R

M_O

LeerPCo

Cgdo

H_V = Historico_VentasH_V_R = Histórico_Ventas_RecibidoP_R = Pedido_RellenadoP_R_R = Pedido_Rellenado_RecibidoC_R = Catálogo RecibidoM_O = Mejores_Ofertas



� Ejemplo de análisis de transacción:

USUARIO USUARIOGESTIONARPISCINA

0

SELEC.TIPO

CARNET1

TRATARESTUDIANTE

2

TRATARTRABAJADOR

3

Carnet

Carnet

Carnet

Carnet

Entrada

Entrada

Entrada

Estudiante

Trabajador


Diseño estructurado: Estrategias de Diseño� Ejemplo de análisis de transacción:

SELEC.TIPO

CARNET1

COMPROBARCARNET

ESTUDIANTE2.1

Carnet

C-Est

C-Trab

EntradaTrabajador

COMPROBARCARNET

TRABAJADOR3.1

NUMERARTALON

ESTUDIANTE2.2

C-EstValid

NUMERARTALON

TRABAJADOR3.2

C-TrabValid

PREPARARENTRADA

ESTUDIANTE2.3

PREPARARENTRADA

TRABAJADOR3.3

EntradaEstudiante

Entrada

Entrada



Carnet

C-Trab

Carnet

C-Est

GESTIONARTIPO ENTRADA

GESTIONARPISCINA

LEER CARNET

GESTIONARESTUDIANTE

GESTIONARTRABAJADOR



GESTIONARESTUDIANTE

GESTIONARESTUDIANTE

COMPROBARCARNET

ESTUDIANTE

NUMERARTALON

ESTUDIANTEENTREGARENTRADA

IMPRIMIRENTRADA

Carnet_EstudianteEntrada_Estudiante

Entrada

EntradaEstudianteCarnet

Validado



GESTIONARESTUDIANTE

GESTIONARESTUDIANTE

COMPROBARCARNET

ESTUDIANTE

NUMERARTALON

ESTUDIANTEENTREGARENTRADA

IMPRIMIRENTRADA

Carnet_Estudiante

Entrada_Estudiante

Entrada

EntradaEstudiante

CarnetValidado

LEERCarnet Est


Otros elementos del Diagrama de Estructuras



� Ejercicio 15: Realizar el diagrama de estructura para el ejercicio del Sistema de Gestión de Préstamos de Libros.

Sistemas de Información

Tema 5: Análisis y Diseño de los Sistemas de Información

tema 5: análisis y diseño de los sistemas de …si-2010... · 17/03/2011 sistemas de información...

Documents