Tema 3.4 Métodos convencionales de especificación y diseño ¿Qué es un método? Lección 3.4.1 Métodos estructurados 1. Pro

1. Tema 3.4 Métodos convencionales de especificación y diseño ¿Qué es un método? Lección 3.4.1 Métodos estructurados 1. Proceso de especificación y diseño 2. SSA 3. SSD: carta de estructura 4. SSD: proceso de diseño 5. Conclusiones Lección 3.4.2 Métodos orientados a objetos 1. Breve historia de UML 2. Herramientas de UML 3. El proceso UML 4. De los casos de usos al diagrama de clases 5. Diseño 4. Comparación con los métodos estructurados Dpto. LSI - Universidad de Granada

2. Concepto de método • Método = (concepción del mundo + herramientas de representación) + heurísticas + reglas de transformación y verificación + proceso de aplicación • El PROCESO es fundamental. • INGENI(o)ERIA Dpto. LSI - Universidad de Granada

3. Métodos estructurados: proceso • ANALISIS: • SSA: Structured System Analysis (De Marco) • DISEÑO: • SSD: Structured System Design (Constantine, Yourdon) Dpto. LSI - Universidad de Granada

4. SSA: proceso 1. Modelo físico actual Estudio del entorno actual Nombres y particiones que utiliza el usuario 2. Modelo lógico actual Derivar el equivalente lógico: eliminar componente físicos Normalizar los datos (por ej. M.E-R) 3. Modelo lógico nuevo Cambios en el sistema actual 4. Modelo físico nuevo ¿Qué se va a automatizar? Varias alternativas Estudio de viabilidad Dpto. LSI - Universidad de Granada

5. SSA: proceso • Muy ligado al ciclo de vida de las fases. • Estudio de viabilidad tardío. • Dificultad de establecer un contrato en estadíos iniciales. • Verificación y validación continua con el usuario Dpto. LSI - Universidad de Granada

6. SSA  SSD • DFD  CARTA DE ESTRUCTURA. • Pasar del flujo de datos a una estructura de programa. • Se obtiene un programa en el que los módulos representan los procesos del sistema. • Orientación procedimental, arquitectura modular. Dpto. LSI - Universidad de Granada

7. Carta de estructura • Representa la estructura modular de un programa. • Relación jerárquica entre módulos. • No indica orden de ejecución • Elementos: • Módulos y sus relaciones • Transferencias entre módulos • Detalles adicionales: procedimentales, léxicos. Dpto. LSI - Universidad de Granada

8. Transferencia de control Transferencia de datos Recibir muestra Transferencia de datos y control NumCliente, NumAnimal NumCliente NumAnimal Conexiones patológicas Comprobar animal Comprobar cliente Alta muestra NumAnimal NumCliente Referencia a datos Alta cliente Alta animal Dpto. LSI - Universidad de Granada

9. Tipos de módulos (I) • Según el flujo de datos: • Aferentes: transfiere información desde los módulos inferiores a los superiores. • Eferentes: transfiere información desde los módulos superiores a los inferiores. • De transformación: transforma datos. • Coordinación: Coordina y gestiona otros módulos • Según su función: • Ejecutivos: llaman a módulos subordinados y realizan las decisiones del sistema. • Atómicos: realizan trabajos concretos. Dpto. LSI - Universidad de Granada

10. Tipos de módulos (II) • Según las conexiones: • Mínimamente conectados: transmisión de datos y control a través de parámetros. Un solo punto de entrada la módulo. • Normalmente conectados: varios puntos de entrada (baja cohesión) • Patológicamente conectados: transferencias de control al interior o datos globales. Dpto. LSI - Universidad de Granada

11. Carta de estructura: morfología ANCHURA PROFUNDIDAD FAN-OUT (abanico de salida) : número de módulos subordinados a otro FAN-IN (abanico de entrada) : número de módulos que llaman a un mismo subordinado Dpto. LSI - Universidad de Granada

12. SSD: proceso de diseño • Revisión y refinamiento del DFD • Determinar el tipo de flujo en el DFD • Convertir en una carta de estructura • Factorizar • Refinar con principios de diseño: acoplamiento, cohesión • Optimizar Dpto. LSI - Universidad de Granada

13. Entrada Transformación Salida Centro de transacción Lee acción Acción 3 Acción 1 Acción 2 DFD  CARTA E. • Flujo de transformación • Entrada-Proceso-Salida • Flujo de transacción • Entrada-Decisión-Activación de módulos Dpto. LSI - Universidad de Granada

14. Métodos estructurados: conclusiones • Estructura modular basada en un paradigma de programación estructurado. • Centrado en el procesamiento de información. • Los objetos de datos aparecen dispersos a lo largo del procesamiento. Dpto. LSI - Universidad de Granada

15. Historia de UML 2001 2000 1999 1998 Nov . 1997 UML 2.0 UML 1.4 UML 1.3 UML 1.2 UML aprobado por el OMG Dpto. LSI - Universidad de Granada

16. ¿Qué es UML? • UML = Unified Modeling Language • UML combina: • Modelado de Datos (Diagramas Entidad-Relación). • Modelado de Flujo de Trabajo (Work flow). • Modelado de Objetos. • Modelado de Componentes. • Es un lenguaje estándar OO para especificar, construir y documentar sistemas software. • Se puede utilizar en todos los procesos. Dpto. LSI - Universidad de Granada

17. Herramientas de UML • Diagrama de clases y objetos (E) • Diagrama de casos de uso (E) • Diagramas de secuencia y colaboración (D) • Diagramas de estados (D) • Diagrama de actividades (D) • Diagrama de componentes (E) • Diagramas de despliegue (E) Dpto. LSI - Universidad de Granada

18. Proceso de desarrollo recursivo-paralelo 1) Especificar para aislar las clases más importantes y sus conexiones. 2) Pequeño diseño para determinar cómo implementar las clases y sus conexiones. 3) Extraer clases reutilizables de una librería y construir un prototipo burdo. 4) Probar el prototipo para descubrir errores. 5) Evaluar el prototipo con el usuario. 6) Modificar la especificación con TODO lo aprendido. 7) Refinar el diseño para acomodar los cambios. 8)Diseñar e implementar las clases especiales (no disponibles en las bibliotecas). 9)Realizar un nuevo prototipo con clases de biblioteca y las nuevas clases creadas. 10) IR A 4. Dpto. LSI - Universidad de Granada

19. Planificación Especificación Diseño Modelado y diseño inicial Revisión y refinamiento Especificación Diseño Especificación Diseño IT 1 Revisión y refinamiento Planificación Especificación Diseño Extraer clases reutilizables Prototipo Prueba Evaluación usuario IT n Revisión y refinamiento Planificación Especificación Diseño Extraer clases reutilizables Prototipo Prueba Evaluación usuario • Iteratividad. • Reutilización. • DISEÑO y ESPECIFICACIÓN no son absolutamente independientes. Dpto. LSI - Universidad de Granada

20. Proceso iterativo simplificado de modelado y diseño 1. Identificación y delimitación del sistema 2. Modelado del sistema 3. Diseño e implementación del sistema Dpto. LSI - Universidad de Granada

21. 1. Identificación y delimitación del sistema • 1.1. Actividad del sistema • Uso del sistema: Casos de uso. • Operaciones del sistema: Diagramas de secuencia. • 1.2. Principales clases y sus relaciones Dpto. LSI - Universidad de Granada

22. 2. Modelado del sistema • 2.1. Modelado (estático) de clases y relaciones: Diagrama de clases y de objetos • 2.2. Modelado del comportamiento externo de las clases: Contratos y diagramas de colaboración • 2.3. Modelado del comportamiento interno de las clases: Diagramas de transición de estados Dpto. LSI - Universidad de Granada

23. 3. Diseño e implementación • Tomar decisiones de diseño y determinar las transformaciones introducidas en los anteriores diagramas por estas decisiones. • Implementación del diseño. Dpto. LSI - Universidad de Granada

24. De los casos de uso al diagrama de clases • Clases: • A partir de los sustantivos relevantes de los casos de uso y documentos del usuario • Atributos • Relaciones: • A partir de los verbos relevantes Dpto. LSI - Universidad de Granada

25. Clases: categorías Dpto. LSI - Universidad de Granada

26. Clases: sustantivos • No hay correspondencia mecánica entre sustantivo y concepto. • El lenguaje natural puede ser ambiguo. • Ejemplo: Este caso de uso comienza cuando un cliente llega a una caja de TPDV con productos que desea comprar. El cajero registra el código universal de producto (CUP) en cada producto. Si el producto se repite, el cajero también puede introducir la cantidad. Dpto. LSI - Universidad de Granada

27. Relaciones entre clases (Las relaciones más importantes en negrita) Dpto. LSI - Universidad de Granada

28. Atributos • De los casos de uso, especificaciones, catálogos, ... se pueden descubrir algunos atributos. El cajero registra el código universal de producto (CUP) en cada producto. Si el producto se repite, el cajero también puede introducir la cantidad. • Otros se detectan en fases posteriores. Dpto. LSI - Universidad de Granada

29. Diseño en UML • Los mismos conceptos que en el modelado • Se determina la arquitectura del software • Se introducen las clases que serán necesarias para la implementación: • Clases contenedoras • Clases especiales para implementar: formularios, gestores de eventos, interfaces con bases de datos,... Dpto. LSI - Universidad de Granada

30. M. Estructurados  M.O. ObjetosPreguntas “curiosas” • ¿Cómo podemos caracterizar un sistema software para que se pueda someter a un proceso de Ingeniería del Software? • ¿Dónde empieza y acaba el sistema? • ¿Cuáles son los elementos relevantes ? • ¿Cómo se relacionan entre sí estos elementos? • ¿Cómo se comportan los elementos en el contexto del sistema? Dpto. LSI - Universidad de Granada

31. Respuestas “curiosas” Dpto. LSI - Universidad de Granada

32. M.E.: Diagrama de contexto ‘Denegasión’Sistemática Garrafón Clientela Banco Pub La Tahà (‘Ese peaso’ de SISTEMA) ¿otroPréstamo? ‘Declarasión’DeDeudas Güiski ‘Hasienda’ Probebedores ‘Recaudasión’Ejecutiva NiUnDuro Dpto. LSI - Universidad de Granada

33. ‘ArrellenarPelas’ Tele Tahà Syber Pub ‘DameArgo’ Jefaso LasPelasAntes ‘ArrellenarGarrafón’ Camata M.O-O.: Contexto de uso • Delimitar a partir del uso: • Por personas, si el sistema es interactivo. • Por máquinas, si el sistema controla procesos. • Por otros programas, si el sistema coordina y controla aplicaciones. ClienteColgao Dpto. LSI - Universidad de Granada