Sistemas de Información - kybele.etsii.urjc.esSI-2009-10]Tema5_SI.pdf · Tema 5: Análisis y Diseño de los Sistemas de Información . ... Según la persistencia en el tiempo de

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


Bibliografía

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

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


Temario

Análisis Estructurado

Diagrama de Flujo de Datos

Diccionario de Datos

Especificación de Procesos

Diseño Estructurado

Diagrama de estructura

Estrategias de diseño (análisis de transformación y de transacción)


Introducción

ERS

Modelo lógico de datos Arquitectura de procesos

Modelo físico de datos Estructura detallada:

programas y módulos

Enfoque de datos Enfoque funcional

DFD E-R

Esquema de BD y ficheros

Cuadernos de carga

Codificación/Programación

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

Diseño de alto nivel (arquitectónico)

Diseño de bajo nivel (detallado)

Implementación Lenguaje comprensible por la máquina

Diseño (Cómo)

Decisiones generales y abstractas (organiza- ción lógica)

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


Análisis Estructurado


Diagrama de Flujos de Datos (DFD)

Es un diagrama en forma de red que representa

el flujo de datos y las transformaciones que se

aplican sobre ellos al moverse desde la entrada

hasta la salida del sistema.

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

Se apoya en otras técnicas de descripción textual: diccionario de datos

especificaciones de proceso.

Se utiliza para modelar las funciones del sistema y los datos que fluyen entre ellas a distintos niveles de abstracción. Niveles superiores: funciones del sistema de forma general Niveles inferiores: funciones del sistema de forma detallada



Componentes de un DFD Procesos: componentes funcionales del sistema

Almacenes: representan datos almacenados o en

reposo

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

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



Notaciones de un DFD

Yourdon, DeMarco Gane y Sarson

Flujos de datos

Procesos

Almacenes de

datos

Entidades

externas

SSADM

MÉTRICA


Diagrama de Flujos de Datos (DFD): Procesos

Procesos (Funciones o Transformaciones)

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

salida.

No define un programa en ejecución.

El proceso debe ser capaz de generar flujos de datos de salida a partir de flujos de datos de entrada más una información local:

Error de conservación de datos

Pérdida de información


Diagrama de Flujos de Datos (DFD): Procesos

Representación gráfica (Yourdon): Un Círculo.

Incluye un número y un nombre (únicos en el conjunto de DFD que representan el sistema)

Características de los nombres:

Lo más representativo posible.

Dar un nombre que englobe a toda la función

Suprimir nombres con poca significación (Ej: REALIZAR OPERACIÓN, GESTIONAR ACCIÓN, etc.)

Verbo seguido de un sustantivo (Ej.: GENERAR PEDIDO).

Existen DFD lógicos y físicos


Diagrama de Flujos de Datos (DFD): Almacenes

Almacenes de Datos:

Representa información del sistema

almacenada de forma temporal

datos en reposo (flujos: datos en movimientos)

cualquier dato temporalmente almacenado independientemente del dispositivo utilizado

Ejemplos: un cajón con papeles, un archivador manual, un fichero o una base de datos, etc.

Su contenido se define en diccionario de datos.


Diagrama de Flujos de Datos (DFD): Almacenes

Características de los almacenes:

Nombre:

Lo más representativo posible

No asociado a connotaciones físicas

En plural (Ej: “clientes”) .

Se puede representar varias veces en un DFD

Se puede representar en distintos niveles de DFD

Si es local a un proceso, se representará en el DFD en el que se especifique dicho proceso.

Almacén de estructura simple (es de tipo registro)

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


Diagrama de Flujos de Datos (DFD): Entidades Externas

Entidades Externas (Terminadores):

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

no pertenece al mismo.

Ejemplos: subsistemas, personas, departamentos,

organizaciones, otras aplicaciones o sistemas, etc.

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

entre el sistema y el mundo exterior.

Relaciones entre las entidades externas no son objeto del estudio del modelo.


Diagrama de Flujos de Datos (DFD): Entidades Externas

Representación Gráfica:

El nombre debe ser representativo.

Se pueden dibujar varias veces en un DFD (con un asterisco).

Normalmente las entidades externas sólo van a aparecer en el DFD de mayor nivel llamado diagrama de contexto.

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


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

Flujos de Datos:

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

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

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

Se representan por arcos dirigidos.

Según la persistencia en el tiempo de los datos que fluyen por el flujo, estos pueden ser discretos o continuos.

Flujo de datos discreto

Flujo de datos continuo



Conexiones permitidas:

Destino

Fuente

Proceso Almacén Entidad Externa

Proceso Si Si Si

Almacén Si No No*

Entidad Externa

Si No* No



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



Conexiones entre procesos y Almacenes:

FLUJO DE

CONSULTA

FLUJO DE

ACTUALIZACION

FLUJO DE

DIALOGO



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



Caso Particular de Flujo entre Almacenes y Entidades Externas:

GESTIONAR

PRESTAMOS DE

BIBLIOTECA

USUARIO

Petición de libro

SISTEMA DE

MANTENIMIENTO

DE PUBLICACIONES

LIBROS

Resguardo de

aceptación


Características de los Flujos de Datos:

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

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

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

Elemento Grupo Par de diálogo Múltiple



Descomposición en Niveles de un DFD El modelo de un sistema grande es representado “por

capas”. Se sigue una aproximación descendente (top-down)

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

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

modelado). Facilita la documentación del sistema.



Descomposición en Niveles de un DFD Diagrama de Contexto: En este

diagrama sólo hay un proceso que representa el sistema completo

Niveles Medios Diagrama de Sistema: representan

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

detallados

Funciones Primitivas: están

presentes tanto en los niveles intermedios como en los últimos niveles de la jerarquía y se corresponden con procesos que no se explotan en nuevos DFD.


GESTIONSISTEMA

X

DIAGRAMA DE CONTEXTO

E1

E2

E3

A

B

C

D

E

0

1 2

A1

A2

A

B

E

D

CDIAGRAMA 0: GESTION SISTEMA X

DIAGRAMA 1: DIAGRAMA 2:A2A1

A

E

BA3

1.1 1.2

1.3

A1

A2

A3

B1.2.1 1.2.2

1.2.3

DIAGRAMA 1.2:


Convenciones sobre la numeración:

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

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

Los procesos del diagrama del sistema se enumeran por un entero comenzando por 1 y de forma creciente hasta completar el número de procesos del diagrama.

En los restantes niveles, los números de los procesos están formados por la concatenación del número de diagrama en el que están más un punto y un número entero único para identificarlo dentro del diagrama.



Diagrama de Contexto (Diagrama de Nivel 0):

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

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

Está formado por:

Un proceso que representa una “caja negra” del sistema completo.

Un conjunto de entidades externas

Un conjunto de flujos de datos




Ejercicio:

Construir el Diagrama de Contexto para el Caso de Estudio 1, descrito en el Ejercicio de Análisis 9.

Caso de Estudio 1: Sistema de Matriculación

Un estudiante envía un formulario de solicitud relleno donde figuran sus datos personales y el curso en el que desea matricularse. La Universidad debe cotejar esa petición con la lista de cursos para saber si el curso está disponible aún. En caso afirmativo, el alumno es matriculado en el curso, hecho que le es comunicado mediante una carta de confirmación. En caso contrario también es informado mediante la correspondiente carta de denegación.

15/04/2010 Sistemas de InformaciónSistemas de Información

27

15/04/2010 28 28

Diagrama de Flujos de Datos (DFD): ejercicio

Diagrama de Contexto para el Sistema de Matriculación

SISTEMA

DE

MATRICULACIÓN

ESTUDIANTE

Formulario

de

Matrícula

Carta

de

Aceptación

Carta

de

Denegación


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.




Ejercicio:

Construir el Diagrama de Sistema ó Nivel 0 para el Sistema de Matriculación.

15/04/2010 31 31


Diagrama de Sistema para el sistema de Matriculación

ESTUDIANTE

Formulario

de

Matrícula

Carta

de

AceptaciónNOTIFICACIÓN

3

MATRICULACIÓN

2

COMPROBAR

DISPONIBILIDAD

CURSO

1

Formulario de Matrícula /

Detalles del Curso

Detalles

de

Matrícula


Procesos primitivos:

Son aquellos procesos de un DFD que ya no se

descomponen en más diagramas de nivel inferior.

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

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

Algunas reglas:

Cuando un requisito funcional se puede especificar en menos de una página.

Cuando los procesos del diagrama tienen pocos flujos de datos de entrada y salida.

Cuando al descomponer una función de un nivel determinado, se pierde el significado de lo que tiene que hacer esa función.



Consistencia entre niveles (Balanceo):

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

Regla del balanceo entre niveles:

Todos los flujos de datos que entran a un diagrama hijo deben estar representados en el padre por el mismo flujo de datos entrando al proceso asociado.

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

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


15/04/2010 34

Consistencia entre niveles (Balanceo)

Diagrama de Flujos de Datos (DFD): regla del balanceo

¿? A y D

¿? x - c – Q - P

Rec

uper

ada

de:

Jus

t E

noug

h S

truc

ture

d A

naly

sis

(You

rdon

)

15/04/2010 Sistemas de Información 34


Recomendaciones en la creación de un DFD: Diagrama de contexto: Localizar las entidades externas que van a proporcionar y/o consumir

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

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

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

almacén) Identificar almacenes

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

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

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



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

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

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

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

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

Renumerar y renombrar cada componente.

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

En lo posible, evitarlo.



Modificaciones de un DFD:

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

Ante la aparición de una nueva funcionalidad:

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

Incluirla en el diagrama correspondiente

Asociar las interfaces con el resto de componentes del DFD




Ejercicio 12:

Construir el Diagrama de Nivel 2 para el sistema de Matriculación, centrándose en el proceso 1 (Comprobar disponibilidad curso)

15/04/2010 39 39


Ejercicio:

ESTUDIANTEPROCESAR

FORMULARIO

1.1

Formulario

de

Matrícula

COTEJAR

DATOS CON

CURSOS

1.2

MATRICULACIÓN

2

Estado de Cursos

Detalle de Cursos

LISTADO

CURSOS

Detalle de Cursos

Formulario de Matrícula y

Detalle de Cursos


Diccionario de Datos (DD)

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

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

de DFD.

El DD se crea a la vez que los DFD

Las entradas son realizadas cada vez que se identifica un elemento.

El DD define:

Flujos de datos

Almacenes

Datos elementales



Definición de los Flujos de Datos:

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

Ejemplo:

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

A = B1 + B2 + B3 + C1 + C2

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

A = B + C

B = B1 + B2 + B3

C = C1 + C2



Símbolos utilizados para las definiciones

en el DD:

SIMBOLO SIGNIFICADO

= Composición : está compuesto de, o es equivalente a

+ Inclusión: y

[ ] Selección: selección una de la opciones encerradas entre corchetes, y separadas por

el símbolo “|”

{ } Iteración: iteraciones del componente encerrado entre llaves

( ) Opción: significa que el componente encerrado es opcional (puede estar presente o

ausente)

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

DD

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

identifican cada ocurrencia de un almacén



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

introduce con el símbolo “=” A = B + C (flujo de datos múltiple A,

compuesto de un flujo B y uno C) Ejemplos: PETICIÓN LIBROS = CARNET BIBLIOTECA + FICHA

LIBROS CARNET BIBLIOTECA = NUM. CARNET + APELLIDOS +

NOMBRE + TIPO CARNET



Selección:

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

Indica una selección entre campos alternativos distintos.

Ejemplo:

SOCIO = NOMBRE + DOMICILIO + [NIF | CIF]



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

elementos incluidos entre paréntesis. Ejemplo: FICHA LIBROS = { LIBROS } LIBROS = SIGNATURA + TÍTULO + AUTOR Es posible representar los límites inferior y superior

sobre las ocurrencias de una estructura repetitiva: FICHA LIBROS = 1{LIBROS}5



Opción:

El dato opcional indica que puede o no estar presente.

Ejemplo:

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



Definición de los almacenes:

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

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

Ejemplo:

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



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

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

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

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

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

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

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



Ejercicio: Construir el DD para el Sistema de Matriculación

15/04/2010 50

Diccionario de Datos Ejercicio

Formulario_matrícula =

Datos_Alumno + Datos_cursos Datos_Alumno = Nombre + Apellidos +

Dirección + Teléfono + [DNI | NIE | Pasaporte]

Dirección = Tipo_vía + Nombre_vía + Nº_portal + (Nº_piso) + Nº_escalera) + (Nº_puerta) + Código_postal + Ciudad Tipo_vía = [Av|Calle|Paseo|Plaza|Travesia]

Datos_cursos = {Curso}

Curso = Nombre_Asignatura + Código_asignatura + Horario + Año_Académico + Disponibilidad Listado_Cursos = @Codigo_Asignatura +

Nombre_Asignatura + Horario + Grupo + Nº_plazas


Especificaciones de Procesos (EP)

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

Describe cómo se obtienen los flujos de datos de

salida a partir de los flujos de datos de entrada, más una información local al proceso.

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


Especificaciones de Procesos (EP): Lenguaje Estructurado

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

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

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

Alternativa

SI condición

bloque

SI NO bloque

F FIN SI

Repetitiva

MIENTRAS condición

bloque

FIN MIENTRAS

REPETIR bloque

HASTA condición

Secuencia Está formada por un conjunto de sentencias (bloque) donde cada una puede ser o

una acción sencilla o una estructura de las anteriores.


Especificaciones de Procesos (EP): Árboles de Decisión Es una representación en forma de árbol que representa: Los valores de las variables Las acciones tomadas para cada valor El orden en que se realiza la decisión

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

Ejemplo:

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


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

CLIENTE

ESPECIAL

Sí

No

VOLUMEN

DE COMPRAS

> 50.000€

<= 50.000€

Aplicar 25% descuento


AÑOS ANTIGÜEDAD

> 5

<= 5 y >= 3

< 3

VOLUMEN DE COMPRAS

> 50.000€

<= 50.000€ y >= 30.000€

< 30.000€

> 40.000€

<= 40.000€

> 40.000€

<= 40.000€


Aplicar 15 % descuento

Aplicar 10 % descuento




Sin descuento


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

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

Definir:

La parte de condición (un conjunto de condiciones y entradas de condiciones)

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


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

Ejemplo:

CONDICIONES Cliente especial

Vol. compras > 50.000 €

Vol. compras <= 50.000 € 50.000 € >= Vol. compras >= 30.000 €

Vol. compras < 30.000 €

Vol. compras > 40.000 € Vol. compras <= 40.000 €

Años ant. > 5

5 >= Años ant. >= 3 Años ant. < 3

SÍ

SÍ -

-

- -

-

- -

-

SÍ

- SÍ

-

- -

-

- -

-

NO

SÍ -

-

- -

-

SÍ -

-

NO

- NO

SÍ

- -

-

SÍ -

-

NO

- -

-

SÍ -

-

SÍ -

-

NO

- -

-

- SÍ

-

- SÍ

-

NO

- -

-

- -

SÍ

- SÍ

-

NO

- -

-

- SÍ

-

- -

SÍ

NO

- -

-

- -

SÍ

- -

SÍ

ACCIONES

Aplicar 25 % descuento. Aplicar 20% descuento.

Aplicar 15% descuento.

Aplicar 11% descuento. Aplicar 10% descuento.

Aplicar 9% descuento.

Aplicar 5% descuento. Sin descuento.

X

X

X

X

X

X

X

X

X


Especificaciones de Procesos (EP): Precondiciones y poscondiciones

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

Sólo se indican:

Precondiciones: las condiciones que se tienen que cumplir para que el proceso pueda comenzar.

Postcondiciones: las condiciones que deben cumplirse cuando el proceso ha concluido.

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


Especificaciones de Procesos (EP)

Ejercicio: Realizar las EP’s para el Caso de Estudio 2 del Ejercicio de Análisis 9

15/04/2010 59

Especificación de Procesos: ejemplo

Diagrama de Contexto

GENERADOR

de

TRANSACCIONES

PERSONAL Registro

transacción

Datos

EmpleadoDATOS

EMPLEADOS

Datos

Erróneos


15/04/2010 60


Diagrama de Sistema (Nivel 1)

LEER DATOS

EMPLEADO

1

VALIDAR

DATOS

2

CONSTRUIR

REGISTRO

de

TRANSACCIÓN

3GRABAR

REGISTRO

de

TRANSACCIÓN

4

Datos

EmpleadoDatos

Empleado

Datos

Erróneos

Datos

Válidos

Registro

Transacción

Registro

transacciónDATOS

EMPLEADOS


15/04/2010 61


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


15/04/2010 62


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


15/04/2010 63


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






Objetivo:

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


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”


Diagrama de Estructuras: Módulos

Arquitectura implica modularidad.

El software debe dividirse en elementos (módulos) que se integran entre sí para, con su ejecución, satisfacer los requisitos del sistema.

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

La modularidad mejora la calidad del diseño:

Facilitando la implementación, depuración, pruebas, documentación y mantenimiento de un producto software.


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

código que puede ser compilada independientemente.

Otras definiciones:

Según la IEEE [IEEE, 1990], un módulo es (1) una parte lógica separable de un programa; (2) una unidad de programa discreta e identificable respecto de la compilación, combinación con otras unidades y la carga de memoria.

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

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

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



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



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


Diagrama de Estructuras: Conexión entre módulos

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

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


Diagrama de Estructuras: Conexión entre módulos

Un Diagrama de Estructuras no es un Diagrama de Flujo.

A

B

C

El orden de llamadas en un

Diagrama de Estructuras es

de arriba hacia abajo y de

izquierda a derecha.


Diagrama de Estructuras: Comunicación entre módulos

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

Diferencias entre datos y flags:

Finalidad Importancia Representación

Datos Se procesan están relacionados con

el problema y son importantes para el mundo exterior

Flags Comunican condiciones entre módulos

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


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



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



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


exclusivos


exclusivos



Diseño

Pasos del análisis de transformación/transacción:

1. Revisión del modelo fundamental del sistema

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

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

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

5. Realizar el primer corte del diagrama de estructuras

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

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

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



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.



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.



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.



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.



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.



Diseño



Entrada Salida Transformación

Cm

Ce Ct Cs

1.1

2.1

1.2

2.2

3

4.1

4.2



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



Diseño


Análisis de Transacción:

Hay que convertir un flujo de transacción en una estructura con una bifurcación de entrada y otra de salida.

Entrada: Igual que el análisis de transformación.

Salida: Se añade un módulo controlador por cada camino de flujo de acción.



Diseño



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



Diseño

6. Ejecución del segundo nivel de factorizació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.



Diseño



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



Diseño



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



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.



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



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.



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.



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.



Diseño

Ejemplo de análisis de transformación:

ALMACÉN

PROVEEDOR

0 GESTIONAR

CENTRAL DE COMPRAS

ALMACÉN

PROVEEDOR

DOCUMENTOS ALMACEN

CATALOGO

PEDIDO GLOBAL

NOTIFICACIÓN PEDIDO

1

SELECCIONAR MEJORES OFERTAS

CATALOGO

MEJORES OFERTAS

2 HACER

PEDIDOS SEGUN

OFERTAS

DOCUMENTOS ALMACEN

PEDIDO GLOBAL

NOTIFICACIÓN PEDIDO



Diseño


2.1 RECIBIR

HISTORICO VENTAS

HISTORICO VENTAS

HISTORICO

HISTORICO VENTAS RECIBIDO

2.2 RECIBIR PEDIDOS

RELLENADOS

PEDIDO RELLENADO

PEDIDOS

PEDIDO RELLENADO RECIBIDO

1.1 RECIBIR

CATALOGO

CATALOGO CATALOGOS

CATALOGO RECIBIDO

2.3 AJUSTAR PEDIDOS

ALMACEN

HISTORICO VENTAS RECIBIDO

PEDIDO RELLENADO RECIBIDO

1.2 CALCULAR MEJORES OFERTAS

CATALOGO RECIBIDO

2.4 HACER PEDIDO GLOBAL

MEJORES OFERTAS

PEDIDOS CORREGIDOS

CORREGIDO

CORREGIDO

MEJOR OFERTA

MEJOR OFERTA

PEDIDO GLOBAL

NOTIFICACION PEDIDO



Diseño


Gestión Central

Compras

Recibir Documenta-

ción Almacen

Recibir Histórico Ventas

Recibir Pedidos

Rellenados

Leer Histórico Ventas

Leer Pedidos

Rellenados

Recibir Catálogo

Leer Catálogo

Ajustar Pedidos Almacén

Calcular Mejores Ofertas

Hacer Pedido Global

Imprimir Notificación

Pedido

Imprimir Pedido Global

H_V P_R

H_V_R

P_R_R Catálogo

P_R_R

H_V_R

C_R P_R_R

H_V_R C_R

Corre- gido M_O

M_O

Corregido

Notificación Pedido

Pedido Global

H_V = Historico_Ventas H_V_R = Histórico_Ventas_Recibido P_R = Pedido_Rellenado P_R_R = Pedido_Rellenado_Recibido C_R = Catálogo Recibido M_O = Mejores_Ofertas



Diseño


Gestión Central

Compras

Recibir Documenta-

ción Almacen

Recibir Histórico Ventas

Recibir Pedidos

Rellenados

Leer P_R

Recibir Catálogo

Ajustar Pedidos Almacen

Calcular Mejores Ofertas

Hacer Pedido Global

Impr N_P

Impr P_G

H_V P_R

Cat

M_O

N_P P_G

Leer H_V

Leer Cat

Esc H

H_V_R

Esc P

P_R_R

Esc Cat

C_R

Leer H

Leer Cat

Esc PCo

H_V_R P_R_R

Cgdo

Leer Cat

E/L MO

C_R

M_O

Leer PCo

Cgdo

H_V = Historico_Ventas H_V_R = Histórico_Ventas_Recibido P_R = Pedido_Rellenado P_R_R = Pedido_Rellenado_Recibido C_R = Catálogo Recibido M_O = Mejores_Ofertas



Diseño

Ejemplo de análisis de transacción:

USUARIO USUARIO GESTIONAR PISCINA

0

SELEC. TIPO

CARNET 1

TRATAR ESTUDIANTE

2

TRATAR TRABAJADOR

3

Carnet

Carnet

Carnet

Carnet

Entrada

Entrada

Entrada

Estudiante

Trabajador



Diseño


SELEC.

TIPO

CARNET 1

COMPROBAR

CARNET

ESTUDIANTE 2.1

Carnet

C-Est

C-Trab

Entrada Trabajador

COMPROBAR

CARNET

TRABAJADOR 3.1

NUMERAR

TALON

ESTUDIANTE 2.2

C-Est

Valid

NUMERAR

TALON

TRABAJADOR 3.2

C-Trab

Valid

PREPARAR

ENTRADA

ESTUDIANTE 2.3

PREPARAR

ENTRADA

TRABAJADOR 3.3

Entrada Estudiante

Entrada

Entrada



Diseño


Carnet

C-Trab

Carnet

C- Est

GESTIONAR TIPO ENTRADA

GESTIONAR

PISCINA

LEER CARNET

GESTIONAR ESTUDIANTE

GESTIONAR TRABAJADOR



Diseño



GESTIONAR

ESTUDIANTE

COMPROBAR CARNET

ESTUDIANTE

NUMERAR TALON

ESTUDIANTE ENTREGAR ENTRADA

IMPRIMIR ENTRADA

Carnet_Estudiante Entrada_Estudiante

Entrada

Entrada Estudiante

Carnet Validado



Diseño



GESTIONAR

ESTUDIANTE

COMPROBAR CARNET

ESTUDIANTE

NUMERAR TALON

ESTUDIANTE

ENTREGAR ENTRADA

IMPRIMIR ENTRADA

Carnet_Estudiante

Entrada_Estudiante

Entrada

Entrada Estudiante

Carnet Validado

LEER Carnet Est


Otros elementos del Diagrama de Estructuras



Diseño

Ejercicio 15: Realizar el diagrama de estructura para el caso del Ejercicio de Análisis 10.


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

Documents

Sistemas de Información - kybele.etsii.urjc.esSI-2009-10]Tema5_SI.pdf · Tema 5: Análisis y Diseño de los Sistemas de Información . ... Según la persistencia en el tiempo de