Diana Marcela S ánchez F úquene · Índice El proceso de diseño Modelos de diseño. Diseño...
Transcript of Diana Marcela S ánchez F úquene · Índice El proceso de diseño Modelos de diseño. Diseño...
-
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
Ingeniería del Software de Gestión
-
Vista GeneralVista General
OrientaciOrientacióón a Objetosn a Objetos
Ingeniería del Software de Gestión
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?
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?
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
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?
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?
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
DiagramasDiagramasdede
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()
DiagramasDiagramasdede
ColaboraciColaboracióónn
DiagramasDiagramasdede
ColaboraciColaboracióónn
Modelo de ClasesModelo de Clasesdede
DiseDiseññooPatronesPatrones
DiagramaDiagramadede
ComponentesComponentes
DiagramaDiagramadede
DespliegueDespliegue
RequisitosRequisitos
AnAnáálisislisis
DiseDiseññoo
ImplementaciImplementacióónn
-
Ingeniería del Software de Gestión
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
DiagramaDiagramadede
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
Ingeniería del Software de Gestión
-
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
Ingeniería del Software de Gestión
-
DiseDiseñño Estructuradoo Estructurado
� 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
Ingeniería del Software de Gestión
-
DiseDiseñño Estructuradoo Estructurado
� 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
Ingeniería del Software de Gestión
-
Diagramas de Estructura de Diagramas de Estructura de Cuadros de ConstantineCuadros de Constantine
Ingeniería del Software de Gestión
� 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
Ingeniería del Software de Gestión
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
Ingeniería del Software de Gestión
-
Diagrama de EstructurasDiagrama de Estructuras
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
Ingeniería del Software de Gestión
-
Diagrama de EstructurasDiagrama de Estructuras
MMóódulosdulosRepresentación
Ingeniería del Software de Gestión
OBTENER DATOS
CLIENTES
MÓDULOIMPRIMIR
CHEQUE DE PAGO
MÓDULO PREDEFINIDO
1
CONECTOR
Almacenes de datos
Dispositivos físicos
NOMBRE
DISPOSITIVO
MÉTRICA
-
Diagrama de EstructurasDiagrama de Estructuras
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 �
Ingeniería del Software de Gestión
-
Diagrama de EstructurasDiagrama de Estructuras
MMóódulosdulosEsfuerzo requerido para desarrollar módulos
Ingeniería del Software de Gestión
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
Ingeniería del Software de Gestión
¿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
-
Diagrama de EstructurasDiagrama de Estructuras
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
Ingeniería del Software de Gestión
-
Diagrama de EstructurasDiagrama de Estructuras
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
Ingeniería del Software de Gestión
-
Diagrama de EstructurasDiagrama de Estructuras
ConexiConexióón entre mn entre móódulosdulos� Ejemplo menú Secretaría Virtual
Ingeniería del Software de Gestión
-
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)
Ingeniería del Software de Gestión
Datos
Correctos
NIF
-
Diagrama de Estructuras Diagrama de Estructuras
ComunicaciComunicacióón entre Mn entre Móódulosdulos� Diferencias entre Datos y Flags
Ingeniería del Software de Gestión
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)
Ingeniería del Software de Gestión
-
Tablas de InterfazTablas de Interfaz
� 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
Ingeniería del Software de Gestión
-
Tablas de InterfazTablas de Interfaz
� Tabla de nemotécnicos de la columna uso de la tabla de interfaz
Ingeniería del Software de Gestión
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
-
Tablas de InterfazTablas de Interfaz
� Ejemplo de Tabla de Interfaz
Ingeniería del Software de Gestión
MóduloParámetro
FormalEntrada Salida Uso
SignificadoParámetro
F(x, y) X SÍ NO PFecha-
Nacimiento
Y NO SÍ M Edad
-
Tablas de InterfazTablas de Interfaz
� Ejercicio: Realizar la tabla de interfaz para este caso
Ingeniería del Software de Gestión
LEER
PETICION
PRESTAMO
GESTIONAR
PETICIONES
PET_ACEPTADA
INFORME
PRESTAMO
PET_ACEPTADA
INFORMAR
PETICIONTRATAR
PETICION
CONSULTAR
STOCK
PET_PRESTAMOPET_RECHAZADA
RECHAZAR
PETICION
INFORME
PRESTAMO
-
Tablas de InterfazTablas de Interfaz
� Solución
Ingeniería del Software de Gestió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
Ingeniería del Software de Gestión
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
Ingeniería del Software de Gestión
-
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
AnAnáálisis de Transformacilisis de TransformacióónnFlujo de Transformación
Ingeniería del Software de Gestió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
-
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
AnAnáálisis de Transformacilisis de Transformacióón: ejemplon: ejemplo
Ingeniería del Software de Gestión
-
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
AnAnáálisis de Transaccilisis de TransaccióónnFlujo de Transacción
Ingeniería del Software de Gestió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
-
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
AnAnáálisis de Transaccilisis de Transaccióónn
Ingeniería del Software de Gestión
-
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
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
Ingeniería del Software de Gestión
-
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
Ingeniería del Software de Gestión
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
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
Ingeniería del Software de Gestión
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
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
Ingeniería del Software de Gestión
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
Pasos Pasos
-
Identificar Centro de Transformación Ejemplo
Ingeniería del Software de Gestión
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
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
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
Ingeniería del Software de Gestión
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
Pasos Pasos
-
Ingeniería del Software de Gestión
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
Parámetro deSeguimiento
Parámetro deDisparo
Curso Corriente
Ángulo deDirecionamiento
Coordenadasdel Objetivo
Detalle delDisparo
Terminalde Control Giroscópo
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
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
Pasos Pasos
-
Ingeniería del Software de Gestión
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
Parámetro deSeguimiento
Parámetro deDisparo
Curso Corriente
Ángulo deDirecionamiento
Coordenadasdel Objetivo
Detalle delDisparo
Terminalde Control Giroscópo
Timón
Misil
Direccionarel Barco
LocalizarObjetivo
AjustarCurso
DispararMísil
Inv. Op.Adecuada
Señal deControl
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
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
Ingeniería del Software de Gestión
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
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
Ingeniería del Software de Gestión
Entrada Salida Transformación
Cm
Ce Ct Cs
1.1
2.1
1.2
2.2
34.1
4.2
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
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
Ingeniería del Software de Gestión
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
Pasos Pasos –– Primer cortePrimer corte
-
Ingeniería del Software de Gestión
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
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
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
Ingeniería del Software de Gestión
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
Pasos Pasos ––SegundoSegundo nivelnivel
-
6. Ejecución del segundo nivel de factorización
� Análisis de Transformación
Ingeniería del Software de Gestió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
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
Pasos Pasos ––SegundoSegundo nivelnivel
-
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
Ingeniería del Software de Gestión
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
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
Pasos Pasos ––SegundoSegundo nivelnivel
-
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
Ingeniería del Software de Gestión
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
Pasos Pasos –– Refinar la estructuraRefinar la estructura
-
� Ejemplo
Ingeniería del Software de Gestió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
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
Pasos Pasos –– Refinar la estructuraRefinar la estructura
-
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
Ingeniería del Software de Gestión
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
Pasos Pasos –– Refinar la estructuraRefinar la estructura
-
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
Ingeniería del Software de Gestión
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
Pasos Pasos –– Refinar la estructuraRefinar la estructura
-
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
Ingeniería del Software de Gestión
Estrategias de DiseEstrategias de Diseñño Estructuradoo Estructurado
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
Ingeniería del Software de Gestión
-
AnAnáálisis de Transformacilisis de Transformacióónn
EjemploEjemplo
Ingeniería del Software de Gestión
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
-
AnAnáálisis de Transformacilisis de Transformacióónn
EjemploEjemplo
Ingeniería del Software de Gestión
2.1RECIBIR
HISTORICOVENTAS
HISTORICOVENTAS
HISTORICO
HISTORICOVENTASRECIBIDO
2.2RECIBIRPEDIDOS
RELLENADOS
PEDIDORELLENADO
PEDIDOS
PEDIDORELLENADORECIBIDO
1.1RECIBIR
CATALOGO
CATALOGO CATALOGOS
CATALOGORECIBIDO
2.3AJUSTARPEDIDOS
ALMACEN
HISTORICOVENTASRECIBIDO
PEDIDORELLENADORECIBIDO
1.2CALCULARMEJORESOFERTAS
CATALOGORECIBIDO
2.4HACERPEDIDOGLOBAL
MEJORESOFERTAS
PEDIDOSCORREGIDOS
CORREGIDO
CORREGIDO
MEJOROFERTA
MEJOROFERTA
PEDIDOGLOBAL
NOTIFICACIONPEDIDO
Diagrama de Nivel 2
-
AnAnáálisis de Transformacilisis de Transformacióónn
EjemploEjemplo
Ingeniería del Software de Gestión
2.1RECIBIR
HISTORICOVENTAS
HISTORICOVENTAS
HISTORICO
HISTORICOVENTASRECIBIDO
2.2RECIBIRPEDIDOS
RELLENADOS
PEDIDORELLENADO
PEDIDOS
PEDIDORELLENADORECIBIDO
1.1RECIBIR
CATALOGO
CATALOGO CATALOGOS
CATALOGORECIBIDO
2.3AJUSTARPEDIDOS
ALMACEN
HISTORICOVENTASRECIBIDO
PEDIDORELLENADORECIBIDO
1.2CALCULARMEJORESOFERTAS
CATALOGORECIBIDO
2.4HACERPEDIDOGLOBAL
MEJORESOFERTAS
PEDIDOSCORREGIDOS
CORREGIDO
CORREGIDO
MEJOROFERTA
MEJOROFERTA
PEDIDOGLOBAL
NOTIFICACIONPEDIDO
Diagrama de Nivel 2
Centrode
Transformación
-
AnAnáálisis de Transformacilisis de Transformacióónn
EjemploEjemplo
Ingeniería del Software de Gestión
2.1RECIBIR
HISTORICOVENTAS
HISTORICOVENTAS
HISTORICO
HISTORICOVENTASRECIBIDO
2.2RECIBIRPEDIDOS
RELLENADOS
PEDIDORELLENADO
PEDIDOS
PEDIDORELLENADORECIBIDO
1.1RECIBIR
CATALOGO
CATALOGO CATALOGOS
CATALOGORECIBIDO
2.3AJUSTARPEDIDOS
ALMACEN
HISTORICOVENTASRECIBIDO
PEDIDORELLENADORECIBIDO
1.2CALCULARMEJORESOFERTAS
CATALOGORECIBIDO
2.4HACERPEDIDOGLOBAL
MEJORESOFERTAS
PEDIDOSCORREGIDOS
CORREGIDO
CORREGIDO
MEJOROFERTA
MEJOROFERTA
PEDIDOGLOBAL
NOTIFICACIONPEDIDO
Diagrama de Nivel 2
Centrode
Transformación
(otra alternativa)
-
AnAnáálisis de Transformacilisis de Transformacióónn
EjemploEjemplo
Ingeniería del Software de Gestión
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
-
AnAnáálisis de Transformacilisis de Transformacióónn
EjemploEjemplo� Añadimos los acceso a los almacenes de
datos
Ingeniería del Software de Gestión
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
-
AnAnáálisis de Transaccilisis de Transaccióónn
EjemploEjemplo
Ingeniería del Software de Gestión
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
-
AnAnáálisis de Transaccilisis de Transaccióónn
EjemploEjemplo
Ingeniería del Software de Gestión
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
-
AnAnáálisis de Transaccilisis de Transaccióónn
EjemploEjemplo
Ingeniería del Software de Gestión
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
-
AnAnáálisis de Transaccilisis de Transaccióónn
EjemploEjemplo
Ingeniería del Software de Gestión
Diagrama de Estructura- Factorización -
GESTIONARESTUDIANTE
GESTIONARESTUDIANTE
COMPROBARCARNET
ESTUDIANTE
NUMERARTALON
ESTUDIANTEENTREGARENTRADA
IMPRIMIRENTRADA
Carnet_EstudianteEntrada_Estudiante
Entrada
EntradaEstudianteCarnet
Validado
-
AnAnáálisis de Transaccilisis de Transaccióónn
EjemploEjemplo
Ingeniería del Software de Gestión
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
Ingeniería del Software de Gestión
-
ConclusionesConclusiones
� 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
Ingeniería del Software de Gestión
-
ConclusionesConclusiones
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
Ingeniería del Software de Gestión
1.1
2.1
1.2
2.2
34.1
4.2
-
ConclusionesConclusiones
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
Ingeniería del Software de Gestión
-
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/
Ingeniería del Software de Gestión