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
17/03/2011 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.
17/03/2011 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)
17/03/2011 Sistemas de Información 4
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)
17/03/2011 Sistemas de Información 5
Análisis Estructurado
17/03/2011 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
17/03/2011 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
17/03/2011 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 dedatos
Entidades externas
SSADMMÉTRICA
17/03/2011 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
17/03/2011 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
17/03/2011 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.
17/03/2011 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)
17/03/2011 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.
17/03/2011 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.
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
17/03/2011 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
17/03/2011 Sistemas de Información 16
Diagrama de Flujos de Datos (DFD): Flujos de Datos
Conexiones permitidas:
NoNo*SiEntidad Externa
No*NoSiAlmacén
SiSiSiProceso
Entidad Externa
Almacén ProcesoDestinoFuente
17/03/2011 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ónentre procesos
Paso asíncrono de informaciónentre procesos
17/03/2011 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 DEDIALOGO
17/03/2011 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 aCliente
CLIENTES
Par dialogo
17/03/2011 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
17/03/2011 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
17/03/2011 Sistemas de Información 22
� Ejercicio 10:
Diagrama de Flujos de Datos (DFD)
17/03/2011 Sistemas de Información 23
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)
17/03/2011 Sistemas de Información 24
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
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:
17/03/2011 Sistemas de Información 25
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)
17/03/2011 Sistemas de Información 26
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)
17/03/2011 Sistemas de Información 27
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)
17/03/2011 Sistemas de Información 28
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)
17/03/2011 Sistemas de Información 29
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)
17/03/2011 Sistemas de Información 30
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)
17/03/2011 Sistemas de Información 31
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)
17/03/2011 Sistemas de Información 32
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)
17/03/2011 Sistemas de Información 33
Diagrama de Flujos de Datos (DFD)
� Ejercicio 11:
Construir el Diagrama de Contexto para el caso del ejercicio 10.
17/03/2011 Sistemas de Información 34
Diagrama de Flujos de Datos (DFD)
� Ejercicio 12:
17/03/2011 Sistemas de Información 35
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
17/03/2011 Sistemas de Información 36
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 + CB = B1 + B2 + B3C = C1 + C2
17/03/2011 Sistemas de Información 37
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
17/03/2011 Sistemas de Información 38
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
17/03/2011 Sistemas de Información 39
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]
17/03/2011 Sistemas de Información 40
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
17/03/2011 Sistemas de Información 41
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)
17/03/2011 Sistemas de Información 42
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 *
17/03/2011 Sistemas de Información 43
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
17/03/2011 Sistemas de Información 44
Diccionario de Datos (DD)
� Ejercicio 13: Construir el DD para el Sistema de Gestión de Préstamos de Libros (Ejer. 12)
17/03/2011 Sistemas de Información 45
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
17/03/2011 Sistemas de Información 46
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.
17/03/2011 Sistemas de Información 47
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.
17/03/2011 Sistemas de Información 48
Especificaciones de Procesos (EP): Árboles de Decisión
CLIENTEESPECIAL
Sí
No
VOLUMENDE 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
17/03/2011 Sistemas de Información 49
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)
17/03/2011 Sistemas de Información 50
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
17/03/2011 Sistemas de Información 51
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.
17/03/2011 Sistemas de Información 52
Especificaciones de Procesos (EP)
� Ejercicio 14: Realizar las EP’s para los procesos primitivos del Sistema de Gestión de Préstamos de Libros.
17/03/2011 Sistemas de Información 53
Diseño Estructurado
17/03/2011 Sistemas de Información 54
Diseño Estructurado
� Objetivo:
Desarrollar la estructura de programas, así como las relaciones entre los elementos (módulos) que componen esta estructura.
17/03/2011 Sistemas de Información 55
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”
17/03/2011 Sistemas de Información 56
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.
17/03/2011 Sistemas de Información 57
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.
17/03/2011 Sistemas de Información 58
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 �
17/03/2011 Sistemas de Información 59
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
17/03/2011 Sistemas de Información 60
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
17/03/2011 Sistemas de Información 61
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.
17/03/2011 Sistemas de Información 62
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
17/03/2011 Sistemas de Información 63
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
17/03/2011 Sistemas de Información 64
Diseño estructurado: Estrategias de Diseño
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
17/03/2011 Sistemas de Información 65
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 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
Caminos Alternativos y
exclusivos
Caminos Alternativos y
exclusivos
17/03/2011 Sistemas de Información 66
Diseño estructurado: Estrategias de Diseño
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
17/03/2011 Sistemas de Información 67
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.
17/03/2011 Sistemas de Información 68
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.
17/03/2011 Sistemas de Información 69
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.
17/03/2011 Sistemas de Información 70
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.
17/03/2011 Sistemas de Información 71
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.
17/03/2011 Sistemas de Información 72
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
17/03/2011 Sistemas de Información 73
Diseño estructurado: Estrategias de Diseño
� 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
17/03/2011 Sistemas de Información 74
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.
17/03/2011 Sistemas de Información 75
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
17/03/2011 Sistemas de Información 76
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.
17/03/2011 Sistemas de Información 77
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.11.1
3 4.1
4.2
escribir zleer a leer b
a
b z
17/03/2011 Sistemas de Información 78
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
17/03/2011 Sistemas de Información 79
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.
17/03/2011 Sistemas de Información 80
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.11.1
3 4.1
4.2
escribir zleer a leer b
a
b z
17/03/2011 Sistemas de Información 81
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.
17/03/2011 Sistemas de Información 82
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.
17/03/2011 Sistemas de Información 83
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.
17/03/2011 Sistemas de Información 84
Diseño estructurado: Estrategias de Diseño
� 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
17/03/2011 Sistemas de Información 85
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
17/03/2011 Sistemas de Información 86
Diseño estructurado: Estrategias de Diseño� Ejemplo de análisis de transformación:
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
17/03/2011 Sistemas de Información 87
Diseño estructurado: Estrategias de Diseño� Ejemplo de análisis de transformación:
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
17/03/2011 Sistemas de Información 88
Diseño estructurado: Estrategias de Diseño
� 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
17/03/2011 Sistemas de Información 89
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
17/03/2011 Sistemas de Información 90
Diseño estructurado: Estrategias de Diseño� Ejemplo de análisis de transacción:
Carnet
C-Trab
Carnet
C-Est
GESTIONARTIPO ENTRADA
GESTIONARPISCINA
LEER CARNET
GESTIONARESTUDIANTE
GESTIONARTRABAJADOR
17/03/2011 Sistemas de Información 91
Diseño estructurado: Estrategias de Diseño� Ejemplo de análisis de transacción:
GESTIONARESTUDIANTE
GESTIONARESTUDIANTE
COMPROBARCARNET
ESTUDIANTE
NUMERARTALON
ESTUDIANTEENTREGARENTRADA
IMPRIMIRENTRADA
Carnet_EstudianteEntrada_Estudiante
Entrada
EntradaEstudianteCarnet
Validado
17/03/2011 Sistemas de Información 92
Diseño estructurado: Estrategias de Diseño� Ejemplo de análisis de transacción:
GESTIONARESTUDIANTE
GESTIONARESTUDIANTE
COMPROBARCARNET
ESTUDIANTE
NUMERARTALON
ESTUDIANTEENTREGARENTRADA
IMPRIMIRENTRADA
Carnet_Estudiante
Entrada_Estudiante
Entrada
EntradaEstudiante
CarnetValidado
LEERCarnet Est
17/03/2011 Sistemas de Información 93
Otros elementos del Diagrama de Estructuras
17/03/2011 Sistemas de Información 94
Diseño estructurado: Estrategias de Diseño
� Ejercicio 15: Realizar el diagrama de estructura para el ejercicio del Sistema de Gestión de Préstamos de Libros.