Upload
hangoc
View
221
Download
0
Embed Size (px)
Citation preview
15/04/2010 1 15/04/2010 Sistemas de Información 1
Sistemas de Información
Tema 5: Análisis y Diseño de los Sistemas de Información
15/04/2010 2 15/04/2010 Sistemas de Información 2
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.
15/04/2010 3 15/04/2010 Sistemas de Información 3
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)
15/04/2010 4 15/04/2010 Sistemas de Información 4
Introducción
ERS
Modelo lógico de datos Arquitectura de procesos
Modelo físico de datos Estructura detallada:
programas y módulos
Enfoque de datos Enfoque funcional
DFD E-R
Esquema de BD y ficheros
Cuadernos de carga
Codificación/Programación
Análisis (Qué) Lenguaje comprensible para el usuario/cliente
Diseño de alto nivel (arquitectónico)
Diseño de bajo nivel (detallado)
Implementación Lenguaje comprensible por la máquina
Diseño (Cómo)
Decisiones generales y abstractas (organiza- ción lógica)
Decisiones concretas y específicas (optimiza- ción y rendimiento)
15/04/2010 6 15/04/2010 Sistemas de Información 6
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
15/04/2010 7 15/04/2010 Sistemas de Información 7
Diagrama de Flujos de Datos (DFD)
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
15/04/2010 8 15/04/2010 Sistemas de Información 8
Diagrama de Flujos de Datos (DFD)
Notaciones de un DFD
Yourdon, DeMarco Gane y Sarson
Flujos de datos
Procesos
Almacenes de
datos
Entidades
externas
SSADM
MÉTRICA
15/04/2010 9 15/04/2010 Sistemas de Información 9
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
15/04/2010 10 15/04/2010 Sistemas de Información 10
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
15/04/2010 11 15/04/2010 Sistemas de Información 11
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.
15/04/2010 12 15/04/2010 Sistemas de Información 12
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)
15/04/2010 13 15/04/2010 Sistemas de Información 13
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.
15/04/2010 14 15/04/2010 Sistemas de Información 14
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.
DEPARTAMENTO COMPRAS
CLIENTE
*
Representación de una entidad externa de
cardinalidad simple y repetida en un DFD
Representación opcional de entidades
externas de cardinalidad N
15/04/2010 15 15/04/2010 Sistemas de Información 15
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
15/04/2010 16 15/04/2010 Sistemas de Información 16
Diagrama de Flujos de Datos (DFD): Flujos de Datos
Conexiones permitidas:
Destino
Fuente
Proceso Almacén Entidad Externa
Proceso Si Si Si
Almacén Si No No*
Entidad Externa
Si No* No
15/04/2010 17 15/04/2010 Sistemas de Información 17
Diagrama de Flujos de Datos (DFD): Flujos de Datos
Formas de Paso de Datos entre procesos:
ALMACEN TEMPORAL
PROCESO
A
PROCESO
A
PROCESO
B
PROCESO
B
Paso síncrono de información
entre procesos
Paso asíncrono de información
entre procesos
15/04/2010 18 15/04/2010 Sistemas de Información 18
Diagrama de Flujos de Datos (DFD): Flujos de Datos
Conexiones entre procesos y Almacenes:
FLUJO DE
CONSULTA
FLUJO DE
ACTUALIZACION
FLUJO DE
DIALOGO
15/04/2010 19 15/04/2010 Sistemas de Información 19
Diagrama de Flujos de Datos (DFD): Flujos de Datos
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 a
Cliente
CLIENTES
Par dialogo
15/04/2010 20 15/04/2010 Sistemas de Información 20
Diagrama de Flujos de Datos (DFD): Flujos de Datos
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
15/04/2010 21 15/04/2010 Sistemas de Información 21
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
Diagrama de Flujos de Datos (DFD): Flujos de Datos
15/04/2010 22 15/04/2010 Sistemas de Información 22
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.
Diagrama de Flujos de Datos (DFD)
15/04/2010 23 15/04/2010 Sistemas de Información 23
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.
Diagrama de Flujos de Datos (DFD)
GESTIONSISTEMA
X
DIAGRAMA DE CONTEXTO
E1
E2
E3
A
B
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
B1.2.1 1.2.2
1.2.3
DIAGRAMA 1.2:
15/04/2010 24 15/04/2010 Sistemas de Información 24
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 Flujos de Datos (DFD)
15/04/2010 25 15/04/2010 Sistemas de Información 25
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 Flujos de Datos (DFD)
15/04/2010 26 15/04/2010 Sistemas de Información 26
Diagrama de Flujos de Datos (DFD)
Ejercicio:
Construir el Diagrama de Contexto para el Caso de Estudio 1, descrito en el Ejercicio de Análisis 9.
Caso de Estudio 1: Sistema de Matriculación
Un estudiante envía un formulario de solicitud relleno donde figuran sus datos personales y el curso en el que desea matricularse. La Universidad debe cotejar esa petición con la lista de cursos para saber si el curso está disponible aún. En caso afirmativo, el alumno es matriculado en el curso, hecho que le es comunicado mediante una carta de confirmación. En caso contrario también es informado mediante la correspondiente carta de denegación.
15/04/2010 Sistemas de InformaciónSistemas de Información
27
15/04/2010 28 28
Diagrama de Flujos de Datos (DFD): ejercicio
Diagrama de Contexto para el Sistema de Matriculación
SISTEMA
DE
MATRICULACIÓN
ESTUDIANTE
Formulario
de
Matrícula
Carta
de
Aceptación
Carta
de
Denegación
15/04/2010 29 15/04/2010 Sistemas de Información 29
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.
Diagrama de Flujos de Datos (DFD)
15/04/2010 30 15/04/2010 Sistemas de Información 30
Diagrama de Flujos de Datos (DFD)
Ejercicio:
Construir el Diagrama de Sistema ó Nivel 0 para el Sistema de Matriculación.
15/04/2010 31 31
Diagrama de Flujos de Datos (DFD): ejercicio
Diagrama de Sistema para el sistema de Matriculación
ESTUDIANTE
Formulario
de
Matrícula
Carta
de
AceptaciónNOTIFICACIÓN
3
MATRICULACIÓN
2
COMPROBAR
DISPONIBILIDAD
CURSO
1
Formulario de Matrícula /
Detalles del Curso
Detalles
de
Matrícula
15/04/2010 32 15/04/2010 Sistemas de Información 32
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.
Diagrama de Flujos de Datos (DFD)
15/04/2010 33 15/04/2010 Sistemas de Información 33
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).
Diagrama de Flujos de Datos (DFD)
15/04/2010 34
Consistencia entre niveles (Balanceo)
Diagrama de Flujos de Datos (DFD): regla del balanceo
¿? A y D
¿? x - c – Q - P
Rec
uper
ada
de:
Jus
t E
noug
h S
truc
ture
d A
naly
sis
(You
rdon
)
15/04/2010 Sistemas de Información 34
15/04/2010 35 15/04/2010 Sistemas de Información 35
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)
Diagrama de Flujos de Datos (DFD)
15/04/2010 36 15/04/2010 Sistemas de Información 36
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.
Diagrama de Flujos de Datos (DFD)
15/04/2010 37 15/04/2010 Sistemas de Información 37
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
Diagrama de Flujos de Datos (DFD)
15/04/2010 38 15/04/2010 Sistemas de Información 38
Diagrama de Flujos de Datos (DFD)
Ejercicio 12:
Construir el Diagrama de Nivel 2 para el sistema de Matriculación, centrándose en el proceso 1 (Comprobar disponibilidad curso)
15/04/2010 39 39
Diagrama de Flujos de Datos (DFD): ejercicio
Ejercicio:
ESTUDIANTEPROCESAR
FORMULARIO
1.1
Formulario
de
Matrícula
COTEJAR
DATOS CON
CURSOS
1.2
MATRICULACIÓN
2
Estado de Cursos
Detalle de Cursos
LISTADO
CURSOS
Detalle de Cursos
Formulario de Matrícula y
Detalle de Cursos
15/04/2010 40 15/04/2010 Sistemas de Información 40
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
15/04/2010 41 15/04/2010 Sistemas de Información 41
Diccionario de Datos (DD)
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 + C
B = B1 + B2 + B3
C = C1 + C2
15/04/2010 42 15/04/2010 Sistemas de Información 42
Diccionario de Datos (DD)
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
15/04/2010 43 15/04/2010 Sistemas de Información 43
Diccionario de Datos (DD)
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
15/04/2010 44 15/04/2010 Sistemas de Información 44
Diccionario de Datos (DD)
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]
15/04/2010 45 15/04/2010 Sistemas de Información 45
Diccionario de Datos (DD)
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
15/04/2010 46 15/04/2010 Sistemas de Información 46
Diccionario de Datos (DD)
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)
15/04/2010 47 15/04/2010 Sistemas de Información 47
Diccionario de Datos (DD)
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 *
15/04/2010 48 15/04/2010 Sistemas de Información 48
Diccionario de Datos (DD)
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
15/04/2010 49 15/04/2010 Sistemas de Información 49
Diccionario de Datos (DD)
Ejercicio: Construir el DD para el Sistema de Matriculación
15/04/2010 50
Diccionario de Datos Ejercicio
Formulario_matrícula =
Datos_Alumno + Datos_cursos Datos_Alumno = Nombre + Apellidos +
Dirección + Teléfono + [DNI | NIE | Pasaporte]
Dirección = Tipo_vía + Nombre_vía + Nº_portal + (Nº_piso) + Nº_escalera) + (Nº_puerta) + Código_postal + Ciudad Tipo_vía = [Av|Calle|Paseo|Plaza|Travesia]
Datos_cursos = {Curso}
Curso = Nombre_Asignatura + Código_asignatura + Horario + Año_Académico + Disponibilidad Listado_Cursos = @Codigo_Asignatura +
Nombre_Asignatura + Horario + Grupo + Nº_plazas
15/04/2010 51 15/04/2010 Sistemas de Información 51
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
15/04/2010 52 15/04/2010 Sistemas de Información 52
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.
15/04/2010 53 15/04/2010 Sistemas de Información 53
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.
15/04/2010 54 15/04/2010 Sistemas de Información 54
Especificaciones de Procesos (EP): Árboles de Decisión
CLIENTE
ESPECIAL
Sí
No
VOLUMEN
DE COMPRAS
> 50.000€
<= 50.000€
Aplicar 25% descuento
Aplicar 20% 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 25% descuento
Aplicar 15 % descuento
Aplicar 10 % descuento
Aplicar 11% descuento
Aplicar 5% descuento
Aplicar 9% descuento
Sin descuento
15/04/2010 55 15/04/2010 Sistemas de Información 55
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)
15/04/2010 56 15/04/2010 Sistemas de Información 56
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
15/04/2010 57 15/04/2010 Sistemas de Información 57
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.
15/04/2010 58 15/04/2010 Sistemas de Información 58
Especificaciones de Procesos (EP)
Ejercicio: Realizar las EP’s para el Caso de Estudio 2 del Ejercicio de Análisis 9
15/04/2010 59
Especificación de Procesos: ejemplo
Diagrama de Contexto
GENERADOR
de
TRANSACCIONES
PERSONAL Registro
transacción
Datos
EmpleadoDATOS
EMPLEADOS
Datos
Erróneos
Sistemas de Información
15/04/2010 60
Especificación de Procesos: ejemplo
Diagrama de Sistema (Nivel 1)
LEER DATOS
EMPLEADO
1
VALIDAR
DATOS
2
CONSTRUIR
REGISTRO
de
TRANSACCIÓN
3GRABAR
REGISTRO
de
TRANSACCIÓN
4
Datos
EmpleadoDatos
Empleado
Datos
Erróneos
Datos
Válidos
Registro
Transacción
Registro
transacciónDATOS
EMPLEADOS
Sistemas de Información
15/04/2010 61
Especificación de Procesos: ejemplo
Proceso 1: Leer Datos Empleado Botón = “Visualizar datos personales()” // DNI, nombre , apellidos, estado civil, dirección IF boton = cancelar borrar_info_pantalla() ir a proceso 1 ELSE leer_datos_pantalla()
boton = visualizar_datos_economicos() // sueldo, trienio, complementos, etc. IF boton = cancelar borrar_info_pantalla()
ir a proceso 1 ELSE
leer_datos_pantalla() boton = visualizar_datos_academicos() // titulacion, cursos reealizados, etc. IF boton =cancelar borrar_info_pantalla() ir a proceso 1 ELSE leer_datos_pantalla() ir a proceso_2 ENDIF ENDIF ENDIF
END Proceso
Especificación del proceso 1:
Leer Datos Empleado
Sistemas de Información
15/04/2010 62
Especificación de Procesos: ejemplo
Proceso 2: Validar Datos // El proceso 1 realiza una validación sintáctica de los datos (p.e: edad valor numérico), // mientras que el proceso 2 realiza una validación semántica ComprobarDatosPersonales() // comprobar dirección en Madrid, prefijo = 91 Comprobar DatosEconomicos() // no puede poner una gratificación por destino en el extranjero si está // destinado en el país de origen ComprobarDatosAcademicos() // no puede poner una titulación académica que no exista IF error_validacion visualizar_datos_erroneos() ELSE ir al proceso 3 ENDIF
END Proceso 2
Especificación del proceso 2: Validar Datos
Sistemas de Información
15/04/2010 63
Especificación de Procesos: ejemplo
Proceso 3: Construir Registro Transacción CrearTransaccion() // poner indicativo, transformar literales en códigos, ajustar longitudes de campos // quitar blancos, etc. Ir al proceso 4
END Proceso 3
Especificación del proceso 3: Construir Registro Transacción
Proceso 4: Grabar Registro Transacción GrabarRegistro (fichero, movimientos) // Insertar el registro en el fichero de movimientos // ordenado por indicativo y orden de llegada
END Proceso 4
Especificación del proceso 4: Grabar Registro Transacción
Sistemas de Información
15/04/2010 65 15/04/2010 Sistemas de Información 65
Diseño Estructurado
Objetivo:
Desarrollar la estructura de programas, así como las relaciones entre los elementos (módulos) que componen esta estructura.
15/04/2010 66 15/04/2010 Sistemas de Información 66
Diagrama de Estructuras
Elementos Principales:
LEER
PETICION
PRESTAMO
GESTIONAR
PETICIONES
PET_ACEPTADA
INFORME
PRESTAMO
PET_ACEPTADA
INFORMAR
PETICION
TRATAR
PETICION
CONSULTAR
STOCK
PET_PRESTAMO PET_RECHAZADA
RECHAZAR
PETICION
INFORME
PRESTAMO
Módulos
Conexiones entre módulos
Comunicación entre módulos
(estructuras de datos o de control “flags”)
Módulos “predefinidos”
15/04/2010 67 15/04/2010 Sistemas de Información 67
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.
15/04/2010 68 15/04/2010 Sistemas de Información 68
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.
15/04/2010 69 15/04/2010 Sistemas de Información 69
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
15/04/2010 70 15/04/2010 Sistemas de Información 70
Diagrama de Estructuras: Módulos
Esfuerzo requerido para desarrollar módulos
Nº Módulos
Coste o Coste de interfaz
Coste por módulo
Coste Total del Software
Región de coste mí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 de interfaz
Coste por módulo
Coste Total del Software
Región de coste mínimo
Esfuerzo
20 Módulos
de 50 líneas
cada uno
15/04/2010 71 15/04/2010 Sistemas de Información 71
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
15/04/2010 72 15/04/2010 Sistemas de Información 72
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.
15/04/2010 73 15/04/2010 Sistemas de Información 73
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:
Finalidad Importancia Representación
Datos Se procesan están relacionados con
el problema y son importantes para el mundo exterior
Flags Comunican condiciones entre módulos
sólo importan para la comunicación de información.
15/04/2010 74 15/04/2010 Sistemas de Información 74
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
15/04/2010 75 15/04/2010 Sistemas de Información 75
Diseño estructurado: Estrategias de
Diseño
Flujo de Transformación
FLUJO DE
SALIDA
FLUJO DE
LLEGADA
FLUJO DE
TRANSFORMACIÓ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
15/04/2010 76 15/04/2010 Sistemas de Información 76
Diseño estructurado: Estrategias de
Diseño
Flujo de Transacción
1
2.1
4.1
3.1
2.2
3.2
4.2
CENTRO DE
TRANSACCIÓ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
Caminos Alternativos y
exclusivos
Caminos Alternativos y
exclusivos
15/04/2010 77 15/04/2010 Sistemas de Información 77
Diseño estructurado: Estrategias de
Diseño
Pasos del análisis de transformación/transacción:
1. Revisión del modelo fundamental del sistema
2. Determinar si el DFD tiene características de transformación o 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
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 estructuras
6. Ejecución del segundo nivel de factorización
7. Refinar la estructura del sistema utilizando medidas y guías de diseño
8. Asegurarse del trabajo realizado por el diseño obtenido
15/04/2010 78 15/04/2010 Sistemas de Información 78
Diseño estructurado: Estrategias de
Diseño
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.
15/04/2010 79 15/04/2010 Sistemas de Información 79
Diseño estructurado: Estrategias de
Diseño
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.
15/04/2010 80 15/04/2010 Sistemas de Información 80
Diseño estructurado: Estrategias de
Diseño
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.
15/04/2010 81 15/04/2010 Sistemas de Información 81
Diseño estructurado: Estrategias de
Diseño
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.
15/04/2010 82 15/04/2010 Sistemas de Información 82
Diseño estructurado: Estrategias de
Diseño
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.
15/04/2010 83 15/04/2010 Sistemas de Información 83
Diseño estructurado: Estrategias de
Diseño
5. Realizar el primer corte del diagrama de estructuras:
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
15/04/2010 84 15/04/2010 Sistemas de Información 84
Diseño estructurado: Estrategias de
Diseño
Cm: Módulo principal
Coordina 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
15/04/2010 85 15/04/2010 Sistemas de Información 85
Diseño estructurado: Estrategias de
Diseño
5. Realizar el primer corte del diagrama de estructuras:
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.
15/04/2010 86 15/04/2010 Sistemas de Información 86
Diseño estructurado: Estrategias de
Diseño
5. Realizar el primer corte del diagrama de estructuras:
Análisis de Transacción:
Camino 3
Cm
Ce D
C 1 C 2 C 3
A
D
R
P
Q
Camino 1
Camino 2
a
z
b
Centro de Transacción Centro de
Transacción
Refleja la exclusividad de los diferentes caminos
15/04/2010 87 15/04/2010 Sistemas de Información 87
Diseño estructurado: Estrategias de
Diseño
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.
15/04/2010 88 15/04/2010 Sistemas de Información 88
Diseño estructurado: Estrategias de
Diseño
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.1 1.1
3 4.1
4.2
escribir z leer a leer b
a
b z
15/04/2010 89 15/04/2010 Sistemas de Información 89
Diseño estructurado: Estrategias de
Diseño
6. 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
C 1 C 2 C 3
P Q R
A
a
Leer a z
b
Leer b Escribir
z
Flujo de transformación
15/04/2010 90 15/04/2010 Sistemas de Información 90
Diseño estructurado: Estrategias de
Diseño
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.
15/04/2010 91 15/04/2010 Sistemas de Información 91
Diseño estructurado: Estrategias de
Diseño
7. Refinar la estructura del sistema utilizando medidas y guías de diseño:
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.1 1.1
3 4.1
4.2
escribir z leer a leer b
a
b z
15/04/2010 92 15/04/2010 Sistemas de Información 92
Diseño estructurado: Estrategias de
Diseño
7. Refinar la estructura del sistema utilizando medidas y guías de diseño:
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.
15/04/2010 93 15/04/2010 Sistemas de Información 93
Diseño estructurado: Estrategias de
Diseño
7. Refinar la estructura del sistema utilizando medidas y guías de diseño:
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.
15/04/2010 94 15/04/2010 Sistemas de Información 94
Diseño estructurado: Estrategias de
Diseño
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.
15/04/2010 95 15/04/2010 Sistemas de Información 95
Diseño estructurado: Estrategias de
Diseño
Ejemplo de análisis de transformación:
ALMACÉN
PROVEEDOR
0 GESTIONAR
CENTRAL DE COMPRAS
ALMACÉN
PROVEEDOR
DOCUMENTOS ALMACEN
CATALOGO
PEDIDO GLOBAL
NOTIFICACIÓN PEDIDO
1
SELECCIONAR MEJORES OFERTAS
CATALOGO
MEJORES OFERTAS
2 HACER
PEDIDOS SEGUN
OFERTAS
DOCUMENTOS ALMACEN
PEDIDO GLOBAL
NOTIFICACIÓN PEDIDO
15/04/2010 96 15/04/2010 Sistemas de Información 96
Diseño estructurado: Estrategias de
Diseño
Ejemplo de análisis de transformación:
2.1 RECIBIR
HISTORICO VENTAS
HISTORICO VENTAS
HISTORICO
HISTORICO VENTAS RECIBIDO
2.2 RECIBIR PEDIDOS
RELLENADOS
PEDIDO RELLENADO
PEDIDOS
PEDIDO RELLENADO RECIBIDO
1.1 RECIBIR
CATALOGO
CATALOGO CATALOGOS
CATALOGO RECIBIDO
2.3 AJUSTAR PEDIDOS
ALMACEN
HISTORICO VENTAS RECIBIDO
PEDIDO RELLENADO RECIBIDO
1.2 CALCULAR MEJORES OFERTAS
CATALOGO RECIBIDO
2.4 HACER PEDIDO GLOBAL
MEJORES OFERTAS
PEDIDOS CORREGIDOS
CORREGIDO
CORREGIDO
MEJOR OFERTA
MEJOR OFERTA
PEDIDO GLOBAL
NOTIFICACION PEDIDO
15/04/2010 97 15/04/2010 Sistemas de Información 97
Diseño estructurado: Estrategias de
Diseño
Ejemplo de análisis de transformación:
Gestión Central
Compras
Recibir Documenta-
ción Almacen
Recibir Histórico Ventas
Recibir Pedidos
Rellenados
Leer Histórico Ventas
Leer Pedidos
Rellenados
Recibir Catálogo
Leer Catálogo
Ajustar Pedidos Almacén
Calcular Mejores Ofertas
Hacer Pedido Global
Imprimir Notificación
Pedido
Imprimir Pedido Global
H_V P_R
H_V_R
P_R_R Catálogo
P_R_R
H_V_R
C_R P_R_R
H_V_R C_R
Corre- gido M_O
M_O
Corregido
Notificación Pedido
Pedido Global
H_V = Historico_Ventas H_V_R = Histórico_Ventas_Recibido P_R = Pedido_Rellenado P_R_R = Pedido_Rellenado_Recibido C_R = Catálogo Recibido M_O = Mejores_Ofertas
15/04/2010 98 15/04/2010 Sistemas de Información 98
Diseño estructurado: Estrategias de
Diseño
Ejemplo de análisis de transformación:
Gestión Central
Compras
Recibir Documenta-
ción Almacen
Recibir Histórico Ventas
Recibir Pedidos
Rellenados
Leer P_R
Recibir Catálogo
Ajustar Pedidos Almacen
Calcular Mejores Ofertas
Hacer Pedido Global
Impr N_P
Impr P_G
H_V P_R
Cat
M_O
N_P P_G
Leer H_V
Leer Cat
Esc H
H_V_R
Esc P
P_R_R
Esc Cat
C_R
Leer H
Leer Cat
Esc PCo
H_V_R P_R_R
Cgdo
Leer Cat
E/L MO
C_R
M_O
Leer PCo
Cgdo
H_V = Historico_Ventas H_V_R = Histórico_Ventas_Recibido P_R = Pedido_Rellenado P_R_R = Pedido_Rellenado_Recibido C_R = Catálogo Recibido M_O = Mejores_Ofertas
15/04/2010 99 15/04/2010 Sistemas de Información 99
Diseño estructurado: Estrategias de
Diseño
Ejemplo de análisis de transacción:
USUARIO USUARIO GESTIONAR PISCINA
0
SELEC. TIPO
CARNET 1
TRATAR ESTUDIANTE
2
TRATAR TRABAJADOR
3
Carnet
Carnet
Carnet
Carnet
Entrada
Entrada
Entrada
Estudiante
Trabajador
15/04/2010 100 15/04/2010 Sistemas de Información 100
Diseño estructurado: Estrategias de
Diseño
Ejemplo de análisis de transacción:
SELEC.
TIPO
CARNET 1
COMPROBAR
CARNET
ESTUDIANTE 2.1
Carnet
C-Est
C-Trab
Entrada Trabajador
COMPROBAR
CARNET
TRABAJADOR 3.1
NUMERAR
TALON
ESTUDIANTE 2.2
C-Est
Valid
NUMERAR
TALON
TRABAJADOR 3.2
C-Trab
Valid
PREPARAR
ENTRADA
ESTUDIANTE 2.3
PREPARAR
ENTRADA
TRABAJADOR 3.3
Entrada Estudiante
Entrada
Entrada
15/04/2010 101 15/04/2010 Sistemas de Información 101
Diseño estructurado: Estrategias de
Diseño
Ejemplo de análisis de transacción:
Carnet
C-Trab
Carnet
C- Est
GESTIONAR TIPO ENTRADA
GESTIONAR
PISCINA
LEER CARNET
GESTIONAR ESTUDIANTE
GESTIONAR TRABAJADOR
15/04/2010 102 15/04/2010 Sistemas de Información 102
Diseño estructurado: Estrategias de
Diseño
Ejemplo de análisis de transacción:
GESTIONAR ESTUDIANTE
GESTIONAR
ESTUDIANTE
COMPROBAR CARNET
ESTUDIANTE
NUMERAR TALON
ESTUDIANTE ENTREGAR ENTRADA
IMPRIMIR ENTRADA
Carnet_Estudiante Entrada_Estudiante
Entrada
Entrada Estudiante
Carnet Validado
15/04/2010 103 15/04/2010 Sistemas de Información 103
Diseño estructurado: Estrategias de
Diseño
Ejemplo de análisis de transacción:
GESTIONAR ESTUDIANTE
GESTIONAR
ESTUDIANTE
COMPROBAR CARNET
ESTUDIANTE
NUMERAR TALON
ESTUDIANTE
ENTREGAR ENTRADA
IMPRIMIR ENTRADA
Carnet_Estudiante
Entrada_Estudiante
Entrada
Entrada Estudiante
Carnet Validado
LEER Carnet Est
15/04/2010 105 15/04/2010 Sistemas de Información 105
Diseño estructurado: Estrategias de
Diseño
Ejercicio 15: Realizar el diagrama de estructura para el caso del Ejercicio de Análisis 10.