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