Story Transcript
Sistemas de Información
Tema 5: Análisis y Diseño de los Sistemas de Información
17/03/2011
Sistemas de Información
1
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, PrenticeHall, 1985.
17/03/2011
Sistemas de Información
2
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
3
Introducción Análisis (Qué) Lenguaje comprensible para el usuario/cliente
ERS E-R
DFD
Enfoque de datos
Diseño de alto nivel (arquitectónico) Diseño de bajo nivel (detallado)
Enfoque funcional
Modelo lógico de datos
Arquitectura de procesos
Modelo físico de datos
Estructura detallada: programas y módulos
Esquema de BD y ficheros
Cuadernos de carga
Codificación/Programación
17/03/2011
Sistemas de Información
Decisiones generales y abstractas (organización lógica)
Diseño (Cómo)
Decisiones concretas y específicas (optimización y rendimiento)
Implementación Lenguaje comprensible por la máquina
4
Análisis Estructurado
17/03/2011
Sistemas de Información
5
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
6
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
7
Diagrama de Flujos de Datos (DFD) Notaciones de un DFD Yourdon, DeMarco
Gane y Sarson
SSADM MÉTRICA
Flujos de datos
Procesos
Almacenes de datos
Entidades externas
17/03/2011
Sistemas de Información
8
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
9
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
10
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
11
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
12
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
13
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
17/03/2011
Representación de una entidad externa de cardinalidad simple y repetida en un DFD
Representación opcional de entidades externas de cardinalidad N
Sistemas de Información
14
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
15
Diagrama de Flujos de Datos (DFD): Flujos de Datos
Conexiones permitidas: Destino Proceso Fuente
Almacén
Entidad Externa
Proceso
Si
Si
Si
Almacén
Si
No
No*
Entidad Externa
Si
No*
No
17/03/2011
Sistemas de Información
16
Diagrama de Flujos de Datos (DFD): Flujos de Datos
Formas de Paso de Datos entre procesos: Paso síncrono de información entre procesos PROCESO A
PROCESO B
Paso asíncrono de información entre procesos PROCESO A
17/03/2011
PROCESO B
ALMACEN TEMPORAL
Sistemas de Información
17
Diagrama de Flujos de Datos (DFD): Flujos de Datos
Conexiones entre procesos y Almacenes:
FLUJO DE CONSULTA
17/03/2011
FLUJO DE ACTUALIZACION
FLUJO DE DIALOGO
Sistemas de Información
18
Diagrama de Flujos de Datos (DFD): Flujos de Datos
Ejemplos de Flujo de Dialogo: LIBROS
Petición de libro USUARIO
GESTIONAR PETICIONES DE USUARIO
PRESTAMOS
Petición de informe CLIENTE Informe a Cliente
GESTIONAR PETICIONES DE USUARIO
INFORMES
Par dialogo CLIENTES
17/03/2011
Sistemas de Información
19
Diagrama de Flujos de Datos (DFD): Flujos de Datos
Caso Particular de Flujo entre Almacenes y Entidades Externas: SISTEMA DE MANTENIMIENTO DE PUBLICACIONES
LIBROS Petición de libro
USUARIO
17/03/2011
Resguardo de aceptación
GESTIONAR PRESTAMOS DE BIBLIOTECA
Sistemas de Información
20
Diagrama de Flujos de Datos (DFD): Flujos de Datos
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:
17/03/2011
Elemento Grupo Par de diálogo Múltiple
Sistemas de Información
21
Diagrama de Flujos de Datos (DFD)
Ejercicio 10:
17/03/2011
Sistemas de Información
22
Diagrama de Flujos de Datos (DFD) 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.
17/03/2011
Sistemas de Información
23
Diagrama de Flujos de Datos (DFD) DIAGRAMA DE CONTEXTO B
Descomposición en Niveles de un DFD
A
E2
C
0 GESTION SISTEMA X
E1
D E
Diagrama de Contexto: En este diagrama sólo hay un proceso que representa el sistema completo
Niveles Medios
E3
DIAGRAMA 0: GESTION SISTEMA X A A1
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.
D
B A2
DIAGRAMA 1:
C 2
1
E
A
A1 1.2 A3
E
DIAGRAMA 2:
A2
1.1
B
1.3
DIAGRAMA 1.2: A1
A3 1.2.2
1.2.1 B A2 1.2.3
17/03/2011
Sistemas de Información
24
Diagrama de Flujos de Datos (DFD) 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. 17/03/2011
Sistemas de Información
25
Diagrama de Flujos de Datos (DFD) 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
17/03/2011
Sistemas de Información
26
Diagrama de Flujos de Datos (DFD) 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.
17/03/2011
Sistemas de Información
27
Diagrama de Flujos de Datos (DFD) 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.
17/03/2011
Sistemas de Información
28
Diagrama de Flujos de Datos (DFD) 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).
17/03/2011
Sistemas de Información
29
Diagrama de Flujos de Datos (DFD) 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)
17/03/2011
Sistemas de Información
30
Diagrama de Flujos de Datos (DFD) 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.
17/03/2011
Sistemas de Información
31
Diagrama de Flujos de Datos (DFD) 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
17/03/2011
Sistemas de Información
32
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
33
Diagrama de Flujos de Datos (DFD) Ejercicio 12:
17/03/2011
Sistemas de Información
34
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
35
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
17/03/2011
Sistemas de Información
36
Diccionario de Datos (DD) Símbolos utilizados para las definiciones en el DD: SIMBOLO = + [] {} () * texto * @
17/03/2011
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) 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
Sistemas de Información
37
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
38
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
39
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
40
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
41
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
42
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
43
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
44
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
45
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
Repetitiva
Secuencia
17/03/2011
SI condición bloque SI NO bloque F FIN SI MIENTRAS condición bloque FIN MIENTRAS REPETIR bloque HASTA condición Está formada por un conjunto de sentencias (bloque) donde cada una puede ser o una acción sencilla o una estructura de las anteriores. Sistemas de Información
46
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
47
Especificaciones de Procesos (EP): Árboles de Decisión CLIENTE ESPECIAL
VOLUMEN DE COMPRAS > 50.000€
Sí 5
> 50.000€ = 30.000€ < 30.000€
No
= 3
> 40.000€ = 30.000 € Vol. compras < 30.000 € Vol. compras > 40.000 € Vol. compras 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. 17/03/2011
X
X X X X X X X X
Sistemas de Información
50
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
51
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
52
Diseño Estructurado
17/03/2011
Sistemas de Información
53
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
54
Diagrama de Estructuras Elementos Principales: Conexiones entre módulos
Módulos GESTIONAR PETICIONES
PET_ACEPTADA PET_ACEPTADA CONSULTAR STOCK
PET_PRESTAMO
LEER PETICION PRESTAMO
17/03/2011
INFORME PRESTAMO
INFORME PRESTAMO
INFORMAR PETICION
TRATAR PETICION
Módulos “predefinidos”
PET_RECHAZADA
RECHAZAR PETICION
Comunicación entre módulos (estructuras de datos o de control “flags”)
Sistemas de Información
55
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
56
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
57
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
58
Diagrama de Estructuras: Módulos Esfuerzo requerido para desarrollar módulos Coste o Esfuerzo
20 Módulos de 50 líneas cada uno
Coste Total del Software
Coste de interfaz Coste Total del Software
Coste o Esfuerzo
Región de coste mínimo
Coste de interfaz
Región de coste mínimo
Coste por módulo
Coste por Nº Módulos módulo
¿Qué elegiríamos un módulo con 1000 líneas o 1000 módulos de 1 línea? 17/03/2011
Nº Módulos
Sistemas de Información
59
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
60
Diagrama de Estructuras: Conexión entre módulos Un Diagrama de Estructuras no es un Diagrama de Flujo.
A
B
El orden de llamadas en un Diagrama de Estructuras es de arriba hacia abajo y de izquierda a derecha.
C 17/03/2011
Sistemas de Información
61
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
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.
17/03/2011
Sistemas de Información
Representación
62
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
63
Diseño estructurado: Estrategias de Diseño Caminos de datos que entran en el Sistema
Flujo de Transformación
1.1
1.2
DFD con características de Transformación
3 4.1
2.1 FLUJO DE LLEGADA
2.2 4.2 Ocurre una transformación de los datos
FLUJO DE SALIDA
FLUJO DE TRANSFORMACIÓN 17/03/2011
Sistemas de Información
Caminos de datos de salida Sistema 64
Diseño estructurado: Estrategias de Diseño Un dato determina caminos alternativos por los que puede transitar el flujo de información
Flujo de Transacción
DFD con características de Transacción
Camino de acción 1
CENTRO DE TRANSACCIÓN
2.1
2.2 Camino de acción 2
1
3.1
3.2 Camino de acción 3
4.1 4.2
17/03/2011
Caminos Alternativos y exclusivos
Sistemas de Información
65
Diseño estructurado: Estrategias de Diseño Pasos del análisis de transformación/transacción: 1. 2. 3.
4.
5. 6. 7. 8.
Revisión del modelo fundamental del sistema Determinar si el DFD tiene características de transformación o de transacción 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 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 Realizar el primer corte del diagrama de estructuras Ejecución del segundo nivel de factorización Refinar la estructura del sistema utilizando medidas y guías de diseño Asegurarse del trabajo realizado por el diseño obtenido
17/03/2011
Sistemas de Información
66
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
67
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
68
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
69
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
70
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
71
Diseño estructurado: Estrategias de Diseño 5. Realizar el primer corte del diagrama de estructuras: Análisis de Transformación: Entrada 1.1
Salida 1.2
Transformación
3
Cm
4.1 2.1
17/03/2011
2.2 4.2
Ce
Sistemas de Información
Ct
Cs
72
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
17/03/2011
Sistemas de Información
73
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
74
Diseño estructurado: Estrategias de Diseño 5. Realizar el primer corte del diagrama de estructuras: Análisis de Transacción:
Centro de Transacción
a
A
b
D
Cm
P Q R
C1
z
Camino 3
Camino 1 Camino 2
17/03/2011
D
Ce
C2
C3
Refleja la exclusividad de los diferentes caminos
Sistemas de Información
75
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
76
Diseño estructurado: Estrategias de Diseño 6. Ejecución del segundo nivel de factorización: Cm
Análisis de Transformación: Entrada a 1.1
Salida 1.2
Ce
3 4.1
b
2.2
2.1
4.2
z
1.2
2.2
1.1
2.1
Ct
Cs
3
4.1 4.2
Transformación leer a 17/03/2011
escribir z
leer b
Sistemas de Información
77
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
Flujo de transformación
A D
P
A
R z
Camino 3
D
Ce Q
Leer a
Camino 1 Camino 2 17/03/2011
Cm
b
Sistemas de Información
C1 P Leer b
C2 Q
C3 R
Escribir z 78
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
79
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
Cm
Entrada a 1.1
Salida 1.2
Ce
3 4.1
b
2.1
2.2 4.2
z
1.2
2.2
1.1
2.1
Transformación leer a 17/03/2011
Sistemas de Información
leer b
Ct
Cs
3
4.1 4.2 escribir z 80
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:
17/03/2011
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.
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:
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
82
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
83
Diseño estructurado: Estrategias de Diseño Ejemplo de análisis de transformación: DOCUMENTOS ALMACEN
ALMACÉN
PEDIDO GLOBAL
0 GESTIONAR CENTRAL DE COMPRAS
PROVEEDOR
CATALOGO
NOTIFICACIÓN PEDIDO
ALMACÉN
PROVEEDOR
DOCUMENTOS ALMACEN
MEJORES OFERTAS CATALOGO
1 SELECCIONAR MEJORES OFERTAS
PEDIDO GLOBAL
2 HACER PEDIDOS SEGUN OFERTAS NOTIFICACIÓN PEDIDO
17/03/2011
Sistemas de Información
84
Diseño estructurado: Estrategias de Diseño Ejemplo de análisis de transformación: HISTORICO VENTAS
2.1 RECIBIR HISTORICO HISTORICO VENTAS VENTAS RECIBIDO
HISTORICO VENTAS RECIBIDO
2.3 AJUSTAR PEDIDOS ALMACEN
CORREGIDO PEDIDOS CORREGIDOS
HISTORICO
PEDIDO RELLENADO
CORREGIDO PEDIDO RELLENADO RECIBIDO
PEDIDOS 2.2 RECIBIR PEDIDOS RELLENADOS
PEDIDO RELLENADO RECIBIDO
PEDIDO GLOBAL
2.4 HACER PEDIDO GLOBAL
MEJOR OFERTA
NOTIFICACION PEDIDO
MEJORES OFERTAS
CATALOGO
MEJOR OFERTA
CATALOGO RECIBIDO 1.1 CATALOGOS RECIBIR CATALOGO CATALOGO RECIBIDO
17/03/2011
1.2 CALCULAR MEJORES OFERTAS
Sistemas de Información
85
Diseño estructurado: Estrategias de Diseño Ejemplo de análisis de transformación: Gestión Central Compras
P_R_R
M_O
H_V_R C_R
Recibir Documentación Almacen
H_V_R
H_V
Leer Histórico Ventas
17/03/2011
H_V_R
Recibir Catálogo P_R_R
Recibir Histórico Ventas
P_R_R
Recibir Pedidos Rellenados
Corregido
Corregido
C_R
Ajustar Pedidos Almacén
Catálogo
Leer Catálogo
P_R
M_O
Calcular Mejores Ofertas Notificación Pedido
Imprimir
Notificación
Pedido
Hacer Pedido Global Pedido Global
Imprimir 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
Leer Pedidos
Rellenados
Sistemas de Información
86
Diseño estructurado: Estrategias de Diseño Ejemplo de análisis de transformación: 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
Gestión Central Compras
Recibir Documentación Almacen
Ajustar Pedidos Almacen
Recibir Catálogo H_V_R
Recibir Pedidos Rellenados
Recibir Histórico Ventas H_V
H_V_R
Leer Esc H_V H
Leer P_R
P_R
Esc P
Leer Cat
17/03/2011
P_G
N_P
P_R_R
Leer Cat
C_R
P_R_R
Hacer Pedido Global
M_O
Cgdo
Leer H
Cat
Calcular Mejores Ofertas
Esc Cat
Impr N_P
Esc PCo C_R
Cgdo
M_O
Leer Cat
Impr P_G
E/L MO
Leer PCo
Sistemas de Información
87
Diseño estructurado: Estrategias de Diseño Ejemplo de análisis de transacción:
USUARIO
Carnet
GESTIONAR PISCINA Entrada 0 Carnet Estudiante
Carnet
SELEC. TIPO CARNET 1 Carnet Trabajador
17/03/2011
Sistemas de Información
USUARIO
Entrada TRATAR ESTUDIANTE 2
Entrada TRATAR TRABAJADOR 3 88
Diseño estructurado: Estrategias de Diseño Ejemplo de análisis de transacción:
COMPROBAR CARNET ESTUDIANTE 2.1
C-Est Carnet
SELEC. TIPO CARNET 1
C-Est Valid
PREPARAR NUMERAR ENTRADA TALON ESTUDIANTE ESTUDIANTE 2.2 2.3 Entrada Estudiante Entrada
C-Trab COMPROBAR PREPARAR NUMERAR C-Trab CARNET ENTRADA TALON TRABAJADOR Valid TRABAJADOR TRABAJADOR 3.1 3.3 3.2 Entrada Trabajador Entrada
17/03/2011
Sistemas de Información
89
Diseño estructurado: Estrategias de Diseño Ejemplo de análisis de transacción: GESTIONAR PISCINA Carnet
Carnet
LEER CARNET
GESTIONAR TIPO ENTRADA CEst
GESTIONAR ESTUDIANTE
17/03/2011
Sistemas de Información
C-Trab
GESTIONAR TRABAJADOR
90
Diseño estructurado: Estrategias de Diseño Ejemplo de análisis de transacción: GESTIONAR ESTUDIANTE
GESTIONAR ESTUDIANTE
Carnet_Estudiante
COMPROBAR CARNET ESTUDIANTE
Carnet Validado
Entrada_Estudiante
Entrada Estudiante
NUMERAR TALON ESTUDIANTE
ENTREGAR ENTRADA Entrada
IMPRIMIR ENTRADA 17/03/2011
Sistemas de Información
91
Diseño estructurado: Estrategias de Diseño Ejemplo de análisis de transacción: GESTIONAR ESTUDIANTE
GESTIONAR ESTUDIANTE Carnet Validado
COMPROBAR CARNET ESTUDIANTE
Entrada_Estudiante
Entrada Estudiante
NUMERAR TALON ESTUDIANTE
ENTREGAR ENTRADA
Carnet_Estudiante
Entrada
LEER Carnet Est 17/03/2011
IMPRIMIR
ENTRADA Sistemas de Información
92
Otros elementos del Diagrama de Estructuras
17/03/2011
Sistemas de Información
93
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.
17/03/2011
Sistemas de Información
94
Sistemas de Información
Tema 5: Análisis y Diseño de los Sistemas de Información