ingeniería del software de gestión - inicio | kybeleis... · proceso o un sistema con suficiente...

69
www.kybele.urjc.es Tema VII: Diseño Estructurado Diana Marcela Sánchez Fúquene Ingeniería del Software de Gestión

Upload: vanquynh

Post on 19-Feb-2018

215 views

Category:

Documents


0 download

TRANSCRIPT

www.kybele.urjc.es

Tema VII:

Diseño Estructurado

Diana Marcela Sánchez Fúquene Ingeniería del Software de Gestión

www.kybele.urjc.es

Índice

El proceso de diseño

Modelos de diseño.

Diseño estructurado.

Diagramas de estructura.

Estrategias de diseño

Análisis de transformaciones.

Análisis de transacciones

Ingeniería del Software de Gestión

www.kybele.urjc.es

El proceso de Diseño

El proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, un

proceso o un sistema con suficiente detalle como para permitir su realización física

Proceso iterativo a través del cual se traducen los

requisitos en una representación del software

El diseño estructurado es un enfoque disciplinado de la transformación de qué es necesario para el

desarrollo de un sistema, a cómo deberá ser hecha la implementación

Ingeniería del Software de Gestión

www.kybele.urjc.es

Vista General Análisis Estructurado

Ingeniería del Software de Gestión

Modelo lógico de datos

Modelo físico de datos

Arquitectura de procesos

Estructura detallada: programas y módulos

Codificación y pruebas

Análisis (Qué)

Lenguaje comprensible por el

usuario

Diseño de alto nivel (arquitectónico)

Diseño de bajo nivel (detallado)

Diseño

(Cómo)

Decisiones Generales y

Abstractas:

Organización lógica

Decisiones concretas y

específicas:

optimización y rendimiento

Implementación

Lenguaje comprensible por la

máquina

Enfoque de datos

Enfoque Funcional

ERS

Modelo Entidad/Relació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

Diagrama de

Flujo de Datos

Esquema de BD y ficheros

Cuadernos de carga

www.kybele.urjc.es

El proceso de Diseño

Diseño de datos Transforma el modelo del dominio de la información del análisis en las estructuras de datos necesarias para la implementación. Esquema Lógico de Datos ó Modelo Relacional.

Diseño arquitectónico Estructura modular del programa/aplicación Diagramas de Estructura de Cuadros de Constantine

Diseño de interfaz Interfaces del sistema con otros sistemas y con los usuarios.

Diseño procedimental Descripción procedimental de los componentes del sistema

Ingeniería del Software de Gestión

www.kybele.urjc.es

Diseño Estructurado

Objetivos

Desarrollar la estructura modular del programa

Definir las relaciones entre módulos

Técnica Principal

Diagrama de Estructura de Cuadros de Constantine

Documentación de partida

DFDs – Análisis Estructurado.

Estrategias de diseño - Tipos de Esquemas

Análisis de transformaciones

Análisis de transacciones

Ingeniería del Software de Gestión

www.kybele.urjc.es

Diseño Estructurado

Se dispone de

Las entradas que suministran al sistema las entidades externas

Las salidas aportadas por el sistema a dichas entidades externas

Las funciones descompuestas que se han de realizar en ese sistema

El esquema lógico de datos del sistema

Ingeniería del Software de Gestión

www.kybele.urjc.es

Diseño Estructurado

Tareas a realizar

Módulos obtenidos en el análisis Procesos primitivos

Organizar la estructura de estos módulos y definir las conexiones entre los mismos

Describir el pseudocódigo para cada módulo

Se basa en los siguientes principios Abstracción

Modularidad

Encapsulamiento y Ocultamiento de información

No confundir con programación estructurada

Ingeniería del Software de Gestión

www.kybele.urjc.es

Objetivo: diseño de la ARQUITECTURA

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

Identifica qué módulos se necesitan, así como sus inputs/outputs (caja negra)

Refleja la comunicación de datos y control y la jerarquía entre módulos

Ingeniería del Software de Gestión

Diagrama de Estructura de Cuadros de Constantine

www.kybele.urjc.es

Diagrama de Estructuras: ejemplo

Ingeniería del Software de Gestión

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”

www.kybele.urjc.es

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

Ingeniería del Software de Gestión

www.kybele.urjc.es

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

Ingeniería del Software de Gestión

www.kybele.urjc.es

Diagrama de Estructuras Módulos

Representación

Ingeniería del Software de Gestión

OBTENER DATOS

CLIENTES

MÓDULO

MÓDULO PREDEFINIDO

1

CONECTOR

Almacenes de datos

Dispositivos físicos

NOMBRE

DISPOSITIVO

MÉTRICA

IMPRIMIR CHEQUE DE PAGO

www.kybele.urjc.es

Diagrama de Estructuras Módulos

Típicamente representa un programa, subprograma o rutina, dependiendo del lenguaje que se vaya a utilizar

Admite parámetros de llamada y retorna algún valor, si es preciso

Puede tener aproximadamente entre unas 40 o 50 líneas de código (muchas opiniones encontradas)

Es posible dividir el software indefinidamente • Compromiso entre

Esfuerzo requerido para cada módulo Esfuerzo requerido para las interfaces entre módulos

Ingeniería del Software de Gestión

www.kybele.urjc.es

Diagrama de Estructuras Módulos

Esfuerzo requerido para desarrollar módulos

Ingeniería del Software de Gestión

Nº Módulos

Coste o Coste de interfaz

Coste por módulo

Coste Total del Software

Región de coste mínimo

Esfuerzo

www.kybele.urjc.es

Diagrama de Estructuras: Módulos

Esfuerzo requerido para desarrollar módulos

Ingeniería del Software de Gestión

¿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

www.kybele.urjc.es

Cada conexión representa una llamada de un módulo a otro

Se representan con una flecha

Distinguir de un organigrama A B C

A B C B A

El orden de llamadas es interpretado de forma distinta

arriba hacia abajo y de izquierda a derecha

Independiente de la disposición del grafo

Ingeniería del Software de Gestión

A

B

C

Diagrama de Estructuras: Conexión entre módulos

www.kybele.urjc.es

Diagrama de Estructuras: Estructuras de control

Repetición

Una flecha circular, abarcando un número de invocaciones, especifica que las invocaciones que abarca son ejecutadas repetidamente

Alternativa

Un rombo incluyendo una o más invocaciones especifica la ejecución condicional de ellas

Ingeniería del Software de Gestión

A

B B

www.kybele.urjc.es

Ejemplo menú Secretaría Virtual

Ingeniería del Software de Gestión

MENÚ

de

LOGIN

OPCIONES

ESTUDIANTES

OPCIONES

PAS

OPCIONES

PDI

Diagrama de Estructuras: Conexión entre módulos

www.kybele.urjc.es

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

Datos

Transporta datos “puros” a un módulo

No es necesario conocer la lógica interna del módulo receptor, para determinar los valores válidos (ej: nº cuenta, saldo, etc.)

Control

Transporta un dato indispensable para la toma de una decisión (ej: código de operación)

Ingeniería del Software de Gestión

MENÚ

de

LOGIN

COMPROBAR

NIF

Da

tos

Co

rre

cto

s

NIF

Diagrama de Estructuras: Comunicación entre módulos

www.kybele.urjc.es

Diferencias entre Datos y Flags

Ingeniería del Software de Gestión

Finalidad Descripción Relevancia

Datos Los datos se procesan

• Los datos son la información compartida por los módulos. • La posición de la flecha (hacia arriba o hacia abajo) indica el sentido de la comunicación

Los datos están relacionados con el problema y son importantes para el mundo exterior

Flags Los controles sólo sirven para comunicar condiciones entre los módulos

Los controles indican al módulo que llama la terminación EOF, o un error del módulo llamado, y deben ir siempre en sentido ascendente

Los flags tienen importancia en la comunicación de información en el interior; son los que sincronizan la operativa de los módulos

Diagrama de Estructuras: Comunicación entre módulos

www.kybele.urjc.es

Tablas de Interfaz

Representa y especifica los módulos de un diagrama de estructuras y los parámetros que se pasan entre ellos.

Mejora su claridad (Nº de parámetros mayor que 4)

Una fila por cada módulo y parámetro

Se especifica: El nombre del módulo

Cada parámetro formal

Tipo de parámetro (entrada, salida)

El uso de cada parámetro

El significado de cada parámetro

Ingeniería del Software de Gestión

www.kybele.urjc.es

Tablas de Interfaz: Nemotécnicos de uso de un parámetro

Ingeniería del Software de Gestión

Nemotécnico Significa

P El parámetro es PROCESADO a = b + 2

M El parámetro es MODIFICADO a = 3 + b

T El parámetro es TRANSFERIDO por el módulo llamado a otro módulo que éste llama, sin modificar su valor

C

El parámetro es usado como una VARIABLE DE CONTROL, quizás para actuar como índice conmutador, como un valor de un flag o para la especificación de una función que es usada por el módulo llamado

I El parámetro es TRANSFERIDO a otro módulo, y es MODIFICADO en este segundo módulo

www.kybele.urjc.es

Tablas de Interfaz Ejemplo

Ejemplo de Tabla de Interfaz

Ingeniería del Software de Gestión

Módulo Parámetro

Formal Entrada Salida Uso

Significado Parámetro

F(x, y) X SÍ NO P Fecha-

Nacimiento

Y NO SÍ M Edad

www.kybele.urjc.es

Tablas de Interfaz Ejercicio

Realizar la tabla de interfaz para el siguiente diagrama de estructuras

Ingeniería del Software de Gestión

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

www.kybele.urjc.es

Tablas de Interfaz

Solución

Ingeniería del Software de Gestión

Módulo Parámetro

Formal Entrada Salida Uso

Significado Parámetro

TRATAR PETICIÓN

Petición Aceptada

SÍ NO P Consentimiento

TRATAR PETICIÓN

Informe Préstamo

NO SÍ I Informe de Préstamo

INFORMAR PETICIÓN

Informe Préstamo

SI NO M Informe de Préstamo

www.kybele.urjc.es

Diagrama de Estructuras: ejemplo

Ingeniería del Software de Gestión

CONSEGUIR ENTERO VÁLIDO

LEER ENTERO DE

FICHERO

VALIDAR ENTERO

ENTERO

ENTERO

ENTERO VÁLIDO

FIN DE FICHERO

“CONSEGUIR ENTERO VÁLIDO”:

…………………..

LEER_ENTERO( fin_fichero, entero ) ;

……………………..

if VALIDAR_ENTERO( entero ) then ...

...

www.kybele.urjc.es

Estrategias de Diseño Estructurado

Derivar el Diagrama de Estructuras de los DFD de procesos primitivos

Dos estrategias

Análisis de Transformaciones

Análisis de Transacciones

Ingeniería del Software de Gestión

www.kybele.urjc.es

Flujo de Transformación

Ingeniería del Software de Gestió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

Estrategias de Diseño Estructurado Análisis de Transformación

www.kybele.urjc.es

Ingeniería del Software de Gestión

Estrategias de Diseño Estructurado Análisis de Transformación

www.kybele.urjc.es

Estrategias de Diseño Estructurado Análisis de Transacción

Flujo de Transacción

Ingeniería del Software de Gestió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

www.kybele.urjc.es

Ingeniería del Software de Gestión

Estrategias de Diseño Estructurado Análisis de Transacción

www.kybele.urjc.es

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

Ingeniería del Software de Gestión

Estrategias de Diseño Estructurado Guía análisis de transformación/transacción

www.kybele.urjc.es

1.Revisión del modelo fundamental del sistema

Partir de los DFD del sistema

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 nivel de detalle se han de tener como mínimo 3 niveles de profundidad

Ingeniería del Software de Gestión

Estrategias de Diseño Estructurado Pasos

www.kybele.urjc.es

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

En general, la mayoría de DFD son de tipo transformación

Elegir sólo los inequívocos

Procesos con salidas exclusivas entre sí típicos de problemas de transacción

Los centros de transacción a veces no son distinguibles en el DFD

Ingeniería del Software de Gestión

Estrategias de Diseño Estructurado Pasos

www.kybele.urjc.es

Estrategias de Diseño Estructurado Pasos

3. 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

Ingeniería del Software de Gestión

www.kybele.urjc.es

Identificar Centro de Transformación Ejemplo

Ingeniería del Software de Gestión

Reunir

del ClienteMovimentos

Leer

del ClienteMovimientos

FormatearLinea delInforme

CalcularTotal

FormatearEncabezado

FormatearTotal

ImprimirLinea

Leer

del ClienteInformaçión

# de Cuenta

# de Cuenta

# de Cuenta

Movimiento

Movimiento

Cuenta Corriente Clientes

Informe

Nombre + Dirección

Registro del Cliente

Movimiento

Encabezado

Saldo

Linea

Tipo de Movimiento +

Valor del Movimiento

Total Depósitos +

Total Extracciones

Estrategias de Diseño Estructurado Pasos

www.kybele.urjc.es

4. Análisis de transacción: identificar el centro de transacción y las características del flujo de cada camino de acción

Identificación intuitiva a partir del DFD. Ligado al origen de varios caminos de información

que fluyen desde é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

Ingeniería del Software de Gestión

Estrategias de Diseño Estructurado Pasos

www.kybele.urjc.es

Estrategias de Diseño Estructurado Pasos

Ingeniería del Software de Gestión

Valor

Generar

Movimientos

Informe de

Iniciar

Deseada Operaçión

Registrar

Extracciones

Registrar Depósito

# de Cuenta

Cuenta Corriente

Clientes Registro del Cliente

Movimiento

Operación Deseada

Saldo

# de Cuenta

# de Cuenta

# de Cuenta

# de Cuenta

Consultar

de Cuenta Saldo

Movimiento

Saldo

Movimiento

Movimiento

Parámetro deDireccionamiento

Parámetro deCurso

Parámetro deSeguimiento

Parámetro deDisparo

Curso Corriente

Ángulo deDireccionamiento

Coordenadasdcl objetivo

Detalle delDisparo

Direccionarel Barco

Localizar

Objetivo

AjustarCurso

Terminalde Control Giroscópo

Timón

DispararMísil

Misil

Parámetro deDirecionamiento

Parámetro deCurso

Parámetro deSeguimiento

Parámetro deDisparo

Curso Corriente

Ángulo deDirecionamiento

Coordenadasdel Objetivo

Detalle delDisparo

Terminalde Control Giroscópo

Timón

Misil

Direccionarel Barco

LocalizarObjetivo

AjustarCurso

DispararMísil

Inv. Op.Adecuada

Señal deControl

Identificar el centro de transacción

A veces no es tan evidente

www.kybele.urjc.es

Estrategias de Diseño Estructurado Pasos

Ingeniería del Software de Gestión

TransacciónTipo de

Obtener

TransacciónTipo de

TransacciónTipo

B

TransacciónTipo

A

TransacciónTipo

C

AplicarTransacción

Valor

Generar

MovimientosReporte de

Iniciar

DeseadaOperación

RegistrarExtracción

RegistrarDepósito

# de Cuenta

Cuenta Corriente

ClientesRegistro del Cliente

Movimiento

OperaciónDeseada

Saldo

# de Cuenta

# de Cuenta

# de Cuenta

# de Cuenta

Consultar

de CuentaSaldo

Movimiento

Saldo

Movimiento

Movimiento

Control

Señal de

Obtener

ControlSeñal de Ajustar

Curso

ControlarDireccióndel Barco

LocalizarObjetivo

DispararMísil

GobernarBarco

DeseadaOperación

Obtener

DeseadaOperación Consultar

Saldo

GenerarReporte

de Movims

Registrar

Depósito

RegistrarExtracción

TransacciónBancarias

# de Cuenta

# de Cuenta # de Cuenta# de Cuenta

# de Cuenta

Parámetro deDirecionamiento

Parámetro deCurso

Parámetro deSeguimiento

Parámetro deDisparo

Curso Corriente

Ángulo deDirecionamiento

Coordenadasdel Objetivo

Detalle delDisparo

Terminalde Control Giroscópo

Timón

Misil

Direccionarel Barco

LocalizarObjetivo

AjustarCurso

DispararMísil

Inv. Op.Adecuada

Señal deControl

www.kybele.urjc.es

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 Los Módulos de nivel superior toman decisiones de

ejecución

Los Módulos del nivel inferior ejecutan la mayoría del trabajo de entrada, de cálculo y de salida.

Los Módulos de nivel intermedio ejecutan algún control y realizan moderadas cantidades de trabajo

Ingeniería del Software de Gestión

Estrategias de Diseño Estructurado Pasos

www.kybele.urjc.es

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

Ingeniería del Software de Gestión

Entrada Salida Transformación

Cm

Ce Ct Cs

1.1

2.1

1.2

2.2

3

4.1

4.2

Estrategias de Diseño Estructurado Pasos – Primer corte

www.kybele.urjc.es

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

Para la entrada se hace igual que el análisis de transformación

Para la salida se añade un módulo controlador por cada camino de flujo de acción

Ingeniería del Software de Gestión

Estrategias de Diseño Estructurado Pasos – Primer corte

www.kybele.urjc.es

Estrategias de Diseño Estructurado Pasos – Primer corte

Ingeniería del Software de Gestió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

www.kybele.urjc.es

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

Análisis de Transformación Procesos DFD Módulos del DE

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

Ingeniería del Software de Gestión

Estrategias de Diseño Estructurado Pasos – Segundo nivel

www.kybele.urjc.es

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

Análisis de Transformación

Ingeniería del Software de Gestió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

Estrategias de Diseño Estructurado Pasos – Segundo nivel

www.kybele.urjc.es

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

Ingeniería del Software de Gestión

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

Estrategias de Diseño Estructurado Pasos – Segundo nivel

www.kybele.urjc.es

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

Criterios Consideraciones prácticas y de sentido común

Requisitos del software

Ingeniería del Software de Gestión

Estrategias de Diseño Estructurado Pasos

www.kybele.urjc.es

Estrategias de Diseño Estructurado Pasos – Refinar la estructura

Ejemplo

Ingeniería del Software de Gestió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

www.kybele.urjc.es

Estrategias de Diseño Estructurado Pasos – Refinar la estructura

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

Representar los parámetros de cada módulo Datos

• Flujos de información de los DFD

• Representar como datos que se pasan entre módulos

Flags • Descripciones de los procesos del DFD

• Se refleja en el módulo correspondiente del diagrama de estructura cuando se necesita una variable de control

Ingeniería del Software de Gestión

www.kybele.urjc.es

Estrategias de Diseño Estructurado Pasos – Refinar la estructura

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

Acceso a un almacén en el DFD

Módulos predefinidos colgando del módulo correspondiente (READ/WRITE)

Reflejando el acceso a la BD en el DE se facilita la programación

Ingeniería del Software de Gestión

www.kybele.urjc.es

Estrategias de Diseño Estructurado Pasos – Verificar

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

Comprobar que la funcionalidad que realiza el diseño creado es la correcta

Revisar que el orden de ejecución de los módulos sea el correcto

Ingeniería del Software de Gestión

www.kybele.urjc.es

Análisis de Transformación Ejemplo

Desarrollo de un sistema de información que apoye la gestión de una Central de Compras (C.C.) que permita realizar pedidos globales por temporada (Reyes, acampadas de verano, etc.)

El sistema, a partir del catálogo de los proveedores y el archivo histórico de ventas, obtiene el pedido global a partir de los pedidos individuales (Pedido Rellenado).

No obstante, la C.C puede modificar a la baja o al alza la cantidad solicitada por el almacén en función de algunos factores, como umbrales de descuento, etc. Entonces, se notificará al almacén el cambio en el pedido (Notificacion Pedido) y se comunica a todos los proveedores las cantidades definitivas de los distintos productos (Pedido Global).

Se pide Identificar las características general del flujo de datos (y el centro de

transformación o transacción correspondiente) Generar el diagrama de estructuras

Ingeniería del Software de Gestión

www.kybele.urjc.es

Análisis de Transformación Ejemplo

Ingeniería del Software de Gestión

ALMACÉN

PROVEEDOR

0 GESTIONAR

CENTRAL DE COMPRAS

PROVEEDOR

ALMACEN *

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

Documentos Almacén = Histórico de Ventas + Pedido Rellenado Pedido Global = Notificación Pedido

Diccionario de Datos

Diagrama de Contexto

Diagrama de Sistema

www.kybele.urjc.es

Análisis de Transformación Ejemplo

Ingeniería del Software de Gestión

2.1 RECIBIR

HISTORICO VENTAS

HISTORICO VENTAS

HISTORICO

HISTORICO VENTAS RECIBIDO

2.2 RECIBIR PEDIDOS

RELLENADOS

PEDIDO RELLENADO

PEDIDOS

PEDIDO RELLENADO RECIBIDO

1.1 RECIBIR

CATALOGO

CATALOGO CATALOGOS

CATALOGO RECIBIDO

2.3 AJUSTAR PEDIDOS

ALMACEN

HISTORICO VENTAS RECIBIDO

PEDIDO RELLENADO RECIBIDO

1.2 CALCULAR

MEJORES OFERTAS

CATALOGO RECIBIDO

2.4 HACER PEDIDO GLOBAL

MEJORES OFERTAS

PEDIDOS CORREGIDOS

CORREGIDO

CORREGIDO

MEJOR OFERTA

MEJOR OFERTA

PEDIDO GLOBAL

NOTIFICACION PEDIDO

Diagrama de Nivel 2

www.kybele.urjc.es

Análisis de Transformación Ejemplo

Ingeniería del Software de Gestión

2.1 RECIBIR

HISTORICO VENTAS

HISTORICO VENTAS

HISTORICO

HISTORICO VENTAS RECIBIDO

2.2 RECIBIR PEDIDOS

RELLENADOS

PEDIDO RELLENADO

PEDIDOS

PEDIDO RELLENADO RECIBIDO

1.1 RECIBIR

CATALOGO

CATALOGO CATALOGOS

CATALOGO RECIBIDO

2.3 AJUSTAR PEDIDOS

ALMACEN

HISTORICO VENTAS RECIBIDO

PEDIDO RELLENADO RECIBIDO

1.2 CALCULAR

MEJORES OFERTAS

CATALOGO RECIBIDO

2.4 HACER PEDIDO GLOBAL

MEJORES OFERTAS

PEDIDOS CORREGIDOS

CORREGIDO

CORREGIDO

MEJOR OFERTA

MEJOR OFERTA

PEDIDO GLOBAL

NOTIFICACION PEDIDO

Diagrama de Nivel 2

Centro de

Transformación

www.kybele.urjc.es

Análisis de Transformación Ejemplo

Ingeniería del Software de Gestión

2.1 RECIBIR

HISTORICO VENTAS

HISTORICO VENTAS

HISTORICO

HISTORICO VENTAS RECIBIDO

2.2 RECIBIR PEDIDOS

RELLENADOS

PEDIDO RELLENADO

PEDIDOS

PEDIDO RELLENADO RECIBIDO

1.1 RECIBIR

CATALOGO

CATALOGO CATALOGOS

CATALOGO RECIBIDO

2.3 AJUSTAR PEDIDOS

ALMACEN

HISTORICO VENTAS RECIBIDO

PEDIDO RELLENADO RECIBIDO

1.2 CALCULAR

MEJORES OFERTAS

CATALOGO RECIBIDO

2.4 HACER PEDIDO GLOBAL

MEJORES OFERTAS

PEDIDOS CORREGIDOS

CORREGIDO

CORREGIDO

MEJOR OFERTA

MEJOR OFERTA

PEDIDO GLOBAL

NOTIFICACION PEDIDO

Diagrama de Nivel 2

Centro de

Transformación

(otra alternativa)

www.kybele.urjc.es

Análisis de Transformación Ejemplo

Ingeniería del Software de Gestión

Gestión Central

Compras

Recibir Documenta-

ción Almacen

Recibir Histórico

Ventas

Recibir Pedidos

Rellenados

Leer Histórico

Ventas

Leer Pedidos

Rellenados

Recibir Catálogo

Leer Catálogo

Ajustar Pedidos Almacén

Calcular Mejores Ofertas

Hacer Pedido Global

Imprimir Notificación

Pedido

Imprimir Pedido Global

H_V P_R

H_V_R P_R_R Catálogo

P_R_R

H_V_R

C_R P_R_R

H_V_R C_R

Corre- gido M_O

M_O Corregido

Notificación Pedido

Pedido Global

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

Entrada

Centro de Transformación Salida

www.kybele.urjc.es

Análisis de Transformación Ejemplo

Añadimos los acceso a los almacenes de datos

Ingeniería del Software de Gestión

Gestión Central

Compras

Recibir Documenta-

ción Almacen

Recibir Histórico

Ventas

Recibir Pedidos

Rellenados

Leer P_R

Recibir Catálogo

Ajustar Pedidos Almacen

Calcular Mejores Ofertas

Hacer Pedido Global

Impr N_P

Impr P_G

H_V P_R

Cat

M_O

N_P P_G

Leer H_V

Leer Cat

Esc H

H_V_R

Esc P

P_R_R

Esc Cat

C_R

Leer H

Leer Cat

Esc PCo

H_V_R P_R_R

Cgdo

Leer Cat

E/L MO

C_R

M_O

Leer PCo

Cgdo

www.kybele.urjc.es

Análisis de Transacción Ejemplo

Ingeniería del Software de Gestión

USUARIO USUARIO GESTIONAR PISCINA

0

Carnet Entrada

SELEC. TIPO

CARNET 1

TRATAR ESTUDIANTE

2

TRATAR TRABAJADOR

3

Carnet

Carnet

Carnet

Entrada

Entrada

Estudiante

Trabajador

Diagrama de Contexto

Diagrama de Sistema

www.kybele.urjc.es

Análisis de Transacción Ejemplo

Ingeniería del Software de Gestión

Diagrama de Nivel 2

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

www.kybele.urjc.es

Análisis de Transacción Ejemplo

Ingeniería del Software de Gestión

Diagrama de Estructura - Primer Corte -

Carnet

C-Trab

Carnet

C- Est

GESTIONAR TIPO ENTRADA

GESTIONAR

PISCINA

LEER CARNET

GESTIONAR ESTUDIANTE

GESTIONAR TRABAJADOR

Centro de Transacción

Camino 1

Camino 2

Controlador de la Entrada

Módulo Principal

www.kybele.urjc.es

Análisis de Transacción Ejemplo

Ingeniería del Software de Gestión

Diagrama de Estructura - Factorización -

GESTIONAR

ESTUDIANTE

GESTIONAR ESTUDIANTE

COMPROBAR CARNET

ESTUDIANTE

NUMERAR TALON

ESTUDIANTE

ENTREGAR ENTRADA

IMPRIMIR ENTRADA

Carnet_Estudiante Entrada_Estudiante

Entrada

Entrada Estudiante

Carnet Validado

www.kybele.urjc.es

Análisis de Transacción Ejemplo

Ingeniería del Software de Gestión

Diagrama de Estructura - Factorización -

GESTIONAR

ESTUDIANTE

GESTIONAR ESTUDIANTE

COMPROBAR CARNET

ESTUDIANTE

NUMERAR TALON

ESTUDIANTE

ENTREGAR ENTRADA

IMPRIMIR ENTRADA

Entrada_Estudiante

Entrada

Entrada Estudiante

Carnet Validado

Carnet_Estudiante

LEER Carnet Est

Cada camino gestiona su propia entrada

www.kybele.urjc.es

Conclusiones

Principios del Diseño Estructurado

Descomposición de los módulos

Un módulo Una función

Jerarquía de Módulos

Niveles Superiores coordinan Niveles Inferiores

Independencia de los Módulos ≈ Cajas Negras

Ingeniería del Software de Gestión

www.kybele.urjc.es

Conclusiones

Estrategias de Diseño

En función de la estructura inicial del DFD se pueden aplicar dos estrategias, NO excluyentes

Análisis de Transformación

Análisis de Transacción

Ingeniería del Software de Gestión

www.kybele.urjc.es

Conclusiones Análisis de Transformación

Se puede distinguir ◦ Flujo de Llegada o entrada

◦ Flujo ó Centro de Transformación

◦ Flujo de Salida

Pasos 1. Identificar centro de

transformación

2. 1º Nivel de Factorización 1. Controlador Entrada, Transf., Salida

3. 2º Nivel de Factorización 1. Proceso Módulo

4. Revisar la estructura utilizando medidas y guías de Diseño

Ingeniería del Software de Gestión

1.1

2.1

1.2

2.2

3 4.1

4.2

www.kybele.urjc.es

Conclusiones Análisis de Transacción

En función del flujo de llegada, determina la elección de uno o más flujos de información

Pasos

◦ Identificar Centro Transacción

proceso desde el que parten los posibles caminos

◦ Estructura con una bifurcación de Entrada y otra de Salida

◦ Factorizar cada camino

Transacción o Transformación

◦ Refinar la estructura utilizando medidas y guías de Diseño

Ingeniería del Software de Gestión

www.kybele.urjc.es

Bibliografía

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

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

Ingeniería del Software: un enfoque práctico. Pressman, McGraw-Hill, 2002

Guía de técnicas y prácticas de Métrica v.3. http://www.csi.map.es/csi/metrica3/

Ingeniería del Software de Gestión