Análisis y Diseño Estructurado Docente : Yessica Gómez Gutiérrez Diagrama de Flujo de Datos 1

Análisis y Diseño Estructurado

Docente : Yessica Gómez Gutiérrez

P1 Proceso ENTIDAD

EXTERNA

flujo de datos D ALMACÉN DE

DATOS

Diagrama de Flujo de Datos

1

2

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.

Introducción

3

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

Actividades Iniciales y Análisis de Requisitos. Donde nos encontramos…Donde nos encontramos…

Análisis del Sistema de Información (Proceso ASI) Definición del Sistema.

Introducción

4

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.

Introducción

5

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

Introducción

6

Objetivos: Detectar inconsistencias, ambigüedades, duplicidad o escasez de

información. Se revisan las prioridades. Se revisan las prioridades. Se relacionan requisitos. Se relacionan requisitos. Identificar relaciones entre casos de uso.

Introducción

7

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

Introducción

8

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.

Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos. Estudio de Viabilidad. EVS.

Introducción

9

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

Introducción

10

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

Introducción

11

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.

Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos. Técnicas de recogida de Información.

Introducción

12

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.

Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos. Técnicas de recogida de Información.

Introducción

13

“El proceso de estudio de las necesidades de los usuarios para llegar a una definición de los 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]

REQUISITO:

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 un problema o conseguir un beneficio determinado.

Análisis de Requisitos:

Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos. Actividades generales de la etapa de análisis. ASI.

Introducción

14

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.

Introducción

15

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.


Introducción

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 Proceso ENTIDAD

EXTERNA


DATOS 16

Visión panorámica del AyDEVisión panorámica del AyDE

Análisis EstructuradoMétodo clave en el “desarrollo

estructurado” o “convencional”Aparece a finales de los 70Facilita 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

Amplia difusión Descomposición funcional

(Originariamente) Orientada a procesos (Originariamente) Top/down

Presente en numerosas metodologíasp.ej. Métrica, SSADM, information

engineering, Merise Herramientas CASE disponibles

Visión panorámica del AyDE. Visión panorámica del AyDE. CaracterísticasCaracterísticas

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

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)

Visión panorámica del AyDE. ComponentesVisión panorámica del AyDE. Componentes

21

Lógica de procesosLenguaje estructuradoPre y post-condicionesTablas de decisiónÁrboles de decisión

Diccionario de Datos (DD)

Visión panorámica del AE. componentesVisión panorámica del AE. componentes

22

Visión panorámica Visión panorámica del AE. DFDdel AE. DFD

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

P1

Proceso ENTIDAD EXTERNA


DATOS

23

P1

Proceso ENTIDAD EXTERNA


DATOS

Tipos de símbolos en los DFDs

(notación de Yourdon/De Marco)

Visión panorámica del AE. DFDVisión panorámica del AE. DFD

24

Adaptado del capítulo 2 de Gane, C. and T. Sarson, Análisis estructurado de sistemas. 1990, Buenos Aires: El Ateneo.

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

Ejemplo

Visión panorámica del AE. DFD: Ejemplo Visión panorámica del AE. DFD: Ejemplo PrácticoPráctico

25

Diagrama de contexto

Análisis de los procesos del sistema

en principio, no son materiales,

son datos

0. Sistema de

Pedidos EDITOR

libros entregados

pedidosCLIENTE

órdenes de compra

libros pedidos

Aplicamos la visión sistémica

Visión panorámica del AE. DFD: Ejemplo Visión panorámica del AE. DFD: Ejemplo PrácticoPráctico

26

0. Sistema de pedidos

1.Verificar validez

de pedido

pedidos

2.Armar

pedidos a editores

pedidos en lote

3.Verificar

envíode editores

libros pedidos

4.Asignar libros a pedidos

5.Armar entrega

a clientes

pedidos por título

libros recibidos

libros por clientes

D CLIENTES

estado del crédito

dirección

D LIBROS

libros entregados

libros entregados = albarán + lista-novedades

DD

DD

libros recibidos = {título + cantidad}

pedidos válidos

D PEDIDOS PENDIENTES

órdenes de compra

D ÓRDENES DE COMPRA

Visión panorámica del AE. DFD: Ejemplo PrácticoVisión panorámica del AE. DFD: Ejemplo Práctico

27

“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

Visión panorámica del AE. Diccionario de DatosVisión panorámica del AE. Diccionario de Datos

28

Flujo de datos: entregaDescripció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 salidaOrigen Destino*** Off the diagram *** Compra librosPROVEEDORES Biblioteca

Visión panorámica del AyDE. Diccionario de Visión panorámica del AyDE. Diccionario de DatosDatos

29

Visión panorámica AyDEDiccionario de Datos (III)

Almacen: FacturasDescripció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 generalProc_cancelación Proc_pagoProc_consultas Adjuntar_albarán

30

Proceso: Verificar estado del socioNúmero: 1.1.1 Descripción: Se examina si el socio no está sancionadoMiniespecificación:

Recibir “Socio ID” del socioLeer “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:

Visión panorámica del AyDE. Pseudocódigo.Visión panorámica del AyDE. Pseudocódigo.

31

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:Nno atributos multivaluados ni

compuestos

Visión panorámica del AyDE. Modelado de DatosVisión panorámica del AyDE. Modelado de Datos

32

Diagrama E-R

ProyectoEmpleado

Departamento

asignado

pertenece

(1,n)

(1,1)

(0,n) (1,m)

[EN2002] (Chen)

Asignación

Departamento

Empleado

Proyecto

requiere

tiene

perteneceDED

Visión panorámica del AE. Ejemplo de E/RVisión panorámica del AE. Ejemplo de E/R . .

33

Técnicas para describir la lógica de los procesos primitivosLenguaje estructuradoPre y post-condicionesTablas de decisiónÁrboles de decisión

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

34

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

Pre y post-condicionesPre1 (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)

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

36

ESTADO DE LA CUENTA

CORRECTO IMPAGADO CORRECTO IMPAGADO

NETO-FACTURA >300€ >300€ <=300€ <=300€

CONFIRMACIÓN PENDIENTE

x

HACER CONFIRMACIÓN

x x x

HACER FACTURA

x x x

ESCRIBIR MENSAJE x

Tablas de decisión


37

Árboles de decisión

Política contabl

e

Factura excede de 300€

Factura menos de 300€

Cuentas impagadas más de 60 días

Cuentas en buen estado

Cuentas impagadas más de 60 días

Cuentas en buen estado

1. Dejar confirmación pendiente de los pagos debidos.

2. Hacer confirmación y factura

3. Hacer confirmación y factura y escribir mensaje sobre informe de crédito

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 DIAGRAMA DE ESTRUCTURAESTRUCTURA.

En el paso AE DE, Análisis de transacciones Análisis de transformaciones

39

Diseño Estructurado: DIAGRAMA DE Diseño Estructurado: DIAGRAMA DE ESTRUCTURA.ESTRUCTURA. Ejemplo de diagrama de

estructuras

Informarpetición

Elaborarinforme

Rechazarpetición

Leerpeticiones

Consultarstock

Recibirpeticiones

Evaluar peticiones

informe préstamoinforme préstamo

pet rechazada

okpet préstamo

pet aceptada

pet aceptada

pet préstamo

40

Definiciones de la BD

Visión panorámica AEEsquema resumen

Diccionariode Datos

Diagrama de flujo de datos

PROC

B

Z

Y

X

W

V

APROC

PROC

PROCPROC

FUENTE

DESTINO

D ALMACÉN DE DATOS

Diagrama E-R (o DED)

Diagrama de estructuras

Paso al diseño

Descripcióndel proceso

Definición del FD

Definiciones de los módulos

Descrip.E. E.

41

Diagramas de Flujo de Datos(DFDs)

42

Símbolos del DFD(notación Yourdon/De Marco)

PProceso

Entidad Externa

D ALMACÉN DE DATOS

Flujo de eventos

Flujo de datos

Transformaciones o procesos (funciones, cálculo, selección)

Terminadores (Fuentes o Destinos)(personas, entidades)

Flujos de información(inputs-outputs)

Flujos de control (Ward & Mellor 85)

Ficheros o depósitos temporales de información (base de datos, armario, clasificador, etc.)

2.- Diagramas de Flujo de Datos

43

Símbolos del DFD(notación Métrica/SSADM)

Entidad Externa

D ALMACÉN DE DATOS

Flujo de datos

Transformaciones o procesos

Terminadores (Fuentes o Destinos)

Flujos de información

Ficheros o depósitos temporales de información

Localización

Proceso

ID


44

Procesos

TRANSFORMACIÓN (cálculo, operación)

FILTRO(verificación fecha, validación transacción)

DISTRIBUCIÓN(menú, selección transacción)

P

TransformaciónE2

E3

E1

S2

S1


45

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

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

Entidades externas

Señalan los límites del sistema y establecen sus relaciones con el entorno

P

Sistema

DESTINO

DESTINO

DESTINO

FUENTE

FUENTE

FUENTE

Los identificadores (nombres) de las entidades externas serán únicos, significativos y concisos


48

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

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.

PDeterminar

estado pedido respuesta estado pedido

petición estado pedido

denegacióncrédito

PAnalizarPeticióncrédito

PAceptar pago solicitud crédito

autorización crédito

recibo

pago


50

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!

PB

PA

X

X

PA

PB

X


51

Flujos de datos (IV)

Se puede representar, si se desea, el FLUJO DE MATERIAL, usando flechas de trazo grueso

EDITORIALES INTERVENTOR

P4

Enviar al dpto.comprador

P1

Selecc. ypedir nuevos

libros

P3

Registrar librosnuevos

P5

Poner librosnuevos enestantes

P2

Examinarnuevos libros

D2 ESTANTES

D3 INVENTARIO

D4 SIGNATURAS

D9 CARRITOLIBROS NUEVOS

D1 LISTA MAESTRADE ISBN

nuevas ofertas

pedidos de libros nuevos

ajuste de inventario

ajuste de signaturas

nuevos libros

libros nuevos

libros nuevos

libros nuevoslibros nuevos

libros nuevos

libros nuevos

Notación Gane & Sarson


52

Flujos de datos (V)

Se pueden considerar flechas convergentes o divergentes, con un mismo nombre

PB

PA

número de cuenta

PValidar

calle

PValidar

cod postal

PValidarTelef.

calle

dirección clicod postal

telef

Observaciones:

Sólo los procesos pueden separar FD (Piattini et al. 96)

No poner FD como señales de activación (Yourdon 89)


53

Flujos de datos (VI)

Notación System Architect. Ejemplos

FD divergentes (conectores XOR y AND)

PImprimir facturacliente

PImprimir

lista empaquetado

PDeterminarprods.para

enviar XORcuando los datos son

divididos en subconjuntos

datos de facturación

datos de empaquetadodatos de envío

PDeterminar prescripción

PRellenar

prescripción

PActualizar

registropaciente

ANDcuando todos los datos

siguen por ambos caminos

prescripción


54

Flujos de datos (VII)

Notación System Architect. Ejemplos

FD convergentes (conectores XOR y AND)

PAceptar pago

en metálico

PTransferir

pago

PAceptar pago

a crédito

XOR cuando los mismos

datos provienen decualquier dirección

datos de pago

PConfirmar

historial de crédito

PConcedertarjeta de

crédito

PConfirmar

empleo

ANDcuando los subconjuntosson combinados en uno

historial de empleo

historial de crédito

historia combinada


55

Flujos de datos (VIII)

No lo sabemos, no importa:Los aspectos procedurales no se

manifiestan en los DFDsSi tales aspectos son relevantes, se

deben incluir en las miniespecificaciones

¿El proceso “pide” el FD “pedido”?

¿El proceso “necesita” ambos FD?

PEvaluar pedido

criterios valoración

pedido


56

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

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

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-RCada almacén de un DFD representa

una o varias entidades del E-RCada entidad del E-R pertenece a un

único almacén principal de un DFD


59

Consistencia DFD / E-R (II)

ETIQUETA DE LOS ALMACENESSegún explosione a

Entidad de datos Plural nombre entidad Diagrama E-R (o DED) Nombre diagrama

DEFINICIÓN DE LOS ALMACENES1. 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

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

Descomposición funcional (II)

Pf5

Pf4

Pf3

Pf2

Pf1

B

Z

Y

X

W

V

A

Pf45

Pf44

Pf43

Pf42

Pf41

Z

y2

x2

y1

x1

Y

X

PSist

B

AFUENTE

DESTINO


62

Consistencia en el DFD

Cada proceso en un diagrama “padre” es una consolidación del DFD “hijo”

Balanceo de DFDsLas E/S de un proceso “padre” deben

corresponderse con las E/S del DFD “hijo” que lo explica


63

Descomposición paralela

Descomposiciones de funcionesProceso en subprocesos (DFD)

Descomposición de flujos de datos La regla de balanceo se aplica

teniendo en cuenta la descomposición paralela


64

Descomposición paralela (II)

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

P6

P5

P4P3

P2

P1

envío

pedido

P6.3

P6.2

P6.1

pago

envío

cupón de pedido

autorización


65

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ónProceso Proceso primitivo en Métrica


66

Jerarquía de DFDs (II)

P 1.2

Proceso A

B

A

P 1.2.3f3

P 1.2.1f1

Y

W

V

A

X

P 1.2.2f2

DFD 1.2


67

Jerarquía de DFDsDFD 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

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


69

Descomposición funcional y almacenes de datos (II)

PB

PA

D FICH

PA.2

PA.1

D FICH

PB.2

PB.1

D FICH


70

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 / sistemaDiagrama de subsistemasDiagrama de funcionesDiagrama de subfuncionesDiagrama de procesos (opcional)

Métrica


71

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)

P

SIST. DEINVESTIG. DEMERCADOS

CENTROS DEINVESTIGACIÓN

CLIENTE

CLIENTESCORPORATIVOS

D DATOS DELMERCADO

informes anuales

datos de investigación

datos del mercado

datos del mercado


72

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

Sumidero

PFuente


73

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 outputsDe outputs a inputsDesde una posición intermedia hacia

delante o hacia atrás


74

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

DFDs - Conclusiones

Valiosa herramienta de comunicaciónUsuario, analista, diseñador, programadorSe puede combinar con el uso de

prototipos Fácil de entender y de aprender Facilita las relaciones con el usuario Amplia difusión


76

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

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

Diseño EstructuradoDiseño Estructurado IntroducciónIntroducció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

3.- Diseño: Diagrama de Estructuras

79

Diseño ArquitectónicoDiseño Arquitectónico ( Diseño Preliminar) ( 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

3.- Diseño: Diagrama de Estructuras

80

“ El diseño es un proceso a través del cual los

requerimientos establecidos en la fase de análisis

deben traducirse en una representación ‑que se

sugiere modular‑ del producto de software que se

precisa construir y que se acompaña de los

procedimientos en virtud de los cuales cada módulo

debe llevar a cabo su tarea, y de las estructuras de

datos que debe procesar” Larry Constantine ‘78

Concepto y Principios del DiseñoConcepto y Principios del Diseño

81

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.

Concepto y Principios del Concepto y Principios del DiseñoDiseño

82

Efectividad del DiseñoPara 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


‑ 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


‑ 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


‑ Módulo

Módulo Superordinado

Módulo Subordinado

Fan‑out : 2

Fan‑in : 1 89


‑ Módulos & Integración

N° Módulos

Costos o Esfuerzo

Costo por Módulo

Costo por IntegraciónCosto Total SW

Costos Mínimos90


‑ 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


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

Módulo A

Abstracción RefinamientoGradual

A1 A2

Modularidad Factorización

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

Cohesión

Principios de un 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


Grado de Acoplamiento

NORMAL

Mejor Acoplamiento

DATOS

ESTAMPADO

CONTROL

EXTERNO (caso especial de COMÚN)

COMÚN

CONTENIDO

98


1.Acoplamiento Normal

Dos Módulo A y B están Normalmente Acoplados si:• Un Módulo A llama a otro B• B retorna el control a A

No se produce traspaso de parámetros entre ellos, sólo existe la llamada de uno a otro.

A

B

99

Tipos de Acoplamiento2. Acoplamiento por Datos

Dos módulos están acoplados por

datos si ellos se comunican por

parámetros, siendo cada parámetro

una unidad elemental de datos

El acoplamiento por datos

corresponde a la comunicación de

datos necesaria entre módulos. Toda

vez que los módulos tienen que

comunicarse entre sí, la ligazón por

datos es inevitable y serán adecuadas

si se mantienen a niveles mínimos.

Obtener Datos

Cliente

Leer Rut

Rut_cliente

100

Tipos de Acoplamiento3. Acoplamiento por Estampado

o Imagen

Dos módulos aparecen

acoplados por estampado o

ligados por imagen si ellos se

refieren a la misma estructura

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

constituye de varios campos.

Calcular DeudaCliente

Leer Cliente

Cliente

Cliente= rut+nombres+apellido_paterno+Apellido_materno+dirección+fono+e_mail

101


4. Acoplamiento de Control

Dos módulos están acoplados

por control cuando uno de ellos

pasa al otro módulo elementos

de control (flags, switchs) como

argumentos.

Provoca dependencia de

ejecución entre un módulo y

otro.

No es muy recomendable.

ObtenerDatos

Cliente

Leer Cliente

ClienteTipo_dato

102


5. Acoplamiento Común

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

una variable (global), se trata

de un Acoplamiento Externo

Obtener Nombre

Video

Leer RegistroVideo

video

Actualizar StockVideo

Programas con muchos datos globales son extremadamente difíciles de entender por los programadores de mantención, porque no es fácil saber cuáles son los datos usados por un cierto módulo.

103

Tipos de Acoplamiento6. Acoplamiento por Contenido

Este es un tipo de Acoplamiento

Inaceptable. Dos módulos presentan

acoplamiento de contenido (o

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

comando de otro.

Tal acoplamiento torna el concepto de

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.

………..………………..Jump to Srch……….………

A

………..Srch: Move..………..……….……….………

B

104


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

Grado de Cohesión

FUNCIONAL

Mayor Cohesión

SECUENCIAL

COMUNICACIONAL

PROCEDURAL

TEMPORAL

LÓGICA

COINCIDENTAL

Módulo como Caja Negra

Módulo Transparente

STEVEN, MYERS, CONSTANTINE y YOURDON (1974)establecieron "una escala de cohesión" 106

Tipos de Cohesión

1. Cohesión Funcional

Se puede decir que un

módulo con cohesión

funcional es aquel que

contiene elementos que

contribuyen a la ejecución

de una y sólo una tarea

relacionada al problema

objeto de diseño,.

Ejemplos

• Calcular el coseno de un ángulo

•Calcular el I.V.A. De una factura

•Verificar el dígito de un RUT

107

Tipos de Cohesión

2. Cohesión Secuencial

Un módulo secuencialmente

cohesionado es aquel cuyos

elementos están envueltos en

actividades tales que los datos

de salida de una actividad sirven

como datos de entrada para la

próxima actividad.

Ejemplo: Calcular Salario

1. Obtener sueldo base

2. Verificar número de cargas

3. Revisar días con permiso

4. Revisar días con licencia

5. Calcular horas de trabajo

6. Descontar horas de atraso

7. Agregar horas extras

....

108

Tipos de Cohesión

3. Cohesión Comunicacional

Un módulo presenta cohesión

comunicacional cuando sus

elementos contribuyen a

actividades que usan la misma

entrada o la misma salida. No

importa el orden secuencial

Ejemplo: Obtener datos

Video

1. Obtener nombre video

2. Obtener stock video

3. Obtener ubicación

4. Obtener precio

....

109

Tipos de Cohesión

4. Cohesión Procedimental

un módulo cohesionado por

procedimientos es aquel cuyos


actividades diferentes y

posiblemente no relacionadas,

en donde el control fluye de

una actividad a otra.

Ejemplos: Actividades en

una oficina

1. Hablar por teléfono

2. Tomar un café

3. Leer correo electrónico

4. Solicitar cotización

....

110

Tipos de Cohesión

5. Cohesión Temporal

Un módulo con cohesión

temporal es aquel cuyos


actividades que están

relacionadas en función del

momento en que se realizan.

Ejemplo: Actividades al

iniciar el día

1. Apagar despertador

2. Tomar una ducha

3. Vestirse

4. Hacer la cama

5. Tomar desayuno

....

111

Tipos de Cohesión

6. Cohesión Lógica

Un módulo tiene cohesión

lógica, cuando existe alguna

relación entre los elementos

del módulo, contribuyendo al

desarrollo de actividades de

una misma categoría general,

donde la actividad o las

actividades a ser ejecutadas se

seleccionan desde fuera del

módulo.

Ejemplo: Registrar Pago

1. Registrar pago con tarjeta de

crédito

2. Registrar pago con cheque

3. Registrar pago con efectivo

....

112

Tipos de Cohesión

7. Cohesión Coincidental

Un módulo coincidentemente

cohesionado es aquel cuyos

elementos desarrollan

actividades sin relación

significativa entre sí.

Ejemplo:

1. Comprar un libro

2. Comer un trozo de torta

3. Ir al teatro

4. Lavar la ropa

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ónicoDiseñ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

Interfaz

Nombre : REGISTRAR DATOS ACTUALIZACIÓN

Entradas : Datos_actualización Salidas :Datos_actualización,

datos_actualización_registrados. Procedimiento: Recibir Datos_actualización. Abrir archivo INFORMACIÓN MUNICIPAL. Escribir en archivo los

Datos_actualización. Cerrar archivo INFORMACIÓN MUNICIPAL. Mandar mensaje indicando

Datos_actualización_registrados.

Pseudocódigo

120

Diseño de Datos

I d _ O r g a n

M u n ic ip a l id a d

D ir e c c ió n

N o m _ O r g a n

F o n o

C o m u n a

Se r v ic io s

I d _ V o t o

V o t a n t e

R u t _ V o t

N o m _ C a n dN o m _ C a n dc la v e _ V o t

V o t oc a n d id a t o s

P a r t _ C a n d

c o n s u l t a

c o n t ie n e

a s ig n a

N o m _ V o t

N o m _ C a n d

I d _ P a r t id o

121

Diseño de Datos

Votante

Clave_Vot A10Rut_Vot A10Nom_Vot A30

Voto

Id_Voto A10

Candidato

Id_Partido A30Nom_Cand A30

Servicio

Cod_Serv N5Descrip_Serv A30

Municipalidad

Id_Orga A10Nom_Orga A30Servcio A30Dirección A30Fono N10Comuna A20

Detalle_Voto

Id_Voto A10Id_Partido A30

122

Diseño de Interfaz

123

Elementos del Diagrama de Estructura

MóduloObtener Nombre

Video

Leer RegistroVideo Módulo

Predeterminado

MÓDULO JEFE(INVOCADOR)

MÓDULO SUBORDINADO(INVOCADO)

X

Y

124


Flujo de Control

Un almacén de datos corresponde a la instancia realen la cual van a estar los datos que precisa el sistema

Un dispositivo físico es cualquier dispositivomediante el cual se puede recibir o enviar datosnecesarios para el sistema

ObtenerDatos

Cliente

Leer Cliente

ClienteTipo_dato Flujo de

Dato

125


Conectores

126


Secuencia

Iteración

127


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

Diseño Centrado en

Transacciones

DFD Diagrama de Estructura

DiseñoAnálisis

130

Estrategia de Diseño

Diseño Centrado en

Transformaciones

• Los datos entran al sistema

mediante caminos que se llaman

flujos de entrada

• En el núcleo ocurre la

transformación de los datos, que

entraron anteriormente

•Finalmente los datos se mueven

por caminos llamados flujos de

salida

1.1

4.2

4.13

1.2

2.1 2.2

Flujo de Llegada

Centrode

Transformación

Flujo de Salida

131

Estrategia de DiseñoDiseño Centrado en

Transacciones

• Se presenta un centro de

transacción, como centro de

flujo de información

• Desde el centro de flujo de

Información, surgen muchos

caminos de acción alternativos

•Los caminos de acción

alternativos, son de forma

excluyentes

2.1

1

2.2

3.1 3.2

Camino de Acción 1

4.1 4.2

Camino de Acción 2

Camino de Acción 3

CentrodeTransacción

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

•Módulos a incorporar

• Módulo principal Cp, que

controla el resto de los

módulos

•Módulo coordinador de la

Información de Entrada, Ce

•Módulo controlador del centro

de transformación, que

supervisa las operaciones de

los datos, Ct

•Módulo controlador, del

procesamiento de la

información de salida, Cs

1.1

4.2

4.13

1.2

2.1 2.2

Flujo de Llegada

Centrode

Transformación Flujo de Salida

Cp

CsCtCe

Diagrama de Contexto

Nombres representativos


134


5. Ejecución del “segundo nivel de factorización”

1.1

4.2

4.13

1.2

2.1 2.2

Flujo de Llegada

Centrode

Transformación Flujo de Salida

Cp

CsCtCe

2.2

2.11.1

1.2

Leer a Leer b

a

b

4.1

4.2

3

Escribirz

z


135

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

•Módulos a incorporar

• Módulo principal Cp, que

controla el resto de los

módulos

•Módulo coordinador de la

Información de Entrada, Ce

•Módulo gestor del centro de

transacción, D

•Módulo controlador, los

distintos caminos que generan

información de salida,

Ci i =1—n (n: n° caminos)

Cp

D

C1

Ce


C2 C3

R

A

Q

D

P

a

z

b

138



Cp

Ce

RP Q

Leer a

Leer b

a

Escribirz


R

A

Q

D

P

a

z

b

Camino 1

Camino 2

Camino 3

D

C1 C2 C3

139

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 Diseño Procedimental (Diseño DetalladoDetallado

Especificación Interfaz-FunciónEspecificación Interfaz-FunciónEspecificación Mediante las Especificación Mediante las Miniespecificaciones del AnálisisMiniespecificaciones del AnálisisEspecificación por PseudocódigoEspecificación por Pseudocódigo

141

Diseño Detallado1. 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 Detallado2. 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

Documents

Análisis y Diseño Estructurado Docente : Yessica Gómez Gutiérrez Diagrama de Flujo de Datos 1