An lisis y dise o estructurado l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 132

Análisis y Diseño Estructurado PowerPoint PPT Presentation


  • 237 Views
  • Uploaded on
  • Presentation posted in: General

Diagrama de Flujo de Datos. Análisis y Diseño Estructurado. Docente : Yessica Gómez Gutiérrez . Análisis y Diseño Estructurado. Introducción - Visión panorámica del Análisis y Diseño Estructurado. Análisis : Diagramas de Flujo de Datos . Diseño: Diagrama de Estructuras.

Download Presentation

Análisis y Diseño Estructurado

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


An lisis y dise o estructurado l.jpg

Diagrama de Flujo de Datos

Análisis y Diseño Estructurado

Docente : Yessica Gómez Gutiérrez


An lisis y dise o estructurado2 l.jpg

Análisis y Diseño Estructurado

  • Introducción - Visión panorámica del Análisis y Diseño Estructurado.

  • Análisis : Diagramas de Flujo de Datos.

  • Diseño: Diagrama de Estructuras


1 introducci n visi n panor mica del ayde l.jpg

1.- Introducción: Visión panorámica del AyDE

  • Análisis Estructurado

    • Método clave en el “desarrollo estructurado” o “convencional”

    • Aparece a finales de los 70

    • Facilita la comunicación en el proceso de desarrollo de un sistema de información

      • análisis y diseño

      • usuarios y analistas

    • Sencillo, fácil de entender y fácil de aprender


1 introducci n visi n panor mica del ayde caracter sticas l.jpg

1.- Introducción: Visión panorámica del AyDE. Características

  • Amplia difusión

  • Descomposición funcional

    • (Originariamente) Orientada a procesos

    • (Originariamente) Top/down

  • Presente en numerosas metodologías

    • p.ej. Métrica, SSADM, information engineering, Merise

  • Herramientas CASE disponibles


Bibliograf a l.jpg

Bibliografía

  • Texto principal

    • Mario Piattini,Jose Calvo-Manzano,Joaquín Cervera,Luis Fernandez, Análisis y diseño detallado de Aplicaciones Informáticas de gestión. Edit. Ra-ma

    • Yourdon, E., Análisis estructurado moderno. 1993: Prentice-Hall Hispanoamericana


Bibliograf a ii l.jpg

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


Slide7 l.jpg

1.- Introducción: Visión panorámica del AyDE. Componentes

  • DFD (Diagrama de Flujo de Dato Dataflow diagram)

  • Diagrama E-R (Entidad-Relación), o alternativamente, DED (Diagrama de Estructura de Datos)

  • Diagramas HVE (Historia de Vida de las Entidades)

  • Diagramas de Transición de Estados (STD, State Transition Diagram)


1 introducci n visi n panor mica del ae componentes l.jpg

1.- Introducción: Visión panorámica del AE. componentes

  • Lógica de procesos

    • Lenguaje estructurado

    • Pre y post-condiciones

    • Tablas de decisión

    • Árboles de decisión

  • Diccionario de Datos (DD)


1 introducci n visi n panor mica del ae dfd l.jpg

1.- Introducción: Visión panorámica del AE. DFD

  • Visión general de las funciones y transformaciones de datos en una organización

  • Modelo lógicoy gráfico del sistema

    • también como modelo físico

  • Identifica entradas, salidas, procesos y relaciones con el exterior

    • ...a nivel general

    • ...por refinamiento, a nivel detallado


1 introducci n visi n panor mica del ae dfd10 l.jpg

1.- Introducción: Visión panorámica del AE. DFD

Tipos de símbolos en los DFDs

(notación de Yourdon/De Marco)


1 introducci n visi n panor mica del ae dfd ejemplo pr ctico l.jpg

1.- Introducción: Visión panorámica del AE. DFD: Ejemplo Práctico

Ejemplo

Sistema de distribución sin inventario

“Se trata de un sistema que sirve pedidos de libros a unos clientes, con la particularidad de que no mantiene un stock o inventario interno. El sistema puede agrupar los pedidos que clientes distintos hacen a un mismo editor, de manera que se puedan conseguir descuentos.”

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


1 introducci n visi n panor mica del ae dfd ejemplo pr ctico12 l.jpg

pedidos

órdenes de compra

libros entregados

0.

Sistema de

Pedidos

CLIENTE

EDITOR

libros pedidos

1.- Introducción: Visión panorámica del AE. DFD: Ejemplo Práctico

Análisis de los procesos del sistema

 Aplicamos la visión sistémica

Diagrama de contexto

en principio, no son materiales, son datos


1 introducci n visi n panor mica del ae dfd ejemplo pr ctico13 l.jpg

pedidos

órdenes de compra

D LIBROS

pedidos válidos

2.

Armar

pedidos

a editores

estado del crédito

1.

Verificar

validez

de pedido

D PEDIDOS

PENDIENTES

D ÓRDENES DE

COMPRA

pedidos en lote

D CLIENTES

pedidos por título

dirección

libros por

clientes

libros

recibidos

3.

Verificar

envío

de editores

libros entregados = albarán + lista-novedades

libros recibidos = {título + cantidad}

libros pedidos

libros entregados

5.

Armar

entrega

a clientes

 DD

 DD

4.

Asignar

librosa

pedidos

1.- Introducción: Visión panorámica del AE. DFD: Ejemplo Práctico

0. Sistema de pedidos


1 introducci n visi n panor mica del ae diccionario de datos l.jpg

1.- Introducción: Visión panorámica del AE. Diccionario de Datos

  • “Es un conjunto de metadatos, es decir, de información (datos) sobre datos”

  • Contiene las definiciones de todos los elementos de los diagramas

  • Implementación

    • Manual

    • Procesador de textos

    • Base de datos

    • Automático e integrado


1 introducci n visi n panor mica del ayde diccionario de datos l.jpg

1.- Introducción: Visión panorámica del AyDE. Diccionario de Datos

Flujo de datos: entrega

Descripción: Conjunto de libros enviados por un proveedor a la biblioteca, basado en la relación que previamente había recibido.

Sinónimos: *** none ***

Componente de: *** none ***

Composición:

Libros

+ { Albarán }

Información de entrada y salida

OrigenDestino

*** Off the diagram ***Compra libros

PROVEEDORESBiblioteca


Visi n panor mica ayde diccionario de datos iii l.jpg

Visión panorámica AyDEDiccionario 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ónProc_pago

Proc_consultasAdjuntar_albarán


1 introducci n visi n panor mica del ayde pseudoc digo l.jpg

1.- Introducción: Visión panorámica del AyDE. Pseudocódigo.

Proceso: Verificar estado del socio

Número: 1.1.1

Descripción: Se examina si el socio no está sancionado

Miniespecificación:

Recibir “Socio ID” del socio

Leer “SOCIOS” para

Leer “Flag-de-precaución”

Si OK, enviar “Socio ID válido”

Complejidad: Prioridad:

Ratio de transacciones: Memoria requerida (Kb):

Tiempo de proceso:


1 introducci n visi n panor mica del ayde modelado de datos l.jpg

1.- Introducción: Visión panorámica del AyDE. Modelado de Datos

  • Diagramas E-R y DED (Diagrama de Estructura de Datos)

  • DED es, básicamente, un E-R limitado:

    • no relaciones ternarias

    • sólo cardinalidades 1:N

    • no atributos multivaluados ni compuestos


1 introducci n visi n panor mica del ae ejemplo de e r l.jpg

Diagrama E-R

Departamento

(1,n)

pertenece

(1,1)

Empleado

asignado

Proyecto

(0,n)

(1,m)

Departamento

Proyecto

DED

pertenece

requiere

Empleado

Asignación

tiene

1.- Introducción: Visión panorámica del AE. Ejemplo de E/R .

[EN2002] (Chen)


1 introducci n visi n panor mica del ayde l gica de proceso l.jpg

1.- Introducción: Visión panorámica del AyDE. Lógica de Proceso.

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

    • Lenguaje estructurado

    • Pre y post-condiciones

    • Tablas de decisión

    • Árboles de decisión


1 introducci n visi n panor mica del ayde l gica de proceso21 l.jpg

1.- Introducción: Visión panorámica del AyDE. Lógica de Proceso.

  • Lenguaje estructurado

    • SI la factura excede de 300€

      • SI la cuenta del cliente tiene alguna factura sin pagar más de 60 días, dejar la confirmación pendiente de este pago.

      • SI NO (la cuenta está en buen estado) hacer confirmación y factura

    • SI NO (la factura es de 300€ o menos)

      • SI la cuenta del cliente tiene alguna factura sin pagar más de 60 días hacer la confirmación, la factura y escribir un mensaje sobre informe de crédito

      • SI NO (la cuenta está en buen estado)hacer confirmación y factura

    • FIN-SI.


1 introducci n visi n panor mica del ae l gica de proceso l.jpg

Pre1 (la factura excede de 300€) Y (la cuenta del cliente tiene alguna factura sin pagar más de 60 días)

Pos1 (confirmación pendiente de este pago)

Pre2 (la factura excede de 300€) o (la cuenta del cliente no tiene ninguna factura sin pagar más de 60 días)

Pos2 (confirmación y factura realizadas)

Pre3 (la factura no excede de 300€) Y (la cuenta del cliente tiene alguna factura sin pagar más de 60 días)

Pos3 (confirmación y factura realizadas) Y (mensaje impreso sobre informe de crédito)

Pre4 (la factura no excede de 300€) Y (la cuenta del cliente no tiene ninguna factura sin pagar más de 60 días)

Pos4 (confirmación y factura realizadas)

1.- Introducción: Visión panorámica del AE. Lógica de Proceso.

  • Pre y post-condiciones


1 introducci n visi n panor mica del ayde l gica de proceso23 l.jpg

1.- Introducción: Visión panorámica del AyDE. Lógica de Proceso.

Tablas de decisión


1 introducci n visi n panor mica del ayde l gica de proceso24 l.jpg

Cuentas impagadas más de 60 días

Cuentas en buen estado

1.- Introducción: Visión panorámica del AyDE. Lógica de Proceso.

Árboles de decisión

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

Cuentas impagadas más de 60 días

Factura excede de 300€

Cuentas en buen estado

2. Hacer confirmación y factura

Política contable

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

Factura menos de 300€

4. Hacer confirmación y factura


Y despu s del ae l.jpg

¿Y después del AE?

  • DISEÑO ESTRUCTURADO (DE)

    • El diseño lógico de los requisitos del nuevo sistema de información se convierte en un modelo de la aplicación, plasmado en un DIAGRAMA DE ESTRUCTURA.

    • En el paso AE  DE,

      • Análisis de transacciones

      • Análisis de transformaciones


Dise o estructurado diagrama de estructura ejemplo de diagrama de estructuras l.jpg

Evaluar

peticiones

pet aceptada

informe préstamo

pet aceptada

informe préstamo

Recibir

peticiones

Elaborar

informe

Informar

petición

pet préstamo

pet rechazada

ok

pet préstamo

Leer

peticiones

Consultar

stock

Rechazar

petición

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


Visi n panor mica ae esquema resumen l.jpg

Diagrama de flujo de datos

B

PROC

Z

X

PROC

PROC

V

Paso al diseño

Y

A

W

FUENTE

PROC

DESTINO

D ALMACÉN DE

DATOS

Diagrama de estructuras

PROC

Descrip.E. E.

Definición del FD

Descripcióndel proceso

Diagrama E-R (o DED)

Diccionariode Datos

Definiciones de la BD

Definiciones de los módulos

Visión panorámica AEEsquema resumen


2 diagramas de flujo de datos dfds l.jpg

2.- Diagramas de Flujo de Datos(DFDs)


S mbolos del dfd notaci n yourdon de marco l.jpg

P

Proceso

Entidad Externa

Flujo de datos

Flujo de eventos

D ALMACÉN DE

DATOS

2.- Diagramas de Flujo de Datos

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

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

Terminadores (Fuentes o Destinos)(personas, entidades)

Flujos de información(inputs-outputs)

Flujos de control (Ward & Mellor 85)

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


S mbolos del dfd notaci n m trica ssadm l.jpg

Localización

ID

Proceso

Entidad

Externa

Flujo de datos

D

ALMACÉN DE

DATOS

2.- Diagramas de Flujo de Datos

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

Transformaciones o procesos

Terminadores (Fuentes o Destinos)

Flujos de información

Ficheros o depósitos temporales de información


Procesos l.jpg

E1

S1

P

Transformación

S2

E2

E3

2.- Diagramas de Flujo de Datos

Procesos

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

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

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


Procesos ii l.jpg

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 ambiguosprocesar, gestionar, manejar...

    • “objeto” está definido en el DD

  • Los procesos se descomponen en “subprocesos”, hasta llegar a los procesos primitivos


Diagrama de contexto l.jpg

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


Entidades externas l.jpg

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

DESTINO

Sistema

FUENTE

DESTINO

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


Flujos de datos l.jpg

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)


Flujos de datos ii l.jpg

P

Determinar

estado

pedido

petición estado pedido

respuesta estado pedido

denegación

crédito

pago

autorización crédito

P

P

solicitud crédito

Aceptar pago

Analizar

Petición

crédito

recibo

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.


Flujos de datos iii l.jpg

X

X

X

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

P

P

P

A

B

A

B


Flujos de datos iv l.jpg

P1

Selecc. y

pedir nuevos

libros

EDITORIALES

INTERVENTOR

nuevas ofertas

pedidos de libros nuevos

libros nuevos

D3

INVENTARIO

P3

ajuste de inventario

P2

Registrar libros

Examinar

ajuste de signaturas

nuevos

nuevos libros

D4

SIGNATURAS

libros nuevos

nuevos libros

D1

LISTA MAESTRA

DE ISBN

P4

P5

libros nuevos

D9

CARRITO

libros nuevos

libros nuevos

Enviar al dpto.

Poner libros

LIBROS NUEVOS

comprador

nuevos en

D2

ESTANTES

libros nuevos

estantes

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

Notación Gane & Sarson


Flujos de datos v l.jpg

2.- Diagramas de Flujo de Datos

Flujos de datos (V)

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

P

Validar

cod postal

P

cod postal

A

dirección cli

telef

número de cuenta

calle

P

Validar

Telef.

P

P

Validar

calle

B

  • Observaciones:

    • Sólo los procesos pueden separar FD (Piattini et al. 96)No poner FD como señales de activación (Yourdon 89)


Flujos de datos vi l.jpg

P

Imprimir listaempaquetado

P

Rellenar prescripción

datos de empaquetado

P

P

Determinarprescripción

prescripción

datos de envío

Determinar

prods.para enviar

datos de facturación

ANDcuando todos los datossiguen por ambos caminos

XORcuando los datos sondivididos en subconjuntos

P

P

Actualizar registropaciente

Imprimir factura

cliente

2.- Diagramas de Flujo de Datos

Flujos de datos (VI)

Notación System Architect. Ejemplos

FD divergentes (conectores XOR y AND)


Flujos de datos vii l.jpg

P

P

Aceptar pago enmetálico

Confirmar empleo

historial de empleo

historia combinada

P

P

datos de pago

Transferir pago

Concedertarjetadecrédito

historial de crédito

XOR cuando los mismos datosprovienen decualquier dirección

P

ANDcuando los subconjuntosson combinados en uno

P

Aceptar pagoacrédito

Confirmar historialde crédito

2.- Diagramas de Flujo de Datos

Flujos de datos (VII)

Notación System Architect. Ejemplos

FD convergentes (conectores XOR y AND)


Flujos de datos viii l.jpg

P

Evaluar pedido

2.- Diagramas de Flujo de Datos

Flujos de datos (VIII)

  • 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

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

¿El proceso “necesita” ambos FD?

pedido

criterios valoración


Flujos de control l.jpg

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)


Almacenes de datos l.jpg

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


Consistencia dfd e r map 95 l.jpg

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


Consistencia dfd e r ii l.jpg

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

    • Pocos almacenes

      • Para cada uno, diagrama E-R (o DED)

    • Tantos almacenes como entidades se hayan identificado

      • Preferible (si no hay muchas entidades)


Descomposici n funcional l.jpg

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


Descomposici n funcional ii l.jpg

DESTINO

B

P

Sist

A

B

FUENTE

P

f5

Z

P

P

X

f2

f4

V

Y

P

f1

P

A

W

f3

Z

x2

P

P

f43

f45

x1

P

f41

X

y2

P

y1

f44

P

Y

f42

2.- Diagramas de Flujo de Datos

Descomposición funcional (II)


Consistencia en el dfd l.jpg

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


Descomposici n paralela l.jpg

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


Descomposici n paralela ii l.jpg

P2

P1

envío

P6

P5

pedido

envío

autorización

P6.2

P4

P3

P6.1

cupón de pedido

P6.3

pago

2.- Diagramas de Flujo de Datos

Descomposición paralela (II)

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


Jerarqu a de dfds l.jpg

Localización

Proceso primitivo en Métrica

Proceso

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.


Jerarqu a de dfds ii l.jpg

B

P 1.2

Proceso A

A

DFD 1.2

P 1.2.2

X

f2

V

Y

P 1.2.1

f1

P 1.2.3

f3

A

W

2.- Diagramas de Flujo de Datos

Jerarquía de DFDs (II)


Jerarqu a de dfds dfd 0 l.jpg

2.- Diagramas de Flujo de Datos

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


Descomposici n funcional y almacenes de datos l.jpg

2.- Diagramas de Flujo de Datos

Descomposición funcional y almacenes de datos

  • Los almacenes aparecen lo más tarde posible

  • En un nivel superior únicamente cuando son interfaz entre procesos

  • Una vez que aparezca en un DFD, el almacén aparecerá otra vez en cada DFD de nivel más bajo relacionado


Descomposici n funcional y almacenes de datos ii l.jpg

P

P

B.1

A.1

D

FICH

D

FICH

P

P

A.2

B.2

2.- Diagramas de Flujo de Datos

Descomposición funcional y almacenes de datos (II)

P

P

A

B

D

FICH


Tama o de la jerarqu a de dfds l.jpg

Diagrama de contexto / sistema

Diagrama de subsistemas

Diagrama de funciones

Diagrama de subfunciones

Diagrama de procesos (opcional)

Métrica

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


Reglas sint cticas en dfds l.jpg

CLIENTE

CLIENTES

CORPORATIVOS

D

DATOS DEL

CENTROS DE

P

INVESTIGACIÓN

SIST. DE

INVESTIG. DE

MERCADOS

2.- Diagramas de Flujo de Datos

Reglas sintácticas en DFDs

  • El origen y/o el destino de un FD es siempre un proceso

    • Excepción: almacenes en el diagrama de contexto (Yourdon 89)

datos del mercado

informes anuales

MERCADO

datos de investigación

datos del mercado


Reglas sint cticas en dfds ii l.jpg

P

P

Fuente

Sumidero

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


Ideas tiles para construir el dfd l.jpg

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


Ideas tiles para construir el dfd ii l.jpg

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


Dfds conclusiones l.jpg

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


Dfds conclusiones ii l.jpg

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


  • Dfds conclusiones iii l.jpg

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


    Slide65 l.jpg

    2.- Diseño: Diagrama de Estructuras

    • Diseño Estructurado

    • 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


    Slide66 l.jpg

    2.- Diseño: Diagrama de Estructuras

    • Diseño Arquitectónico ( Diseño Preliminar)

      • Elementos Diagrama de Estructura

      • Partición Estructural de un Diagrama de Estructura

      • Estrategias de Diseño

      • Construcción del Diagrama de Estructura


    Concepto y principios del dise o l.jpg

    Concepto y Principios del Diseño

    • “ El diseño es un proceso a través del cual los requerimientos establecidos en la fase de análisis deben traducirse en una representación ‑que se sugiere modular‑ del producto de software que se precisa construir y que se acompaña de los procedimientos en virtud de los cuales cada módulo debe llevar a cabo su tarea, y de las estructuras de datos que debe procesar”

      • Larry Constantine ‘78


    Concepto y principios del dise o68 l.jpg

    Concepto y Principios del Diseño

    • El diseño estructurado es un método de configuración de la organización modular del software que se desarrolla a partir de los flujos de datos que contiene la especificación de requerimientos obtenida en la fase de análisis bajo enfoque estructurado. En este sentido, puede decirse que este enfoque consiste en el diseño de programas como estructuras de funciones únicas y de relativa independencia.


    Efectividad del dise o l.jpg

    Efectividad del Diseño

    • Para poder evaluar la efectividad de una representación de diseño, es preciso establecer lo que se denomina en Ingeniería de software, "criterios para un buen diseño", entre los cuales es posible destacar los siguientes:

    • El diseño debe exhibir una organización jerárquica con mecanismos de control que no atenten contra la independencia relativa de cada componente de la jerarquía.


    Efectividad del dise o70 l.jpg

    Efectividad del Diseño

    ‑ El diseño debe ser modular, esto es, el software debe estar particionado lógicamente en elementos que ejecuten funciones y subfunciones específicas.

     - El diseño debe generar módulos que exhiban niveles adecuados de independencia funcional.

     ‑ El diseño debe obtenerse a partir de la especificación de requerimientos generada durante la fase de análisis.

    ‑ Módulo(laridad)

    ‑ Abstracción

    ‑ Refinamiento


    Efectividad del dise o71 l.jpg

    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 problemaglobal que da origen a la necesidad de construir un producto de software. “

    Tiene que ver con la separabilidad de las funciones que en conjunto cumplen un objetivo mayor, esto es, responden a la idea de totalidades emergentes propia de la noción de sistemas.


    Efectividad del dise o72 l.jpg

    Efectividad del Diseño

    ‑ Beneficios de la Modularidad

    ‑ Programas más simples, ya que puede ser comprendido, verificado, programado, depurado, mejorado y alterado por partes.

    ‑ Módulos que pueden ser desarrollados con relativa independencia.

      ‑ Disminución de la posibilidad de errores al reducir la complejidad.

      ‑ Programas que pueden evaluarse por partes, por lo cual todo test se hace más fácil.

    ‑ Programas más fáciles de alterar ya que son menores las líneas de código a considerar para incorporar los cambios.

    ‑ Módulos de función única que pueden ser reutilizados.


    Efectividad del dise o73 l.jpg

    Efectividad del Diseño

    ‑ Beneficios de la Modularidad

    ‑ La posibilidad de cometer errores por parte de los programadores disminuye porque son menos las líneas de código que deben enfrentarse al mismo tiempo.

    ‑ La rotación de personal se hace menos crítica, ya que los programadores están involucrados en unidades de código más pequeñas por lo cual la sustitución resulta menos dificultosa.

    ‑ Responder al requerimiento de la división del código en segmentos de una página, como lo sugiere la programación estructurada, es casi total.


    Efectividad del dise o74 l.jpg

    Efectividad del Diseño

    ‑ Módulo

    El Fan‑out es una medida del número de módulos controlados directamente por otro módulo (número de subordinados inmediatos que posee). El Fan‑in indica cuántos módulos controlan directamente un determinado módulo (número de superiores inmediatos que posee)

    Un módulo que controla a otro se dice que es "superordinado" a éste y, recíprocamente, un módulo controlado por otro se dice que es "subordinado".


    Efectividad del dise o75 l.jpg

    Efectividad del Diseño

    ‑ Módulo

    Módulo Superordinado

    Módulo Subordinado

    Fan‑out : 2

    Fan‑in : 1  


    Efectividad del dise o76 l.jpg

    Efectividad del Diseño

    ‑ Módulos & Integración

    Costos

    o Esfuerzo

    Costo Total SW

    Costo por Integración

    Costo por Módulo

    N° Módulos

    Costos Mínimos


    Efectividad del dise o77 l.jpg

    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”


    Efectividad del dise o78 l.jpg

    Efectividad del Diseño

    ‑ Refinamiento

    El refinamiento gradual es una estrategia de diseño top_down cuyo origen es la propuesta de Niklaus Wirth (WIRTH‑71) quien postula que "La arquitectura de un programa se desarrolla refinando sucesivamente los niveles de detalle de los procedimientos. De este modo se desarrolla una jerarquía de procedimientos al descomponer sucesivamente una sentencia global hasta alcanzar sentencias específicas a nivel de un lenguaje de programación".

    R. Pressman (PRESSMAN‑88) al respecto cita a Wirth señalando que: "En cada etapa (del refinamiento), se descomponen una o varias de las instrucciones del programa dado en instrucciones cada vez más detalladas. Esta descomposición o refinamiento sucesivo termina cuando todas las intrucciones están expresadas en términos de cualquier lenguaje básico de computador o de programación.


    Efectividad del dise o79 l.jpg

    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


    Factores de calidad l.jpg

    Factores de Calidad

    ‑ Acoplamiento

    Corresponde al grado de independencia entre dos módulos. Entendido así, minimizar el acoplamiento aparece entonces como una determinante prioritaria al configurar las conformaciones estructurales.

    La obtención de módulos tan independientes como sea posible,se puede ser lograda principalmente de tres maneras:

      ‑ Eliminando relaciones innecesarias.

    ‑ Reduciendo el número de relaciones necesarias.

    ‑ Debilitando la dependencia de las relaciones necesarias.


    Factores de calidad81 l.jpg

    Factores de Calidad

    ‑ Cohesión

    Corresponde a la medida de relación funcional de los elementosde un módulo, Los elementos de un módulo corresponden a instrucciones, definiciones de datos, o llamadas o otros módulos. La idea es organizar estos elementos de tal manera que tengan una mayor relación entre ellos a la hora de realizar la tarea específica del módulo


    Factores de calidad82 l.jpg

    Factores de Calidad

    Acoplamiento

    Principios de un

    Buen Diseño

    Cohesión


    Tipos de acoplamiento l.jpg

    Tipos de Acoplamiento

    • Acoplamiento Normal

    • Acoplamiento por Datos

    • Acoplamiento por Estampado o Imagen

    • Acoplamiento de Control

    • Acoplamiento Común

    • Acoplamiento por Contenido


    Tipos de acoplamiento84 l.jpg

    Tipos de Acoplamiento

    Mejor Acoplamiento

    NORMAL

    DATOS

    ESTAMPADO

    CONTROL

    EXTERNO (caso especial de COMÚN)

    COMÚN

    CONTENIDO

    Grado de

    Acoplamiento


    Tipos de acoplamiento85 l.jpg

    Tipos de Acoplamiento

    • Acoplamiento Normal

    • Dos Módulo A y B están Normalmente Acoplados si:

      • Un Módulo A llama a otro B

      • B retorna el control a A

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

  • A

    B


    Tipos de acoplamiento86 l.jpg

    Tipos de Acoplamiento

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

    Rut_cliente

    Leer Rut


    Tipos de acoplamiento87 l.jpg

    Tipos de Acoplamiento

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

    Deuda

    Cliente

    Cliente

    Leer Cliente

    Cliente= rut+nombres+apellido_paterno+

    Apellido_materno+dirección+fono+e_mail


    Tipos de acoplamiento88 l.jpg

    Tipos de Acoplamiento

    Obtener

    Datos

    Cliente

    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.

    Tipo_dato

    Cliente

    Leer Cliente


    Tipos de acoplamiento89 l.jpg

    Leer Registro

    Video

    Tipos de Acoplamiento

    Actualizar

    Stock

    Video

    Obtener

    Nombre

    Video

    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

    video

    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.


    Tipos de acoplamiento90 l.jpg

    Tipos de Acoplamiento

    A

    B

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

    ………..

    Srch: Move..

    ………..

    ……….

    ……….

    ………

    ………..

    ………

    ………..

    Jump to Srch

    ……….

    ………

    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.


    Tipos de acoplamiento91 l.jpg

    Tipos de Acoplamiento

    Dos módulos pueden estar relacionados por más de un tipo de acoplamiento. Si esto ocurre, el acoplamiento que caracteriza la relación entre ellos queda definido por el peor tipo que presenten. Por ejemplo, si dos módulos están ligados por acoplamiento de imagen y acoplamiento común a la vez, se dirá que los módulos están ligados por acoplamiento común.

    • Enfoques: ¿Cómo Analizar el Tipo de Acoplamiento?

      • Imaginar el Módulo como una Biblioteca

      • Cada Módulo es codificado por un programador diferente


    Tipos de cohesi n l.jpg

    Tipos de Cohesión

    Mayor Cohesión

    Módulo como

    Caja Negra

    FUNCIONAL

    SECUENCIAL

    COMUNICACIONAL

    PROCEDURAL

    Módulo

    Transparente

    TEMPORAL

    LÓGICA

    COINCIDENTAL

    Grado de

    Cohesión

    STEVEN, MYERS, CONSTANTINE y YOURDON (1974)

    establecieron "una escala de cohesión"


    Tipos de cohesi n93 l.jpg

    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


    Tipos de cohesi n94 l.jpg

    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

    ....


    Tipos de cohesi n95 l.jpg

    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

    ....


    Tipos de cohesi n96 l.jpg

    Tipos de Cohesión

    4. Cohesión Procedimental

    un módulo cohesionado por procedimientos es aquel cuyos elementos están envueltos en 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

    ....


    Tipos de cohesi n97 l.jpg

    Tipos de Cohesión

    5. Cohesión Temporal

    Un módulo con cohesión temporal es aquel cuyos elementos están envueltos en 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

    ....


    Tipos de cohesi n98 l.jpg

    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

    ....


    Tipos de cohesi n99 l.jpg

    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

    ....


    Slide100 l.jpg

    Árbol de Cohesión


    Consideraciones importantes para un dise o de calidad l.jpg

    Consideraciones Importantes para un Diseño de Calidad

    • La factorización consiste en separar la funcionalidad de un módulo, en subfunciones claramente identificables, en términos tales que sea posible considerarla como constitutiva de un módulo independiente.

    • 1. La necesidad de reducir el tamaño de un módulo.

    • 2. Obtener las ventajas de la modularización mediante un diseño "top_down". => Sistema más comprensible el sistema y facilitamiento de cambios

    • 3. Evitar que una misma función aparezca en diferentes partes del sistema, es decir, en más de un módulo.

    • 4. Proveer módulos de uso general.

    • 5. Simplificar la implementación.


    Reducir el tama o de un m dulo l.jpg

    Reducir el Tamaño de un Módulo

    1. De Marco señala, un tamaño razonable para un módulo corresponde a un conjunto de líneas de código de alrededor de media página de listado (30 líneas más o menos),

    2. Page‑Jones, señala que toda la codificación de un módulo debería, idealmente, ser visible en una página de listado (una exigencia que impone un límite no superior a 60 líneas)

    3. Geral Weinberg (WEI‑72) muestran que la habilidad del hombre para entender un módulo y encontrar errores depende de la capacidad de aprehender el módulo como un todo de una sola vez.


    Resultados del dise o l.jpg

    Resultados del Diseño

    • El proceso de diseño debe lograr la determinación de las directrizes en virtud de las cuales el producto de software ha de construirse, tomando como base la especificación de requerimientos generada en la fase de análisis. Así, entonces, el diseño, en cuanto proceso, debe dar como resultado:

    •   el Diseño de la Arquitectura del producto de software a construir.

    •  la Especificación de los Procedimientos del software a construir.

    •  el Diseño de los Datos involucrados

    • el Diseño de la Interfaz de usuario


    Dise o arquitect nico l.jpg

    Diseño Arquitectónico


    Slide105 l.jpg

    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.


    Slide106 l.jpg

    Especificación de procesos

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

    Interfaz

    Pseudocódigo


    Dise o de datos l.jpg

    Diseño de Datos


    Dise o de datos108 l.jpg

    Diseño de Datos


    Slide109 l.jpg

    Diseño de Interfaz


    Slide110 l.jpg

    Leer Registro

    Video

    Elementos del Diagrama de Estructura

    Obtener

    Nombre

    Video

    Módulo

    Módulo

    Predeterminado

    X

    MÓDULO JEFE

    (INVOCADOR)

    Y

    MÓDULO SUBORDINADO

    (INVOCADO)


    Slide111 l.jpg

    Elementos del Diagrama de Estructura

    Obtener

    Datos

    Cliente

    Flujo de Control

    Flujo de Dato

    Tipo_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


    Slide112 l.jpg

    Elementos del Diagrama de Estructura

    Conectores


    Slide113 l.jpg

    Elementos del Diagrama de Estructura

    Secuencia

    Iteración


    Slide114 l.jpg

    Elementos del Diagrama de Estructura

    Selección


    Slide115 l.jpg

    Profundidad y Ancho de un Diagrama de Estructura

    Profundidad y anchoproporcionan una idea del número de niveles de control y el ámbito global decontrol respectivamente.

    El grado de salidaes una medida del número de módulos que soncontrolados directamente por otro módulo.

    El grado de entradaindica cuántos módulos controlandirectamente un módulo dado.


    Slide116 l.jpg

    Estrategia de Diseño para Construir Diagrama de Estructura

    Diseño Centrado en Transformaciones

    Diseño Centrado en Transacciones

    Diagrama de

    Estructura

    DFD

    Análisis

    Diseño


    Slide117 l.jpg

    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

    1.2

    3

    4.1

    2.1

    2.2

    4.2

    Flujo de Llegada

    Flujo de

    Salida

    Centro

    de

    Transformación


    Slide118 l.jpg

    Estrategia de Diseño

    • Diseñ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

    Camino de

    Acción 1

    2.1

    2.2

    1

    3.1

    3.2

    Camino de

    Acción 2

    Centro

    de

    Transacción

    4.1

    4.2

    Camino de

    Acción 3


    Slide119 l.jpg

    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


    Slide120 l.jpg

    Estrategia de Diseño: Transformación

    1.1

    1.2

    3

    4.1

    2.1

    2.2

    Centro

    de

    Transformación

    4.2

    Flujo de Llegada

    Flujo de

    Salida

    • 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

    Diagrama de

    Contexto

    Cp

    Ce

    Ct

    Cs

    Nombres representativos


    Slide121 l.jpg

    Estrategia de Diseño: Transformación

    1.1

    1.2

    3

    4.1

    2.1

    2.2

    Centro

    de

    Transformación

    4.2

    Flujo de Llegada

    Flujo de

    Salida

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

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

    a

    Cp

    b

    z

    Ce

    Ct

    Cs

    1.2

    2.2

    3

    4.1

    1.1

    2.1

    4.2

    Leer a

    Leer b

    Escribir

    z


    Slide122 l.jpg

    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.


    Slide123 l.jpg

    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


    Slide124 l.jpg

    Estrategia de Diseño: Transacción

    a

    A

    D

    z

    P

    Q

    R

    b

    • Módulos a incorporar

      • Módulo principalCp, 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

    Ce

    D

    C1

    C2

    C3


    Slide125 l.jpg

    Estrategia de Diseño: Transacción

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

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

    Camino 1

    Cp

    a

    A

    D

    Camino 2

    D

    Ce

    z

    P

    Q

    R

    a

    b

    Camino 3

    C1

    C2

    C3

    Leer a

    P

    Q

    R

    Escribir

    z

    Leer b


    Slide126 l.jpg

    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.


    Slide127 l.jpg

    • Diseño Procedimental (Diseño Detallado

      • Especificación Interfaz-Función

      • Especificación Mediante las Miniespecificaciones del Análisis

      • Especificación por Pseudocódigo


    Slide128 l.jpg

    Diseño Detallado

    1. Especificación por interfaz-función

    Permite definir un módulo sin entrar en excesivos detalles. La interfaz del módulo contiene los parámetros de entrada y de salida, mientras la función del módulo describe las tareas que este lleva a cabo. Se permite el uso de tablas, fórmulas, lenguaje natural, etc. Permite variar el grado de formalismo en la definición del módulo, generalmente, dando bastante libertad a los programadores. Su inclusión como comentario en el código final facilita el mantenimiento.


    Ejemplo l.jpg

    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 deubicación sean lo más cercanas (ponderadamente) al asiento elegido.


    Slide130 l.jpg

    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.


    Slide131 l.jpg

    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 deFuncionalidad

    · Buscar asiento disponible comenzando con la clase solicitada y continuando conclases 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 nofumadores en la clase del cliente (si es posible).

    · Si la diferencia entre el asiento preferido y el asiento seleccionado es 0, realizar laasignación PREFERENCIA-DISPONIBLE=”Y”; de lo contrario asígnele “N”.


    Slide132 l.jpg

    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


  • Login