Page 1

Análisis y Diseño Estructurado Diagrama de Flujo de Datos ENTIDAD EXTERNA

flujo de datos

P1 Proceso

D ALMACÉN DE DATOS

Docente : Yessica Gómez Gutiérrez


Análisis y Diseño Estructurado • Introducción - Visión panorámica del Análisis y Diseño Estructurado. • Análisis : Diagramas de Flujo de Datos. • Diseño: Diagrama de Estructuras ENTIDAD EXTERNA

flujo de datos

P1 Proceso

D ALMACÉN DE DATOS


1.- Introducción: Visión panorámica del AyDE Análisis Estructurado Método clave en el “desarrollo estructurado” o “convencional” Aparece a finales de los 70 Facilita la comunicación en el proceso de desarrollo de un sistema de información − análisis y diseño − usuarios y analistas

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


1.- Introducción: Visión panorámica del AyDE. Características Amplia difusión Descomposición funcional (Originariamente) Orientada a procesos (Originariamente) Top/down

Presente en numerosas metodologías p.ej. Métrica, SSADM, information engineering, Merise

Herramientas CASE disponibles


Bibliografía Texto principal Mario Piattini,Jose Calvo-Manzano,Joaquín Cervera,Luis Fernandez, Análisis y diseño detallado de Aplicaciones Informáticas de gestión. Edit. Ra-ma Yourdon, E., Análisis estructurado moderno. 1993: Prentice-Hall Hispanoamericana


Bibliografía (II) Entre la bibliografía básica... MAP, MÉTRICA versión 2.1. Guía de Técnicas. 1995, Madrid: Ministerio de Administraciones Públicas. Secretaría de Estado para la Administración Pública. Consejo Superior de Informática.

Referencias clásicas... DeMarco, T., Structured analysis and system specification. 1979, Englewood Cliffs, New Jersey: Yourdon Press. Gane, C. and T. Sarson, Análisis estructurado de sistemas. 1990, Buenos Aires: El Ateneo (traducción de Gane, C. and T. Sarson, Structured systems analysis, tools and techniques. Software series. 1979, New Jersey: Prentice-Hall.)


1.- Introducciรณn: Visiรณn panorรกmica del AyDE. Componentes

DFD (Diagrama de Flujo de Dato Dataflow diagram) Diagrama E-R (Entidad-Relaciรณn), o alternativamente, DED (Diagrama de Estructura de Datos) Diagramas HVE (Historia de Vida de las Entidades) Diagramas de Transiciรณn de Estados (STD, State Transition Diagram)


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

Lógica de procesos Lenguaje estructurado Pre y post-condiciones Tablas de decisión Árboles de decisión

Diccionario de Datos (DD)


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

ENTIDAD EXTERNA

flujo de datos

P1 Proceso

D ALMACÉN DE DATOS

Visión general de las funciones y transformaciones de datos en una organización Modelo lógico y gráfico del sistema también como modelo físico

Identifica entradas, salidas, procesos y relaciones con el exterior ...a nivel general ...por refinamiento, a nivel detallado


1.- Introducción: Visión panorámica del AE. DFD Tipos de símbolos en los DFDs (notación de Yourdon/De Marco) ENTIDAD EXTERNA

flujo de datos

P1 Proceso

D ALMACÉN DE DATOS


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

Ejemplo Sistema de distribución sin inventario “Se trata de un sistema que sirve pedidos de libros a unos clientes, con la particularidad de que no mantiene un stock o inventario interno. El sistema puede agrupar los pedidos que clientes distintos hacen a un mismo editor, de manera que se puedan conseguir descuentos.” Adaptado del capítulo 2 de Gane, C. and T. Sarson, Análisis estructurado de sistemas. 1990, Buenos Aires: El Ateneo.


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

Análisis de los procesos del sistema ⇒ Aplicamos la visión sistémica Diagrama de contexto CLIENTE

pedidos órdenes de compra

libros entregados

en principio, no son materiales, son datos

0. Sistema de Pedidos

EDITOR libros pedidos


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

D LIBROS órdenes de compra

1. Verificar validez de pedido

estado del crédito D CLIENTES

pedidos válidos D PEDIDOS PENDIENTES

pedidos por título

2. Armar pedidos a editores

D ÓRDENES DE COMPRA

pedidos en lote

dirección

libros entregados libros entregados = albarán + lista-novedades

5. Armar entrega a clientes

libros por clientes

4. Asignar libros a pedidos

3. Verificar envío de editores

libros recibidos libros recibidos = {título + cantidad}

libros pedidos


1.- Introducción: Visión panorámica del AE. Diccionario de Datos “Es un conjunto de metadatos, es decir, de información (datos) sobre datos” Contiene las definiciones de todos los elementos de los diagramas Implementación Manual Procesador de textos Base de datos Automático e integrado


1.- Introducción: Visión panorámica del AyDE. Diccionario de Datos Flujo de datos: entrega Descripción: Conjunto de libros enviados por un proveedor a la biblioteca, basado en la relación que previamente había recibido. Sinónimos: *** none *** Componente de: *** none *** Composición: Libros + { Albarán } Información de entrada y salida Origen Destino *** Off the diagram *** Compra libros PROVEEDORES Biblioteca


Visión panorámica AyDE Diccionario de Datos (III) Almacen: Facturas Descripción: Información, por número de factura, sobre facturas en el sistema actual. Sinónimos: *** none *** Composición: @Número-factura + Fecha-factura + Dirección-cliente + { Número-producto + Cantidad-producto + Costo-unidad-producto } + Costo-envío + Tasa-de-descuento + Neto-factura + Estado-factura

Procesos asociados: Proc_cancelación Proc_consultas

Según DFD general Proc_pago Adjuntar_albarán


1.- Introducción: Visión panorámica del AyDE. Pseudocódigo. Proceso: Verificar estado del socio Número: 1.1.1 Descripción: Se examina si el socio no está sancionado Miniespecificación: Recibir “Socio ID” del socio Leer “SOCIOS” para Leer “Flag-de-precaución” Si OK, enviar “Socio ID válido” Complejidad: Ratio de transacciones:

Prioridad: Memoria requerida (Kb): Tiempo de proceso:


1.- Introducciรณn: Visiรณn panorรกmica del AyDE. Modelado de Datos

Diagramas E-R y DED (Diagrama de Estructura de Datos) DED es, bรกsicamente, un E-R limitado: no relaciones ternarias sรณlo cardinalidades 1:N no atributos multivaluados ni compuestos


1.- Introducci贸n: Visi贸n panor谩mica del AE. Ejemplo de E/R . Departamento

Diagrama E-R

(1,n)

[EN2002] (Chen)

pertenece

(1,1) Empleado

asignado (0,n)

Proyecto (1,m)

Departamento

DED

Proyecto

pertenece

Empleado

requiere

tiene

Asignaci贸n


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

Técnicas para describir la lógica de los procesos primitivos Lenguaje estructurado Pre y post-condiciones Tablas de decisión Árboles de decisión


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

Lenguaje estructurado SI la factura excede de 300€ − SI la cuenta del cliente tiene alguna factura sin pagar más de 60 días, dejar la confirmación pendiente de este pago. − SI NO (la cuenta está en buen estado) hacer confirmación y factura

SI NO (la factura es de 300€ o menos) − SI la cuenta del cliente tiene alguna factura sin pagar más de 60 días hacer la confirmación, la factura y escribir un mensaje sobre informe de crédito − SI NO (la cuenta está en buen estado) hacer confirmación y factura

FIN-SI.


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

Pre y post-condiciones Pre1 (la factura excede de 300€) Y (la cuenta del cliente tiene alguna factura sin pagar más de 60 días) Pos1 (confirmación pendiente de este pago) Pre2 (la factura excede de 300€) o (la cuenta del cliente no tiene ninguna factura sin pagar más de 60 días) Pos2 (confirmación y factura realizadas) Pre3 (la factura no excede de 300€) Y (la cuenta del cliente tiene alguna factura sin pagar más de 60 días) Pos3 (confirmación y factura realizadas) Y (mensaje impreso sobre informe de crédito) Pre4 (la factura no excede de 300€) Y (la cuenta del cliente no tiene ninguna factura sin pagar más de 60 días) Pos4 (confirmación y factura realizadas)


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

Tablas de decisión 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


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

Árboles de decisión Factura excede de 300€

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

Política contable

Factura menos de 300€

Cuentas impagadas más de 60 días Cuentas en buen estado

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


¿Y después del AE? DISEÑO ESTRUCTURADO (DE) El diseño lógico de los requisitos del nuevo sistema de información se convierte en un modelo de la aplicación, plasmado en un DIAGRAMA DE ESTRUCTURA. En el paso AE ⇒ DE, − Análisis de transacciones − Análisis de transformaciones


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

pet aceptada

informe préstamo

pet aceptada

Recibir peticiones

pet préstamo

informe préstamo

Elaborar informe

pet rechazada pet préstamo

Leer peticiones

ok

Consultar stock

Rechazar petición

Informar petición


Visión panorámica AE Esquema resumen Diagrama de flujo de datos

B PROC

V

Z

X

PROC Y

FUENTE

Descrip. E. E.

A

PROC

Descripción del proceso

W

PROC

Definición del FD

DESTINO

PROC

D ALMACÉN DE DATOS

Diagrama E-R (o DED)

Diccionario de Datos Definiciones de la BD Definiciones de los módulos

Paso al diseño Diagrama de estructuras


2.- Diagramas de Flujo de Datos (DFDs)


Símbolos del DFD

2.- Diagramas de Flujo de Datos

(notación Yourdon/De Marco) P Proceso

Entidad Externa

Flujo de datos

Flujo de eventos

D ALMACÉN DE DATOS

Transformaciones o procesos (funciones, cálculo, selección) Terminadores (Fuentes o Destinos) (personas, entidades) Flujos de información (inputs-outputs) Flujos de control (Ward & Mellor 85) Ficheros o depósitos temporales de información (base de datos, armario, clasificador, etc.)


Símbolos del DFD

2.- Diagramas de Flujo de Datos

(notación Métrica/SSADM)

ID

Localización

Proceso

Transformaciones o procesos

Entidad Externa

Terminadores (Fuentes o Destinos)

Flujo de datos

D

ALMACÉN DE DATOS

Flujos de información Ficheros o depósitos temporales de información


Procesos

2.- Diagramas de Flujo de Datos

TRANSFORMACIÓN (cálculo, operación) FILTRO (verificación fecha, validación transacción) DISTRIBUCIÓN (menú, selección transacción) E1 P E2 E3

Transformación

S1 S2


Procesos (II)

2.- Diagramas de Flujo de Datos

Nombres únicos, significativos y concisos Preferiblemente expresados en función de las entradas y salidas Recomendación: verbo (no ambiguo) + objeto Evitar verbos ambiguos procesar, gestionar, manejar... “objeto” está definido en el DD

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


2.- Diagramas de Flujo de Datos

Diagrama de contexto

Es el DFD mรกs general de todos Estรก formado por un solo macroproceso (el sistema), las entidades externas (fuentes y destinos) y sus relaciones con el macroproceso Delimita el sistema y su entorno


2.- Diagramas de Flujo de Datos

Entidades externas

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

FUENTE

FUENTE

DESTINO

P Sistema

DESTINO

DESTINO

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


Flujos de datos

2.- Diagramas de Flujo de Datos

Los nombres de los FD deben ser únicos, significativos y concisos Son datos, así que nómbralos como datos. Pueden estar indistintamente en singular o en plural, ya que en los DFDs no se representan cantidades (Barranco 95) Los nombres no sirven sólo para identificar los datos, sino también la información que se tiene sobre ellos P.ej. Información (fecha-válida) > Información (fecha)


2.- Diagramas de Flujo de Datos

Flujos de datos (II)

Flujos de datos interactivos (dialog flows) Cuando dos FD establecen un diálogo o comparten una acción de estímulo-respuesta, pueden dibujarse como un único FD de doble flecha, donde ambos extremos deben llevar el nombre del FD que representan. P Determinar estado pedido

petición estado pedido respuesta estado pedido

pago autorización crédito P solicitud crédito Aceptar pago recibo

denegación crédito

P Analizar Petición crédito


2.- Diagramas de Flujo de Datos

Flujos de datos (III)

Las flechas dobles con sentidos opuestos que transportan los mismos datos pueden sustituirse por flechas doblemente encabezadas 隆Pero s贸lo si transportan los mismos datos! P A

X

X

P B

P A

X

P B


2.- Diagramas de Flujo de Datos

Flujos de datos (IV)

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

EDITORIALES

Selecc. y pedir nuevos libros

Notaci贸n Gane & Sarson

INTERVENTOR

nuevas ofertas

pedidos de libros nuevos libros nuevos ajuste de inventario

D3

INVENTARIO

Registrar libros ajuste de signaturas nuevos

D4

SIGNATURAS

P3

P2 Examinar nuevos libros

libros nuevos

nuevos libros

libros nuevos

D9

CARRITO LIBROS NUEVOS

libros nuevos

D1 LISTA MAESTRA DE ISBN

P4

P5

Enviar al dpto. comprador

Poner libros nuevos en estantes

libros nuevos

libros nuevos D2

ESTANTES


2.- Diagramas de Flujo de Datos

Flujos de datos (V)

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

cod postal

P Validar cod postal

dirección cli telef

número de cuenta

calle P B

P Validar calle

P Validar Telef.

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


2.- Diagramas de Flujo de Datos

Flujos de datos (VI)

Notación System Architect. Ejemplos FD divergentes (conectores XOR y AND) P Imprimir lista empaquetado datos de P empaquetado Determinar datos de envío prods.para datos de facturación enviar XOR cuando los datos son divididos en subconjuntos P Imprimir factura cliente

P Determinar prescripción

P Rellenar prescripción prescripción

AND cuando todos los datos siguen por ambos caminos

P Actualizar registro paciente


2.- Diagramas de Flujo de Datos

Flujos de datos (VII)

Notación System Architect. Ejemplos FD convergentes (conectores XOR y AND) P Aceptar pago en metálico

P Confirmar empleo datos de pago

P Aceptar pago a crédito

XOR cuando los mismos datos provienen de cualquier dirección

P Transferir pago

historial de crédito P Confirmar historial de crédito

historial de empleo

historia combinada

AND cuando los subconjuntos son combinados en uno

P Conceder tarjeta de crédito


2.- Diagramas de Flujo de Datos

Flujos de datos (VIII) pedido

P Evaluar pedido

criterios valoración

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

No lo sabemos, no importa: Los aspectos procedurales no se manifiestan en los DFDs Si tales aspectos son relevantes, se deben incluir en las miniespecificaciones


2.- Diagramas de Flujo de Datos

Flujos de control

En los DFDs no se muestra el control ni el orden de ejecuci贸n No se puede mostrar: Procesos que se realizan antes que otros Sincronizaci贸n Periodificaci贸n

Extensiones al AE para sistemas en tiempo real: (Ward & Mellor 85) (Hatley & Pirbhai 87)


2.- Diagramas de Flujo de Datos

Almacenes de datos

Nombre único, significativo y conciso Convenciones de nombres en los FD a/desde un almacén: No lleva etiqueta

− El FD se refiere a un paquete (instancia) completo de la información contenida en el almacén

La etiqueta es la misma que la del almacén

− El FD se refiere a uno o más paquetes completos (instancias) de la información contenida en el almacén

La etiqueta es distinta de la del almacén

− El FD se refiere a uno o más componentes (atributos) de una o más instancias del almacén


2.- Diagramas de Flujo de Datos

Consistencia DFD / E-R

(MAP 95)

Para facilitar validaciones cruzadas entre DFDs y E-R (o DED)... Correspondencia entre los almacenes de datos “principales” (permanentes) del DFD y las entidades del E-R Cada almacén de un DFD representa una o varias entidades del E-R Cada entidad del E-R pertenece a un único almacén principal de un DFD


2.- Diagramas de Flujo de Datos

Consistencia DFD / E-R (II)

ETIQUETA DE LOS ALMACENES Según explosione a − Entidad de datos ⇒ Plural nombre entidad − Diagrama E-R (o DED) ⇒ Nombre diagrama

DEFINICIÓN DE LOS ALMACENES 1. Pocos almacenes Para cada uno, diagrama E-R (o DED) 2. Tantos almacenes como entidades se hayan identificado Preferible (si no hay muchas entidades)


2.- Diagramas de Flujo de Datos

Descomposición funcional

Cada proceso se puede explotar, refinar o descomponer en un DFD más detallado El DFD de un sistema es realmente un conjunto de DFDs dispuestos jerárquicamente Los niveles de la jerarquía están determinados por la descomposición funcional de los procesos La raíz de la jerarquía es el “diagrama de contexto”, que es el más general de todos


2.- Diagramas de Flujo de Datos

Descomposici贸n funcional A

P Sist

(II)

DESTINO

B

FUENTE P f2

P f4

X

B

P f5

Z

V

A

P f1

Y P f3

W

P f43

x1

x2

P f41

X

y2 y1

Y

P f45

P f42

P f44

Z


2.- Diagramas de Flujo de Datos

Consistencia en el DFD

Cada proceso en un diagrama “padre” es una consolidación del DFD “hijo” Balanceo de DFDs Las E/S de un proceso “padre” deben corresponderse con las E/S del DFD “hijo” que lo explica


2.- Diagramas de Flujo de Datos

Descomposici贸n paralela

Descomposiciones de funciones Proceso en subprocesos (DFD)

Descomposici贸n de flujos de datos La regla de balanceo se aplica teniendo en cuenta la descomposici贸n paralela


2.- Diagramas de Flujo de Datos

Descomposición paralela (II) Ejemplo:

pedido = autorización + cupón de pedido + pago P2

P1 envío P6 P5

pedido P3

envío

autorización

P6.2

P4 cupón de pedido

P6.1

pago

P6.3


2.- Diagramas de Flujo de Datos

Jerarquía de DFDs

En un DFD completo cada proceso tiene un número único que lo identifica en función de su situación en la jerarquía Cada DFD tiene también un número único que coincide con el proceso que describe Las hojas o nodos terminales corresponden a “procesos primitivos” o indescomponibles Para cada proceso primitivo existirá una miniespecificación. Localización Proceso

Proceso primitivo en Métrica


2.- Diagramas de Flujo de Datos

JerarquĂ­a de DFDs (II) P 1.2 Proceso A

B

A

DFD 1.2 P 1.2.2 f2

X

V Y

P 1.2.1 f1 A

W

P 1.2.3 f3


Jerarquía de DFDs DFD 0

2.- Diagramas de Flujo de Datos

El primer diagrama general que sigue al de contexto es el número 0 por convenio En el DFD 0 se hace una descomposición en subsistemas, es decir, se indican los procesos más importantes en el sistema ⇒ Han de ser SUBSISTEMAS


2.- Diagramas de Flujo de Datos Descomposición funcional y almacenes de datos

Los almacenes aparecen lo más tarde posible En un nivel superior únicamente cuando son interfaz entre procesos Una vez que aparezca en un DFD, el almacén aparecerá otra vez en cada DFD de nivel más bajo relacionado


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

P A

D

FICH

P B.1

P A.1

D P A.2

P B

D

FICH

P B.2

FICH


2.- Diagramas de Flujo de Datos

Tamaño de la jerarquía de DFDs

Cada DFD debería tener alrededor de 7 procesos o menos (Miller 57) En general, habrá varios niveles intermedios, dependiendo del tamaño y complejidad del sistema que se está modelando ¿Cuántos niveles son convenientes? Yourdon: depende del problema Métrica

Diagrama Diagrama Diagrama Diagrama Diagrama

de de de de de

contexto / sistema subsistemas funciones subfunciones procesos (opcional)


2.- Diagramas de Flujo de Datos

Reglas sintácticas en DFDs

El origen y/o el destino de un FD es siempre un proceso Excepción: almacenes en el diagrama de contexto (Yourdon 89) datos del mercado CLIENTES CORPORATIVOS

informes anuales D

CENTROS DE INVESTIGACIÓN

CLIENTE

datos de investigación

P SIST. DE INVESTIG. DE MERCADOS

DATOS DEL MERCADO

datos del mercado


2.- Diagramas de Flujo de Datos

Reglas sintácticas en DFDs

(II)

Todo almacén y todo proceso tienen uno o más FD de E y uno o más FD de S EXCEPCIÓN: un almacén puede no tener FD de salida, por simplificación (p.ej. BD Histórica) RECOMENDACIÓN: si aparece un proceso fuente o sumidero, replantearse los límites del sistema P Fuente

P Sumidero


2.- Diagramas de Flujo de Datos

Ideas útiles para construir el DFD

Identificar todos los elementos exógenos Identificar sus relaciones con el sistema Trabajar según alguna de las siguientes filosofías: De inputs a outputs De outputs a inputs Desde una posición intermedia hacia delante o hacia atrás


2.- Diagramas de Flujo de Datos Ideas 煤tiles para construir el DFD (II)

Nombrar adecuadamente todos los objetos del DFD Numerar adecuadamente procesos y diagramas Realizar una correcta divisi贸n en subsistemas (DFD 0) Utilizar la descomposici贸n funcional jer谩rquica hasta alcanzar las funciones primitivas


2.- Diagramas de Flujo de Datos

DFDs - Conclusiones

Valiosa herramienta de comunicaci贸n Usuario, analista, dise帽ador, programador Se puede combinar con el uso de prototipos

F谩cil de entender y de aprender Facilita las relaciones con el usuario Amplia difusi贸n


2.- Diagramas de Flujo de Datos

DFDs – Conclusiones (II)

Superado por las metodologías OO, pero todavía vigente: − se enseña en 12 de 15 ppales. universidades españolas,casi todas en Chile − industria, − administración (Métrica 2.1 y 3), − cuerpo de conocimiento de ingeniería del software (SWEBOK, SEEK, etc.)

El control no aparece hasta el final de la especificación estructurada No es inmediato el paso a la codificación y prueba ⇒ Diseño estructurado


2.- Diagramas de Flujo de Datos

DFDs – Conclusiones (III)

Útil para el análisis y para el diseño del nuevo sistema Más adecuado para el nivel lógico, aunque también puede ser adecuado para el nivel físico (indicando personas concretas, lugares geográficos, formatos de datos, etc.)


Diseño Estructurado Introducción

2.- Diseño: Diagrama de Estructuras

Concepto y Principios del Diseño Inicios del Diseño Efectividad del Diseño Módulo(laridad) Abstracción Refinamiento

Factores de calidad Acoplamiento Cohesión

Tipos de Acoplamiento Tipos de Cohesión Consideraciones para un Diseño de Calidad Resultados del Diseño


2.- Diseño: Diagrama de Estructuras

Diseño Arquitectónico ( Diseño Preliminar) Elementos Diagrama de Estructura Partición Estructural de un Diagrama de Estructura Estrategias de Diseño Construcción del Diagrama de Estructura


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


Concepto y Principios del Diseño El diseño estructurado es un método de configuración de la organización modular del software que se desarrolla a partir de los flujos de datos que contiene la especificación de requerimientos obtenida en la fase de análisis bajo enfoque estructurado.

En este sentido, puede decirse

que este enfoque consiste en el diseño de programas como estructuras de funciones únicas y de relativa independencia.


Efectividad del Diseño Para

poder

evaluar

la

efectividad

de

una

representación de diseño, es preciso establecer lo que

se

denomina

en

Ingeniería

de

software,

"criterios para un buen diseño", entre los cuales es posible destacar los siguientes:

• El diseño debe exhibir una organización jerárquica con

mecanismos de control que no atenten contra

la independencia relativa de cada componente de la jerarquía.


Efectividad del Diseño ‑ El diseño debe ser modular, esto es, el software debe estar particionado lógicamente en elementos que ejecuten funciones y subfunciones específicas. - El diseño debe generar módulos que exhiban niveles adecuados de independencia funcional. ‑ El diseño debe obtenerse a partir de la especificación de requerimientos generada durante la fase de análisis. ‑ Módulo(laridad) ‑ Abstracción ‑ Refinamiento


Efectividad del Diseño ‑ Módulo(laridad) “Módulo es una unidad claramente definida y manejable que forman parte de los elementos constituyentes del software” “La modularidad consiste básicamente en el particionamiento del software en elementos con nombres y direcciones separadas que se denominan módulos, los cuales en su composición generan la totalidad que debe ser capaz de resolver el problema global que da origen a la necesidad de construir un producto de software. “ Tiene que ver con la separabilidad de las funciones que en conjunto cumplen un objetivo mayor, esto es, responden a la idea de totalidades emergentes propia de la noción de sistemas.


Efectividad del Diseño ‑ Beneficios de la Modularidad ‑ Programas más simples, ya que puede ser comprendido, verificado, programado, depurado, mejorado y alterado por partes. ‑ Módulos

que pueden ser desarrollados con relativa

independencia. ‑ Disminución de la posibilidad de errores al reducir la complejidad. ‑ Programas que pueden evaluarse por partes, por lo cual todo test se hace más fácil. ‑ Programas más fáciles de alterar ya que son menores las líneas de código a considerar para incorporar los cambios. ‑ Módulos de función única que pueden ser reutilizados.


Efectividad del Diseño ‑ Beneficios de la Modularidad ‑ La posibilidad de cometer errores por parte de los programadores disminuye porque son menos las líneas de código que deben enfrentarse al mismo tiempo. ‑ La rotación de personal se hace menos crítica, ya que los programadores están involucrados en unidades de código más pequeñas por lo cual la sustitución resulta menos dificultosa. ‑ Responder al requerimiento de la división del código en segmentos de una página, como lo sugiere la programación estructurada, es casi total.


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

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


Efectividad del Diseño ‑ Módulo

Módulo Superordinado

Módulo Subordinado

Fan‑ out : 2 Fan‑ in : 1


Efectividad del Diseño ‑ Módulos & Integración Costos o Esfuerzo Costo Total SW

Costo por Integración

Costo por Módulo

N° Módulos Costos Mínimos


Efectividad del Diseño ‑ Abstracción “Cuando se considera una solución modular para enfrentar un problema, se puede plantear en distintos niveles de abstracción. Un nivel superior de Abstracción supone una solución en términos amplios, usando un lenguaje del entorno del problema. A un niveles más bajos, se toma una orientación más procedimental, se combina una

terminologia orientada al

problema con una orientada a la implementación. El nivel más bajo

de

abstracción

permite

implementarse directamente”

que

la

solución

pueda


Efectividad del Diseño ‑ Refinamiento El refinamiento gradual es una estrategia de diseño top_down cuyo origen es la propuesta de Niklaus Wirth (WIRTH‑ 71) quien postula que "La arquitectura de un programa se desarrolla refinando sucesivamente los niveles de detalle de los procedimientos. De este modo se desarrolla una jerarquía de procedimientos al descomponer sucesivamente una sentencia global hasta alcanzar sentencias específicas a nivel de un lenguaje de programación". R. Pressman (PRESSMAN‑ 88) al respecto cita a Wirth señalando que: "En cada etapa (del refinamiento), se descomponen una o varias de las instrucciones del programa dado en instrucciones cada vez más detalladas. Esta descomposición o refinamiento sucesivo termina cuando todas las intrucciones están expresadas en términos de cualquier lenguaje básico de computador o de programación.


Efectividad del Diseño ‑ Refinamiento En el dominio de la Ingeniería de Software, la modularización se apoya en lo que se conoce como refinamiento sucesivo o gradual, para la configuración de la estructura del software que se precisa diseñar y luego construír. Refinamiento Gradual

Abstracción Módulo A

Modularidad

A1

A2

Factorización


Factores de Calidad ‑ Acoplamiento Corresponde al grado de independencia entre dos módulos. Entendido así,

minimizar

el

acoplamiento

aparece

entonces

como

una

determinante prioritaria al configurar las conformaciones estructurales. La obtención de módulos tan independientes como sea posible,se puede ser lograda principalmente de tres maneras: ‑ Eliminando relaciones innecesarias. ‑ Reduciendo el número de relaciones necesarias. ‑ Debilitando la dependencia de las relaciones necesarias.


Factores de Calidad ‑

Cohesión

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


Factores de Calidad Acoplamiento

Cohesi贸n

Principios de un Buen Dise帽o


Tipos de Acoplamiento 1. Acoplamiento Normal 2. Acoplamiento por Datos 3. Acoplamiento por Estampado o Imagen 4. Acoplamiento de Control 5. Acoplamiento ComĂşn 6. Acoplamiento por Contenido


Tipos de Acoplamiento Mejor Acoplamiento NORMAL DATOS ESTAMPADO CONTROL EXTERNO (caso especial de COMÚN) COMÚN CONTENIDO Grado de Acoplamiento


Tipos de Acoplamiento 1.Acoplamiento Normal Dos Módulo A y B están Normalmente Acoplados si: • Un Módulo A llama a otro B • B retorna el control a A No se produce traspaso de parámetros entre ellos, sólo existe la llamada de uno a otro. A

B


Tipos de Acoplamiento 2. Acoplamiento por Datos

Obtener Datos Cliente

Dos módulos están acoplados por datos si ellos se comunican por parámetros, siendo cada parámetro

Rut_cliente

una unidad elemental de datos El

acoplamiento

por

datos

corresponde a la comunicación de datos necesaria entre módulos. Toda vez que los módulos tienen que comunicarse entre sí,

la ligazón por

datos es inevitable y serán adecuadas si se mantienen a niveles mínimos.

Leer Rut


Tipos de Acoplamiento 3. Acoplamiento por Estampado

Calcular Deuda Cliente

o Imagen Dos acoplados

m贸dulos por

aparecen

estampado

o

ligados por imagen si ellos se refieren a la misma estructura datos local. Cabe destacar que

Cliente

Leer Cliente

por estructura de datos se debe entender un grupo compuesto de datos, tal como un registro, el

cual,

por

su

parte,

constituye de varios campos.

se

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


Tipos de Acoplamiento 4. Acoplamiento de Control Dos mรณdulos estรกn acoplados por control cuando uno de ellos pasa al otro mรณdulo elementos

Obtener Datos Cliente Tipo_dato

Cliente

de control (flags, switchs) como Leer Cliente

argumentos. Provoca

dependencia

de

ejecuciรณn entre un mรณdulo y otro. No es muy recomendable.


Tipos de Acoplamiento 5. Acoplamiento Común Los

módulos

Actualizar Stock Video

Obtener Nombre Video

presentan

acoplamiento común, si ellos se refieren a la misma área estructura de datos (global). Cuando sólo se acomplan por

video

una variable (global), se trata de un Acoplamiento Externo Programas con muchos datos globales son extremadamente difíciles de entender por los programadores de mantención, porque no es fácil saber cuáles son los datos usados por un cierto módulo.

Leer Registro Video


Tipos de Acoplamiento 6. Acoplamiento por Contenido Este es un tipo de Acoplamiento Inaceptable. acoplamiento

Dos módulos presentan de

contenido

(o

patológico) si uno hace referencia al interior del otro. Esto ocurre si por

A

B

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

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

ejemplo, en un módulo se desvía la secuencia de instrucciones al interior de otro o si un módulo altera un

Tal acoplamiento torna el concepto de

comando de otro.

módulos configurados bajo el criterio de la caja negra sin sentido, ya que fuerza a un módulo a conocer explícitamente los contenidos y la implementación de otro.


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

Enfoques: ¿Cómo Analizar el Tipo de Acoplamiento? • Imaginar el Módulo como una Biblioteca • Cada Módulo es codificado por un programador diferente


Tipos de Cohesión Mayor Cohesión FUNCIONAL

Módulo como Caja Negra

SECUENCIAL COMUNICACIONAL PROCEDURAL TEMPORAL

Módulo Transparente

LÓGICA COINCIDENTAL Grado de Cohesión

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


Tipos de Cohesión 1. Cohesión Funcional

Ejemplos

Se puede decir que un módulo

con

cohesión

funcional

es

aquel

que

contiene

elementos

que

contribuyen a la ejecución de una y sólo una tarea relacionada

al

objeto de diseño,.

problema

• Calcular el coseno de un ángulo •Calcular el I.V.A. De una factura •Verificar el dígito de un RUT


Tipos de Cohesión 2. Cohesión Secuencial Un

módulo

cohesionado

Ejemplo: Calcular Salario

secuencialmente es

aquel

cuyos

1. Obtener sueldo base 2. Verificar número de cargas

elementos están envueltos en

3. Revisar días con permiso

actividades tales que los datos

4. Revisar días con licencia

de salida de una actividad sirven

5. Calcular horas de trabajo

como datos de entrada para la

6. Descontar horas de atraso

próxima actividad.

7. Agregar horas extras ....


Tipos de Cohesiรณn 3. Cohesiรณn Comunicacional

Ejemplo:

Obtener

datos

Un mรณdulo presenta cohesiรณn

Video

comunicacional

1. Obtener nombre video

elementos

cuando

contribuyen

sus a

2. Obtener stock video

actividades que usan la misma

3. Obtener ubicaciรณn

entrada o la misma salida. No

4. Obtener precio

importa el orden secuencial

....


Tipos de Cohesión 4. Cohesión Procedimental un módulo cohesionado por

Ejemplos:

procedimientos es aquel cuyos

una oficina

elementos están envueltos en actividades

diferentes

y

Actividades

1. Hablar por teléfono 2. Tomar un café

posiblemente no relacionadas,

3. Leer correo electrónico

en donde el control fluye de

4. Solicitar cotización

una actividad a otra.

....

en


Tipos de Cohesión 5. Cohesión Temporal Ejemplo: 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.

Actividades

iniciar el día 1. Apagar despertador 2. Tomar una ducha 3. Vestirse 4. Hacer la cama 5. Tomar desayuno ....

al


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ón 7. Cohesión Coincidental Un módulo coincidentemente

Ejemplo: 1. Comprar un libro

cohesionado es aquel cuyos

2. Comer un trozo de torta

elementos

3. Ir al teatro

actividades

desarrollan sin

significativa entre sí.

relación

4. Lavar la ropa 5. Dormir ....


Árbol de Cohesión


Consideraciones Importantes para un Diseño de Calidad La factorización consiste en separar la funcionalidad de un módulo, en subfunciones claramente identificables, en términos tales que sea posible considerarla como constitutiva de un módulo independiente. 1. La necesidad de reducir el tamaño de un módulo. 2. Obtener las ventajas de la modularización mediante un diseño "top_down". => Sistema más comprensible el sistema y facilitamiento de cambios 3. Evitar que una misma función aparezca en diferentes partes del sistema, es decir, en más de un módulo. 4. Proveer módulos de uso general. 5. Simplificar la implementación.


Reducir el Tamaño de un Módulo 1. De Marco señala, un tamaño razonable para un módulo corresponde a un conjunto de líneas de código de alrededor de media página de listado (30 líneas más o menos), 2. Page‑ Jones, señala que toda la codificación de un módulo debería, idealmente, ser visible en una página de listado (una exigencia que impone un límite no superior a 60 líneas) 3. Geral Weinberg (WEI‑ 72) muestran que la habilidad del hombre para entender un módulo y encontrar errores depende de la capacidad de aprehender el módulo como un todo de una sola vez.


Resultados del Diseño El proceso de diseño debe lograr la determinación de las directrizes en virtud de las cuales el producto de software ha de construirse, tomando como base la especificación de requerimientos generada en la fase de análisis. Así, entonces, el diseño, en cuanto proceso, debe dar como resultado: • el Diseño de la Arquitectura del producto de software a construir. • la Especificación de los Procedimientos del software a construir. • el Diseño de los Datos involucrados • el Diseño de la Interfaz de usuario


Dise帽o Arquitect贸nico


Diccionario de Datos Clave_votante_vรกlida: Flag que indica que la combinaciรณn ingresada por el cliente es vรกlida, y puede llevar a emitir su voto.


Especificación de procesos Interfaz

Nombre : REGISTRAR DATOS ACTUALIZACIÓN Entradas : Datos_actualización Salidas :Datos_actualización, datos_actualización_registrados. Procedimiento: Recibir Datos_actualización. Abrir archivo INFORMACIÓN MUNICIPAL. Escribir en archivo los Datos_actualización. Pseudocódigo Cerrar archivo INFORMACIÓN MUNICIPAL. Mandar mensaje indicando Datos_actualización_registrados.


Dise単o de Datos


Dise帽o de Datos Votante Clave_Vot A10 Rut_Vot A10 Nom_Vot A30

Voto Id_Voto A10

Detalle_Voto Id_Voto A10 Id_Partido A30

Servicio Cod_Serv N5 Descrip_Serv A30

Candidato Id_Partido Nom_Cand Municipalidad Id_Orga A10 Nom_Orga A30 Servcio A30 Direcci贸n A30 Fono N10 Comuna A20

A30 A30


Dise単o de Interfaz


Elementos del Diagrama de Estructura Obtener Nombre Video Leer Registro Video

X

Y

Módulo

Módulo Predeterminado

MÓDULO JEFE (INVOCADOR)

MÓDULO SUBORDINADO (INVOCADO)


Elementos del Diagrama de Estructura Obtener Datos Cliente Tipo_dato

Flujo de Control

Flujo de Dato

Cliente

Leer Cliente

Un dispositivo fĂ­sico es cualquier dispositivo mediante el cual se puede recibir o enviar datos necesarios para el sistema

Un almacĂŠn de datos corresponde a la instancia real en la cual van a estar los datos que precisa el sistema


Elementos del Diagrama de Estructura Conectores


Elementos del Diagrama de Estructura Secuencia

Iteraci贸n


Elementos del Diagrama de Estructura Selecci贸n


Profundidad y Ancho de un Diagrama de Estructura Profundidad y ancho proporcionan una idea del número de niveles de control y el ámbito global de control respectivamente. El grado de salida es una medida del número de módulos que son controlados directamente por otro módulo. El grado de entrada indica cuántos módulos controlan directamente un módulo dado.


Estrategia de Diseño para Construir Diagrama de Estructura

Diseño Centrado en Transformaciones DFD

Diseño Centrado en Transacciones

Análisis

Diseño

Diagrama de Estructura


Estrategia de Diseño Diseño Centrado en Transformaciones

1.1

1.2 3

• Los datos entran al sistema mediante caminos que se llaman

4.1 2.1

2.2

flujos de entrada • 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

4.2 Flujo de Llegada Flujo de Centro Salida de Transformación


Estrategia de Diseño Diseño Centrado en

Camino de Acción 1

Transacciones 2.1

• Se presenta un centro de

2.2

transacción, como centro de flujo de información • 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

1 Centro de Transacción

3.1

3.2

4.1

4.2

Camino de Acción 2

Camino de Acción 3


Estrategia de Diseño: Transformación 1. Revisión del Modelo Fundamental del sistema DFD, mínimo tres niveles 2. Determinar si el DFD tiene características de Transformación o Transacción Analizar el centro de transformación propiamente tal 3. Aislar el centro de Transformación, especificando los límites del flujo de llegada y de salida Delimitar 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


Estrategia de Diseño: Transformación •Módulos a incorporar 1.1

• Módulo principal Cp, que controla

el

resto

de

2.1 coordinador

de

la

Información de Entrada, Ce •Módulo controlador del centro de

3

los

módulos •Módulo

transformación,

1.2

que

4.1

2.2

Centro 4.2 de Flujo de Llegada Transformación Flujo de Salida Diagrama de Contexto

supervisa las operaciones de

Cp

los datos, Ct •Módulo

controlador,

procesamiento

de

del

Ce

Ct

la

información de salida, Cs Nombres representativos

Cs


Estrategia de Diseño: Transformación 5. Ejecución del “segundo nivel de factorización” a

1.1

1.2 3

b

2.1

4.1

2.2

Centro 4.2 de Flujo de Llegada Transformación Flujo de Salida

Cp z Ce 1.2

2.2

1.1

2.1

Leer a

Leer b

Ct 3

Cs 4.1 4.2

Escribir z


Estrategia de Diseño: Transformación 6. Refinar la estructura obtenida, utilizando las guías, principios y conceptos, para un diseño de calidad Aumentar o Disminuir el N° de módulos (ejemplo Ct) Incorporar flujos de datos (DFD) y de control 7. Asegurarse del trabajo realizado, representado en el diseño construido Verificar funcioanalidad, orden de módulos, etc.


Estrategia de Diseño: Transacción 1. Revisión del Modelo Fundamental del sistema DFD, mínimo tres niveles 2. Determinar si el DFD tiene características de Transformación o Transacción Analizar el centro de transacción propiamente tal 3. Aislar el centro de Transacción, especificando los límites del flujo de llegada y de salida El centro de transacción se encuentra ligado al origen de varios caminos de información que fluyen radialmente de él 4. Realizar el primer corte del diagrama de estructura Primer nivel de factorización, se incorporan módulos coordinadores


Estrategia de Diseño:

Transacción •Módulos a incorporar • Módulo principal Cp, que controla

el

resto

de

a A

D

los

módulos

z P

•Módulo

coordinador

de

la

•Módulo gestor del centro de

Cp

transacción, D controlador,

R

b

Información de Entrada, Ce

•Módulo

Q

los

distintos caminos que generan

Ce

D

información de salida, Ci

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

C2

C3


Estrategia de Diseño:

Transacción

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

a A

Camino 2

D

D

Ce P b

Q

R

z a

Camino 3

C1

C2

C3

Leer a P

Leer b

Q

R Escribir z


Estrategia de Diseño:

Transacción

6. Refinar la estructura obtenida, utilizando las guías, principios y conceptos, para un diseño de calidad Aumentar o Disminuir el N° de módulos Incorporar flujos de datos (DFD) y de control 7. Asegurarse del trabajo realizado, representado en el diseño construido Verificar funcionalidad, orden de módulos, etc.


Diseño Procedimental (Diseño Detallado Especificación Interfaz-Función Especificación Mediante las Miniespecificaciones del Análisis Especificación por Pseudocódigo


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


Ejemplo:

M贸dulo: SELECCIONAR ASIENTO DE PASAJERO Entrada: PREFERENCIA_ASIENTO_PONDERADA Salidas: ASIENTO_SELECCIONADO, PREFERENCIA_DISPONIBLE Funci贸n: Seleccionar un asiento para un pasajero considerando que sus preferencias de ubicaci贸n sean lo m谩s cercanas (ponderadamente) al asiento elegido.


Diseño Detallado 2. Especificación Mediante las Miniespecificaciones del Análisis Este método

considera que las miniespecificaciones

generadas durante la fase de análisis sirven también como

especificación

de

módulos.

Se

considera,

en

general, que la especificación de cada burbuja del diagrama

de

especificar

flujo

de

datos

es

suficiente

para

lo que en la fase siguiente al diseño se

debe construir. La gran limitación de este método es que no siempre existe una correspondencia uno a uno entre las burbujas, explicitadas como necesarias de automatizar en la fase de análisis, y los módulos del diagrama de estructura.


Módulo: SELECCIONAR ASIENTO DE PASAJERO Entrada: PREFERENCIA_ASIENTO_PONDERADA Salidas: ASIENTO_SELECCIONADO, PREFERENCIA_DISPONIBLE Función: Seleccionar un asiento para un pasajero considerando que sus preferencias deubicación sean lo más cercanas (ponderadamente) al asiento elegido. Detalles de Funcionalidad • Buscar asiento disponible comenzando con la clase solicitada y continuando con clases inferiores. • Anotar para cada asiento la diferencia respecto a la preferencia del cliente. • Seleccionar el asiento con menor diferencia: este será el AsientoSeleccionado. (Diferencia=Dif-Fumador*PESO_FUMADOR+ ...) • Si el cliente necesita un asiento no fumador (y Peso-Fumador > 1) y ha sido seleccionado un asiento fumador, intentar mover en una fila atrás la sección de no fumadores en la clase del cliente (si es posible). • Si la diferencia entre el asiento preferido y el asiento seleccionado es 0, realizar la asignación PREFERENCIA-DISPONIBLE=”Y”; de lo contrario asígnele “N”.


Diseño Detallado 2. Especificación por pseudocódigo Pseudocódigo es un lenguaje informal similar al lenguaje estructurado, el cual es más preciso y detallado que la especificación por interfaz-función. Tiene sintaxis fija para constructores, declaración de datos y módulos, y sintaxis libre para describir características de procesamiento

Diagrama de Flujo de Datos  

Material con información referente a flujos de datos

Read more
Read more
Similar to
Popular now
Just for you