Sistemas de Información

(1)

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

(2)

15/04/2010 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,

(3)

15/04/2010 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

(4)

15/04/2010 4

Introducción

ERS

Modelo lógico de datos Arquitectura de procesos

Modelo físico de datos Estructuradetallada: 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)

(5)

15/04/2010 5

(6)

15/04/2010 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

(7)

15/04/2010 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

(8)

15/04/2010 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

(9)

15/04/2010 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

(10)

15/04/2010 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:



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

(11)

15/04/2010 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.

(12)

15/04/2010 12

Diagrama de Flujos de Datos (DFD):

Almacenes

Características de los almacenes:



Nombre:



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

(13)

15/04/2010 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

(14)

15/04/2010 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)

15/04/2010 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

(16)

15/04/2010 16

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

Conexiones permitidas:

Destino

Fuente

Proceso

Almacén Entidad

Externa

Proceso

Si

Almacén

Si

No

No*

Entidad

(17)

15/04/2010 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

(18)

15/04/2010 18

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

Conexiones entre procesos y Almacenes:

FLUJO DE CONSULTA FLUJO DE ACTUALIZACION FLUJO DE DIALOGO

(19)

15/04/2010 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

(20)

15/04/2010 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

(21)

15/04/2010 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

(22)

15/04/2010 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.

(23)

15/04/2010 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)

GESTION SISTEMA X DIAGRAMA DE CONTEXTO E1 E2 E3 A B C D E 0 1 2 A1 A2 A B E D C DIAGRAMA 0: GESTION SISTEMA X

DIAGRAMA 1: DIAGRAMA 2: A2 A1 A E B A3 1.1 1.2 1.3 A1 A2 A3 B 1.2.1 1.2.2 1.2.3 DIAGRAMA 1.2:

(24)

15/04/2010 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.

(25)

15/04/2010 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

(26)

15/04/2010 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.

(27)

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

(28)

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

(29)

15/04/2010 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.

(30)

15/04/2010 30

Diagrama de Flujos de Datos (DFD)



Ejercicio:

Construir el Diagrama de Sistema ó

Nivel 0 para el Sistema de

Matriculación.

(31)

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ón NOTIFICACIÓN

3

MATRICULACIÓN

2

COMPROBAR DISPONIBILIDAD CURSO

1

Formulario de Matrícula / Detalles del Curso

Detalles de Matrícula

(32)

15/04/2010 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.

(33)

15/04/2010 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).

(34)

15/04/2010 34

Consistencia entre niveles (Balanceo)

Diagrama de Flujos de Datos (DFD): regla del

balanceo

¿?

A y D

¿?

x - c – Q - P Re cup er ada de : Ju st En ough Str uctur ed A na lys is ( Yo ur do n) 15/04/2010 Sistemas de Información 34

(35)

15/04/2010 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)

(36)

15/04/2010 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.

(37)

15/04/2010 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

(38)

15/04/2010 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

(39)

15/04/2010 39 39

Diagrama de Flujos de Datos (DFD):

ejercicio



Ejercicio:

ESTUDIANTE _FORMULARIOPROCESAR

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

(40)

15/04/2010 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

(41)

15/04/2010 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

(42)

15/04/2010 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

(43)

15/04/2010 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

(44)

15/04/2010 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:

(45)

15/04/2010 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

(46)

15/04/2010 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)

(47)

15/04/2010 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 *

(48)

15/04/2010 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

(49)

15/04/2010 49

Diccionario de Datos (DD)



Ejercicio: Construir el DD para el

Sistema de Matriculación

(50)

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 +

(51)

15/04/2010 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

(52)

15/04/2010 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.

(53)

15/04/2010 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.

(54)

15/04/2010 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

(55)

15/04/2010 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

(56)

15/04/2010 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

(57)

15/04/2010 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

(58)

15/04/2010 58

Especificaciones de Procesos (EP)



Ejercicio: Realizar las EP’s para el Caso de

(59)

15/04/2010 59

Especificación de Procesos:

ejemplo

Diagrama de Contexto

GENERADOR de TRANSACCIONES PERSONAL Registro transacción Datos Empleado DATOS EMPLEADOS Datos Erróneos Sistemas de Información

(60)

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

3

GRABAR REGISTRO de TRANSACCIÓN

4

Datos Empleado Datos Empleado Datos Erróneos Datos Válidos Registro Transacción Registro transacción DATOS EMPLEADOS Sistemas de Información

(61)

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

(62)

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

(63)

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

(64)

15/04/2010 64

(65)

15/04/2010 65

Diseño Estructurado



Objetivo:

Desarrollar la estructura de programas,

así como las relaciones entre los

elementos (módulos) que componen esta

estructura.

(66)

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”

(67)

15/04/2010 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.

(68)

15/04/2010 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

(69)

15/04/2010 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

(70)

15/04/2010 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

(71)

15/04/2010 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

(72)

15/04/2010 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

(73)

15/04/2010 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

(74)

15/04/2010 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

(75)

15/04/2010 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

(76)

15/04/2010 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

(77)

15/04/2010 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

(78)

15/04/2010 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

(79)

15/04/2010 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.

(80)

15/04/2010 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).

(81)

15/04/2010 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

(82)

15/04/2010 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

(83)

15/04/2010 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

(84)

15/04/2010 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

(85)

15/04/2010 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

(86)

15/04/2010 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

(87)

15/04/2010 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.

(88)

15/04/2010 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

(89)

15/04/2010 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

(90)

15/04/2010 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

(91)

15/04/2010 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

(92)

15/04/2010 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

(93)

15/04/2010 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.

(94)

15/04/2010 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