Análisis y Diseño Estructurado
Diagrama de Flujo de Datos
P1
E N T ID AD
EXTERNA
flu jo d e d a to s
P ro c e s o
D
ALM ACÉN DE
DATOS
Docente : Yessica Gómez Gutiérrez
Análisis y Diseño Estructurado
• Introducción - Visión panorámica
del Análisis y Diseño Estructurado.
• Análisis : Diagramas de Flujo de
Datos.
• Diseño: Diagrama de Estructuras
P1
E N T ID AD
EXTERNA
flu jo d e d a to s
P ro c e s o
D
ALM ACÉN DE
DATOS
1.- Introducción:
Visión panorámica del AyDE
Análisis Estructurado
Método clave en el “desarrollo estructurado”
o “convencional”
Aparece a finales de los 70
Facilita la comunicación en el proceso de
desarrollo de un sistema de información
 análisis y diseño
 usuarios y analistas
Sencillo, fácil de entender y fácil de aprender
1.- Introducción:
Visión panorámica del AyDE.
Características
Amplia difusión
Descomposición funcional
(Originariamente) Orientada a procesos
(Originariamente) Top/down
Presente en numerosas metodologías
p.ej. Métrica, SSADM, information
engineering, Merise
Herramientas CASE disponibles
Bibliografía
Texto principal
Mario Piattini,Jose Calvo-Manzano,Joaquín
Cervera,Luis Fernandez, Análisis y diseño
detallado de Aplicaciones Informáticas de
gestión. Edit. Ra-ma
Yourdon, E., Análisis estructurado moderno.
1993: Prentice-Hall Hispanoamericana
Bibliografía (II)
 Entre la bibliografía básica...
 MAP, MÉTRICA versión 2.1. Guía de Técnicas. 1995, Madrid: Ministerio de
Administraciones Públicas. Secretaría de Estado para la Administración Pública.
Consejo Superior de Informática.
 Referencias clásicas...
 DeMarco, T., Structured analysis and system specification. 1979, Englewood
Cliffs, New Jersey: Yourdon Press.
 Gane, C. and T. Sarson, Análisis estructurado de sistemas. 1990, Buenos Aires:
El Ateneo (traducción de Gane, C. and T. Sarson, Structured systems analysis,
tools and techniques. Software series. 1979, New Jersey: Prentice-Hall.)
1.- Introducción:
Visión panorámica del AyDE.
Componentes
DFD (Diagrama de Flujo de Dato Dataflow
diagram)
Diagrama E-R (Entidad-Relación), o
alternativamente, DED (Diagrama de
Estructura de Datos)
 Diagramas HVE (Historia de Vida de las
Entidades)
 Diagramas de Transición de Estados (STD, State
Transition Diagram)
1.- Introducción:
Visión panorámica del AE. componentes
Lógica de procesos
Lenguaje estructurado
Pre y post-condiciones
Tablas de decisión
Árboles de decisión
Diccionario de Datos (DD)
1.- Introducción:
Visión panorámica
del AE. DFD
P1
E N T ID AD
EXTERNA
flu jo d e d a to s
P ro c e s o
D
ALM ACÉN DE
DATOS
 Visión general de las funciones y
transformaciones de datos en una organización
 Modelo lógico y gráfico del sistema
 también como modelo físico
 Identifica entradas, salidas, procesos y relaciones
con el exterior
 ...a nivel general
 ...por refinamiento, a nivel detallado
1.- Introducción:
Visión panorámica del AE. DFD
Tipos de símbolos en los DFDs
(notación de Yourdon/De Marco)
P1
E N T ID AD
EXTERNA
flu jo d e d a to s
P ro c e s o
D
ALM ACÉN DE
DATOS
1.- Introducción:
Visión panorámica del AE. DFD: Ejemplo
Práctico
Ejemplo
Sistema de distribución sin inventario
“Se trata de un sistema que sirve pedidos de libros
a unos clientes, con la particularidad de que no
mantiene un stock o inventario interno. El sistema
puede agrupar los pedidos que clientes distintos
hacen a un mismo editor, de manera que se puedan
conseguir descuentos.”
Adaptado del capítulo 2 de Gane, C. and T. Sarson, Análisis estructurado de sistemas.
1990, Buenos Aires: El Ateneo.
1.- Introducción:
Visión panorámica del AE. DFD: Ejemplo
Práctico
Análisis de los procesos del sistema
 Aplicamos la visión sistémica
Diagrama de contexto
CLIENTE
pedidos
órdenes de compra
libros entregados
en principio, no
son materiales,
son datos
0.
Sistema de
Pedidos
EDITOR
libros pedidos
1.- Introducción:
Visión panorámica del AE. DFD: Ejemplo
Práctico
0. Sistema de pedidos
pedidos
D LIBROS
órdenes de compra
pedidos válidos
1.
Verificar
validez
de pedido
estado del crédito
D CLIENTES
D PEDIDOS
PENDIENTES
pedidos por título
2.
Armar
pedidos
a editores
D ÓRDENES DE
COMPRA
pedidos en lote
dirección
libros entregados
libros entregados =
albarán + lista-novedades
5.
Armar
entrega
a clientes
 DD
libros por
clientes
4.
Asignar
libros a
pedidos
3.
Verificar
envío
de editores
libros
recibidos
libros recibidos =
{título + cantidad}
 DD
libros pedidos
1.- Introducción:
Visión panorámica del AE. Diccionario de
Datos
 “Es un conjunto de metadatos, es decir, de
información (datos) sobre datos”
 Contiene las definiciones de todos los elementos
de los diagramas
 Implementación
 Manual
 Procesador de textos
 Base de datos
 Automático e integrado
1.- Introducción:
Visión panorámica del AyDE. Diccionario de
Datos
Flujo de datos: entrega
Descripción: Conjunto de libros enviados por un
proveedor a la biblioteca, basado en la relación
que previamente había recibido.
Sinónimos: *** none ***
Componente de: *** none ***
Composición:
Libros
+ { Albarán }
Información de entrada y salida
Origen
Destino
*** Off the diagram ***
Compra libros
PROVEEDORES
Biblioteca
Visión panorámica AyDE
Diccionario de Datos (III)
Almacen: Facturas
Descripción: Información, por número de factura, sobre
facturas en el sistema actual.
Sinónimos: *** none ***
Composición:
@Número-factura
+ Fecha-factura
+ Dirección-cliente
+ { Número-producto
+ Cantidad-producto
+ Costo-unidad-producto }
+ Costo-envío
+ Tasa-de-descuento
+ Neto-factura
+ Estado-factura
Procesos asociados: Según DFD general
Proc_cancelación
Proc_consultas
Proc_pago
Adjuntar_albarán
1.- Introducción:
Visión panorámica del AyDE. Pseudocódigo.
Proceso: Verificar estado del socio
Número: 1.1.1
Descripción: Se examina si el socio no está sancionado
Miniespecificación:
Recibir “Socio ID” del socio
Leer “SOCIOS” para
Leer “Flag-de-precaución”
Si OK, enviar “Socio ID válido”
Complejidad:
Ratio de transacciones:
Prioridad:
Memoria requerida (Kb):
Tiempo de proceso:
1.- Introducción:
Visión panorámica del AyDE. Modelado de
Datos
Diagramas E-R y DED (Diagrama de
Estructura de Datos)
DED es, básicamente, un E-R limitado:
no relaciones ternarias
sólo cardinalidades 1:N
no atributos multivaluados ni compuestos
1.- Introducción:
Visión panorámica del AE. Ejemplo de
E/R .
Diagrama E-R
Departamento
(1,n)
[EN2002] (Chen)
pertenece
(1,1)
Empleado
asignado
(0,n)
Proyecto
(1,m)
Departamento
DED
Proyecto
pertenece
Empleado
requiere
tiene
Asignación
1.- Introducción:
Visión panorámica del AyDE. Lógica de
Proceso.
Técnicas para describir la lógica de los
procesos primitivos
Lenguaje estructurado
Pre y post-condiciones
Tablas de decisión
Árboles de decisión
1.- Introducción:
Visión panorámica del AyDE. Lógica de
Proceso.
Lenguaje estructurado
 SI la factura excede de 300€
 SI la cuenta del cliente tiene alguna factura sin pagar más
de 60 días, dejar la confirmación pendiente de este pago.
 SI NO (la cuenta está en buen estado)
hacer confirmación y factura
 SI NO (la factura es de 300€ o menos)
 SI la cuenta del cliente tiene alguna factura sin pagar más
de 60 días hacer la confirmación, la factura y escribir un
mensaje sobre informe de crédito
 SI NO (la cuenta está en buen estado)
hacer confirmación y factura
 FIN-SI.
1.- Introducción:
Visión panorámica del AE. Lógica de
Proceso.
Pre y post-condiciones
Pre1 (la factura excede de 300€) Y (la cuenta del cliente tiene alguna factura sin
pagar más de 60 días)
Pos1 (confirmación pendiente de este pago)
Pre2 (la factura excede de 300€) o (la cuenta del cliente no tiene ninguna factura
sin pagar más de 60 días)
Pos2 (confirmación y factura realizadas)
Pre3 (la factura no excede de 300€) Y (la cuenta del cliente tiene alguna factura
sin pagar más de 60 días)
Pos3 (confirmación y factura realizadas) Y (mensaje impreso sobre informe de
crédito)
Pre4 (la factura no excede de 300€) Y (la cuenta del cliente no tiene ninguna
factura sin pagar más de 60 días)
Pos4 (confirmación y factura realizadas)
1.- Introducción:
Visión panorámica del AyDE. Lógica de
Proceso.
Tablas de decisión
ESTAD O D E LA
CUENTA
N E T O -F A C T U R A
CORRECTO
IM P A G A D O
CORRECTO
IM P A G A D O
>300€
>300€
<=300€
<=300€
C O N F IR M A C IÓ N
P E N D IE N T E
x
HACER
C O N F IR M A C IÓ N
x
x
x
H ACER FACTUR A
x
x
x
E S C R IB IR M E N S A J E
x
1.- Introducción:
Visión panorámica del AyDE. Lógica de
Proceso.
Árboles de decisión
Cuentas impagadas
más de 60 días
Factura
excede de
300€
Cuentas en buen estado
1. Dejar confirmación
pendiente de los pagos
debidos.
2. Hacer confirmación y
factura
Política
contable
Factura
menos de
300€
Cuentas impagadas
más de 60 días
Cuentas en buen estado
3. Hacer confirmación y factura y
escribir mensaje sobre informe de
crédito
4. Hacer confirmación y
factura
¿Y después del AE?
DISEÑO ESTRUCTURADO (DE)
El diseño lógico de los requisitos del nuevo
sistema de información se convierte en un
modelo de la aplicación, plasmado en un
DIAGRAMA DE ESTRUCTURA.
En el paso AE  DE,
 Análisis de transacciones
 Análisis de transformaciones
Diseño Estructurado: DIAGRAMA DE
ESTRUCTURA. Ejemplo de diagrama de
estructuras
Evaluar
peticiones
pet aceptada
informe préstamo
pet aceptada
Recibir
peticiones
pet préstamo
informe préstamo
Elaborar
informe
pet rechazada
pet préstamo
Leer
peticiones
ok
Consultar
stock
Rechazar
petición
Informar
petición
Visión panorámica AE
Esquema resumen
Diagrama de
flujo de datos
B
Z
X
PROC
PROC
PROC
V
Paso al
diseño
Y
FUENTE
Descrip.
E. E.
A
PROC
Descripción
del proceso
W
PROC
Definición
del FD
DESTINO
D ALMACÉN DE
DATOS
Diagrama E-R
(o DED)
Diccionario
de Datos
Definiciones
de la BD
Definiciones de
los módulos
Diagrama de
estructuras
2.- Diagramas de Flujo de
Datos
(DFDs)
Símbolos del DFD
2.- Diagramas de Flujo de
Datos
(notación Yourdon/De Marco)
P
Proceso
Entidad Externa
Flujo de datos
Flujo de eventos
D ALMACÉN DE
DATOS
Transformaciones o procesos
(funciones, cálculo, selección)
Terminadores (Fuentes o Destinos)
(personas, entidades)
Flujos de información
(inputs-outputs)
Flujos de control (Ward & Mellor 85)
Ficheros o depósitos temporales de
información (base de datos, armario,
clasificador, etc.)
Símbolos del DFD
2.- Diagramas de Flujo de
Datos
(notación Métrica/SSADM)
ID
Localización
Proceso
Transformaciones o procesos
Entidad
Externa
Terminadores (Fuentes o Destinos)
Flujo de datos
D
ALMACÉN DE
DATOS
Flujos de información
Ficheros o depósitos temporales de
información
Procesos
2.- Diagramas de Flujo de
Datos
TRANSFORMACIÓN
(cálculo, operación)
FILTRO
(verificación fecha, validación transacción)
DISTRIBUCIÓN
(menú, selección transacción)
E1
P
E2
E3
Transformación
S1
S2
Procesos (II)
2.- Diagramas de Flujo de
Datos
 Nombres únicos, significativos y concisos
 Preferiblemente expresados en función de las
entradas y salidas
 Recomendación:
verbo (no ambiguo) + objeto
 Evitar verbos ambiguos
procesar, gestionar, manejar...
 “objeto” está definido en el DD
 Los procesos se descomponen en “subprocesos”,
hasta llegar a los procesos primitivos
2.- Diagramas de Flujo de
Datos
Diagrama de contexto
Es el DFD más general de todos
Está formado por un solo macroproceso
(el sistema), las entidades externas
(fuentes y destinos) y sus relaciones con
el macroproceso
Delimita el sistema y su entorno
2.- Diagramas de Flujo de
Datos
Entidades externas
Señalan los límites del sistema y
establecen sus relaciones con el entorno
FUENTE
DESTINO
P
FUENTE
FUENTE
Sistema
DESTINO
DESTINO
Los identificadores (nombres) de las entidades externas serán
únicos, significativos y concisos
Flujos de datos
2.- Diagramas de Flujo de
Datos
 Los nombres de los FD deben ser únicos,
significativos y concisos
 Son datos, así que nómbralos como datos.
 Pueden estar indistintamente en singular o en
plural, ya que en los DFDs no se representan
cantidades (Barranco 95)
 Los nombres no sirven sólo para identificar los
datos, sino también la información que se tiene
sobre ellos
P.ej. Información (fecha-válida) > Información (fecha)
2.- Diagramas de Flujo de
Datos
Flujos de datos (II)
Flujos de datos interactivos (dialog flows)
 Cuando dos FD establecen un diálogo o comparten una acción
de estímulo-respuesta, pueden dibujarse como un único FD de
doble flecha, donde ambos extremos deben llevar el nombre del
FD que representan.
P
Determinar
estado
pedido
petición estado pedido
respuesta estado pedido
pago
autorización crédito
P
solicitud crédito
Aceptar pago
recibo
denegación
crédito
P
Analizar
Petición
crédito
2.- Diagramas de Flujo de
Datos
Flujos de datos (III)
Las flechas dobles con sentidos opuestos
que transportan los mismos datos pueden
sustituirse por flechas doblemente
encabezadas
¡Pero sólo si transportan los mismos datos!
P
A
X
X
P
B
P
A
X
P
B
2.- Diagramas de Flujo de
Datos
Flujos de datos (IV)
 Se puede representar, si se desea, el FLUJO DE
MATERIAL, usando flechas de trazo grueso
P1
EDITORIALES
Selecc. y
pedir nuevos
libros
Notación Gane & Sarson
INTERVENTOR
nuevas ofertas
pedidos de libros nuevos
libros nuevos
ajuste de inventario
D3
INVENTARIO
Registrar libros
ajuste de signaturas
nuevos
D4
SIGNATURAS
P3
P2
Examinar
nuevos libros
libros nuevos
nuevos libros
libros nuevos
D9
CARRITO
LIBROS NUEVOS
libros nuevos
D1 LISTA MAESTRA
DE ISBN
P4
P5
Enviar al dpto.
comprador
Poner libros
nuevos en
estantes
libros nuevos
libros nuevos
D2
ESTANTES
2.- Diagramas de Flujo de
Datos
Flujos de datos (V)
Se pueden considerar flechas convergentes o
divergentes, con un mismo nombre
P
A
cod postal
P
Validar
cod postal
dirección cli
telef
número de cuenta
calle
P
B
P
Validar
calle
P
Validar
Telef.
Observaciones:
Sólo los procesos pueden separar FD (Piattini et al. 96)
No poner FD como señales de activación (Yourdon 89)
2.- Diagramas de Flujo de
Datos
Flujos de datos (VI)
Notación System Architect. Ejemplos
FD divergentes (conectores XOR y AND)
P
Imprimir
lista
empaquetado
datos de
P
empaquetado
Determinar datos de envío
prods.para
datos de facturación
enviar
XOR
cuando los datos son
divididos en subconjuntos
P
Imprimir
factura
cliente
P
Rellenar
prescripción
P
Determinar
prescripción
prescripción
AND
cuando todos los datos
siguen por ambos caminos
P
Actualizar
registro
paciente
2.- Diagramas de Flujo de
Datos
Flujos de datos (VII)
Notación System Architect. Ejemplos
FD convergentes (conectores XOR y AND)
P
Aceptar pago
en metálico
P
Confirmar
empleo
datos de pago
P
Aceptar pago
a crédito
XOR
cuando los mismos
datos provienen de
cualquier dirección
P
Transferir
pago
historial
de crédito
P
Confirmar
historial de
crédito
historial de
empleo
historia
combinada
AND
cuando los subconjuntos
son combinados en uno
P
Conceder
tarjeta de
crédito
2.- Diagramas de Flujo de
Datos
Flujos de datos (VIII)
pedido
P
Evaluar pedido
criterios valoración
¿El proceso “pide” el FD “pedido”?
¿El proceso “necesita” ambos FD?
No lo sabemos, no importa:
Los aspectos procedurales no se manifiestan
en los DFDs
Si tales aspectos son relevantes, se deben
incluir en las miniespecificaciones
2.- Diagramas de Flujo de
Datos
Flujos de control
 En los DFDs no se muestra el control ni el orden
de ejecución
 No se puede mostrar:
 Procesos que se realizan antes que otros
 Sincronización
 Periodificación
 Extensiones al AE para sistemas en tiempo real:
 (Ward & Mellor 85)
 (Hatley & Pirbhai 87)
2.- Diagramas de Flujo de
Datos
Almacenes de datos
 Nombre único, significativo y conciso
 Convenciones de nombres en los FD a/desde un
almacén:
 No lleva etiqueta
 El FD se refiere a un paquete (instancia) completo de la
información contenida en el almacén
 La etiqueta es la misma que la del almacén
 El FD se refiere a uno o más paquetes completos
(instancias) de la información contenida en el almacén
 La etiqueta es distinta de la del almacén
 El FD se refiere a uno o más componentes (atributos) de
una o más instancias del almacén
2.- Diagramas de Flujo de
Datos
Consistencia DFD / E-R
(MAP 95)
 Para facilitar validaciones cruzadas entre DFDs y
E-R (o DED)...
 Correspondencia entre los almacenes de datos
“principales” (permanentes) del DFD y las
entidades del E-R
Cada almacén de un DFD representa una o
varias entidades del E-R
Cada entidad del E-R pertenece a un único
almacén principal de un DFD
2.- Diagramas de Flujo de
Datos
Consistencia DFD / E-R (II)
ETIQUETA DE LOS ALMACENES
Según explosione a
 Entidad de datos  Plural nombre entidad
 Diagrama E-R (o DED)  Nombre diagrama
 DEFINICIÓN DE LOS ALMACENES
1. Pocos almacenes
 Para cada uno, diagrama E-R (o DED)
2. Tantos almacenes como entidades se hayan
identificado
 Preferible (si no hay muchas entidades)
2.- Diagramas de Flujo de
Datos
Descomposición funcional
 Cada proceso se puede explotar, refinar o
descomponer en un DFD más detallado
 El DFD de un sistema es realmente un conjunto
de DFDs dispuestos jerárquicamente
 Los niveles de la jerarquía están determinados
por la descomposición funcional de los procesos
 La raíz de la jerarquía es el “diagrama de
contexto”, que es el más general de todos
2.- Diagramas de Flujo de
Datos
Descomposición funcional
A
P
Sist
(II)
DESTINO
B
FUENTE
P
f2
P
f4
X
B
P
f5
Z
V
Y
A
P
f1
P
f3
W
P
f43
x1
x2
P
f41
X
y2
y1
Y
P
f45
P
f42
P
f44
Z
2.- Diagramas de Flujo de
Datos
Consistencia en el DFD
Cada proceso en un diagrama “padre” es
una consolidación del DFD “hijo”
Balanceo de DFDs
Las E/S de un proceso “padre” deben
corresponderse con las E/S del DFD “hijo”
que lo explica
2.- Diagramas de Flujo de
Datos
Descomposición paralela
Descomposiciones de funciones
Proceso en subprocesos (DFD)
Descomposición de flujos de datos
La regla de balanceo se aplica teniendo en
cuenta la descomposición paralela
2.- Diagramas de Flujo de
Datos
Descomposición paralela (II)
 Ejemplo:
pedido = autorización + cupón de pedido + pago
P2
P1
envío
P6
P5
pedido
envío
autorización
P6.2
P4
P3
cupón de
pedido
P6.1
P6.3
pago
2.- Diagramas de Flujo de
Datos
Jerarquía de DFDs
 En un DFD completo cada proceso tiene un
número único que lo identifica en función de su
situación en la jerarquía
 Cada DFD tiene también un número único que
coincide con el proceso que describe
 Las hojas o nodos terminales corresponden a
“procesos primitivos” o indescomponibles
 Para cada proceso primitivo existirá una
miniespecificación.
Localización
Proceso
Proceso primitivo en Métrica
2.- Diagramas de Flujo de
Datos
Jerarquía de DFDs (II)
P 1.2
Proceso A
B
A
DFD 1.2
P 1.2.2
f2
X
V
Y
P 1.2.1
f1
A
W
P 1.2.3
f3
Jerarquía de DFDs
DFD 0
2.- Diagramas de Flujo de
Datos
El primer diagrama general que sigue al
de contexto es el número 0 por convenio
En el DFD 0 se hace una
descomposición en subsistemas, es
decir, se indican los procesos más
importantes en el sistema
 Han de ser SUBSISTEMAS
2.- Diagramas de Flujo de
Datos
Descomposición funcional y
almacenes de datos
Los almacenes aparecen lo más tarde
posible
En un nivel superior únicamente cuando
son interfaz entre procesos
Una vez que aparezca en un DFD, el
almacén aparecerá otra vez en cada DFD
de nivel más bajo relacionado
2.- Diagramas de Flujo de
Descomposición
Datos
funcional y almacenes de
datos (II)
P
A
D
FICH
P
B.1
P
A.1
D
P
A.2
P
B
D
FICH
P
B.2
FICH
2.- Diagramas de Flujo de
Datos
Tamaño de la jerarquía de DFDs
 Cada DFD debería tener alrededor de 7
procesos o menos (Miller 57)
 En general, habrá varios niveles intermedios,
dependiendo del tamaño y complejidad del
sistema que se está modelando
 ¿Cuántos niveles son convenientes?
Yourdon: depende del problema
Métrica
Diagrama
Diagrama
Diagrama
Diagrama
de
de
de
de
contexto / sistema
subsistemas
funciones
subfunciones
Diagrama de procesos (opcional)
2.- Diagramas de Flujo de
Datos
Reglas sintácticas en DFDs
El origen y/o el destino de un FD es
siempre un proceso
 Excepción: almacenes en el diagrama de contexto
(Yourdon 89)
datos del mercado
CLIENTES
CORPORATIVOS
informes anuales
D
CENTROS DE
INVESTIGACIÓN
CLIENTE
datos de
investigación
P
SIST. DE
INVESTIG. DE
MERCADOS
DATOS DEL
MERCADO
datos del mercado
2.- Diagramas de Flujo de
Datos
Reglas sintácticas en DFDs
(II)
Todo almacén y todo proceso tienen uno o
más FD de E y uno o más FD de S
 EXCEPCIÓN: un almacén puede no tener FD de salida,
por simplificación (p.ej. BD Histórica)
 RECOMENDACIÓN: si aparece un proceso fuente o
sumidero, replantearse los límites del sistema
P
Fuente
P
Sumidero
2.- Diagramas de Flujo de
Datos
Ideas útiles para construir el DFD
Identificar todos los elementos exógenos
Identificar sus relaciones con el sistema
Trabajar según alguna de las siguientes
filosofías:
De inputs a outputs
De outputs a inputs
Desde una posición intermedia hacia delante
o hacia atrás
2.- Diagramas de Flujo de
Datos
Ideas útiles para construir el DFD (II)
Nombrar adecuadamente todos los
objetos del DFD
Numerar adecuadamente procesos y
diagramas
Realizar una correcta división en
subsistemas (DFD 0)
Utilizar la descomposición funcional
jerárquica hasta alcanzar las funciones
primitivas
2.- Diagramas de Flujo de
Datos
DFDs - Conclusiones
Valiosa herramienta de comunicación
Usuario, analista, diseñador, programador
Se puede combinar con el uso de prototipos
Fácil de entender y de aprender
Facilita las relaciones con el usuario
Amplia difusión
2.- Diagramas de Flujo de
Datos
DFDs – Conclusiones (II)
 Superado por las metodologías OO,
pero todavía vigente:
 se enseña en 12 de 15 ppales. universidades españolas,casi
todas en Chile
 industria,
 administración (Métrica 2.1 y 3),
 cuerpo de conocimiento de ingeniería del software
(SWEBOK, SEEK, etc.)
 El control no aparece hasta el final de la
especificación estructurada
 No es inmediato el paso a la codificación y
prueba  Diseño estructurado
2.- Diagramas de Flujo de
Datos
DFDs – Conclusiones (III)
Útil para el análisis y para el diseño del
nuevo sistema
Más adecuado para el nivel lógico, aunque
también puede ser adecuado para el nivel
físico (indicando personas concretas,
lugares geográficos, formatos de datos,
etc.)


Diseño Estructurado
Introducción
2.- Diseño: Diagrama de
Estructuras
Concepto y Principios del Diseño
 Inicios del Diseño
 Efectividad del Diseño





Módulo(laridad)
Abstracción
Refinamiento
Factores de calidad


Acoplamiento
Cohesión
Tipos de Acoplamiento
 Tipos de Cohesión
 Consideraciones para un Diseño de Calidad
 Resultados del Diseño

2.- Diseño: Diagrama de
Estructuras

Diseño Arquitectónico ( Diseño Preliminar)




Elementos Diagrama de Estructura
Partición Estructural de un Diagrama de
Estructura
Estrategias de Diseño
Construcción del Diagrama de Estructura
Concepto y Principios del
Diseño
 “ El diseño es un proceso a través del cual los
requerimientos establecidos en la fase de análisis
deben traducirse en una representación -que se
sugiere modular- del producto de software que se
precisa construir y que se acompaña de los
procedimientos en virtud de los cuales cada módulo
debe llevar a cabo su tarea, y de las estructuras de
datos que debe procesar”
 Larry Constantine ‘78
Concepto y Principios del
Diseño
 El diseño estructurado es un método de configuración de
la organización modular del software que se desarrolla a
partir de los flujos de datos que contiene la especificación
de requerimientos obtenida en la fase de análisis bajo
enfoque estructurado.
En este sentido, puede decirse
que este enfoque consiste en el diseño de programas
como estructuras de funciones únicas y de relativa
independencia.
Efectividad del Diseño
Para
poder
evaluar
la
efectividad
de
una
representación de diseño, es preciso establecer lo
que
se
denomina
en
Ingeniería
de
software,
"criterios para un buen diseño", entre los cuales es
posible destacar los siguientes:
• El diseño debe exhibir una organización jerárquica
con
mecanismos de control que no atenten contra
la independencia relativa de cada componente de la
jerarquía.
Efectividad del Diseño
- El diseño debe ser modular, esto es, el software debe
estar particionado lógicamente en elementos que ejecuten
funciones y subfunciones específicas.
- El diseño debe generar módulos que exhiban niveles
adecuados de independencia funcional.
- El diseño debe obtenerse a partir de la especificación de
requerimientos generada durante la fase de análisis.
- Módulo(laridad)
- Abstracción
- Refinamiento
Efectividad del Diseño
- Módulo(laridad)
“Módulo es una unidad claramente definida y manejable que forman
parte de los elementos constituyentes del software”
“La modularidad consiste básicamente en el particionamiento del
software en elementos con nombres y direcciones separadas que se
denominan módulos, los cuales en su composición generan la
totalidad que debe ser capaz de resolver el problema global que da
origen a la necesidad de construir un producto de software. “
Tiene que ver con la separabilidad de las funciones que en conjunto cumplen
un objetivo mayor, esto es, responden a la idea de totalidades emergentes
propia de la noción de sistemas.
Efectividad del Diseño
- Beneficios de la Modularidad
- Programas
más
simples,
ya
que
puede ser
comprendido,
verificado, programado, depurado, mejorado y alterado por partes.
-
Módulos
que
pueden
ser
desarrollados
con
relativa
independencia.
- Disminución
de la posibilidad de errores al reducir la
complejidad.
- Programas que pueden evaluarse por partes, por lo cual todo test
se hace más fácil.
- Programas más fáciles de alterar ya que son menores las
líneas de código a considerar para incorporar los cambios.
- Módulos de función única que pueden ser reutilizados.
Efectividad del Diseño
- Beneficios de la Modularidad
- La
posibilidad de cometer errores por parte de los programadores
disminuye porque son menos las líneas de código que deben enfrentarse
al mismo tiempo.
- La rotación de personal se hace menos crítica, ya que los
programadores están involucrados en unidades de código más pequeñas
por lo cual la sustitución resulta menos dificultosa.
- Responder al requerimiento de la división del código en segmentos de
una página, como lo sugiere la programación estructurada, es casi total.
Efectividad del Diseño
- Módulo
El Fan-out es una medida del número de módulos controlados
directamente por otro módulo (número de subordinados inmediatos
que posee). El Fan-in indica cuántos módulos controlan
directamente un determinado módulo (número de superiores
inmediatos que posee)
Un
módulo
que
controla
a
otro
se
dice
que
es
"superordinado" a éste y, recíprocamente, un módulo controlado
por otro se dice que es "subordinado".
Efectividad del Diseño
- Módulo
Módulo Superordinado
Módulo Subordinado
Fan-out : 2
Fan-in : 1
Efectividad del Diseño
- Módulos & Integración
Costos
o Esfuerzo
Costo Total SW
Costo por Integración
Costo por Módulo
N° Módulos
Costos Mínimos
Efectividad del Diseño
- Abstracción
“Cuando se considera una solución modular para enfrentar un
problema, se puede plantear en distintos niveles de abstracción.
Un nivel superior de Abstracción supone una solución en
términos amplios, usando un lenguaje del entorno del problema.
A un niveles más bajos, se toma una orientación más
procedimental, se combina una
terminologia orientada al
problema con una orientada a la implementación. El nivel más
bajo
de
abstracción
permite
implementarse directamente”
que
la
solución
pueda
Efectividad del Diseño
- Refinamiento
El refinamiento gradual es una estrategia de diseño top_down cuyo origen
es la propuesta de Niklaus Wirth (WIRTH-71) quien postula que "La
arquitectura de un programa se desarrolla refinando sucesivamente los
niveles de detalle de los procedimientos. De este modo se desarrolla una
jerarquía de procedimientos al descomponer sucesivamente una sentencia
global hasta alcanzar sentencias específicas a nivel de un lenguaje de
programación".
R. Pressman (PRESSMAN-88) al respecto cita a Wirth señalando que: "En
cada etapa (del refinamiento), se descomponen una o varias de las
instrucciones del programa dado en instrucciones cada vez más detalladas.
Esta descomposición o refinamiento sucesivo termina cuando todas las
intrucciones están expresadas en términos de cualquier lenguaje básico de
computador o de programación.
Efectividad del Diseño
- Refinamiento
En el dominio de la Ingeniería de Software, la modularización se
apoya en lo que se conoce como refinamiento sucesivo o
gradual, para la configuración de la estructura del software que
se precisa diseñar y luego construír.
Refinamiento
Gradual
Abstracción
Módulo A
Modularidad
A1
A2
Factorización
Factores de Calidad
- Acoplamiento
Corresponde al grado de independencia entre dos módulos. Entendido
así,
minimizar
el
acoplamiento
aparece
entonces
como
una
determinante prioritaria al configurar las conformaciones estructurales.
La obtención de módulos tan independientes como sea posible,se
puede ser lograda principalmente de tres maneras:
- Eliminando relaciones innecesarias.
- Reduciendo el número de relaciones necesarias.
- Debilitando la dependencia de las relaciones necesarias.
Factores de Calidad
-
Cohesión
Corresponde a la medida de relación funcional de los elementos de un
módulo, Los elementos de un módulo corresponden a instrucciones,
definiciones de datos, o llamadas o otros módulos. La idea es
organizar estos elementos de tal manera que tengan una mayor
relación entre ellos a la hora de realizar la tarea específica del módulo
Factores de Calidad
Acoplamiento
Cohesión
Principios de un
Buen Diseño
Tipos de Acoplamiento
1. Acoplamiento Normal
2. Acoplamiento por Datos
3. Acoplamiento por Estampado o Imagen
4. Acoplamiento de Control
5. Acoplamiento Común
6. Acoplamiento por Contenido
Tipos de Acoplamiento
Mejor Acoplamiento
NORMAL
DATOS
ESTAMPADO
CONTROL
EXTERNO (caso especial de COMÚN)
COMÚN
CONTENIDO
Grado de
Acoplamiento
Tipos de Acoplamiento
1.Acoplamiento Normal
Dos Módulo A y B están Normalmente Acoplados si:
•
•
Un Módulo A llama a otro B
B retorna el control a A
No se produce traspaso de parámetros entre ellos, sólo existe la
llamada de uno a otro.
A
B
Tipos de Acoplamiento
2. Acoplamiento por Datos
Obtener
Datos
Cliente
Dos módulos están acoplados por
datos si ellos se comunican por
parámetros, siendo cada parámetro
Rut_cliente
una unidad elemental de datos
El
acoplamiento
por
datos
corresponde a la comunicación de
datos necesaria entre módulos. Toda
vez que los módulos tienen que
comunicarse entre sí,
la ligazón por
datos es inevitable y serán adecuadas
si se mantienen a niveles mínimos.
Leer Rut
Tipos de Acoplamiento
3. Acoplamiento por Estampado
Calcular
Deuda
Cliente
o Imagen
Dos
módulos
acoplados
por
aparecen
estampado
o
ligados por imagen si ellos se
Cliente
refieren a la misma estructura
datos local. Cabe destacar que
Leer Cliente
por estructura de datos se debe
entender un grupo compuesto
de datos, tal como un registro,
el
cual,
por
su
parte,
constituye de varios campos.
se
Cliente= rut+nombres+apellido_paterno+
Apellido_materno+dirección+fono+e_mail
Tipos de Acoplamiento
4. Acoplamiento de Control
Dos módulos están acoplados
Obtener
Datos
Cliente
por control cuando uno de ellos
pasa al otro módulo elementos
Tipo_dato
Cliente
de control (flags, switchs) como
Leer Cliente
argumentos.
Provoca
dependencia
de
ejecución entre un módulo y
otro.
No es muy recomendable.
Tipos de Acoplamiento
5. Acoplamiento Común
Los
módulos
Actualizar
Stock
Video
Obtener
Nombre
Video
presentan
acoplamiento común, si ellos
se refieren a la misma área
estructura de datos (global).
Cuando sólo se acomplan por
video
una variable (global), se trata
de un Acoplamiento Externo
Programas con muchos datos globales son
extremadamente difíciles de entender por
los programadores de mantención, porque
no es fácil saber cuáles son los datos
usados por un cierto módulo.
Leer Registro
Video
Tipos de Acoplamiento
6. Acoplamiento por Contenido
Este es un tipo de Acoplamiento
Inaceptable.
acoplamiento
Dos módulos presentan
de
contenido
(o
patológico) si uno hace referencia al
interior del otro. Esto ocurre si por
A
B
………..
Srch: Move..
………..
……….
……….
………
………..
………
………..
Jump to Srch
……….
………
ejemplo, en un módulo se desvía la
secuencia de instrucciones al interior
de otro o si un módulo altera un
Tal acoplamiento torna el concepto de
comando de otro.
módulos configurados bajo el criterio de la
caja negra sin sentido, ya que fuerza a un
módulo a conocer explícitamente los
contenidos y la implementación de otro.
Tipos de Acoplamiento
Dos módulos pueden estar relacionados por más de un tipo de
acoplamiento. Si esto ocurre, el acoplamiento que caracteriza la relación
entre ellos queda definido por el peor tipo que presenten. Por ejemplo, si
dos módulos están ligados por acoplamiento de imagen y acoplamiento
común a la vez, se dirá que los módulos están ligados por acoplamiento
común.
Enfoques: ¿Cómo Analizar el Tipo de
Acoplamiento?
• Imaginar el Módulo como una Biblioteca
• Cada Módulo es codificado por un programador diferente
Tipos de Cohesión
Mayor Cohesión
FUNCIONAL
Módulo como
Caja Negra
SECUENCIAL
COMUNICACIONAL
PROCEDURAL
TEMPORAL
Módulo
Transparente
LÓGICA
COINCIDENTAL
Grado de
Cohesión
STEVEN, MYERS, CONSTANTINE y YOURDON (1974)
establecieron "una escala de cohesión"
Tipos de Cohesión
1. Cohesión Funcional
Ejemplos
Se puede decir que un
módulo
con
cohesión
funcional
es
aquel
que
contiene
elementos
que
contribuyen a la ejecución
de una y sólo una tarea
relacionada
al
objeto de diseño,.
problema
• Calcular el coseno de un ángulo
•Calcular el I.V.A. De una factura
•Verificar el dígito de un RUT
Tipos de Cohesión
2. Cohesión Secuencial
Ejemplo: Calcular Salario
Un
módulo
cohesionado
secuencialmente
es
aquel
cuyos
1. Obtener sueldo base
2. Verificar número de cargas
elementos están envueltos en
3. Revisar días con permiso
actividades tales que los datos
4. Revisar días con licencia
de salida de una actividad sirven
5. Calcular horas de trabajo
como datos de entrada para la
6. Descontar horas de atraso
próxima actividad.
7. Agregar horas extras
....
Tipos de Cohesión
3. Cohesión Comunicacional
Ejemplo:
Un módulo presenta cohesión
comunicacional
elementos
cuando
contribuyen
sus
a
Obtener
datos
Video
1. Obtener nombre video
2. Obtener stock video
actividades que usan la misma
3. Obtener ubicación
entrada o la misma salida. No
4. Obtener precio
importa el orden secuencial
....
Tipos de Cohesión
4. Cohesión Procedimental
un módulo cohesionado por
Ejemplos:
procedimientos es aquel cuyos
una oficina
elementos están envueltos en
actividades
diferentes
y
posiblemente no relacionadas,
en donde el control fluye de
una actividad a otra.
Actividades en
1. Hablar por teléfono
2. Tomar un café
3. Leer correo electrónico
4. Solicitar cotización
....
Tipos de Cohesión
5. Cohesión Temporal
Ejemplo:
Un
módulo
temporal
es
con
cohesión
aquel
que
iniciar el día
cuyos
elementos están envueltos en
actividades
Actividades
están
relacionadas en función del
1. Apagar despertador
2. Tomar una ducha
3. Vestirse
4. Hacer la cama
momento en que se realizan.
5. Tomar desayuno
....
al
Tipos de Cohesión
6. Cohesión Lógica
Un
módulo
lógica,
tiene
cohesión
Ejemplo: Registrar Pago
cuando existe alguna
relación entre los elementos
del módulo,
1. Registrar pago con tarjeta de
crédito
contribuyendo al
desarrollo de actividades de
2. Registrar pago con cheque
una misma categoría general,
3. Registrar pago con efectivo
donde
....
la
actividad
o
las
actividades a ser ejecutadas se
seleccionan desde fuera del
módulo.
Tipos de Cohesión
7. Cohesión Coincidental
Un módulo coincidentemente
cohesionado es aquel cuyos
elementos
actividades
desarrollan
sin
significativa entre sí.
relación
Ejemplo:
1. Comprar un libro
2. Comer un trozo de torta
3. Ir al teatro
4. Lavar la ropa
5. Dormir
....
Árbol de Cohesión
Consideraciones Importantes
para un Diseño de Calidad
La factorización consiste en separar la funcionalidad de un módulo, en
subfunciones claramente identificables, en términos tales que sea posible
considerarla como constitutiva de un módulo independiente.
1. La necesidad de reducir el tamaño de un módulo.
2. Obtener las ventajas de la modularización mediante un diseño
"top_down". => Sistema más comprensible el sistema y facilitamiento de
cambios
3. Evitar que una misma función aparezca en diferentes partes del
sistema, es decir, en más de un módulo.
4. Proveer módulos de uso general.
5. Simplificar la implementación.
Reducir el Tamaño de un
Módulo
1. De Marco señala,
un tamaño razonable para un módulo
corresponde a un conjunto de líneas de código de alrededor de
media página de listado (30 líneas más o menos),
2. Page-Jones, señala que toda la codificación de un módulo
debería, idealmente, ser visible en una página de listado (una
exigencia que impone un límite no superior a 60 líneas)
3. Geral Weinberg (WEI-72) muestran que la habilidad del hombre
para entender un módulo y encontrar errores depende de la
capacidad de aprehender el módulo como un todo de una sola vez.
Resultados del Diseño
El proceso de diseño debe lograr la determinación de las directrizes
en virtud de las cuales el producto de software ha de construirse,
tomando como base la especificación de requerimientos generada en
la fase de análisis. Así, entonces, el diseño, en cuanto proceso, debe
dar como resultado:
• el Diseño de la Arquitectura del producto de software a construir.
• la Especificación de los Procedimientos del software a construir.
• el Diseño de los Datos involucrados
• el Diseño de la Interfaz de usuario
Diseño Arquitectónico
Diccionario de Datos

Clave_votante_válida: Flag que indica que la
combinación ingresada por el cliente es válida, y
puede llevar a emitir su voto.
Especificación de procesos
Interfaz
 Nombre : REGISTRAR DATOS
ACTUALIZACIÓN
 Entradas : Datos_actualización
 Salidas
:Datos_actualización,
datos_actualización_registrados.
 Procedimiento:
 Recibir Datos_actualización.
 Abrir archivo INFORMACIÓN MUNICIPAL.
 Escribir en archivo los Datos_actualización.
 Cerrar archivo INFORMACIÓN MUNICIPAL.
 Mandar mensaje indicando
Datos_actualización_registrados.
Pseudocódigo
Diseño de Datos
c la v e _ Vo t
N o m _ Can d
I d_ Vo t o
N o m _ Can d
P art _ Can d
I d_ P a r t ido
R ut _ Vo t
c a n dida t o s
Vo t o
Vo t a n t e
N o m _ Vo t
c o n t ie n e
a sign a
c o n sult a
N o m _ Can d
D ir e c c ió n
Se r v ic io s
M un ic ip a lida d
Fo n o
N o m _ O r ga n
I d_ O r ga n
C o m un a
Diseño de Datos
Votante
Clave_Vot A10
Rut_Vot
A10
Nom_Vot
A30
Voto
Id_Voto A10
Detalle_Voto
Id_Voto
A10
Id_Partido A30
Servicio
Cod_Serv
N5
Descrip_Serv A30
Candidato
Id_Partido
Nom_Cand
Municipalidad
Id_Orga
A10
Nom_Orga A30
Servcio
A30
Dirección
A30
Fono
N10
Comuna
A20
A30
A30
Diseño de Interfaz
Elementos del Diagrama de
Estructura
Obtener
Nombre
Video
Leer Registro
Video
X
Y
Módulo
Módulo
Predetermina
do
MÓDULO JEFE
(INVOCADOR)
MÓDULO SUBORDINADO
(INVOCADO)
Elementos del Diagrama
de Estructura
Obtener
Datos
Cliente
Tipo_dato
Cliente
Flujo de Control
Flujo de Dato
Leer Cliente
Un dispositivo físico es cualquier dispositivo
mediante el cual se puede recibir o enviar datos
necesarios para el sistema
Un almacén de datos corresponde a la instancia real
en la cual van a estar los datos que precisa el sistema
Elementos del Diagrama de
Estructura
Conectores
Elementos del Diagrama de
Estructura
Secuencia
Iteración
Elementos del Diagrama de
Estructura
Selección
Profundidad y Ancho de un
Diagrama de Estructura
Profundidad y ancho
proporcionan una idea del
número de niveles de control
y el ámbito global de control
respectivamente.
El grado de salida es una
medida del número de
módulos que son controlados
directamente por otro
módulo.
El grado de entrada indica
cuántos módulos controlan
directamente un módulo
dado.
Estrategia de Diseño para
Construir Diagrama de
Estructura
Diseño Centrado en
Transformaciones
DFD
Diseño Centrado en
Transacciones
Análisis
Diseño
Diagrama de
Estructura
Estrategia de Diseño
Diseño Centrado en
Transformaciones
1.1
1.2
3
• Los datos entran al sistema
mediante caminos que se llaman
4.1
2.1
2.2
flujos de entrada
4.2
• En el núcleo ocurre la
transformación de los datos, que
entraron anteriormente
•Finalmente los datos se mueven
por caminos llamados flujos de
salida
Flujo de Llegada
Flujo de
Centro
Salida
de
Transformación
Estrategia de Diseño
Diseño Centrado en
Camino de
Acción 1
Transacciones
2.1
• Se presenta un centro de
2.2
transacción, como centro de
flujo de información
1
• Desde el centro de flujo de
Información, surgen muchos
caminos de acción alternativos
•Los caminos de acción
alternativos, son de forma
excluyentes
3.1
3.2
4.1
4.2
Camino de
Acción 2
Centro
de
Transacción
Camino de
Acción 3
Estrategia de Diseño:
Transformación
1. Revisión del Modelo Fundamental del sistema
DFD, mínimo tres niveles
2. Determinar si el DFD tiene características de Transformación o
Transacción
Analizar el centro de transformación propiamente tal
3. Aislar el centro de Transformación, especificando los límites del
flujo de llegada y de salida
Delimitar
diseñador)
el
centro
de
transformación
(depende
del
4. Realizar el primer corte del diagrama de estructura
Primer nivel de factorización, se incorporan módulos
coordinadores
Estrategia de Diseño:
Transformación
•Módulos a incorporar
1.1
• Módulo principal Cp, que
controla
el
resto
de
3
los
2.1
módulos
•Módulo
coordinador
de
1.2
la
Información de Entrada, Ce
4.1
2.2
Centro
4.2
de
Flujo de Llegada
Transformación Flujo de
Salida
•Módulo controlador del centro
de
transformación,
que
Diagrama de
Contexto
supervisa las operaciones de
Cp
los datos, Ct
•Módulo
controlador,
procesamiento
de
del
Ce
Ct
la
información de salida, Cs
Nombres representativos
Cs
Estrategia de Diseño:
Transformación
5. Ejecución del “segundo nivel de factorización”
a
1.1
1.2
3
b
2.1
4.1
2.2
Cp
z
Centro
4.2
de
Flujo de Llegada
Transformación Flujo de
Salida
Ce
1.2
2.2
1.1
2.1
Leer a
Leer b
Ct
3
Cs
4.1
4.2
Escribir
z
Estrategia de Diseño:
Transformación
6. Refinar la estructura obtenida, utilizando las guías, principios y
conceptos, para un diseño de calidad
Aumentar o Disminuir el N° de módulos (ejemplo Ct)
Incorporar flujos de datos (DFD) y de control
7. Asegurarse del trabajo realizado, representado en el diseño
construido
Verificar funcioanalidad, orden de módulos, etc.
Estrategia de Diseño:
Transacción
1. Revisión del Modelo Fundamental del sistema
DFD, mínimo tres niveles
2. Determinar si el DFD tiene características de Transformación o
Transacción
Analizar el centro de transacción propiamente tal
3. Aislar el centro de Transacción, especificando los límites del flujo
de llegada y de salida
El centro de transacción se encuentra ligado al origen de
varios caminos de información que fluyen radialmente de él
4. Realizar el primer corte del diagrama de estructura
Primer nivel de factorización, se incorporan módulos
coordinadores
Estrategia de Diseño:
Transacción
•Módulos a incorporar
• Módulo principal Cp, que
controla
el
resto
de
a
A
D
los
módulos
•Módulo
z
P
coordinador
de
Q
la
R
b
Información de Entrada, Ce
•Módulo gestor del centro de
Cp
transacción, D
•Módulo
controlador,
los
distintos caminos que generan
Ce
D
información de salida,
Ci
i =1—n (n: n° caminos)
C1
C2
C3
Estrategia de Diseño:
Transacción
5. Ejecución del “segundo nivel de factorización”
Camino 1
Cp
a
A
Camino 2
D
D
Ce
P
b
Q
R
z
a
Camino 3
C1
C2
C3
Leer a
P
Leer b
Q
R
Escribir
z
Estrategia de Diseño:
Transacción
6. Refinar la estructura obtenida, utilizando las guías, principios y
conceptos, para un diseño de calidad
Aumentar o Disminuir el N° de módulos
Incorporar flujos de datos (DFD) y de control
7. Asegurarse del trabajo realizado, representado en el diseño
construido
Verificar funcionalidad, orden de módulos, etc.

Diseño Procedimental (Diseño
Detallado
Especificación Interfaz-Función
Especificación Mediante las
Miniespecificaciones del Análisis
Especificación por Pseudocódigo

Diseño Detallado
1. Especificación por interfaz-función
Permite definir un módulo sin entrar en excesivos detalles. La interfaz del
módulo contiene los parámetros de entrada y de salida, mientras la función
del módulo describe las tareas que este lleva a cabo. Se permite el uso de
tablas, fórmulas, lenguaje natural, etc. Permite variar el grado de
formalismo en la definición del módulo, generalmente, dando bastante
libertad a los programadores. Su inclusión como comentario en el código
final facilita el mantenimiento.
Ejemplo:
Módulo: SELECCIONAR ASIENTO DE PASAJERO
Entrada: PREFERENCIA_ASIENTO_PONDERADA
Salidas: ASIENTO_SELECCIONADO, PREFERENCIA_DISPONIBLE
Función: Seleccionar un asiento para un pasajero considerando que sus
preferencias de ubicación sean lo más cercanas (ponderadamente) al asiento
elegido.
Diseño Detallado
2. Especificación Mediante las Miniespecificaciones del Análisis
Este método
considera que las miniespecificaciones
generadas durante la fase de análisis sirven también
como
especificación
general,
que
diagrama
de
especificar
la
de
módulos.
especificación
flujo
de
datos
de
es
Se
considera,
cada
burbuja
suficiente
en
del
para
lo que en la fase siguiente al diseño se
debe construir. La gran limitación de este método es
que no siempre existe una correspondencia uno a uno
entre las burbujas, explicitadas como necesarias de
automatizar en la fase de análisis, y los módulos del
diagrama de estructura.
Módulo: SELECCIONAR ASIENTO DE PASAJERO
Entrada: PREFERENCIA_ASIENTO_PONDERADA
Salidas: ASIENTO_SELECCIONADO, PREFERENCIA_DISPONIBLE
Función: Seleccionar un asiento para un pasajero considerando que sus
preferencias deubicación sean lo más cercanas (ponderadamente) al asiento
elegido.
Detalles de Funcionalidad
Buscar asiento disponible comenzando con la clase solicitada y continuando
con clases inferiores.
Anotar para cada asiento la diferencia respecto a la preferencia del cliente.
Seleccionar el asiento con menor diferencia: este será el AsientoSeleccionado.
(Diferencia=Dif-Fumador*PESO_FUMADOR+ ...)
Si el cliente necesita un asiento no fumador (y Peso-Fumador > 1) y ha sido
seleccionado un asiento fumador, intentar mover en una fila atrás la sección de
no fumadores en la clase del cliente (si es posible).
Si la diferencia entre el asiento preferido y el asiento seleccionado es 0,
realizar la asignación PREFERENCIA-DISPONIBLE=”Y”; de lo contrario
asígnele “N”.
Diseño Detallado
2. Especificación por pseudocódigo
Pseudocódigo es un lenguaje informal similar al lenguaje estructurado, el
cual es más preciso y detallado que la especificación por interfaz-función.
Tiene sintaxis fija para constructores, declaración de datos y módulos, y
sintaxis libre para describir características de procesamiento
Descargar

Análisis de requisitos. Análisis Estructurado