You are on page 1of 146

Análisis y Diseño Estructurado

Diagrama de Flujo de Datos

ENTIDAD
EXTERNA
P1
Proceso Docente : Yessica Gómez Gutiérrez
flujo de datos D ALMACÉN DE
DATOS

1
Introducción

Objetivo: Obtener una especificación detallada del SI,


y de sus interfaces con otros sistemas, que satisfaga
las necesidades de información de los usuarios y
sirva de base para el diseño.
Integra las actividades de análisis estructurado
y OO.
Se refinan los productos obtenidos en el proceso EVS.

2
Actividades Iniciales y Análisis de Requisitos. Introducción
Donde nos encontramos…
Análisis del Sistema de Información (Proceso ASI)
Definición del Sistema.

Productos que se generan:


 Catálogo de requisitos
 Glosario
 En AE,
 Contexto del sistema
 Modelo conceptual de datos
 En AOO,
 Modelo del negocio / Modelo del dominio
 Catálogo de estándares y de normas
 Catálogo de usuarios (participantes y finales)
 Entorno tecnológico del sistema
 Plan de trabajo

3
Introducción

 Objetivo: Definición, análisis y validación de los


requisitos.
 Se completa el catálogo de requisitos.
 Modelos gráficos de requisitos: casos de uso
(obligatorios en AOO, opcionales en AE)
 Las tareas se realizan de forma iterativa y con
continuas realimentaciones y solapamientos.

4
Introducción

Sesiones de trabajo con los usuarios para extraer los requisitos


(con prioridades): Técnica de recogida de información.
Catálogo de requisitos.
Modelo de casos de uso.
 Requisitos funcionales
 Con casos de uso (obligatoriamente) en AOO:
 Actores.
 Casos de uso.
 Breve descripción de cada caso de uso.
 Requisitos no funcionales:
 Restricciones del entorno
 Niveles de servicio del sistema:
 Rendimiento, seguridad, implantación, disponibilidad...

5
Introducción

Objetivos:
 Detectar inconsistencias, ambigüedades, duplicidad o escasez de información.
 Se revisan las prioridades.
 Se relacionan requisitos.
 Identificar relaciones entre casos de uso.

6
Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.
Actividades Iniciales y análisis de necesidades.

Introducción
7
Introducción

Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.


Estudio de Viabilidad. EVS.

 Alternativas.
 Evaluación de las alternativas:
 Económico.
 Técnico.
 Legal (p.e. LOPD “Ley Orgánica de Protección de Datos”)
 Operativo.
 Especificación detallada de la alternativa
seleccionada.
 Definición del plan inicial del proyecto.

8
Introducción

Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.


Estudio de Viabilidad.

9
Introducción

Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.


Estudio de Viabilidad.

10
Introducción

Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.


Técnicas de recogida de Información.

 En general, el proceso de análisis debería seguir los


siguientes cinco pasos:
 Identificar las fuentes de información.
 Realizar las preguntas apropiadas.
 Analizar la información.
 Confirmar con los usuarios lo que parece haberse
comprendido de los requisitos.
 Sintetizar los requisitos en un documento.
Para la práctica y tras determinar la viabilidad del proyecto, como resultado de
la aplicación de una o varias de las técnicas de recogida de información ,se
entregará a los grupos un documento que resume/sintetiza los datos obtenidos,
que será el punto de partida en la etapa análisis del sistema de información.

11
Introducción

Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.


Técnicas de recogida de Información.

 Entrevistas vs JAD (Joint Application Design): Basada en la


creación de equipos de usuarios y analistas que se reúnen para
trabajar conjuntamente en el establecimiento de las necesidades
del sw a desarrollar.
 Prototipado: Construcción de una maqueta o modelo de sistema
para evaluar los requisitos.
 Observación: Análisis in situ del entorno a informatizar.
 Estudio de documentación / Cuestionarios / Tormenta de
ideas (brainstorming)
 .....
 Posible proceso de Reingeniería. Análisis de los sistemas de
información existentes.

12
Introducción

Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.


Actividades generales de la etapa de análisis. ASI.

“El proceso de estudio de las necesidades de los


usuarios para llegar a una definición de los requisitos
Análisis de Requisitos:
del sistema, de hw. o de sw.”
“El proceso de estudio y refinamiento de dichos
requisitos” [IEEE Std. 610, Glosario estándar de
términos en ingeniería del software]

Condiciones que debe cumplir un sistema para satisfacer un


contrato, una norma o una especificación.
Condición o capacidad que necesita el usuario para poder resolver
REQUISITO: un problema o conseguir un beneficio determinado.

13
Introducción
Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.
Actividades generales de la etapa de análisis. ASI.

Requisitos Funcionales: describen la funcionalidad o los servicios que se espera


que el sistema proveerá: sus entradas y salidas, excepciones, .. etc en resumen
su lógica.
Nuestra asignatura se centrará en este tipo de requisitos, mientras en la asignatura de Diseño de BBDD se
centrará en su dominio, aunque el CGR en el mismo.
Requisitos no Funcionales: se refieren a las propiedades emergentes del sistema
como la fiabilidad, el tiempo de respuesta, la capacidad de almacenamiento, la
capacidad de los dispositivos de entrada/salida, y la representación de datos que
se utiliza en las interfaces del sistema.

Extracción: El proceso mediante el cual los clientes o futuros usuarios del software descubren, revelen, articulan y
comprenden los requisitos que desean. Técnicas de recogida de información.
Análisis: el proceso de razonamiento sobre los requisitos obtenidos, detectando y resolución de posibles
inconsistencias o conflictos.
Especificación de requisitos: el proceso de redacción o registro de los requisitos. Para este proceso puede
recurrirse al lenguaje natural, lenguajes formales. Catálogo de requisitos.

Validación de los requisitos: el proceso de confirmación, por parte de los usuarios o clientes, de que los requisitos
especificados son válidos, consistentes, completos.

14
Introducción
Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.
Actividades generales de la etapa de análisis. ASI.

 Las características deseables para un buen análisis de los requisitos


son las siguientes [IEEE 1984b]:

 No ambigua.
 Completa.
 Fácil de verificar.
 Consistente.
 Fácil de modificar.
 Fácil para identificar el origen u las consecuencias de cada
requisito.
 Fácil de utilizar durante la fase de explotación y mantenimiento.

15
Análisis y Diseño Estructurado

•Visión panorámica del Análisis y


Diseño Estructurado.

• Análisis : Diagramas de Flujo de


Datos.

• Diseño: Diagrama de Estructuras


P1
ENTIDAD Proceso
EXTERNA

flujo de datos D ALMACÉN DE

16
DATOS
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

17
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

18
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

19
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.)

20
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)

21
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)

22
P1
ENTIDAD Proceso
EXTERNA

Visión panorámica
del AE. DFD flujo de datos D ALMACÉ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

23
Visión panorámica del AE. DFD

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

24
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.
25
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
0.
Sistema de
Pedidos EDITOR
en principio, no
son materiales, libros pedidos

son datos 26
Visión panorámica del AE. DFD: Ejemplo
Práctico

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 27
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

28
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

29
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_pago
Proc_consultas Adjuntar_albarán
30
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: Prioridad:
Ratio de transacciones: Memoria requerida (Kb):
Tiempo de proceso:

31
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

32
Visión panorámica del AE. Ejemplo de
E/R .
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

33
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

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

35
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) 36
Visión panorámica del AyDE. Lógica de
Proceso.

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

37
Visión panorámica del AyDE. Lógica de
Proceso.

Árboles de decisión
1. Dejar confirmación
Cuentas impagadas más pendiente de los pagos
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 más escribir mensaje sobre informe de
menos de de 60 días crédito
300€
Cuentas en buen estado 4. Hacer confirmación y
factura

38
¿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

39
Diseño Estructurado: DIAGRAMA DE
ESTRUCTURA. 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

40
Visión panorámica AE
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 41
los módulos
Diagramas de Flujo de Datos
(DFDs)

42
Símbolos del 2.- Diagramas de Flujo de
DFD Datos
(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.) 43
2.- Diagramas de Flujo de
Símbolos del DFD Datos
(notación Métrica/SSADM)

ID Localización

Proceso
Transformaciones o procesos

Entidad
Externa
Terminadores (Fuentes o Destinos)

Flujo de datos Flujos de información

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

44
2.- Diagramas de Flujo de
Procesos Datos

 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
E2 S2

E3

45
2.- Diagramas de Flujo de
Datos
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
46
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

47
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 Sistema DESTINO

FUENTE DESTINO

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


48
únicos, significativos y concisos
2.- Diagramas de Flujo de
Datos
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)

49
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 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

50
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 X P P P
A B A B
X
X

51
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
Selecc. y
pedir nuevos
EDITORIALES nuevas ofertas
libros
INTERVENTOR Notación Gane & Sarson

pedidos de libros nuevos

libros nuevos

D3 INVENTARIO
P2 P3 ajuste de inventario
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 libros nuevos
Enviar al dpto. Poner libros
LIBROS NUEVOS comprador nuevos en D2 ESTANTES
libros nuevos estantes
52
2.- Diagramas de Flujo de
Datos
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. 96)
No poner FD como señales de activación (Yourdon 89)
53
2.- Diagramas de Flujo de
Datos
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

54
2.- Diagramas de Flujo de
Datos
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 Confirmar son combinados en uno
datos provienen de historial de
cualquier dirección crédito

55
2.- Diagramas de Flujo de
Datos
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:
 Los aspectos procedurales no se manifiestan
en los DFDs
 Si tales aspectos son relevantes, se deben
incluir en las miniespecificaciones

56
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)

57
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

58
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
59
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) 60
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

61
2.- Diagramas de Flujo de
Datos
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

62
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

63
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

64
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 P6.1
pedido

P6.3
pago

65
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

66
2.- Diagramas de Flujo de
Datos
Jerarquía de DFDs (II)

P 1.2 B
Proceso A
A

DFD 1.2
P 1.2.2
f2 X

P 1.2.1 Y
f1 P 1.2.3
A W f3

67
2.- Diagramas de Flujo de
Jerarquía de DFDs Datos
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

68
2.- Diagramas de Flujo de
Descomposición funcional y Datos
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

69
Descomposición 2.- Diagramas de Flujo de
funcional y almacenes de Datos
datos (II)

P P
A B
D FICH

P
P B.1
A.1

D FICH
D FICH

P
P
A.2
B.2

70
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
Diagrama de contexto / sistema
Diagrama de subsistemas
Métrica Diagrama de funciones
Diagrama de subfunciones
Diagrama de procesos (opcional) 71
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)
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

72
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 P
Fuente Sumidero

73
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

74
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
75
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

76
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
77
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.)

78
3.- Diseño: Diagrama de

Diseño Estructurado Estructuras

Introducción

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

80
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

81
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.
82
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.
83
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
84
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.

85
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. 86


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.

87
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".

 
88
Efectividad del Diseño
‑ Módulo

Módulo Superordinado

Módulo Subordinado

Fan‑out : 2

Fan‑in : 1  
89
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
90
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 que la solución pueda
implementarse directamente”

91
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.
92
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.

Abstracción Refinamiento
Gradual

Módulo A

Modularidad Factorización

A1 A2
93
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.

94
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

95
Factores de Calidad

Acoplamiento

Principios de un
Cohesión Buen Diseño

96
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

97
Tipos de Acoplamiento
Mejor Acoplamiento

NORMAL
DATOS
ESTAMPADO

CONTROL

EXTERNO (caso especial de COMÚN)

COMÚN
CONTENIDO
Grado de
Acoplamiento

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

B
99
Tipos de Acoplamiento
2. Acoplamiento por Datos Obtener
Datos
Dos módulos están acoplados por Cliente
datos si ellos se comunican por
parámetros, siendo cada parámetro Rut_cliente
una unidad elemental de datos

El acoplamiento por datos Leer Rut


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.
100
Tipos de Acoplamiento
3. Acoplamiento por Estampado
Calcular
o Imagen Deuda
Cliente
Dos módulos aparecen
acoplados por estampado o
Cliente
ligados por imagen si ellos se
refieren a la misma estructura
Leer Cliente
datos local. Cabe destacar que
por estructura de datos se debe
entender un grupo compuesto
de datos, tal como un registro,
el cual, por su parte, se
Cliente= rut+nombres+apellido_paterno+
constituye de varios campos. Apellido_materno+dirección+fono+e_mail
101
Tipos de Acoplamiento
Obtener
4. Acoplamiento de Control
Datos
Dos módulos están acoplados Cliente

por control cuando uno de ellos


Tipo_dato Cliente
pasa al otro módulo elementos
de control (flags, switchs) como
argumentos. Leer Cliente

Provoca dependencia de
ejecución entre un módulo y
otro.

No es muy recomendable.

102
Tipos de Acoplamiento
Actualizar Obtener
5. Acoplamiento Común Stock Nombre
Video Video
Los módulos 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 Leer Registro
Programas con muchos datos globales son
Video
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.
103
Tipos de Acoplamiento
A B
6. Acoplamiento por Contenido

Este es un tipo de Acoplamiento ……….. ………..


Inaceptable. Dos módulos presentan Srch: Move.. ………
……….. ………..
acoplamiento de contenido (o ………. Jump to Srch
patológico) si uno hace referencia al ………. ……….
……… ………
interior del otro. Esto ocurre si por
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.
104
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


105
Tipos de Cohesión
Mayor Cohesión

FUNCIONAL Módulo como


SECUENCIAL Caja Negra

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" 106
Tipos de Cohesión

1. Cohesión Funcional
Ejemplos
Se puede decir que un
• Calcular el coseno de un ángulo
módulo con cohesión
funcional es aquel que •Calcular el I.V.A. De una factura
contiene elementos que
•Verificar el dígito de un RUT
contribuyen a la ejecución
de una y sólo una tarea
relacionada al problema
objeto de diseño,.

107
Tipos de Cohesión

2. Cohesión Secuencial
Ejemplo: Calcular Salario
Un módulo secuencialmente 1. Obtener sueldo base
cohesionado es aquel cuyos 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
7. Agregar horas extras
próxima actividad. 
....

108
Tipos de Cohesión

3. Cohesión Comunicacional
Ejemplo: Obtener datos
Un módulo presenta cohesión Video
comunicacional cuando sus 1. Obtener nombre video
elementos contribuyen a 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 ....

109
Tipos de Cohesión
4. Cohesión Procedimental

un módulo cohesionado por Ejemplos: Actividades en


procedimientos es aquel cuyos una oficina
elementos están envueltos en
1. Hablar por teléfono
actividades diferentes y 2. Tomar un café
posiblemente no relacionadas, 3. Leer correo electrónico
en donde el control fluye de 4. Solicitar cotización
una actividad a otra. ....

110
Tipos de Cohesión

5. Cohesión Temporal
Ejemplo: Actividades al
Un módulo con cohesión iniciar el día
temporal es aquel cuyos
1. Apagar despertador
elementos están envueltos en
2. Tomar una ducha
actividades que están
3. Vestirse
relacionadas en función del
4. Hacer la cama
momento en que se realizan. 5. Tomar desayuno
....

111
Tipos de Cohesión
6. Cohesión Lógica

Un módulo tiene cohesión Ejemplo: Registrar Pago


lógica, cuando existe alguna
1. Registrar pago con tarjeta de
relación entre los elementos
crédito
del módulo, contribuyendo al
2. Registrar pago con cheque
desarrollo de actividades de
3. Registrar pago con efectivo
una misma categoría general,
....
donde la actividad o las
actividades a ser ejecutadas se
seleccionan desde fuera del
módulo.
112
Tipos de Cohesión

7. Cohesión Coincidental
Ejemplo:
Un módulo coincidentemente
1. Comprar un libro
cohesionado es aquel cuyos 2. Comer un trozo de torta
elementos desarrollan 3. Ir al teatro
actividades sin relación 4. Lavar la ropa
significativa entre sí. 5. Dormir
....

113
Árbol de Cohesión

114
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.
115
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.
 

116
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

117
Diseño Arquitectónico

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

119
Especificación de procesos
 Nombre : REGISTRAR DATOS
Interfaz ACTUALIZACIÓN
 Entradas : Datos_actualización
 Salidas :Datos_actualización,
datos_actualización_registrados.
 Procedimiento: Pseudocódigo

 Recibir Datos_actualización.
 Abrir archivo INFORMACIÓN MUNICIPAL.
 Escribir en archivo los Datos_actualización.
 Cerrar archivo INFORMACIÓN MUNICIPAL.
 Mandar mensaje indicando
120
Datos_actualización_registrados.
Diseño de Datos
c la v e _ V o t
N om _C and Id_ V o to N om _C and
P art_ C an d
I d _ P a r t id o
R ut_ V o t

c a n d id a t o s
V o tan te V o to

N om _Vot

c o n t ie n e

a sig n a
c o n su lt a

N om _C and

D ir e c c ió n

S e r v ic io s
M u n ic ip a lid a d
Fono

N o m _ O rgan

C o m un a
Id_ O rgan

121
Diseño de Datos

Votante
Clave_Vot A10 Voto Detalle_Voto
Rut_Vot A10 Id_Voto A10 Id_Voto A10
Nom_Vot A30 Id_Partido A30

Servicio
Cod_Serv N5
Descrip_Serv A30

Candidato
Id_Partido A30
Nom_Cand A30

Municipalidad
Id_Orga A10
Nom_Orga A30
Servcio A30
Dirección A30
Fono N10
Comuna A20

122
Diseño de Interfaz

123
Elementos del Diagrama de
Estructura
Obtener
Nombre Módulo
Video

Leer Registro
Video Módulo
Predetermina
do

X MÓDULO JEFE
(INVOCADOR)

Y MÓDULO SUBORDINADO
(INVOCADO)
124
Elementos del Diagrama
de Estructura
Obtener
Datos
Cliente Flujo de Control

Tipo_dato Flujo de Dato


Cliente

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
125
Elementos del Diagrama de
Estructura

Conectores

126
Elementos del Diagrama de
Estructura
Secuencia

Iteración
127
Elementos del Diagrama de
Estructura
Selección

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

129
Estrategia de Diseño para
Construir Diagrama de Estructura
 

Diseño Centrado en
Transformaciones

DFD Diagrama de
Estructura
Diseño Centrado en
Transacciones

Análisis Diseño

130
Estrategia de Diseño
 
Diseño Centrado en
1.1 1.2
Transformaciones
3
• Los datos entran al sistema 4.1
mediante caminos que se llaman 2.1 2.2
flujos de entrada
4.2
• En el núcleo ocurre la Flujo de Llegada
Flujo de
transformación de los datos, que Centro Salida
entraron anteriormente de
Transformación
•Finalmente los datos se mueven
por caminos llamados flujos de
salida
131
Estrategia de Diseño
Diseño Centrado en  
Camino de
Transacciones Acción 1
2.1 2.2
• Se presenta un centro de
transacción, como centro de
flujo de información
1 3.1 3.2 Camino de
Acción 2
• Desde el centro de flujo de Centro
Información, surgen muchos de
Transacción
caminos de acción alternativos 4.1 4.2
Camino de
•Los caminos de acción Acción 3
alternativos, son de forma
excluyentes

132
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 el centro de transformación (depende del


diseñador)

4. Realizar el primer corte del diagrama de estructura

Primer nivel de factorización, se incorporan módulos


coordinadores 133
Estrategia de Diseño:
Transformación
•Módulos a incorporar
1.1 1.2
• Módulo principal Cp, que
3
controla el resto de los 4.1
módulos 2.1 2.2
Centro 4.2
•Módulo coordinador de la de
Flujo de Llegada
Transformación Flujo de
Información de Entrada, Ce
Salida
•Módulo controlador del centro
Diagrama de
de transformación, que Contexto
Cp
supervisa las operaciones de
los datos, Ct

•Módulo controlador, del Ce Ct Cs


procesamiento de la
información de salida, Cs
134
Nombres representativos
Estrategia de Diseño:
Transformación
5. Ejecución del “segundo nivel de factorización”
a
1.1 1.2
3
b 4.1 Cp
2.1 2.2 z
Centro 4.2
de Ce Ct Cs
Flujo de Llegada
Transformación Flujo de
Salida
1.2 2.2 3 4.1

1.1 2.1 4.2

Leer a Leer b Escribir


z

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

136
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 137
Estrategia de Diseño:
Transacción  

•Módulos a incorporar
a
• Módulo principal Cp, que
A D
controla el resto de los
módulos z
P Q R
•Módulo coordinador de la
Información de Entrada, Ce b

•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 138 C3
Estrategia de Diseño:
Transacción
5. Ejecución del “segundo nivel de factorización”

Camino 1

a Cp
A D Camino 2

Ce D
P Q z
R
a
b Camino 3
C1 C2 C3
Leer a

P Q R

Escribir
Leer b 139
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.

140

Diseño Procedimental (Diseño
Detallado

Especificación Interfaz-Función

Especificación Mediante las
Miniespecificaciones del Análisis

Especificación por Pseudocódigo

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

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

143
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 de módulos. Se considera, en
general, que la especificación de cada burbuja del
diagrama de flujo de datos es suficiente para
especificar 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. 144
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 Asiento-
Seleccionado.
(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”.

145
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

146

You might also like