Ingeniería del Software

Presentación del tema: "Ingeniería del Software"— Transcripción de la presentación:

1 Ingeniería del Software
Profesor: Juan Antonio López Quesada. Facultado de Informática. Tema 5. Diseño Estructurado Profesor: Juan Antonio López Quesada Diseño Estructurado

2 Diseño Estructurado El proceso de diseño Modelos de diseño.
Diagramas de estructura. Estrategias de diseño: Análisis de transformaciones. Análisis de transacciones. Profesor: Juan Antonio López Quesada Diseño Estructurado

3 Bibliografía (Piattini et al. 96) Capítulo 8. Apartado 8.1.
(Molina et al. 97) A. Molina, P. Letelier, P.Sánchez, J. Sánchez. “Metodología y Tecnología de la Programación”. Servicio de Publicaciones. UPV (Pressman 01) Capítulo 13 y aptdos a 14.8. (MAP 95) Ministerio de Administraciones Públicas. Guía de Técnicas de Métrica v (MAP 01) Guía de técnicas y prácticas de Métrica v.3. (Page-Jones 88) M. Page-Jones. “The Practical Guide to Structured Systems Design”. Yourdon Press Profesor: Juan Antonio López Quesada Diseño Estructurado

4 Diseño Estructurado: El Proceso de Diseño
“El 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. Fundamental: CALIDAD  sólo se puede conseguir a través de un proceso de diseño. Profesor: Juan Antonio López Quesada Diseño Estructurado

5 Diseño Estructurado: El Proceso de Diseño
ERS Análisis (Qué) Lenguaje comprensible por el usuario E-R DFD Diseño de alto nivel (arquitectónico) Enfoque funcional Organización lógica Enfoque de datos Arquitectura de procesos Estructura detallada: programas y módulos Modelo lógico de datos Modelo físico de datos Diseño (Cómo) Figura 8.1 (Piattini et al. 96) p.245. Diseño de bajo nivel (detallado) Decisiones concretas: organización y rendimiento Esquema de BD y ficheros Cuadernos de carga (Piattini et al. 96) Implementación Lenguaje comprensible por la máquina Profesor: Juan Antonio López Quesada Diseño Estructurado Codificación y pruebas

6 Diseño Estructurado: El Proceso de Diseño
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 Estructuras. Diseño de interfaz. Interfaces del sw. con otros sistemas y con los usuarios. Diseño procedimental. Descripción procedimental de los componentes del sw. La flecha simboliza que cada modelo se asienta en el anterior. Profesor: Juan Antonio López Quesada Diseño Estructurado

7 Diseño Estructurado Objetivos:
Desarrollar la estructura modular del programa. Definir las relaciones entre módulos. Técnica Principal: Diagrama de Estructura. Documentación de partida: DFDs – Análisis Estructurado. Estrategias de diseño - Tipos de Esquemas: Análisis de transformaciones Análisis de transacciones Otras técnicas que se utilizan en el diseño estructurado son el pseudo-código, árboles de decisión, etc. Profesor: Juan Antonio López Quesada Diseño Estructurado

8 Diseño 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. Durante el análisis del sistema se obtiene un conjunto de especificaciones funcionales que describen las entradas y salidas del sistema, las funciones descompuestas realizadas por el sistema, y el esquema lógico de datos. Esta información ha de estar almacenada en el diccionario de datos del proyecto, y es la documentación de partida para realizar el diseño. Profesor: Juan Antonio López Quesada Diseño Estructurado

9 Diseño estructurado Tareas a realizar:
Módulos obtenidos en el análisis. Procesos Terminales (primitivos). Organizar la estructura de estos módulos y definir las conexiones entre los mismos. Describir el pseudocódigo para cada módulo. Técnicas descritas en el Tema 3 III. Se basa en los siguiente Principios: Abstracción Modularidad Encapsulamiento y Ocultamiento de información No confundir con programación estructurada. Para construir el nuevo sistema es preciso convertir las especificaciones del análisis en especificaciones de programas. Se han de realizar las siguientes tareas: Determinar qué módulos implantarán los procesos terminales obtenidos en el análisis. Organizar la estructura de estos módulos y definir las conexiones entre los mismos. Describir el pseudo-código para cada módulo. Utilizaremos el diagrama de estructura de cuadros de Constantine, que permite definir cuándo, bajo qué condiciones y cuántas veces se tienen que realizar los tratamientos identificados en los procesos. El paso de la fase del análisis al diseño será más fácil si se ha llegado a un nivel de detalle muy bajo en los DFDs. A veces es preciso refinar los DFDs aún más: por ejemplo, supongamos que en la fase de análisis se ha obviado el proceso “validar entrada usuario”, que debería estar presente en el programa. El diagrama de estructura proporciona una visión de la arquitectura del sistema. Profesor: Juan Antonio López Quesada Diseño Estructurado

10 Diagrama de estructura. Elementos constituyentes :
Diseño Estructurado: Diagrama de estructura (Diagrama de estructura de cuadros de Constantine). Diseño de la Arquitectura del Sistema: Diagrama de módulos funcionales. 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 estructura. Elementos constituyentes : Módulos. Conexiones. Comunicaciones. (Molina et al. 97) El diagrama de estructura no representa aspectos procedurales del sistema como las secuencias, alternativas o bucles. Tampoco muestra detalles internos de los módulos como código, algoritmos o datos. Sin embargo, existe una notación, mostrada en (Piattini et al. 96), en la que se representa la secuencia, alternativas y bucles. En este capítulo vamos a ver ejemplos en las dos notaciones, aunque en los ejercicios utilizaremos la notación mostrada en (Piattini et al. 96). Profesor: Juan Antonio López Quesada Diseño Estructurado

11 Diseño Estructurado: Diagrama de estructura. Módulo.
“Aquella parte de código que se puede llamar”. (Page-Jones 88). 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. Tamaño ideal: líneas pero hay muchas opiniones! Se representa en el diagrama mediante un rectángulo. Ejemplos típicos de módulos serían una función en C o una función o procedimiento en Pascal. Profesor: Juan Antonio López Quesada Diseño Estructurado

12 En Métrica también se dispone de:
Diseño Estructurado: Diagrama de estructura. Representación de los Módulos. MODULO PREDEFINIDO MODULO CONECTOR OBTENER DATOS CLIENTES IMPRIMIR CHEQUE DE PAGO 1 En Métrica también se dispone de: Almacenes de datos NOMBRE Un módulo predefinido está disponible en la biblioteca del sistema o de la propia aplicación (a veces, puede ser también un módulo de un sistema operativo o de un SGBD), y por tanto, no es necesario codificarlo. En Métrica se pueden utilizar también: (a) almacenes de datos, que son módulos que representan dónde van a estar físicamente los datos (tablas, ficheros); (b) dispositivos físicos, que son dispositivos (de cualquier tipo) por donde se puede recibir o enviar información que necesite el sistema. Para no perder la referencia, el diagrama de estructura debe dibujarse en una hoja tamaño A4. Si no cabe (bien), se deben explosionar los elementos (como en System Architect) o poner conectores. Dispositivos físicos DISPOSITIVO Profesor: Juan Antonio López Quesada Diseño Estructurado

13 Diseño Estructurado: Diagrama de estructura. Conexión entre Módulos.
La conexión entre módulos se representa mediante una línea. En la figura: A llama a B. B hace su función. B retorna a A, inmediatamente después del lugar donde se produjo la llamada de A a B. El diagrama no dice nada sobre el código de A ni sobre el de B, lo único que sabe es que en A existe una sentencia del tipo CALL B. A MODULO QUE LLAMA CONEXION B MODULO LLAMADO Según (Molina et al. 97): en el diagrama no se conoce cuántas veces puede A invocar a B. Sólo se dice que A es capaz de invocar a B. Tal vez no realice ninguna invocación. Profesor: Juan Antonio López Quesada Diseño Estructurado

14 Diseño Estructurado: Diagrama de estructura. Conexión entre Módulos.
Estructura repetitiva A Estructura alternativa B C Orden de ejecución de los módulos: de izquierda a derecha y de arriba abajo (Piattini et al. 96).  Según (Molina et al. 97) el orden no importa. Profesor: Juan Antonio López Quesada Diseño Estructurado

15 Diseño Estructurado: Diagrama de estructura. Conexión entre Módulos.
Ejemplo típico de menú: Menú login Procesos para Agentes externos Procesos para departamentos Procesos Generales El diagrama de estructuras de una aplicación tiene típicamente una estructura similar a la mostrada en la figura: un conjunto de opciones de menú que se escogen cíclicamente por el usuario. Profesor: Juan Antonio López Quesada Diseño Estructurado

16 Los signos para llevar a cabo la comunicación entre módulos son:
Diseño Estructurado: Diagrama de estructura. Comunicación entre Módulos. Los signos para llevar a cabo la comunicación entre módulos son: Flags o controles Datos Profesor: Juan Antonio López Quesada Diseño Estructurado

17 Diseño Estructurado: Diagrama de estructura. Flags o controles.
Mediante los “flags” o controles, se puede representar: Paso de control entre módulos: un módulo comunica a otro módulo que ha terminado su proceso y traspasa al módulo llamado el control del sistema. Comunicación de que se ha producido un error en el proceso. Comunicación de que se puede proceder a una operación concreta. Profesor: Juan Antonio López Quesada Diseño Estructurado

18 Diseño Estructurado: Diagrama de estructura
Diseño Estructurado: Diagrama de estructura. Diferencias entre Comunicadores. 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 tienen importancia para el mundo exterior, están relacionados con el problema. 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. Los flags en sentido descendente no son deseables porque como veremos dan lugar a un acoplamiento de control no deseable. Exigiendo que los flags tengan un sentido ascendente, se pretende que los módulos de arriba sean los que coordinan, los de abajo realizan el trabajo y señalan la condiciones anormales o de terminación, y los módulos intermedios hacen un poco de trabajo y un poco de tareas de coordinación. Pregunta: en C se pueden pasar funciones como parámetro: ¿sería un dato o un control? Aunque en muchas ocasiones, por simplicidad, los flags o controles no se muestran en los diagramas, nosotros sí los mostraremos en los ejercicios que hagamos. Profesor: Juan Antonio López Quesada Diseño Estructurado

19 Diseño Estructurado: Diagrama de estructura. Parámetros.
Se pueden representar mediante tablas de interfaz. Módulo Parámetro formal Entrada Salida Uso Significado F(x,y) x Sí No P Fecha nacimiento y M Edad (Piattini et al. 96) p. 250. Uso: P  procesado M  modificado (...) Profesor: Juan Antonio López Quesada Diseño Estructurado

20 Diseño Estructurado: Diagrama de estructura. Ejemplo.
El diagrama de estructura no tiene que ser necesariamente un árbol. Profesor: Juan Antonio López Quesada Diseño Estructurado

21 Diseño Estructurado: Diagrama de estructura. Ejemplo.
Jerarquía Iterativa CONSEGUIR ENTERO VÁLIDO LEER ENTERO DE FICHERO VALIDAR ENTERO ENTERO ENTERO VÁLIDO FIN DE FICHERO Cuerpo del Bucle EL ENTERO ES VÁLIDO “CONSEGUIR ENTERO VÁLIDO”: ... LEER_ENTERO( fin_fichero, entero ) ; if VALIDAR_ENTERO( entero ) then ... FIN DE FICHERO Profesor: Juan Antonio López Quesada Diseño Estructurado

22 Diseño Estructurado: Diagrama de estructura. Ejemplo I.
Profesor: Juan Antonio López Quesada Diseño Estructurado

23 Diseño Estructurado: Diagrama de estructura. Ejemplo II.
program EMISION_CHEQUES ; type treg_pago : RECORD...END ; treg_jornalero : RECORD...END ; treg_empleado : RECORD...END ; var importe : real ; importe_pago_jorn, importe_pago_empl : real ; registro_pago : treg_pago ; registro_empleado : treg_empleado ; registro_jornalero : treg_jornalero ; fin_registros : boolean ; numero_empleado : integer ; nombre_empleado : string ; begin OBTENER_REGISTRO_PAGO (registro_pago, fin_registros) ; ... importe_pago_jorn := CALCULAR_NETO_JORN (registro_jornalero) ; importe_pago_empl := CALCULAR_NETO_EMPL (registro_empleado) ; IMPRIMIR_CHEQUE_PAGO( numero_empleado, nombre_empleado, importe) ; end. procedure OBTENER_REG_PAGO ( var rp : treg_pago; var fin_reg : boolean ) ; function CALCULAR_NETO_JORN ( rj : treg_jornalero ) : real ; function CALCULAR_NETO_EMPL ( re : treg_empleado ) : real ; function CALCULAR_BRUTO_JORN ( ret_diaria, jorn_trab : real ) : real ; function CALCULAR_BRUTO_EMPL ( sueldo_base, complem : real ) : real ; function CALCULAR_DEDUCCIONES ( pago_bruto, irpf : real ) : real ; procedure IMPRIMIR_CHEQUE_PAGO( num_emp : integer ; nom_emp : string; importe : real ) ; Profesor: Juan Antonio López Quesada Diseño Estructurado

24 Interfaz-función (módulo, entradas, salidas, función). Pseudo-código.
Diseño Estructurado: Diagrama de estructura. Especificación de Módulos. Interfaz-función (módulo, entradas, salidas, función). Pseudo-código. Más preciso que el usado en análisis Deja cierto grado de libertad al programador No trata aspectos de eficiencia, a menos que estén directamente relacionados con requisitos Permite verificar la calidad del diseño Herramientas complementarias: Diagramas de flujo Nassi-Schneiderman Tablas y árboles de decisión Profesor: Juan Antonio López Quesada Diseño Estructurado

25 Diseño Estructurado: Estrategias de Diseño.
Pasos generales a seguir para obtener un buen diseño a partir de un DFD de procesos primitivos A veces hay que refinar el DFD de partida. Dos estrategias: Análisis de transformaciones. Análisis de transacciones. Importante: diseñar el DE de forma que: Los módulos de nivel superior toman las decisiones de ejecución (coordinan). Los de nivel inferior realizan la mayor parte del trabajo de entrada, de cálculo y de salida. Profesor: Juan Antonio López Quesada Diseño Estructurado

26 Diseño Estructurado: Estrategias de Diseño.
Revisar el modelo fundamental del sistema DFD procesos primitivos no hace falta “crear” el DFD de procesos primitivos se añaden procesos, si hace falta recomendado, como mínimo, tener 3 niveles de profundidad Determinar si el DFD tiene características de transformación o de transacción. indica expresamente la característica del DFD! Profesor: Juan Antonio López Quesada Diseño Estructurado

27 Diseño Estructurado: Estrategias de Diseño.
Según sea de transformación o transacción: Aislar el centro de la transformación, especificando los límites del flujo de llegada y de salida ...o bien... b) Identificar el centro de la transacción y las características del flujo de cada camino de acción. indica expresamente los elementos anteriores! Profesor: Juan Antonio López Quesada Diseño Estructurado

28 Diseño Estructurado: Estrategias de Diseño.
Realizar el primer corte del diagrama de estructuras. Realizar el segundo nivel de factorización. Refinar la estructura del programa. Asegurarse del trabajo realizado por el diseño obtenido. Profesor: Juan Antonio López Quesada Diseño Estructurado

29 Diseño Estructurado: Análisis de Transformación.
Profesor: Juan Antonio López Quesada Diseño Estructurado

30 Diseño Estructurado: Análisis de Transformación
Diseño Estructurado: Análisis de Transformación. 1º Nivel de Factorización. Profesor: Juan Antonio López Quesada Diseño Estructurado

31 Diseño Estructurado: Análisis de Transformación
Diseño Estructurado: Análisis de Transformación. 2º Nivel de Factorización. Profesor: Juan Antonio López Quesada Diseño Estructurado

32 Diseño Estructurado: Análisis de Transacción.
Importante: son transacciones (caminos) independientes. Tener en cuenta que este esquema tan claro está muy idealizado: normalmente, en los DFDs no está presente de forma explícita el centro de transacción. Profesor: Juan Antonio López Quesada Diseño Estructurado

33 Diseño Estructurado: Análisis de Transacción. 1º Nivel de Factorización.
Profesor: Juan Antonio López Quesada Diseño Estructurado

34 Diseño Estructurado: Análisis de Transacción. 2º Nivel de Factorización.
Profesor: Juan Antonio López Quesada Diseño Estructurado

35 Diseño Estructurado: Análisis de Transformación. Ejemplo.
Guía de técnicas de Métrica 2.1, pp.144. Profesor: Juan Antonio López Quesada Diseño Estructurado

36 Diseño Estructurado: Análisis de Transformación. Ejemplo.
Profesor: Juan Antonio López Quesada Diseño Estructurado

37 Diseño Estructurado: Análisis de Transacción. Ejemplo.
Guía de técnicas de Métrica 2.1, p.148. Profesor: Juan Antonio López Quesada Diseño Estructurado

38 Diseño Estructurado: Análisis de Transacción. Ejemplo.
¿Es bueno de cara a la reutilización que “Actualizar archivo R (S, T)” haga uso de “imprimir modificaciones”? Profesor: Juan Antonio López Quesada Diseño Estructurado

39 Normalmente el esquema de transacción no es tan claro:
Diseño Estructurado: Centros de Transacción. Normalmente el esquema de transacción no es tan claro: el proceso de transacción no aparece explícitamente en el DFD  solución: examinar el diagrama de contexto y la lista de eventos para determinar los tipos de transacciones en el sistema Profesor: Juan Antonio López Quesada Diseño Estructurado

40 Diseño Estructurado: Análisis de Transacción. Ejemplo.
(Molina et al. 97) p.172 ... Seleccione la opción deseada: Realizar venta Realizar devolución Admitir pago Profesor: Juan Antonio López Quesada Diseño Estructurado