Diana Marcela S ánchez F úquene · Índice El proceso de diseño Modelos de diseño. Diseño estructurado. Diagramas de estructura. Estrategias de diseño Análisis de transformaciones

Tema VII: Tema VII: DiseDiseñño Estructuradoo Estructurado

Diana Marcela SDiana Marcela Sáánchez Fnchez FúúquenequeneIngeniería del Software de Gestión

ÍÍndicendice

� El proceso de diseño

� Modelos de diseño.

� Diseño estructurado.◦ Diagramas de estructura.

◦ Estrategias de diseño� Análisis de transformaciones.

� Análisis de transacciones

Ingeniería del Software de Gestión

El proceso de DiseEl proceso de DiseññooEl proceso de aplicar distintas técnicas y principios

con el propósito de definir un dispositivo, un proceso o un sistema con suficiente detalle como

para permitir su realización física

Proceso iterativo a través del cual se traducen los requisitos en una representación del software

El diseño estructurado es un enfoque disciplinado de la transformación de qué es necesario para el

desarrollo de un sistema, a cómo deberá ser hecha la implementación


Vista GeneralVista General

OrientaciOrientacióón a Objetosn a Objetos


DiagramasDiagramasdede

Casos de UsoCasos de Uso

Hoy día, en muchas situaciones,muchas ofertas de administradores de base de datos con lenguajes de cuarta generación que permiten, al usuario, escribir sus propios programas. ¿Con qué partes del sistema ellos pueden interactuar sin riesgos de producir inconsistencia en muchas situaciones, el usuario y el analista pueden decidir prototipar el sistema y usar un lenguaje de cuarta generación o un paquete generador de aplicaciones. La prototipación puede hacerse porque el usuario no esta seguro de la acción detallada que en el futuro tendrá que ser descrita en las especificaciones de procesos del modelo esencial; aun así, la mayoría de las veces, la prototipación se usa para la exploración y experimentación con formatos de entrada, diálogos en línea y formatos de salida para las pantallas e informes. muchas aplicaciones de una compañía, una opción es la de adquisición de un paquete de software. En estos casos se generan los mismos problemas de implementación: ¿Quépartes del modelo esencial serán llevados a cabo por el paquete adquirido y qué partes tendrán que ser llevadas a cabo en un sistema separado? ¿Cuáles serán las normas de integración y compatibilidad entre el paquete adquirido y el sistema a ser desarrollado?



DescripcionesDescripcionesdede

Casos de UsoCasos de Uso

PrototipoPrototipooo

DiseDiseñño de Interfazo de Interfaz

Dominio del Cliente



ContratosContratosdede

OperacionesOperacionesdeldel

SistemaSistema

Pedido

idtotal

ItemCarro

unidades

Usuario

nombrenif 0..n1

CarroCompra

total0..n1

1

1

LineaPedido

unidades1..n1

Producto

nombrepreciodescripcion

10..n

1

0..n

1 0..n 1 1..n

0..n

11

1

1 0..n 0..n 1

Modelo ConceptualModelo Conceptualde Clasesde Clases


SecuenciaSecuencia : Sistema

as : Anunci oSubasta

puj as : Pu jaOrdi naria

adj : Adjudicaci on

: Arti culo Concre to

Se crean tantas adjudicaci ones como pujas ganadoras haya. Cada adjudicaci ón se asocia con un Arti culoConcreto, una puja adjudicataria y con l a subasta.

: ControladorAnuncios

Se recorre l a colecci ón de puj as obteni endo las pujas ganadoras (consi deramos que la col ección está ordenada de mayor a m enor valor de puja).

adj udi caciones : Ad j udi cac io n

: Edici onSubasta

int numAjudicaci ones =

Mini mo(puj as.l ength(), arti culos. length());

: AnuncioSubasta

5. numAdjs = cal cul arAdjudicaci ones()

1. cerrarEdici onSubasta(es)

6. [1..num Adj s]* pg := g et()

8. [1..num Adj s]* adj := crear(as, pg, a)

7. [1..num Adj s]* a:= get()

9. [1..numAdjs]* add(adj )

2. cerrar()

4. * cerrar()

3. * as := get()


ColaboraciColaboracióónn


ColaboraciColaboracióónn

Modelo de ClasesModelo de Clasesdede

DiseDiseññooPatronesPatrones

DiagramaDiagramadede

ComponentesComponentes


DespliegueDespliegue

RequisitosRequisitos

AnAnáálisislisis

DiseDiseññoo

ImplementaciImplementacióónn


Modelo lógico de datos

Modelo físico de datos

Arquitectura de procesos

Estructura detallada: programas y módulos

Codificación y pruebas

AnAnáálisis (Qulisis (Quéé))

Lenguaje comprensible por el Lenguaje comprensible por el

usuariousuario

Diseño de alto nivel (arquitectónico)

Diseño de bajo nivel (detallado)

DiseDiseññoo

(C(Cóómo)mo)

Decisiones Generales Decisiones Generales

y Abstractas:y Abstractas:

OrganizaciOrganizacióón ln lóógicagica

Decisiones concretas y Decisiones concretas y

especespecííficas: ficas:

optimizacioptimizacióón y rendimienton y rendimiento

ImplementaciImplementacióónn

Lenguaje comprensible Lenguaje comprensible

por la mpor la mááquinaquina

Enfoque de datos

EnfoqueFuncional

ERS

ModeloEntidad/Relación

ModeloModeloEntidad/RelaciEntidad/Relacióónn

Diagramade

Flujo de Datos


Flujo de DatosFlujo de Datos

Esquema de BD y ficheros

Cuadernos de carga

Vista GeneralVista General

AnAnáálisis Estructuradolisis Estructurado

El proceso de DiseEl proceso de Diseññoo

� Diseño de datos◦ Transforma el modelo del dominio de la información del análisis

en las estructuras de datos necesarias para la implementación.◦ Esquema Lógico de Datos ó Modelo Relacional.

� Diseño arquitectónico◦ Estructura modular del programa/aplicación◦ Diagramas de Estructura de Cuadros de Constantine

� Diseño de interfaz◦ Interfaces del sistema con otros sistemas y con los usuarios.

� Diseño procedimental◦ Descripción procedimental de los componentes del sistema


DiseDiseñño Estructuradoo Estructurado

� Objetivos◦ Desarrollar la estructura modular del programa

◦ Definir las relaciones entre módulos

� Técnica Principal◦ Diagrama de Estructura de Cuadros de Constantine

� Documentación de partida◦ DFDs – Análisis Estructurado.

� Estrategias de diseño - Tipos de Esquemas◦ Análisis de transformaciones

◦ Análisis de transacciones



� Se dispone de◦ Las entradas que suministran al sistema las entidades externas

◦ Las salidas aportadas por el sistema a dichas entidades externas

◦ Las funciones descompuestas que se han de realizar en ese sistema

◦ El esquema lógico de datos del sistema



� Tareas a realizar◦ Módulos obtenidos en el análisis� Procesos primitivos

◦ Organizar la estructura de estos módulos y definir las conexiones entre los mismos

◦ Describir el pseudocódigo para cada módulo

� Se basa en los siguientes principios◦ Abstracción

◦ Modularidad

◦ Encapsulamiento y Ocultamiento de información

� No confundir con programación estructurada


Diagramas de Estructura de Diagramas de Estructura de Cuadros de ConstantineCuadros de Constantine


� Objetivo: diseño de la ARQUITECTURA◦ Desarrollar la estructura de programas, asícomo las relaciones entre los elementos (módulos) que componen esta estructura

� Identifica qué módulos se necesitan, asícomo sus inputs/outputs (caja negra)

� Refleja la comunicación de datos y control y la jerarquía entre módulos

Diagrama de Estructuras: ejemploDiagrama de Estructuras: ejemplo


LEER

PETICION

PRESTAMO

GESTIONAR

PETICIONES

PET_ACEPTADA

INFORME

PRESTAMO

PET_ACEPTADA

INFORMAR

PETICIONTRATAR

PETICION

CONSULTAR

STOCK

PET_PRESTAMOPET_RECHAZADA

RECHAZAR

PETICION

INFORME

PRESTAMO

Módulos

Conexiones entre módulos

Comunicación entre módulos

(estructuras de datos o de control “flags”)

Módulos “predefinidos”

Diagrama de EstructurasDiagrama de Estructuras

MMóódulosdulos� Arquitectura implica modularidad◦ El software debe dividirse en elementos (módulos)

que se integran entre sí para, con su ejecución, satisfacer los requisitos del sistema.

Módulouna unidad claramente definida y manejable, con

interfaces modulares perfectamente definidas

� La modularidad mejora la calidad del diseño◦ Facilitando la implementación, depuración, pruebas,

documentación y mantenimiento de un producto software



MMóódulosdulos� Un modulo se entiende como la unidad más pequeña de

código que puede ser compilada independientemente

� Otras definiciones:◦ Según la IEEE [IEEE, 1990], un módulo es (1) una parte lógica separable

de un programa; (2) una unidad de programa discreta e identificable respecto de la compilación, combinación con otras unidades y la carga de memoria

◦ Según Yourdon [YOURDON y CONSTANTINE, 1979], un módulo es una secuencia contigua de sentencias de programa, limitada por delimitadores y que tiene un identificador global

◦ Según Fenton [FENTON, 1991], un módulo puede ser cualquier objeto que, en un nivel de abstracción dado, queramos considerar como un concepto simple

◦ En la teoría del diseño estructurado [PAGE-JONES, 1988], un módulo es aquella parte de código que se puede llamar



MMóódulosdulosRepresentación


OBTENER DATOS

CLIENTES

MÓDULOIMPRIMIR

CHEQUE DE PAGO

MÓDULO PREDEFINIDO

1

CONECTOR

Almacenes de datos

Dispositivos físicos

NOMBRE

DISPOSITIVO

MÉTRICA


MMóódulosdulos� Típicamente representa un programa,

subprograma o rutina, dependiendo del lenguaje que se vaya a utilizar

� Admite parámetros de llamada y retorna algún valor, si es preciso

� Puede tener aproximadamente entre unas 40 o 50 líneas de código (muchas opiniones encontradas)

� Es posible dividir el software indefinidamente◦ Compromiso entre

� Esfuerzo requerido para cada módulo �� Esfuerzo requerido para las interfaces entre módulos �



MMóódulosdulosEsfuerzo requerido para desarrollar módulos


Nº Módulos

Coste o Coste deinterfaz

Coste pormódulo

Coste Totaldel Software

Región de costemínimo

Esfuerzo

Diagrama de Estructuras: MDiagrama de Estructuras: Móódulosdulos

Esfuerzo requerido para desarrollar módulos


¿Qué elegiríamos un módulo con 1000 líneas o 1000 módulos de 1 línea?

Nº Módulos

Coste o Coste deinterfaz

Coste pormódulo

Coste Totaldel Software

Región de costemínimo

Esfuerzo

20 Módulos de 50 líneas cada uno


ConexiConexióón entre mn entre móódulosdulos� Cada conexión representa una llamada de

un módulo a otro � Se representan con una flecha� Distinguir de un organigrama◦ A � B � C◦ A � B � C � B � A

� El orden de llamadas es interpretado de forma distinta◦ arriba hacia abajo y de izquierda a derecha◦ Independiente de la disposición del grafo



EstructurasEstructuras de controlde control� Repetición◦ Una flecha circular, abarcando un número de invocaciones, especifica que las invocaciones que abarca son ejecutadas repetidamente

� Alternativa◦ Un rombo incluyendo una o más invocaciones especifica la ejecución condicional de ellas



ConexiConexióón entre mn entre móódulosdulos� Ejemplo menú Secretaría Virtual


Diagrama de Estructuras Diagrama de Estructuras

ComunicaciComunicacióón entre Mn entre Móódulosdulos� La comunicación en un diagrama de

estructuras se realiza a través de los datos y los flags o controles◦ Datos� Transporta datos “puros” a un módulo� No es necesario conocer la lógica

interna del módulo receptor, para determinar los valores válidos(ej: nº cuenta, saldo, etc.)

◦ Control� Transporta un dato

indispensable para la toma de una decisión (ej: código de operación)


Datos

Correctos

NIF

Diagrama de Estructuras Diagrama de Estructuras

ComunicaciComunicacióón entre Mn entre Móódulosdulos� Diferencias entre Datos y Flags


Finalidad Descripción Relevancia

Datos Los datos se procesan

• Los datos son la información compartida por los módulos. • La posición de la flecha (hacia arriba o hacia abajo) indica el sentido de la comunicación

Los datos están relacionados con el problema y son importantes para el mundo exterior

Flags Los controles sólo sirven para comunicar condiciones entre los módulos

Los controles indican al módulo que llama la terminación EOF, o un error del módulo llamado, y deben ir siempre en sentido ascendente

Los flags tienen importancia en la comunicación de información en el interior; son los que sincronizan la operativa de los módulos

Tablas de InterfazTablas de Interfaz

� Representa los parámetros que se pasan entre módulos

� Permite una mejor especificación de los parámetros

� Sirve de apoyo a los diagramas de estructuras

� Mejora su claridad (Nº de parámetros mayor que 4)



� Representa:◦ El módulo llamado

◦ Cada parámetro formal

◦ Si el parámetro es de entrada (marcando la columna correspondiente)

◦ Si el parámetro es de salida (marcando la columna correspondiente)

◦ El uso de cada parámetro

◦ El significado de cada parámetro



� Tabla de nemotécnicos de la columna uso de la tabla de interfaz


Nemotécnico Significa

P El parámetro es PROCESADO a = b + 2

M El parámetro es MODIFICADO a = 3 + b

T El parámetro es TRANSFERIDO por el módulo llamado a otro módulo que éste llama, sin modificar su valor

CEl parámetro es usado como una VARIABLE DE CONTROL, quizás para actuar como índice conmutador, como un valor de un flag o para la especificación de una función que es usada por el módulo llamado

I El parámetro es TRANSFERIDO a otro módulo, y es MODIFICADO en este segundo módulo


� Ejemplo de Tabla de Interfaz


MóduloParámetro

FormalEntrada Salida Uso

SignificadoParámetro

F(x, y) X SÍ NO PFecha-

Nacimiento

Y NO SÍ M Edad


� Ejercicio: Realizar la tabla de interfaz para este caso


LEER

PETICION

PRESTAMO

GESTIONAR

PETICIONES

PET_ACEPTADA

INFORME

PRESTAMO

PET_ACEPTADA

INFORMAR

PETICIONTRATAR

PETICION

CONSULTAR

STOCK

PET_PRESTAMOPET_RECHAZADA

RECHAZAR

PETICION

INFORME

PRESTAMO


� Solución


MóduloParámetro

FormalEntrada Salida Uso

SignificadoParámetro

TRATAR PETICIÓN

Petición Aceptada

SÍ NO P Consentimiento

TRATAR PETICIÓN

Informe Préstamo

NO SÍ IInforme de Préstamo

INFORMAR PETICIÓN

Informe Préstamo

SI NO PInforme de Préstamo

Diagrama de Estructuras: ejemploDiagrama de Estructuras: ejemplo


CONSEGUIR

ENTERO

VÁLIDO

LEER ENTERO

DE FICHERO

VALIDAR

ENTERO

ENTERO

ENTERO

ENTERO

VÁLIDOFIN DE

FICHERO “CONSEGUIR ENTERO VÁLIDO”:

…………………..

LEER_ENTERO( fin_fichero, entero ) ;

……………………..

if VALIDAR_ENTERO( entero ) then...

...

Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado

� Derivar el Diagrama de Estructuras de los DFD de procesos primitivos

� Dos estrategias◦ Análisis de Transformaciones

◦ Análisis de Transacciones



AnAnáálisis de Transformacilisis de TransformacióónnFlujo de Transformación


FLUJO DESALIDA

FLUJO DELLEGADA

FLUJO DETRANSFORMACIÓN

1.1

2.1

1.2

2.2

3

4.1

4.2

DFD con características de Transformación

Caminos de datos que entran en el Sistema

Caminos de datos de salida Sistema

Ocurre una transformación de

los datos


AnAnáálisis de Transformacilisis de Transformacióón: ejemplon: ejemplo



AnAnáálisis de Transaccilisis de TransaccióónnFlujo de Transacción


1

2.1

4.1

3.1

2.2

3.2

4.2

CENTRO DETRANSACCIÓN

Camino de acción 3

Camino de acción 2

Camino de acción 1

DFD con características de

Transacción

Un dato determina caminos alternativos por los que puede transitar el flujo

de información Caminos Alternativos y exclusivos


AnAnáálisis de Transaccilisis de Transaccióónn



Pasos del análisis de transformación/transacción1. Revisión del modelo fundamental del sistema2. Determinar si el DFD tiene características de

transformación o de transacción3. En el caso de análisis de transformación, aislar el centro de

transformación, especificando los límites del flujo de llegada y de salida

4. En el caso de análisis de transacción, identificar el centro de transacción y las características del flujo de cada camino de acción

5. Realizar el primer corte del diagrama de estructuras6. Ejecución del segundo nivel de factorización7. Refinar la estructura del sistema utilizando medidas y guías

de diseño8. Asegurarse del trabajo realizado por el diseño obtenido


1.Revisión del modelo fundamental del sistema

� Partir de los DFD del sistema◦ Para aplicar diseño estructurado del sistema

es necesario que el análisis de dicho sistema se haya realizado aplicando análisis estructurado

� Para aplicar el diseño estructurado con suficiente nivel de detalle se han de tener como mínimo 3 niveles de profundidad



Pasos Pasos

2. Determinar si el DFD tiene características de transformación o de transacción

� En general, la mayoría de DFD son de tipo transformación

� Elegir sólo los inequívocos◦ Procesos con salidas exclusivas entre sí

típicos de problemas de transacción

◦ Los centros de transacción a veces no son distinguibles en el DFD



Pasos Pasos

3. Análisis de transformación: aislar el centro de transformación, especificando los límites del flujo de llegada y de salida

� El centro de transformación es la parte del DFD que contiene las funciones esenciales del sistema

� Los límites del flujo de llegada y de salida están abiertos a interpretación (dependen del diseñador)◦ Pueden derivarse soluciones de diseño

alternativas



Pasos Pasos

Identificar Centro de Transformación Ejemplo


Reunir

del ClienteMovimentos

Leer

del ClienteMovimientos

FormatearLinea delInforme

CalcularTotal

FormatearEncabezado

FormatearTotal

ImprimirLinea

Leer

del ClienteInformaçión

# de Cuenta

# de Cuenta

# de Cuenta

Movimiento

Movimiento

Cuenta Corriente Clientes

Informe

�ombre + Dirección

Registro del Cliente

Movimiento

Encabezado

Saldo

Linea

Tipo de Movimiento +Valor del Movimiento

Total Depósitos +Total Extracciones


Pasos Pasos

4. Análisis de transacción: identificar el centro de transacción y las características del flujo de cada camino de acción

� Identificación intuitiva a partir del DFD. � Ligado al origen de varios caminos de información que

fluyen desde él � Normalmente el proceso del DFD que corresponde a la

transacción no se refleja en dicho DFD (reflejan procesos de control)◦ Es preciso conocer bien el sistema para darse cuenta que

tenemos entradas al sistema que son exclusivas entre sí y que se corresponden con cada una de las entradas a los caminos de acción

� El camino de llegada y los caminos de acción deben aislarse también



Pasos Pasos


Valor

Generar

Movimientos

Informe de

Iniciar

Deseada Operaçión

Registrar

Extracciones

Registrar Depósito

# de Cuenta

Cuenta

Corriente

Clientes Registro del Cliente

Movimiento

Operación Deseada

Saldo

# de Cuenta

# de Cuenta

# de Cuenta

# de Cuenta

Consultar

de Cuenta Saldo

Movimiento

Saldo

Movimiento

Movimiento

Parámetro deDireccionamiento

Parámetro deCurso

Parámetro deSeguimiento

Parámetro deDisparo

Curso Corriente

Ángulo deDireccionamiento

Coordenadasdcl objetivo

Detalle delDisparo

Direccionarel Barco

Localizar

Objetivo

AjustarCurso

Terminalde Control Giroscópo

Timón

DispararMísil

Misil

Parámetro deDirecionamiento

Parámetro deCurso



Curso Corriente

Ángulo deDirecionamiento

Coordenadasdel Objetivo

Detalle delDisparo


Timón

Misil

Direccionarel Barco

LocalizarObjetivo

AjustarCurso

DispararMísil

Inv. Op.Adecuada

Señal deControl

Identificarel centro detransacción

A veces no es tan evidente


Pasos Pasos


TransacciónTipo de

Obtener

TransacciónTipo de

TransacciónTipoB

TransacciónTipoA

TransacciónTipoC

AplicarTransacción

Valor

Generar

MovimientosReporte de

Iniciar

DeseadaOperación

RegistrarExtracción

RegistrarDepósito

# de Cuenta

Cuenta Corriente

ClientesRegistro del Cliente

Movimiento

OperaciónDeseada

Saldo

# de Cuenta

# de Cuenta

# de Cuenta

# de Cuenta

Consultar

de CuentaSaldo

Movimiento

Saldo

Movimiento

Movimiento

Control

Señal de

Obtener

ControlSeñal de Ajustar

Curso

ControlarDireccióndel Barco

LocalizarObjetivo

DispararMísil

GobernarBarco

DeseadaOperación

Obtener

DeseadaOperación Consultar

Saldo

GenerarReportede Movims

Registrar

Depósito

RegistrarExtracción

TransacciónBancarias

# de Cuenta

# de Cuenta # de Cuenta # de Cuenta

# de Cuenta

Parámetro deDirecionamiento

Parámetro deCurso



Curso Corriente

Ángulo deDirecionamiento

Coordenadasdel Objetivo

Detalle delDisparo


Timón

Misil

Direccionarel Barco

LocalizarObjetivo

AjustarCurso

DispararMísil

Inv. Op.Adecuada

Señal deControl


Pasos Pasos

5. Realizar el primer corte del diagrama de estructuras

� Análisis de Transformación ◦ La aplicación del análisis de transformación da

como resultado una estructura del sistema en la que� Los Módulos de nivel superior toman

decisiones de ejecución � Los Módulos del nivel inferior ejecutan la

mayoría del trabajo de entrada, de cálculo y de salida.

� Los Módulos de nivel intermedio ejecutan algún control y realizan moderadas cantidades de trabajo



Pasos Pasos

� Cm: Módulo principal◦ Coordina los módulos colocados en el primer nivel:

� Ce: Módulo controlador del procesamiento de la información de llegada al sistema

◦ Coordina la recepción de todos los datos que llegan

� Ct: Módulo controlador del centro de transformación◦ Supervisa todas las operaciones sobre los datos

� Cs: Módulo controlador del procesamiento de la información de salida al sistema

◦ Coordina la producción de la información de salida


Entrada Salida Transformación

Cm

Ce Ct Cs

1.1

2.1

1.2

2.2

34.1

4.2


Pasos Pasos –– Primer CortePrimer Corte

5. Realizar el primer corte del diagrama de estructuras

� Análisis de Transacción◦ Hay que convertir un flujo de transacción en

una estructura con una bifurcación de entrada y otra de salida

◦ Para la entrada se hace igual que el análisis de transformación

◦ Para la salida se añade un módulo controlador por cada camino de flujo de acción



Pasos Pasos –– Primer cortePrimer corte


Camino 3

Cm

Ce D

C1 C2 C3

A

D

R

P

Q

Camino 1Camino 2

a

z

b

Centro de Transacción

Centro de Transacción

Refleja la exclusividad de los diferentes caminos


Pasos Pasos –– Primer cortePrimer corte

6. Ejecución del segundo nivel de factorización◦ Análisis de Transformación

� Procesos DFD � Módulos del DE� Se empieza en el límite del centro de

transformación � Yendo hacia fuera a lo largo de los caminos de

llegada y salida, los procesos del DFD se convierten en módulos subordinados de la estructura del sistema

� Además se introducen módulos predefinidos que nos den las entradas y/o salidas que necesita y/o genera el sistema



Pasos Pasos ––SegundoSegundo nivelnivel

6. Ejecución del segundo nivel de factorización

� Análisis de Transformación


Entrada Salida

Transformación

Cm

Ce Ct Cs

1.1

2.1

1.2

2.2

3

4.1

4.2

1.2 2.2

2.11.1

3 4.1

4.2

escribir zleer a leer b

a

b z



6. Ejecución del segundo nivel de factorización

� Análisis de Transacción: Se desarrolla cada camino de acción dependiendo de su tipo de flujo


A

D

R

P

Q

Camino 1

Camino 3

Camino 2

Cm

Ce D

C1 C2 C3

P Q R

A

a

Leeraz

b

Leerb Escribirz

Flujo detransformación



7. Refinar la estructura del sistema utilizando medidas y guías de diseño◦ Se puede aumentar o disminuir el número de

módulos para producir una factorización lógica � De buena calidad� Con una estructura que se implemente sin dificultad� Que la estructura se pruebe sin confusión� Que la estructura se mantenga sin problemas

◦ Criterios� Consideraciones prácticas y de sentido común� Requisitos del software



Pasos Pasos –– Refinar la estructuraRefinar la estructura

� Ejemplo


Entrada Salida

Transformación

Cm

Ce Ct Cs

1.1

2.1

1.2

2.2

3

4.1

4.2

1.2 2.2

2.11.1

3 4.1

4.2

escribir zleer a leer b

a

b z



7. Refinar la estructura del sistema utilizando medidas y guías de diseño◦ Representar los parámetros de cada módulo� Datos� Flujos de información de los DFD� Representar como datos que se pasan entre módulos

� Flags� Descripciones de los procesos del DFD � Se refleja en el módulo correspondiente del diagrama de estructura cuando se necesita una variable de control




7. Refinar la estructura del sistema utilizando medidas y guías de diseño◦ Acceso a un almacén en el DFD� Módulos predefinidos colgando del módulo correspondiente (READ/WRITE)

◦ Reflejando el acceso a la BD en el DE se facilita la programación




8. Asegurarse del trabajo realizado por el diseño obtenido◦ Comprobar que la funcionalidad que realiza el

diseño creado es la correcta� Revisar que el orden de ejecución de los módulos sea

el correcto



Pasos Pasos –– VerificarVerificar

AnAnáálisis de Transformacilisis de Transformacióónn

EjemploEjemplo� Desarrollo de un sistema de información que apoye la gestión de

una Central de Compras (C.C.) que permita realizar pedidos globales por temporada (Reyes, acampadas de verano, etc.)

� El sistema, a partir del catálogo de los proveedores y el archivo histórico de ventas, obtiene el pedido global a partir de los pedidosindividuales (Pedido Rellenado).

� No obstante, la C.C puede modificar a la baja o al alza la cantidad solicitada por el almacén en función de algunos factores, como umbrales de descuento, etc. Entonces, se notificará al almacén el cambio en el pedido (Notificacion Pedido) y se comunica a todos los proveedores las cantidades definitivas de los distintos productos (Pedido Global).

� Se pide� Identificar las características general del flujo de datos (y el centro

de transformación o transacción correspondiente)� Generar el diagrama de estructuras



EjemploEjemplo


ALMACÉN

PROVEEDOR

0GESTIONARCENTRAL DECOMPRAS

PROVEEDOR

ALMACEN *

DOCUMENTOSALMACEN

CATALOGO

PEDIDO GLOBAL

NOTIFICACIÓNPEDIDO

1

SELECCIONARMEJORESOFERTAS

CATALOGO

MEJORES OFERTAS

2HACER

PEDIDOSSEGUN

OFERTAS

DOCUMENTOSALMACEN

PEDIDO GLOBAL

NOTIFICACIÓNPEDIDO

Documentos Almacén = Histórico de Ventas + Pedido RellenadoPedido Global = Notificación Pedido

Diccionario de Datos

Diagrama de Contexto

Diagrama de Sistema


EjemploEjemplo


2.1RECIBIR

HISTORICOVENTAS

HISTORICOVENTAS

HISTORICO

HISTORICOVENTASRECIBIDO

2.2RECIBIRPEDIDOS

RELLENADOS

PEDIDORELLENADO

PEDIDOS

PEDIDORELLENADORECIBIDO

1.1RECIBIR

CATALOGO

CATALOGO CATALOGOS

CATALOGORECIBIDO

2.3AJUSTARPEDIDOS

ALMACEN



1.2CALCULARMEJORESOFERTAS

CATALOGORECIBIDO

2.4HACERPEDIDOGLOBAL

MEJORESOFERTAS

PEDIDOSCORREGIDOS

CORREGIDO

CORREGIDO

MEJOROFERTA

MEJOROFERTA

PEDIDOGLOBAL

NOTIFICACIONPEDIDO

Diagrama de Nivel 2


EjemploEjemplo


2.1RECIBIR

HISTORICOVENTAS

HISTORICOVENTAS

HISTORICO


2.2RECIBIRPEDIDOS

RELLENADOS

PEDIDORELLENADO

PEDIDOS


1.1RECIBIR

CATALOGO

CATALOGO CATALOGOS

CATALOGORECIBIDO

2.3AJUSTARPEDIDOS

ALMACEN




CATALOGORECIBIDO


MEJORESOFERTAS

PEDIDOSCORREGIDOS

CORREGIDO

CORREGIDO

MEJOROFERTA

MEJOROFERTA

PEDIDOGLOBAL

NOTIFICACIONPEDIDO

Diagrama de Nivel 2

Centrode

Transformación


EjemploEjemplo


2.1RECIBIR

HISTORICOVENTAS

HISTORICOVENTAS

HISTORICO


2.2RECIBIRPEDIDOS

RELLENADOS

PEDIDORELLENADO

PEDIDOS


1.1RECIBIR

CATALOGO

CATALOGO CATALOGOS

CATALOGORECIBIDO

2.3AJUSTARPEDIDOS

ALMACEN




CATALOGORECIBIDO


MEJORESOFERTAS

PEDIDOSCORREGIDOS

CORREGIDO

CORREGIDO

MEJOROFERTA

MEJOROFERTA

PEDIDOGLOBAL

NOTIFICACIONPEDIDO

Diagrama de Nivel 2

Centrode

Transformación

(otra alternativa)


EjemploEjemplo


GestiónCentralCompras

RecibirDocumenta-

ciónAlmacen

RecibirHistóricoVentas

RecibirPedidos

Rellenados

LeerHistóricoVentas

LeerPedidos

Rellenados

RecibirCatálogo

LeerCatálogo

AjustarPedidosAlmacén

CalcularMejoresOfertas

HacerPedidoGlobal

ImprimirNotificaciónPedido

ImprimirPedidoGlobal

H_V P_R

H_V_RP_R_R Catálogo

P_R_R

H_V_R

C_RP_R_R

H_V_R C_R

Corre-gido M_O

M_OCorregido

NotificaciónPedido

PedidoGlobal

H_V = Historico_VentasH_V_R = Histórico_Ventas_RecibidoP_R = Pedido_RellenadoP_R_R = Pedido_Rellenado_RecibidoC_R = Catálogo RecibidoM_O = Mejores_Ofertas

Entrada

Centro deTransformación Salida


EjemploEjemplo� Añadimos los acceso a los almacenes de

datos


GestiónCentralCompras

RecibirDocumenta-

ciónAlmacen

RecibirHistóricoVentas

RecibirPedidos

Rellenados

LeerP_R

RecibirCatálogo

AjustarPedidosAlmacen

CalcularMejoresOfertas

HacerPedidoGlobal

ImprN_P

ImprP_G

H_V P_R

Cat

M_O

N_PP_G

LeerH_V

LeerCat

EscH

H_V_R

EscP

P_R_R

EscCat

C_R

LeerH

LeerCat

EscPCo

H_V_RP_R_R

Cgdo

LeerCat

E/LMO

C_R

M_O

LeerPCo

Cgdo


EjemploEjemplo


USUARIO USUARIOGESTIONARPISCINA

0

Carnet Entrada

SELEC.TIPO

CARNET1

TRATARESTUDIANTE

2

TRATARTRABAJADOR

3

Carnet

Carnet

Carnet

Entrada

Entrada

Estudiante

Trabajador

Diagrama de Contexto

Diagrama de Sistema


EjemploEjemplo


Diagrama de Nivel 2

SELEC.TIPO

CARNET1

COMPROBARCARNET

ESTUDIANTE2.1

Carnet

C-Est

C-Trab

EntradaTrabajador

COMPROBARCARNET

TRABAJADOR3.1

NUMERARTALON

ESTUDIANTE2.2

C-EstValid

NUMERARTALON

TRABAJADOR3.2

C-TrabValid

PREPARARENTRADA

ESTUDIANTE2.3

PREPARARENTRADA

TRABAJADOR3.3

EntradaEstudiante

Entrada

Entrada


EjemploEjemplo


Diagrama de Estructura- Primer Corte -

Carnet

C-Trab

Carnet

C-Est

GESTIONARTIPO ENTRADA

GESTIONAR

PISCINA

LEER CARNET

GESTIONARESTUDIANTE

GESTIONARTRABAJADOR

Centro deTransacción

Camino1

Camino2

Controlador de la Entrada

Módulo Principal


EjemploEjemplo


Diagrama de Estructura- Factorización -

GESTIONARESTUDIANTE

GESTIONARESTUDIANTE

COMPROBARCARNET

ESTUDIANTE

NUMERARTALON

ESTUDIANTEENTREGARENTRADA

IMPRIMIRENTRADA

Carnet_EstudianteEntrada_Estudiante

Entrada

EntradaEstudianteCarnet

Validado


EjemploEjemplo


Diagrama de Estructura- Factorización -

GESTIONARESTUDIANTE

GESTIONARESTUDIANTE

COMPROBARCARNET

ESTUDIANTE

NUMERARTALON

ESTUDIANTEENTREGARENTRADA

IMPRIMIRENTRADA

Entrada_Estudiante

Entrada

EntradaEstudianteCarnet

Validado

Carnet_Estudiante

LEERCarnet Est

Cada camino gestionasu propia entrada

ConclusionesConclusiones

� Principios del Diseño Estructurado◦ Descomposición de los módulos� Un módulo � Una función

◦ Jerarquía de Módulos� Niveles Superiores coordinan Niveles Inferiores

◦ Independencia de los Módulos ≈ Cajas Negras



� Estrategias de Diseño

� En función de la estructura inicial del DFD se pueden aplicar dos estrategias, NO excluyentes◦ Análisis de Transformación

◦ Análisis de Transacción



AnAnáálisis de Transformacilisis de Transformacióónn� Se puede distinguir◦ Flujo de Llegada o entrada◦ Flujo ó Centro de Transformación ◦ Flujo de Salida

� Pasos1. Identificar centro de

transformación2. 1º Nivel de Factorización

1. Controlador Entrada, Transf., Salida3. 2º Nivel de Factorización

1. Proceso � Módulo4. Revisar la estructura utilizando medidas y guías de

Diseño


1.1

2.1

1.2

2.2

34.1

4.2


AnAnáálisis de Transaccilisis de Transaccióónn� En función del flujo de llegada, determina la

elección de uno o más flujos de información� Pasos◦ Identificar Centro Transacción� proceso desde el que parten

los posibles caminos◦ Estructura con una

bifurcación de Entrada y otra de Salida◦ Factorizar cada camino� Transacción o Transformación◦ Refinar la estructura utilizando medidas y guías

de Diseño


BibliografBibliografííaa� Análisis y Diseño Detallado de Aplicaciones

Informáticas de Gestión. Piattini et al., RA-MA, 2003.

� Análisis Estructurado Moderno. Yourdon, Prentice-Hall, 1985

� Ingeniería del Software: un enfoque práctico. Pressman, McGraw-Hill, 2002

� Guía de técnicas y prácticas de Métrica v.3. http://www.csi.map.es/csi/metrica3/


Documents

Diana Marcela S ánchez F úquene · Índice El proceso de diseño Modelos de diseño. Diseño estructurado. Diagramas de estructura. Estrategias de diseño Análisis de transformaciones