Ad Analisis Estructurado PDF

Fundamentos de
Ingeniería del Software
Capítulo 3. Análisis de Requisitos

Análisis Estructurado
Situación en el
programa de teoría
1. Actividades iniciales.
2. Técnicas de recogida de la información.
3. Requisitos y análisis de requisitos.
4. Actividades generales de análisis de requisitos.
5. Documentos de especificación de requisitos.
6. Análisis estructurado.
7. Introducción a los casos de uso.
8. Prototipado.
6.1. Introducción – Visión
panorámica del AE
ANÁLISIS ESTRUCTURADO
6.1. Introducción - Visión panorámica del AE
6.2. Diagramas de flujo de datos
6.3. Diccionario de datos
6.4. Modelado de la lógica de los procesos
6.5. Modelado de datos
6.6. Historia de vida de las entidades
6.7. El proceso de Yourdon
Introducción
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
Características principales
Amplia difusión
Descomposición funcional
(Originariamente) Orientada a procesos
(Originariamente) Top/down
(Originariamente)
Presente en numerosas metodologías
p.ej. Métrica, SSADM, information
engineering, Merise
Herramientas CASE disponibles
Bibliografía
Texto de referencia
Yourdon, E., Análisis estructurado moderno. 1993: Prentice-Hall
Hispanoamericana
− Introducción
• Capítulo 4. Herramientas del análisis estructurado
• Capítulo 7. Cambios en el análisis de sistemas
− Técnicas
• Capítulo 9. Diagramas de flujo de datos.
• Capítulo 10. El diccionario de datos.
• Capítulo 11. Especificaciones de proceso.
• Capítulo 14. Balanceo de modelos.
− El proceso de análisis
• Capítulo 17. El modelo esencial.
• Capítulo 18. El modelo ambiental.
• Capítulo 19. Construcción de un primer modelo de comportamiento.
• Capítulo 20. Completando el modelo de comportamiento.
Bibliografía (II)
Entre la bibliografía básica...

Piattini, M., et al., Análisis y diseño detallado de Aplicaciones Informáticas de
Gestión. 2004: Ra-ma.
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.
En castellano y en la biblioteca...
Barranco de Aruba, J., Metodología del Análisis Estructurado de Sistemas (2ª
edición). 2001, Madrid: Publicaciones de la Universidad Pontificia de Comillas.
Hawryszkiewycz, I. T. Introducción al análisis y diseño de sistemas con
ejemplos prácticos. 1ª ed., Madrid : Anaya Multimedia, 1990.
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.)
AE utiliza...
Modelado funcional
DFD (Diagrama de Flujo de Datos, Dataflow diagram)
Modelado de datos
Diagrama E-R (Entidad-Relación), o alternativamente,
DED (Diagrama de Estructura de Datos)
Modelado del comportamiento
Diagramas HVE (Historia de Vida de las Entidades)
Diagramas de Transición de Estados (STD, State Transition
Diagram)
AE utiliza...
Lógica de procesos
Lenguaje estructurado
Pre y post-condiciones
Tablas de decisión
Árboles de decisión
Diccionario de Datos (DD)
Visión panorámica AE
DFDs
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
DFDs (II)
Tipos de símbolos en los DFDs

(notación de Yourdon/De Marco)
P1
ENTIDAD Proceso
EXTERNA
flujo de datos D ALMACÉN DE

DATOS
DFDs (III)
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.
DFDs (IV)
Análisis de los procesos del sistema

⇒ Aplicamos la visión sistémica
Diagrama de contexto
CLIENTE pedidos
órdenes de compra
libros entregados
0.
Sistema de
Pedidos EDITOR
en principio, no
son materiales, libros pedidos
son datos
DFDs (V)
0. Sistema de pedidos
pedidos
D LIBROS
órdenes de compra
pedidos válidos 2.
1.
Armar
Verificar D PEDIDOS
estado del crédito pedidos
validez PENDIENTES D ÓRDENES DE
a editores
de pedido COMPRA
D CLIENTES pedidos en lote
pedidos por título
dirección
4. 3.
5. libros por Asignar libros Verificar libros pedidos
Armar clientes libros a recibidos
libros entregados envío
entrega pedidos de editores
a clientes
libros entregados = libros recibidos =
albarán + lista-novedades {título + cantidad}
∈ DD ∈ DD
DFDs (V)
0. Sistema de pedidos
pedidos
D LIBROS
órdenes de compra
pedidos válidos 2.
1.
Armar
Verificar D PEDIDOS
estado del crédito pedidos
validez PENDIENTES D ÓRDENES DE
a editores
de pedido COMPRA
D CLIENTES pedidos en lote
pedidos por título
dirección
4. 3.
5. libros por Asignar libros Verificar libros pedidos
Armar clientes libros a recibidos
libros entregados envío
entrega pedidos de editores
a clientes
DFDs (VI)
El DFD del ejemplo pertenece al nivel lógico
un FD puede estar contenido en una nota, una factura, una
llamada telefónica, etc.
un almacén de datos puede ser una BD o un fichero en papel
no se dice qué deberá ser automático o manual.
... en el nivel lógico
se evita caer en decisiones físicas prematuras
se maneja la complejidad
En un DFD 0 real, se haría una auténtica división en
subsistemas
Se obvian los FD de error
En el ej. no se muestran las funciones de creación,
mantenimiento y consulta de almacenes de datos
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 ⇐
Diccionario de Datos (II)
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
Diccionario de Datos (III)
Fichero o base de datos: 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_pago
Proc_consultas Adjuntar_albarán
Diccionario de Datos (IV)
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: Prioridad:
Ratio de transacciones: Memoria requerida (Kb):
Tiempo de proceso:
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
Por defecto, usaremos diagramas E-R
DED. Ejemplo
Departamento
Diagrama E-R
(1,n) [EN2002] (Chen)
pertenece
(1,1)
Empleado asignado Proyecto
(0,n) (1,m)
Departamento Proyecto
DED pertenece requiere
Empleado tiene Asignación

Lógica de procesos
Técnicas para describir la lógica de los

procesos primitivos
Tablas de decisión
Lógica de procesos (II)
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.
Lógica de procesos (III)
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)
Lógica de procesos (IV)
Tablas de decisión
ESTADO DE LA CORRECTO IMPAGADO CORRECTO IMPAGADO
CUENTA
NETO-FACTURA >300€ >300€ <=300€ <=300€
CONFIRMACIÓN x
PENDIENTE
HACER x x x
CONFIRMACIÓN
HACER FACTURA x x x
ESCRIBIR MENSAJE x
Lógica de procesos (V)
1. Dejar confirmación
Cuentas impagadas pendiente de los pagos
más de 60 días debidos.
Factura
excede de
300€ Cuentas en buen estado 2. Hacer confirmación y
factura
Política
contable
3. Hacer confirmación y factura y

Factura Cuentas impagadas escribir mensaje sobre informe de
menos de más de 60 días crédito
300€
Cuentas en buen estado 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
Ejemplo de diagrama de
estructuras
Evaluar
peticiones
pet aceptada informe préstamo

pet aceptada informe préstamo
Recibir Elaborar Informar

peticiones informe petición
pet préstamo pet rechazada
pet préstamo ok
Leer Consultar Rechazar

peticiones stock petición
Esquema resumen
Diagrama de B DESTINO
flujo de datos Z PROC
X
PROC PROC
V
Y Paso al
FUENTE A PROC W diseño
PROC D ALMACÉN DE
DATOS Diagrama de
estructuras
Descrip. Descripción Definición

E. E. del FD
del proceso Diagrama E-R
(o DED)
Diccionario
de Datos
Definiciones
de la BD
Definiciones de
los módulos
Proceso de aplicación
Aproximación “clásica”
1. Análisis del sistema actual
− Modelo físico, modelo lógico
2. Análisis de requisitos del nuevo sistema
3. Diseño de soluciones alternativas
4. Evaluación de las soluciones
5. Selección y documentación de una solución
6. Diseño estructurado
7. Codificación y pruebas
6.2 Diagramas de Flujo de
Datos (DFDs)

Símbolos del DFD
(notación Yourdon/De Marco)
P
Proceso Transformaciones o procesos (funciones,
cálculo, selección)
Entidad Externa Terminadores (Fuentes o Destinos)

(personas, entidades)
Flujo de datos
Flujos de información
(inputs-outputs)
Flujo de eventos Flujos de control (Ward & Mellor 85)
Ficheros o depósitos temporales de

D ALMACÉN DE
DATOS
información (base de datos, armario,
clasificador, etc.)
Símbolos del DFD
(notación Métrica/SSADM)
ID Localización
Proceso Transformaciones o procesos
Entidad Terminadores (Fuentes o Destinos)

Externa
Flujo de datos Flujos de información
D ALMACÉN DE Ficheros o depósitos temporales de

DATOS
información
Procesos
TRANSFORMACIÓN
(cálculo, operación)
FILTRO
(verificación fecha, validación transacción)
DISTRIBUCIÓN
(menú, selección transacción)
E1 S1
P
Transformación
Un consejo: Keep it simple!

E2 S2
E3
Procesos (II)
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
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
Entidades externas
Señalan los límites del sistema y
establecen sus relaciones con el entorno
FUENTE DESTINO
P
FUENTE Sistema DESTINO
FUENTE DESTINO
Los identificadores (nombres) de las entidades externas serán

únicos, significativos y concisos
Límites del sistema
Actividad crítica y difícil
Puede haber problemas,
tanto por ser demasiado ambicioso, como poco ambicioso
Entorno Facturación
P Gestión de
Sistema caja (pagos)
de
pedidos
Información
sobre el crédito
Gestión del
Entorno
almacén
Flujos 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)
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 petición estado pedido
estado
pedido respuesta estado pedido
pago denegación
autorización crédito crédito
P P
Aceptar pago solicitud crédito Analizar
Petición
recibo crédito
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 X P P P
A B A B
X
X
Flujos de datos (IV)
Se puede representar, si se desea, el FLUJO DE

MATERIAL, usando flechas de trazo grueso
P1
Selecc. y
pedir nuevos
EDITORIALES nuevas ofertas
libros
INTERVENTOR Notación Gane & Sarson
pedidos de libros nuevos
libros nuevos
P3 ajuste de inventario D3 INVENTARIO

P2
Examinar Registrar libros
nuevos libros nuevos ajuste de signaturas
D4 SIGNATURAS
libros nuevos
nuevos libros D1 LISTA MAESTRA

DE ISBN
P4 P5
libros nuevos
libros nuevos D9 CARRITO Enviar al dpto. Poner libros libros nuevos
LIBROS NUEVOS comprador nuevos en D2 ESTANTES
libros nuevos estantes
Flujos de datos (V)
Se pueden considerar flechas convergentes o

divergentes, con un mismo nombre P
Validar
P cod postal
cod postal
A
dirección cli
telef
número de cuenta
calle P
Validar
P P Telef.
B Validar
calle
Observaciones:
Sólo los procesos pueden separar FD (Piattini et al. 04)
No poner FD como señales de activación (Yourdon 93)
Flujos de datos (VI)
Notación System Architect. Ejemplos

FD divergentes (conectores XOR y AND)
P
Imprimir
P
lista Rellenar
empaquetado prescripción
datos de P
P empaquetado
Determinar datos de envío Determinar prescripción
prods.para prescripción
datos de facturación
enviar XOR AND
cuando los datos son cuando todos los datos
divididos en subconjuntos P siguen por ambos caminos P
Imprimir Actualizar
factura registro
cliente paciente
Flujos de datos (VII)
Notación System Architect. Ejemplos

FD convergentes (conectores XOR y AND)
P P
Aceptar pago Confirmar
en metálico empleo
historial de
P historia P
datos de pago empleo
Transferir historial combinada Conceder
pago de crédito tarjeta de
P XOR crédito
AND
Aceptar pago cuando los mismos P cuando los subconjuntos
a crédito datos provienen de Confirmar son combinados en uno
cualquier dirección historial de
crédito
Flujos de datos (VIII)
P
pedido
Evaluar pedido ¿El proceso “pide” el FD “pedido”?
criterios valoración ¿El proceso “necesita” ambos FD?
No lo sabemos, no importa:
No
Los aspectos procedurales no se manifiestan
en los DFDs
Si tales aspectos son relevantes, se deben
incluir en las miniespecificaciones
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)
Flujos de control (II)
Señales de activación “ON/OFF”

Sirven para “Habilitar/Deshabilitar” procesos
También hay:
Procesos de control
− Coordinan el resto de procesos
− Usualmente uno por DFD
− Se describen mediante Diagramas de transición de estados
Almacenes de control
− Almacenes de eventos
FD discretos
FD continuos
Flujos de control (III)
clave codificada
P
Verificar
clave
D CUENTAS
clave
CLIENTE
clave OK
cantidad saldo
pago
P
Efectuar
reintegro
Flujos de control (IV)
P datos satélite
Monitorizar datos
habilitar proc satélite satélite
P
señal satélite
Controlar sistema
vigilancia D DATOS DE
VIGILANCIA
señal radar
P
Monitorizar datos
habilitar proc radar datos radar
radar
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
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
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)
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
Descomposición funcional (II)
P B DESTINO
A Sist
FUENTE B
P
f5
Z
P X P
f2 f4
V
Y
P
A f1 W P
f3
Z
P x2 P
x1 f43 f45
P
X f41
y2
P
y1 f44
P
Y f42
Descomposición funcional (II)
P B DESTINO
A Sist
FUENTE B
P
f5
Z
P X P
f2 f4
V
Y
P
A f1 W P
f3
Z
P x2 P
x1 f43 f45
P
X f41
y2
P
y1 f44
P
Y f42
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
Excepciones: errores y salidas triviales
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
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 P6.1
pedido
P6.3
pago
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
Jerarquía de DFDs (II)
P 1.2 B
Proceso A B = X + Y ∈ DD
A
DFD 1.2
P 1.2.2
f2 X
P 1.2.1 Y
f1 P 1.2.3
A W f3
Jerarquía de DFDs
DFD 0
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

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
Descomposición funcional y
almacenes de datos (II)
P P
A B
D FICH
P
P B.1
A.1
D FICH
D FICH
P
P
A.2
B.2
Tamaño de la jerarquía de
DFDs
Cada DFD debería tener alrededor de 7 procesos
o menos (Miller 57) Miller, G.A. The magical number seven, plus or minus two: Some limits on
our capacity for processing information. Psycological Review, vol. 63, pp.81-97.
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
Diagrama de contexto / sistema
Diagrama de subsistemas
Métrica Diagrama de funciones
Diagrama de subfunciones
Diagrama de procesos (opcional)
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 93)
CLIENTE
datos del mercado
CLIENTES
CORPORATIVOS informes anuales
D DATOS DEL
MERCADO
CENTROS DE datos de P datos del mercado

INVESTIGACIÓN investigación SIST. DE
INVESTIG. DE
MERCADOS
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 P
Fuente Sumidero
Regla de Balanceo
Localización de los procesos
STAFF PLANNING CONTROL DE ADMIN REGIONES ESCÁNER D600
CALIDAD W, S, N
P P
Copia de
P Fotocopiar Form 55 Revisar
P Revisar Form 55 Form 55
Crear Form 55
Form 55 Form 55 revisado
Formulario
Form 55 autorizado
55
Form 55 Form 55 revisado regionalmente
P
Revisar
Form 55
Det. estado
Form 55
Form 55 no autorizado Form 55 aceptado
P
Form 55 no aceptado Crear

Xact 55
Xact 55
DESTINO P
Informe 55 Crear
Informe 55
informe 55
DESTINO
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
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
DFD (III)
La descomposición top/down adolece de

problemas
SOLUCIÓN: partición de eventos
Es importante que sea preciso y completo, pero
¡es muy importante que sea legible!
El convenio de nombres de FD a/desde almacenes
ayuda a hacer el DFD más legible
Agregar FD en los niveles superiores
Un poco de sentido común…
confirmación subasta
Prácticas sept. 2004

NAVEGANTE datos de prducto
datos de anuncio
solicitud de anuncio
confirmación de cancelación
solicitud de cancelación
notificación de pujas
confirmación de baja MEGASUBASTA PÚBLICA
1
solicitud de baja
3
confirmación GESTIONAR USUARIOS
GESTIONAR ANUNCIOS
datos de usuario
datos usuario
BANCO
datos bancarios
autorización
2
identificación confirmación id.
confirmación de cobro ADMINISTRAR PUJAS
solicitud de puja datos bancarios usuarios
D1 PARTICIPANTES
cobro de participación
nº serie nombres usuarios
borrado usuario
DFD 0 (Ejemplo a).
consulta de datos
datos puja
registro usuario id. usuario e-mail adjudicatario
nº de serie
nº cuenta
registro de puja revisión pujas login usuario id. adjudicatario
borrado datos anuncio e-mail

petición anuncio
D PUJAS información anuncio
D ANUNCIOS
datos de revisión listado de resultados
anuncio referencia de artículo
confirmación de referencia solicitud de resultados

datos de subasta datos resultados
anuncio a cancelar
D RESULTADOS consulta de resultados
fecha fin edición
anuncio revisado resultados de pujas

id. creador
cargo de penalización
confirmación de penalización
impago de participación n. anuncio

registro anuncio 4
puja adjudicataria
cargo
VALIDAR SUBASTA
nº anuncio pujado
confirmación de cargo nº subasta
listado pujas relacionadas
ADMINISTRADOR pujas relacionadas
num. anuncio
datos de penalización
impago puja adjudicataria
cierre edición
confirmación de cierre
Prácticas sept. 2004 La Mega Subasta Pública
D EDICIONES
peticiónSobreParticipante P1 P2 P3
peticiónSobreEdicionesYSubasta peticiónSobrePujas
Gestionar Gestionar Gestionar
peticiónValidarTarjeta s D SUBASTAS
Participantes acciónSobreEdicionesYSubastasO Edición y Pujas respuestaPuja
tarjetaValidadaOK Subastas CIEGAS
K
acciónSobreParticipanteOK avisoAnulamiento
avisoPujaExtendid
a
D SUBASTAS
EXTENDIDAS
D PRODUCTOS
DFD 0 (Ejemplo b).
D PARTICIPANTES
D PUJAS
D EDICIONES
D SUBASTAS
CIEGAS
D SUBASTAS
EXTENDIDAS
peticiónConsultaResultados peticiónDevolverProducto
P4 P5
productoDevueltoOK
respuestaConsultaResultados Seleccionar Genstionar
productosAEntregar
Ganadores Tranferencia de
peticiónControlResultados productoEntregadoOK
Productos
avisoAdministrador
respuestaControlResultados
D LISTA DE validarTranferencia
RESULTADOS tranferenciaOK
avisoGanador
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
DFDs – Conclusiones (II)
Superado por las metodologías OO,

pero todavía vigente:
− educación
− 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
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.)
DFDs – Conclusiones (IV)
Según algunos autores, la aproximación

top-down no es la más correcta para
analizar los sistemas de información
Aunque no es intrínsecamente mala: se
puede usar en proyectos pequeños
Alternativamente, se puede usar:
− bottom-up
− de un nivel intermedio hacia arriba o hacia abajo
En proyectos grandes, partición de eventos

Diccionario de datos (DD)
“Es un conjunto de información (datos) sobre
datos”
Objetivos del DD:
Glosario de términos
Establecer terminología estándar
Proporcionar referencias cruzadas
Proporcionar control centralizado para cambios
Evolución histórica: desde el directorio/diccionario de datos hasta el
diccionario de recursos de información
Posibles elementos para
definir en el DD
Flujos de datos
Procesos
Ficheros Mínimo necesario
Entidades externas
Estructuras de datos
Datos elementales
Cualquier otra cosa que el analista considere
conveniente
Información requerida para
cada elemento del DD
Nombre
Tipo de elemento
Breve descripción Mínimo necesario
Sinónimos
Observaciones
Información requerida para
cada elemento del DD (II)
Frecuencias y fechas
Volúmenes (Ks estimadas, nº líneas impresas, etc.)
Cuellos de botella, valores máximos y mínimos (tablas,
ficheros, impresos, entradas de datos)
Referencia o código de impreso
Rango de valores permitido y clase (numérico,
alfanumérico, etc.)
Miniespecificaciones (sólo procesos)
Referencias cruzadas
Usuarios afectados
Cualquier otra información que se considere de interés
Soporte del DD
Manual
Editor/procesador de textos
Base de datos
Automático e integrado
(sw. específico)
Descomposición top-down
de datos
A=B+C
B = B1 + B2 + B3
C = C1 + C2
A, B, C, B1, B2, B3, C1, C2
todos están definidos en el DD
Ejemplos de descomposición:
− Ficheros en “subficheros” o registros
− Procesos en subprocesos
− Flujos en “subflujos”
− Estructuras de datos en datos elementales
Operadores relacionales
“=” — es equivalente a
“+” — y
“<>” — o (inclusivo: al menos una de las
opciones)
“[ ]”, “|” — o (exclusivo: sólo una de las
opciones)
“1{ }N” — iteraciones entre 1 y N veces del
término entre llaves
“( )” — opcional
Operadores relacionales (II)
Actualmente (Yourdon 93) “<>” no se usa

(en System Architect tampoco)
Se utiliza “[ ]” , “|” con combinaciones de “( )” y “+”
Ejemplos:
direccion-cliente = <direccion-envio, direccion-facturacion>
* se puede expresar como *
dirección-cliente = [direccion-envio | direccion-facturacion |
direccion-envio + direccion-facturacion]
* si se admite que direccion-cliente esté vacio *
direccion-cliente = (direccion-envio) + (direccion-facturacion)
Operadores relacionales (III)
“*...*” — comentario
@ — identificador de campo clave en un
almacén (también, alternativamente, se
puede subrayar la clave)
Ejemplos:
Solicitud-destino = @nºascensor + (nºplanta)
= nºascensor + (nºplanta)
* ambas definiciones son equivalentes *
Ejemplos DD
pedido = cupon-correos + (pago-previo)

etiqueta = 1{carácter}8
nº-de-telefono =
*cualquier secuencia correcta de dígitos que
provoca una llamada *
[extension-local | 9 + numero-exterior]
extension-local = * sólo dentro del edificio *
primer-digito + 3{ cualquier-digito}3
primer-digito = [1|2|3|4|5|6|7]
cualquier-digito = [0|1|2|3|4|5|6|7|8|9]
¿Hasta cuándo especificar?
El proceso de descomposición finaliza en

los términos autocontenidos
Ejemplo
persona = apellidos + nombre + nºss + edad
¿ “edad” es autocontenido?
− edad = 1{digito}2
Sinónimos
Origen:
Distintos usuarios dan distintos nombres a los
mismos objetos
El analista introduce, por error, un nombre distinto
para un objeto ya nombrado
Distintos analistas que trabajan en el mismo proyecto
dan nombres distintos a un mismo objeto
Los sinónimos deben evitarse siempre que sea
posible
Ejemplos DD (II)
Nombre: hoja-verde
Sinónimos: petición, solicitud
Tipo: sinónimo
Observaciones:
Nombre: estado
Sinónimos: estado-cliente, EST$
Tipo: elemento de datos
Valores y significado:
OK.- Cuenta en buen estado
C.- Cuenta cerrada
D.- Cuenta en “números rojos” * cliente moroso *
Observaciones:
Ejemplos DD (III)
Nombre: peticion
Sinónimos: solicitud, hoja-verde
Tipo: flujo de datos
Composición: [peticion-estado-cliente | peticion-stock | peticion-estado-de-un-
pedido | petición-de-materia-prima]
Pertenece a: * ninguno *
Observaciones:
Nombre: Contabilidad de proyectos

Sinónimos: Cuentas
Tipo: fichero
Composición: { @nº-de-proyecto + descripción-proyecto + cuenta-del-
gabinete + { nombre-del-empleado + fecha-ingreso } }
Organización: * secuencial, por número de proyecto *
Observaciones:
Elementos y estructuras de
datos
Son la base sobre la que se definen los

flujos de datos, los almacenes y las
entidades del diagrama E/R.
Un elemento de datos es una pieza de
información atómica.
Una estructura de datos es un registro,
compuesto por otras estructuras o
elementos de datos.
Ejemplos DD (IV)
(Flujo de datos) “Libros prestados” =

[ “Libros entregados” |
“Libros devueltos” ]
donde “Libros entregados” y “Libros
devueltos” son estructuras de datos.
“Libros entregados” = {ISBN + Copia-ID }
“Libros devueltos” = { ISBN + Copia-ID }
donde ISBN y Copia-ID son elementos de datos
6.4. Modelado de la lógica de
los procesos

Miniespecificaciones (ME)
Proceso primitivo ⇒ miniespecificación

La ME describe las reglas sobre cómo
realizar el proceso para transformar las
entradas en salidas
La ME indica el proceso a realizar, la
transformación de datos, no el algoritmo
(que se selecciona en el proceso de
diseño)
Herramientas para describir
la lógica de los procesos
Tablas de decisión
(son alternativas no excluyentes)
Vocabulario (restringido) de una lengua

(español, inglés, etc.)
Verbos imperativos
Términos definidos en el DD
Palabras reservadas para formulación lógica
(mayúsculas)
Sintaxis de la programación estructurada
Lenguaje estructurado (II)
Los objetos de una ME (sujetos de las

sentencias) serán términos del DD o bien
términos locales
Los términos locales se definen explícitamente
dentro de una ME, y son conocidos, relevantes y
significativos sólo dentro de esa ME (por tanto,
no es imprescindible su inclusión en el DD)
Ejemplo:
variables utilizadas para cálculos intermedios,
como sumas parciales, dentro de un proceso.
Lenguaje estructurado -
Sintaxis
Sentencia declarativa simple (secuencia)

Estructura de decisión
Estructura de repetición
Combinaciones de las estructuras
anteriores
Sentencias declarativas
Concisión
Evitar verbos ambiguos (manejar, realizar, procesar,
etc.)
Utilizar verbos precisos que describan acciones
concretas (imprimir, enviar, acumular...)
Mencionar expresamente el objeto de la sentencia,
preferiblemente utilizando los términos del DD
Ejemplos:
Recoger INF-CLIENTE
Separar PETICION
Archivar PETICION en F-PETICION *fichero*
Enviar DATOS-CLIENTE a DPTO-CLIENTES
Estructura de decisión
SI Condición CASO Condición:Acción(es)
Acción(es)
SINO
Acción(es)
Ejemplos:
a) SI Valor-capital-actual es menor que 600€
Asignar Cantidad-depreciada = Valor-capital-actual = 0
SINO
Asignar Cantidad-depreciada = 10% de Valor-capital-actual
b) Seleccionar la política que se aplica:

Caso 1: (Costo-de-pedido > 1000€) :
enviar por avión
Caso 2: (Costo-de-pedido entre 100€ y 1000€) :
enviar por correo urgente
Caso 1: (Costo-de-pedido < 100€) :
enviar por correo normal
Estructura repetitiva
REPETIR (condición de selección)
Acción(es)
HASTA (condición de terminación)
MIENTRAS (condición)
Acción(es)
FIN MIENTRAS
Ejemplo:
REPETIR para cada registro-de-pasajero en fichero-de-reservas
Acumular Cantidad-debida en Total
Construir registro Nuevo-débito
Escribir Nuevo-débito en el diario
HASTA final de fichero-de-reservas
Estructura repetitiva (II)
a) PARA CADA cliente en fichero-cuentas
Acceder al registro de cuenta del fichero-cuentas
Si estado-cuenta es moroso y balance < 10
Poner estado-cuenta en pendiente
Acumular balance-cuenta en total-pendiente
Asignar a fecha-última-transacción la fecha de hoy
b)
REPETIR para cada cliente en fichero-cuentas
Acceder al registro de cuenta del fichero-cuentas

Si estado-cuenta es moroso y balance < 10
Poner estado-cuenta en pendiente

Acumular balance-cuenta en total-pendiente
Asignar a fecha-última-transacción la fecha de hoy
HASTA que no haya más clientes

Lenguaje estructurado -
Observaciones
Utilizar “funciones” o “subrutinas”

Subrayar los términos del DD o usar con
mayúsculas
en SA, usar comillas
Evitar sentencias largas e imprecisas
Usar indentación o notación de bloque
Usar paréntesis para las combinaciones
de condiciones lógicas (and, or, not)
Lenguaje estructurado.
Ejemplos (I) (Yourdon 93) Apéndice F
PROCESO 3.1: PRODUCIR RECIBOS EFECTIVO
COMIENZA
efectivo-recolectado = 0
MIENTRAS haya más registros en DINERO
LEER siguiente registro en DINERO
ENVIAR dinero *en (Yourdon 93) pone “DESPLEGAR”*
efectivo-recolectado = efectivo-recolectado + cantidad-dinero
FIN-MIENTRAS
reporte-efectivo = efectivo-recolectado
ENVIAR reporte-efectivo
D DINERO
TERMINA
P3 dinero + reporte-efectivo
PRODUCIR
RECIBOS
EFECTIVO
Ejemplos (II) (Yourdon 93) Apéndice F
reporte-diario-ventas reporte-mensual-ventas
P2
PRODUCIR P1
REPORTE
PRODUCIR
DIARIO
REPORTE
VENTAS
MENSUAL
VENTAS
D CREDITOS
D PEDIDOS
D DEVOLUCIONES
Ejemplos (III) (Yourdon 93) Apéndice F
PROCESO 3.2: PRODUCIR REPORTE DIARIO VENTAS
COMIENZA
total-diario = 0
MIENTRAS haya más pedido en PEDIDOS con fecha-pedido= fecha actual
LEER siguiente pedido con fecha-pedido = fecha actual
SUMAR numero-factura, nombre-cliente, nombre-compañía, pedido-total
como nuevo renglón en reporte-diario- ventas
SUMAR total-pedidos a total-diario
FIN_MIENTRAS
SUMAR total-diario como nuevo renglón en reporte-diario-ventas
ENVIAR reporte-diario-ventas
TERMINA
Ejemplos (IV) (Yourdon 93) Apéndice F
PROCESO 3.3: PRODUCIR REPORTE MENSUAL VENTAS
COMIENZA
total-ventas = 0
total-devoluciones = 0
total-créditos = 0
MIENTRAS haya más pedido en PEDIDOS con fecha-pedido de este mes
SUMAR total-pedidos a total-ventas
FIN_MIENTRAS
MIENTRAS haya más devolución en DEVOLUCIONES con fecha-devolución de este
mes
SUMAR valor-devolución a total-devoluciones
FIN_MIENTRAS
MIENTRAS haya más crédito en CREDITOS con fecha-crédito de este mes
SUMAR monto-de-crédito a total-créditos
FIN_MIENTRAS
reporte-mensual-ventas = total-ventas, total-devoluciones, total-créditos
ENVIAR reporte-mensual-ventas
TERMINA
Ejemplos (V) (Yourdon 93) Apéndice F
D LIBROS
P4
id-imprenta + fact-imprenta PROCESAR factura-imprenta-aprobada
FACTURAS
IMPRENTA
factura-imprenta autorizacion-fact-imprenta
respuesta-fact-imprenta
Ejemplos (VI) (Yourdon 93) Apéndice F
PROCESO 4.4: PROCESAR FACTURA IMPRENTA
COMIENZA
ENCONTRAR libro en LIBROS con clave-libro que corresponda con clave-libro en fact-imprenta
SI no se encuentra registro
respuesta-fact-imprenta = “No existen pedidos pendientes para este libro”
ENVIAR respuesta-fact-imprenta
OTRO
ENVIAR factura-imprenta (a administración para su aprobación)
ACEPTAR autorización-factura-imprenta
SI autorización-factura-imprenta = “NO”
respuesta-fact-imprenta = “Factura rechazada; comuníquese con la administración para discutirlo”
ENVIAR respuesta-fact-imprenta
OTRO
respuesta-factura-imprenta = “Factura aceptada”
ENVIAR respuesta-factura-imprenta
factura-imprenta-aprobada = fact-imprenta
ENVIAR factura-imprenta-aprobada
FIN_SI
FIN_SI
TERMINA
Ejemplos (VII) (Yourdon 93) Apéndice F
PROCESO 6.1: PRODUCIR ETIQUETAS ENVIO
COMIENZA
ORDENAR CLIENTES por código-postal en etiquetas-envío
ENVIAR etiquetas-envío
TERMINA
etiquetas-envío
P6
solicitud-etiquetas
PRODUCIR
ETIQUETAS
ENVIO
D CLIENTES
Tablas de decisión
Encabezamiento Reglas
Estados de condición Anotación de

condición
Anotación de
Sentencia de acción acción
Se han desarrollado
Autorización de tarjeta de crédito 1 2 3 4 procesadores de
Compra inferior a 50€ Y N N N
Compra entre 50 y 100€ Y N N tablas de decisión
Compra superior a 100€ Y N que generan
Autorizado automáticamente X automáticamente el
Dar número de autorización X X código del proceso
Anotar en la cuenta X
Error X correspondiente.
Autorización de tarjeta de crédito 1 2 3

Valor de la compra p p > 100€ 50€ < p < 100€ 0< p < 50€
Autorizar automáticamente X
Asignar autorización X X
año cuota a pagar
tipo primero 2€
pendiente segundo 3€
tercero
4€
primero 3€
asociado segundo 4€
tercero 6€
Cuotas de
socio primero 5€
de grado segundo 6€
tercero 7€
primero 3€
senior segundo 4€
tercero 5€
Comparativa
Uso AD TD Lenguaje Lenguaje

estructurado narrado
simplificado
Verificación Moderada Muy buena Buena Moderada
lógica
Visualización Muy buena Moderada Buena (para Moderada
de la (pero sólo (sólo todo) (para todo,
estructura decisiones) decisiones) pero
lógica depende del
autor)
Simplicidad Muy buena Muy pobre Moderada Buena
Validación por Buena Pobre (si el Pobre- Buena
el usuario usuario no Moderada
está
formado en
TD)
Especificación Moderada Muy buena Muy buena Moderada
de programa
Editable por Pobre Muy buena Moderada Pobre
la máquina (necesita
sintaxis)
Cambios Moderada Pobre Buena Buena
Pre y post-condiciones (Yourdon 93)
Útiles para representar la acción a realizar sin

entrar en los detalles del algoritmo
Particularmente útiles cuando:
El usuario tiene tendencia a describir el proceso en
términos de un algoritmo particular
El analista está razonablemente seguro de que
existen muchos algoritmos alternativos
El analista desea que el diseñador/programador
explore varios algoritmos, pero no quiere enredarse
con el usuario en discusiones acerca del mérito
relativo de cada uno
Precondiciones
x
a
z
Entradas disponibles
“llega el dato X” * en (Yourdon 93) pone “ocurre” *
y
Relaciones entre las entradas

“llegan detalles de pedido y detalles de envío con el mismo número de
cuenta”
“llega un pedido con fecha de entrega de más de 60 días”
Relaciones entre entradas y almacenes
“hay un pedido-de-cliente con número-de-cta-de-cliente que
corresponde con un número-de-cta-de-cliente del almacén de clientes”
Relaciones entre almacenes distintos (o dentro del mismo almacén)
“hay un pedido en el almacén de pedidos cuyo número-de-cta-del-
cliente corresponde con un número-de-cta-del-cliente en el almacén de
clientes”
“existe un pedido en el almacén de pedidos con fecha-de-envío igual a
la fecha actual”
Post-condiciones
Salidas producidas
“se producirá una factura”
Relaciones entre entradas y salidas
“la factura-total se calcula como suma de precios-unitarios-
de-artículos más costos-de-envío”
Relaciones entre salidas y almacenes
“el balance-actual en el almacén INVENTARIO se
incrementará con cantidad-recibida, y el nuevo balance-
actual se producirá como salida de este proceso”
Cambios en los almacenes
“el pedido se anexará al almacén de PEDIDOS”
“el registro de clientes se eliminará del almacén de clientes”
Ejemplos (Yourdon 93)
ESPECIFICACIÓN DE PROCESO 3.5: CALCULAR

EL IMPUESTO SOBRE VENTAS
Precondición 1
− Llega DATOS-VENTA con TIPO-ITEM que corresponde con
CATEGORÍA-ITEM en CATEGORÍAS-IMPUESTO
Postcondición 1
− IMPUESTO-SOBRE-VENTA se hace igual a MONTO-VENTA *
IMPUESTO
Precondición 2
− Llega DATOS-VENTA con TIPO-ITEM que no concuerda con
CATEGORÍA-ITEM en CATEGORÍAS-IMPUESTO
Postcondición 2
− Se genera mensaje de error
Ejemplos (II) (Yourdon 93)
Precondición 1
El comprador llega con un número-de-cta que corresponde con
un número de cuenta en CUENTAS, cuyo código-de-status es
“válido”
Postcondición 1
Se produce una factura con número-de-cuenta y monto-de-
venta
Precondición 2
La precondición 1 falla por algún motivo (el número-de-cta no
se encuentra en CUENTAS, o el código-de-status no es “válido”)
Postcondición 2
Se produce un mensaje de error
ME – Otras técnicas
Grafos y diagramas propios del usuario

Si son claros, se pueden agregar a la especificación
como redundantes.
Diagramas Nassi-Shneiderman
Flowcharts
No recomendadas
Lenguaje narrativo
Sirve para descripción breve

6.5 Modelado de datos

Objetivo
Obtener una representación de la información del
sistema independiente de aplicaciones y dispositivos
físicos
⇒ Facilitar cambios en los requisitos, SGBD, equipos físicos
Con el análisis estructurado moderno de Yourdon el
modelado de datos cobra la misma importancia que el
modelado de procesos.
Técnicas de modelado de datos en AE:
E/R ⇐ RECOMENDADO
DED (Diagramas de Estructura de Datos)
Representa esquemas
relacionales, jerárquicos, CODASYL
DED
BD lógica, no simplificada ni optimizada, a

efectos de validación por el usuario
(esta especificación pasaría al
implementador de la BD)
Diseño externo, lógico
BD optimizada y normalizada, lista para

ser implementada físicamente
Diseño físico
DED (II)
“E/R limitado”
Sólo interrelaciones de grado 2
− Ternarias: descomponer
Cardinalidad sólo 1:N EQUIPO JUGADOR
− Otras cardinalidades:
− Cardinalidad 1:1
• Agrupar las dos entidades
• Conservar las dos entidades, con una interrelación en
cualquier sentido
− Cardinalidad M:N
• Entidad auxiliar con dos relaciones 1:N
DED. Ejemplo
Departamento
Diagrama E-R
(1,n) Notación [EN2002] (Chen) Elmasri, R.; Navathe, S.B. : "Fundamentos de
Sistemas de Bases de Datos". 3ª Ed. Madrid [etc.]: Addison-Wesley,
Pearson Educación, 2002.
pertenece
(1,1)
Empleado asignado Proyecto
(0,n) (1,m)
Departamento Proyecto
DED pertenece requiere
Empleado tiene Asignación

DED. Interrelaciones
Interrelaciones OPCIONALES
Interrelación opcional en el extremo B y
obligatoria en el A
A B
“∀ ocurrencia de A pueden ∃ o no una o

varias ocurrencias de B, y para cada
ocurrencia de B existe una ocurrencia de A
asociada”
DED. Interrelaciones (II)
Interrelaciones EXCLUSIVAS
Dos o más interrelaciones entre varias
entidades son exclusivas si la existencia de
una implica la no existencia de la otra
− P.ej. En la CARM...
EMPRESA EXTERNA
TRABAJADOR
CONSEJERÍA
(notación De Miguel Piattini)

6.6. Historia de vida de las
entidades

HVE. Bibliografía
Para todo este apartado:

Guía de técnicas de Métrica v.2.1.
Ministerio de Administraciones Públicas.
1996.
(HVE no es mencionada en Métrica 3)
HVE
Describe la posible evolución de las entidades

de datos del sistema
VISIÓN DEL COMPORTAMIENTO,
que complementa:
Visión estática (E/R o DED)
Visión de procesos y flujos (funcional) (DFDs)
HVE se basa en entidades de datos
(identificadas en DED), y transacciones o
eventos (de los DFDs)
Deben ser coherentes HVE, DED, DFD
HVE. Objetivos
Registrar la secuencia de los cambios de

las entidades en el tiempo
Determinar los estados posibles
Determinar los cambios de estado
Identificar interacciones producidas por
eventos
HVE
(En principio) existe una HVE por cada

entidad del sistema
¿Realmente es necesario?
HVE describe la “sucesión de eventos”
que afectan a dicha entidad, cuyos
efectos pueden ser:
Crear/dar de baja a la entidad
Modificar sus atributos
HVE. Elementos
Entidades de datos Nodo
Cualquier objeto sobre el
que el sistema guarda Agrupación de eventos
información (tienen en una caja
atributos)
Eventos
Cajas vacías
Sucesos que activan un Representan el caso
proceso que afecta los en que ningún evento
datos del sistema
afecta a la entidad
Efectos
Resultado de la acción de
un evento sobre una
entidad
Eventos
EXTERNOS. Por activación externa

ej. solicitudes de alta, baja, modificación, etc.
PERIÓDICOS. Activación dependiente del
tiempo (automáticos) sin estímulo externo
ej. “back up” periódico
TRIGGERING. Activados internamente por
cumplimiento de determinadas
condiciones
ej. alarma activada
Efectos
Un evento puede tener distintos efectos sobre

entidades diferentes.
Ej.: SOLICITAR APERTURA CTA. BANCARIA
Crea (o actualiza) entidad CLIENTE
Crea entidad CUENTA
Un evento puede tener efectos distintos sobre
ocurrencias de una misma entidad.
Ej.: entidad CUENTA; ev. REALIZAR TRANSFERENCIA
Efectos: para una ocurrencia: HACER APUNTE EN EL
DEBE
Para la otra ocurrencia: HACER APUNTE EN EL
HABER
Efectos (II)
Tipos de efectos:
I : insertar
M : modificar
B : borrar
Nodo
Es una abstracción gráfica que mejora la

legibilidad.
ENTIDAD
CREAR MODIFICAR BORRAR
“Entidad” es un nodo que agrupa todos

los eventos que le afectan
HVE. Notación (MAP 95)
CUENTA
ABRIR CERRAR BORRAR

VIDA SECUENCIA
cta. ab. cierre cta.borr.
TRANSACCIÓN ITERACIÓN
SELECCIÓN
TRANS. TRANS. TRANS.
PAGO DEPÓSITO ABONO
HVE. Notación (II) (MAP 95)
CUENTA
EVENTO EVENTO EVENTO

NODO
EFECTO EFECTO EFECTO
ESTRUCTURA PARALELA
EVENTO N
NODO 1
EFECTO N
EVENTO K EVENTO L EVENTO M

EFECTO K EFECTO L EFECTO M
También se pueden poner saltos: R Q (En general, RX QX)

HVE. Ejemplo (MAP 95)
1
solicitud reserva ACEPTAR RESERVA datos cliente D1 CLIENTES
CLIENTE
datos reserva
2
DET. D2 RESERVAS
DISPONIBILIDAD
VEHICULOS
reserva conforme
3
CONFIRMAR
RESERVA
confirmación
HVE. Construcción
1. IDENTIFICAR EVENTOS

En el DFD anterior...
−E1: SOLICITUD DE RESERVA
−E2: SOLICITUD DE RESERVA EFECTUADA
POR CLIENTE NUEVO
−E3: CONFIRMACIÓN DE RESERVA
−E4: ASIGNACIÓN DE UN CONDUCTOR A LA
RESERVA
⇒ ¿Se te ocurren más eventos?
HVE. Construcción (II) (MAP 95)
2. CONSTRUIR MATRIZ ENTIDAD/

EVENTO
I : Insertar
EVENTOS
M : Modificar E1 E2 E3 E4
B : Borrar ENTIDADES CLIENTE I I
RESERVA I M M
CONDUCTOR M
HVE. Construcción (III) (MAP 95)
3. CONSTRUIR HVE INICIALES PARA

TODAS LAS ENTIDADES
RESERVA
SOLICITUD CONFIRMACIÓN
RESERVA RESERVA CONDUCTOR
crea reserva reserva confirm.
ASIGNACIÓN -------------
CONDUCTOR
conductor asig.
HVE. Construcción (IV) (MAP 95)
4. REFINAMIENTO DE LAS HVE

NUEVO EVENTO
− E5: ENVÍO DE FACTURA
RESERVA
SOLICITUD CONFIRMACIÓN ENVÍO FACTURA

CONDUCTOR
RESERVA RESERVA
actualizar res.
ASIGNACIÓN -------------
CONDUCTOR
conductor asig.
HVE. Construcción (V) (MAP 95)
4. REFINAMIENTO DE LAS HVE

NUEVO EVENTO
− E6: PETICIÓN DE CAMBIO
RESERVA
SOLICITUD CONFIRMACIÓN * ENVÍO FACTURA

CONDUCTOR CAMBIOS
RESERVA RESERVA
actualizar res.
ASIGNACIÓN ------------- PETICIÓN CONFIRMACIÓN

CONDUCTOR CAMBIO CAMBIO
cambio reserva reserva confirmada
conductor asig.
HVE. Construcción (VI) (MAP 95)
5. AÑADIR INDICADORES DE ESTADO
RESERVA
SOLICITUD CONFIRMACIÓN * ENVÍO FACTURA

CONDUCTOR CAMBIOS FIN
RESERVA RESERVA
actualizar res.
crea reserva reserva confirm. 5/6
-/1
1/2
ASIGNACIÓN ------------- PETICIÓN CONFIRMACIÓN ARCHIVO ARCHIVO

CONDUCTOR CAMBIO CAMBIO RESERVA CLIENTE
cambio reserva reserva confirmada
conductor asig. borrar reserva borrar reserva
2/2 2,3,5/4 4/5
2/3 6/- 6/-
Modo de construcción
Para cada entidad, en principio, debe

haber un HVE
Empezar MAESTRO Y al final...

por las examinar los
entidades efectos de los
detalle eventos del
DETALLE
maestro en
los detalles
HVE. Relaciones con otras
técnicas
Asegurar coherencia “vista evolutiva” (dinámica

o de comportamiento) (HVE) con
Vista estática o de datos (E/R o DED)
Vista funcional (DFD)
Para ello, comprobar:
DFD: para cada evento en el HVE, existe un proceso
en los DFDs del sistema que lo trata
E/R o DED: el modelo de datos permite reflejar las
repercusiones que la actuación de un evento sobre
una entidad tiene sobre otras entidades del sistema

Bibliografía
(Yourdon 89) o (Yourdon 93)

Capítulos 17, 18, 19 y 20.
Introducción
En teoría, hemos visto unas TÉCNICAS (DFDs, DED, HVE, etc.)
En prácticas, hemos visto una HERRAMIENTA (System Architect)
Ahora necesitamos un MODELO DE PROCESO

un esquema de cómo se deben aplicar las técnicas y las herramientas para producir software:
Actividades que se deben realizar
En qué orden
Cuáles son los productos que dichas actividades deben generar
Etc.
En 6.1. Introducción – Visión panorámica del AE, vimos un modelo de proceso “clásico”:
Análisis de requisitos (realizando un análisis del sistema actual, si procede)

Diseño de soluciones alternativas
Selección de una solución
Especificación en detalle de la solución escogida
Diseño estructurado: diagrama de estructuras
Refinamiento del diseño
Implementación
Mantenimiento
⇒ Veamos ahora la aproximación de Yourdon

Aproximación “clásica”
Modelo físico actual
Datos proyecto DESARROLLAR DESARROLLAR

MODELO MODELO LÓGICO
FÍSICO ACTUAL
ACTUAL
Modelo lógico actual
Nuevo
modelo
físico
DESARROLLAR Nuevo modelo lógico DESARROLLAR
NUEVO MODELO NUEVO MODELO
LÓGICO FÍSICO
⇒ demasiado t. modelando el sist. actual

Aproximación de Yourdon –
Modelo esencial
Construir un MODELO ESENCIAL:

Modelo lógico del nuevo sistema
“Un modelo de lo QUE el sist. debe hacer para
satisfacer los requisitos del usuario, diciendo tan
poco como sea posible (idealmente nada) sobre
CÓMO se debe implementar.”
1. Modelo ambiental (o del entorno).
2. Modelo del comportamiento.
Aproximación de Yourdon –
Modelo de implementación
No obstante, a veces conviene construir

tb. un MODELO DE IMPLEMENTACIÓN
centrado en el CÓMO
Debido típicamente a que:
el usuario no está convencido de que los
analistas entienden el sistema
el analista decide que es preciso construir un
modelo del sistema actual para entenderlo
bien
Modelo ambiental
Define el límite entre el sistema y el mundo

exterior
Declaración de ámbito
− descripción breve del propósito del sistema
⇒ Evitar especificar el “protocolo de comunicación”
Lista de eventos F, evento orientado a flujo
Ej. de eventos:
T, evento temporal
Cliente envía pedido (F)
C, evento de control
Cliente cancela pedido (F)
Mensualmente la dirección precisa informe de ventas (T)
Una orden de reimpresión llega al almacén (C)
Lista de eventos
No cada FD es un evento
A B
SISTEMA
¿A, B y C son
eventos?
C
¿Coinciden estos
eventos del modelo
ambiental con los
del HVE?
Modelo del comportamiento
Define el comportamiento requerido del

“interior” del sistema para interactuar con
el exterior.
DFDs
ER
DD
Miniespecificaciones
HVE
...
Modelo del comportamiento.
Construcción.
Aprox. TOP-DOWN
⇒ difícil en probs. reales.
CAUSAS:
“Parálisis del análisis”
“El fenómeno de los 6 analistas”
A veces, se hace una partición física arbitraria
SOLUCIÓN: PARTICIÓN DE EVENTOS
Ni top-down, ni bottom-up
Partición de eventos. Modelo
de comportamiento inicial
1. Se dibuja un proceso para cada evento de la

lista de eventos.
2. El proceso se nombra describiendo la respuesta
que el sistema debe producir en respuesta al
evento asociado.
3. Se dibujan los FD de entrada y salida,
almacenes auxiliares y almacenes para
comunicación entre procesos.
4. Se verifica el balanceo con el DFD de contexto.
(El diagrama E-R se dibuja en paralelo.)
¿Sería válido este DFD?
(que forma parte del modelo de comportamiento inicial)
customer order
PROCESS
CUSTOMER
ORDER
valid customer order
RESPOND
customer order inquiry TO order status
CUSTOMER
INQUIRY
No, ya que los eventos ocurren de forma asíncrona, y se procesan de forma asíncrona:
en el modelo de comportamiento inicial, todos los procesos deben estar desacoplados
usando almacenes de datos.
Partición de eventos.
Refinamientos.
El modelo inicial es muy complejo:
se refina hacia arriba y abajo (7±2 proc.)
DFD
1.1 1.2 PRELIMINAR
1
1.3
DFD
AGRUPADO

Ad Analisis Estructurado PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ad Analisis Estructurado PDF

Cargado por

Copyright:

Formatos disponibles

Fundamentos de

Ingeniería del Software

Capítulo 3. Análisis de Requisitos

Entre la bibliografía básica...

Visión general de las funciones y

Tipos de símbolos en los DFDs

flujo de datos D ALMACÉN DE

Sistema de distribución sin inventario

Adaptado del capítulo 2 de Gane, C. and T. Sarson, Análisis estructurado de sistemas.

Análisis de los procesos del sistema

“Es un conjunto de metadatos, es decir, de

Diagramas E-R y DED (Diagrama de

DED pertenece requiere

Empleado tiene Asignación

Técnicas para describir la lógica de los

3. Hacer confirmación y factura y

DISEÑO ESTRUCTURADO (DE)

pet aceptada informe préstamo

Recibir Elaborar Informar

pet préstamo pet rechazada

Leer Consultar Rechazar

Descrip. Descripción Definición

6.1. Introducción - Visión panorámica del AE

Entidad Externa Terminadores (Fuentes o Destinos)

Flujo de eventos Flujos de control (Ward & Mellor 85)

Ficheros o depósitos temporales de

Proceso Transformaciones o procesos

Entidad Terminadores (Fuentes o Destinos)

Flujo de datos Flujos de información

D ALMACÉN DE Ficheros o depósitos temporales de

Un consejo: Keep it simple!

Nombres únicos, significativos y concisos

Es el DFD más general de todos

Los identificadores (nombres) de las entidades externas serán

Los nombres de los FD deben ser únicos,

Flujos de datos interactivos (dialog flows)

Las flechas dobles con sentidos opuestos

Se puede representar, si se desea, el FLUJO DE

pedidos de libros nuevos

P3 ajuste de inventario D3 INVENTARIO

nuevos libros D1 LISTA MAESTRA

Se pueden considerar flechas convergentes o

Notación System Architect. Ejemplos

Notación System Architect. Ejemplos

En los DFDs no se muestra el control ni el orden

Señales de activación “ON/OFF”

Nombre único, significativo y conciso

Para facilitar validaciones cruzadas entre DFDs y

Correspondencia entre los almacenes de datos

ETIQUETA DE LOS ALMACENES

DEFINICIÓN DE LOS ALMACENES

Cada proceso se puede explotar, refinar o

Cada proceso en un diagrama “padre” es

Ejemplo: pedido = autorización + cupón de pedido + pago

En un DFD completo cada proceso tiene un

El primer diagrama general que sigue al

⇒ Han de ser SUBSISTEMAS

Los almacenes aparecen lo más tarde

En general, habrá varios niveles intermedios,

CENTROS DE datos de P datos del mercado

Todo almacén y todo proceso tienen uno o

Form 55 no aceptado Crear

Identificar todos los elementos exógenos