UN EJEMPLO: EL PROCESO UNIFICADO DE DESARROLLO (1ª parte)

Transcripción

1 UN EJEMPLO: EL PROCESO UNIFICADO DE DESARROLLO (1ª parte) The unified software development process, Ivar Jacobson, Grade Booch, James Rumbaug, Ed. Addison Wesley, 1999 El proceso unificado de desarrollo, Ivar Jacobson, Grade Booch, James Rumbaug, Ed. Addison Wesley, 1999 Ingeniería del Software 1

2 Un ejemplo: el Proceso Unificado Características del Proceso Unificado Flujos de trabajo fundamentales Iteración genérica Planificar Gestionar los riesgos Recursos Evaluar Ingeniería del Software 2

3 Un ejemplo: el Proceso Unificado Características del Proceso Unificado UML Basado en casos de uso Centrado en la arquitectura Iterativo-Incremental Modelos del proceso Flujos de trabajo fundamentales Iteración genérica Planificar Gestionar los riesgos Recursos Evaluar Ingeniería del Software 3

4 El Proceso Unificado (UP) Unificación de tres metodologías de desarrollo basadas en el paradigma orientado a objetos. OOSE: Object Oriented Software Engineering (Casos de Uso) Jacobson, I. Booch (Diseño) Booch, G. OMT: Object Modeling Technique (Análisis) Rumbaugh, J. Ingeniería del Software 4

5 El Proceso Unificado (UP) Es más que un proceso de desarrollo software un marco de trabajo que puede especializarse Basado en componentes conectados a través de interfaces Utiliza UML - Unified Modeling Language Dirigido por casos de uso Centrado en la arquitectura Iterativo e incremental Ingeniería del Software 5

6 UML UML es un lenguaje de modelado Permite la construcción de distintos modelos Diagramas de Clase, Diagramas de Casos de Uso, etc. Es autodescriptivo porque puede especificarse por medio de un diagrama de clases de UML. Bloques de construcción: Elementos: bloques básicos Relaciones: ligan los elementos Diagramas: agrupan colecciones de elementos ligados, aportando un significado adicional Ingeniería del Software 6

7 UML - Elementos y relaciones Elementos: Estructurales: Clases, Casos de Uso, Comportamiento: Interacción, Estados... Agrupación: Paquetes Anotación: Notas Relaciones: Dependencia (Relación de Uso) Asociación (Relación estructural) Generalización (Representación de la herencia.) Realización Ingeniería del Software 7

8 UML - Diagramas Ofrecen distintas perspectivas de una abstracción de la realidad Un mismo elemento puede aparecer en distintos diagramas En el modelo de un sistema no hay motivo para que aparezcan obligatoriamente todos los elementos. Estáticos(estructura) D. de Clases D. de Objetos D. de Componentes D. de Despliegue Dinámicos(comportamiento) Casos de Uso Secuencia Colaboración Estados Actividades Interacción Ingeniería del Software 8

9 Diagrama de clases Motor Piloto Vendedor de billetes Avión * 1 * Vuelo 1 * * Reserva { disjunta, completa } * Avión militar Avión comercial 1 Línea aérea { disjunta, completa } Avión de carga Avión de pasajeros Ingeniería del Software 9

10 Diagramas de Componentes Interfaz de Terminal Comment Control y Análisis Comment Gestión de Cuentas Comment Rutinas de Coneccion Comment Acceso a BD Comment Ingeniería del Software 10

11 Diagramas de Despliegue Servidor Central Acceso a BD Control y Análisis Comment Comment Rutinas de Coneccion Comment Terminal de Consulta Rutinas de Coneccion Comment Interfaz de Terminal Comment Punto de Venta Rutinas de Coneccion Comment Gestión de Cuentas Comment Interfaz de Terminal Comment Ingeniería del Software 11

12 Diagrama de casos de uso V enta Normal Cliente Venta en Rebajas Vendedor V enta en Oferta Ingeniería del Software 12

13 Diagrama de estados Esperando t arjeta tarjeta int ro ducida Leyendo tarjeta Esperando PIN Recogiendo tarjeta [ > 3 intentos ] PIN introducido( PIN ) Validando PIN [ correcto ] [ incorrec to ] Es perando opción Ingre sando ingreso( importe ) transferencia( cuenta, importe ) reintegro( importe ) Transferencia Reintegrando [ Not OK ] [ OK ] Expulsando dinero dinero retirado Expulsar Ingeniería del Software tarjeta 13

14 Diagrama de colaboración 5: cuenta dest ino 3: cantidad 1: transferencia 6: t rans ferencia (cuenta, cantidad) 11: OK : Cliente del banco : Interfaz de cajero : Transacción 2: teclee cant idad 4: teclee cuenta destino 12: transferencia realizada 8: OK 7: reintegro (cantidad) 9: ingreso (cantidad) 10: OK c uentaorigen : Cuenta c uentades tino : Cuenta Ingeniería del Software 14

15 Diagramas de Secuencia : Socio : Encargado : Libro : Ficha socio : Ficha libro : Préstamo Coger libro Solicitar préstam o Verificar situación socio Sit uación socio ok Verificar situación libro Situación libro ok Introducir préstamo Aut orizar prést amo Ingeniería del Software 15

16 Diagramas de actividad Pasajero Vendedor Airline Solicitar pasaje Verificar existencia vuelo Dar detalles vuelo Seleccionar vuelo Informar alternativas y precios Solicitar pago Reservar plazas Pagar pasaje Confirmar plaza reservada Emitir billete Ingeniería del Software 16

17 Dirigido por casos de uso Usuario: alguien o algo. Una interacción con el usuario es un caso de uso. Un caso de uso: Es una función del sistema que da al usuario un resultado útil. Captura los requisitos funcionales. Qué debe hacer el sistema para cada usuario? Modelo de casos de uso. Conducen el proceso de desarrollo: Modelos de diseño e implementación. Pruebas. Se desarrollan y evolucionan junto a la arquitectura del sistema. Ingeniería del Software 17

18 Centrado en la arquitectura Edificio: estructura, servicios, electricidad, fontanería,... Agrupa aspectos estructurales y dinámicos significativos Influencias: plataforma (BBDD, SO, protocolo de comunicación,...), aspectos legales, componentes reusables disponibles, requisitos no funcionales,... Es una vista del diseño completo que hace visibles las características principales. Cómo se relacionan casos de uso y arquitectura? Función y forma Ingeniería del Software 18

19 Centrado en la arquitectura Tareas: Crear una arquitectura inicial no específica de los casos de uso. Trabajar con un conjunto seleccionado de casos de uso que representan las tareas clave del sistema. Caso de uso - subsistemas, clases y componentes. Evolución. Ingeniería del Software 19

20 Iterativo - Incremental División del proyecto. Una iteración produce un incremento. Iteraciones controladas. Factores para la selección en una iteración: La iteración trata un grupo de casos que extienden la funcionalidad. La iteración trata los riesgos más importantes. Incremento no siempre es aditivo. Cada iteración: casos relevantes-diseño quiado por arquitecturaimplementar-verificar Beneficios. Ingeniería del Software 20

21 Iterativo - Incremental Varios ciclos que concluyen con un producto. Código fuente, manuales y documentos. Hitos por fases (Milestones) Ingeniería del Software 21

22 El proceso Papeles y actividades Analista de Sistemas Descubre Actores y Casos de Uso Estructura Modelo de Casos de Uso Planifica Test Diseña Test Evalua Test Ingeniero de pruebas Especifica Casos de Uso Detalla un Caso de Uso Integra Sistema Integrador de Sistemas Diseñador de Interface de Usuario Prototipo del Interfaz de Usuario Ejecuta Test de Integración Ingeniero de pruebas de integración Arquitecto Prioriza Casos de Uso Análisis de Arquitectura Diseño de Arquitectura Implementación de Arquitectura Ingeniero de Ejecuta test pruebas de del sistema sistema Ingeniero de Casos de Uso Analiza un Caso de Uso Diseña un Caso de Uso Ingeniero de Componentes Analiza una Clase Analiza un Paquete Diseña una clase Diseña un Subsistema Implementa Subsistema Implementa una clase Ejecuta Test Unitario Implementa Test Ingeniería del Software 22

23 El proceso El producto (salidas) # # $ %! #! # % #! & # & '(& " #! ) Ingeniería del Software 23

24 El proceso Fases, iteraciones y actividades, -. * $ * $++ " # # / / / 0 / 1 / 2 / 3 / 4 '$ ( Ingeniería del Software 24

25 El proceso Fases, iteraciones y actividades Una Fase es un intervalo de tiempo entre dos hitos importantes del proceso donde: Se cumple un conjunto definido de objetivos Se completan artefactos Se toman decisiones de continuar o no Iniciación, Elaboración, Construcción, Transición Dentro de cada fase hay varias iteraciones Una iteración representa un ciclo de desarrollo completo. El énfasis en cada flujo de trabajo es diferente dependiendo de la fase Ingeniería del Software 25

26 El proceso Fases, iteraciones y actividades Ingeniería del Software 26

27 Un ejemplo: el Proceso Unificado Características del Proceso Unificado Flujos de trabajo fundamentales Requisitos Análisis Diseño Implementación Pruebas Iteración genérica Planificar Gestionar los riesgos Recursos Evaluar Ingeniería del Software 27

28 Captura de requisitos La captura de requisitos es complicada Creamos código para otros Los usuarios no los conocen y les cuesta especificarlos de forma precisa Suelen ser varios usuarios sin una visión global Los requisitos cambian Las condiciones en las que se especifico un requisito varian Ingeniería del Software 28

29 Captura de requisitos Objetivo: guiar el desarrollo hacia el sistema correcto El cliente debe ser capaz de leer y comprender el resultado de la captura El resultado ayuda al jefe de proyecto a planificar las iteraciones y los recursos Usuarios muy diferentes Puntos de partida Diferentes Se deben reducir los riesgos Ingeniería del Software 29

30 Captura de requisitos Pasos a seguir Enumerar los requisitos candidatos Comprender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales Se realizan de forma conjunta Ingeniería del Software 30

31 Captura de requisitos TAREA Enumerar requisitos candidatos Entender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales PRODUCTOS (artifact) Lista de características Modelo de negocio o de dominio Modelo de casos de uso Requisitos suplementarios o casos individuales Ingeniería del Software 31

32 Artefactos de requisitos Modelo de casos de uso Actores Casos de uso Varios diagramas para diferentes perspectivas Descripción de la arquitectura Glosario Prototipo de la interfaz de usuario 1 Modelo de casos de uso Sistema de casos de uso * * Caso de uso Ingeniería del Software 32 $

33 Artefactos de requisitos Ingeniería del Software 33

34 Flujo de trabajo de la captura de requisitos funcionales (Actividades) Ingeniería del Software 34

35 Flujo de trabajo de la captura de requisitos funcionales (Actividades) Encontrar actores y casos de uso! " #$ Ingeniería del Software 35

36 Flujo de trabajo de la captura de requisitos funcionales (Actividades) Priorizar casos de uso! % Ingeniería del Software 36

37 Flujo de trabajo de la captura de requisitos funcionales (Actividades) Detallar un caso de uso! Ingeniería del Software 37

38 Flujo de trabajo de la captura de requisitos funcionales (Actividades) Prototipar la interfaz de usuario! Ingeniería del Software 38

39 Flujo de trabajo de la captura de requisitos funcionales (Actividades) Estructurar el modelo de casos de uso! Ingeniería del Software 39

40 Caso de uso Validar usuario Flujo de eventos ACCIÓN DEL ACTOR 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero 3. Introduce la clave RESPUESTA DEL SISTEMA 2. Pide la clave de identificación 4. Comprueba la clave 5. Si es válida presenta las opciones disponibles y se termina el caso de uso CAMINOS ALTERNATIVOS Línea 3. El cliente cancela la transacción Línea 4. La clave no es válida y se reinicia el caso de uso. Si ocurre tres veces se cancela la transacción y no se devuelve la tarjeta HAY QUE DEFINIR ESTOS DOS FLUJOS DE EVENTOS!! Ingeniería del Software 40

41 Caso de uso Sacar dinero Flujo de eventos ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA 1. Este caso de uso empieza cuando un Cliente ha sido identificado Presenta las opciones de operaciones disponible 2. Selecciona la operación de Reintegro 4. Introduce la cantidad requerida 6. Recoge la tarjeta. 7. Recoge el recibo 8. Recoge el dinero y termina el CU 3. Pide la cantidad a retirar. 5. Procesa la petición y da el dinero solicitado. Devuelve la tarjeta y genera un recibo Ingeniería del Software 41

42 Caso de uso Sacar dinero Flujo de eventos CAMINOS ALTERNATIVOS Línea 5: La cantidad solicitada supera el saldo. Se indica el error y se cancela la operación. Línea 5: La cantidad solicitada supera el límite diario. Se indica el error y se vuelve a pedir otra cantidad. Línea 5: En el cajero no hay dinero. HAY QUE DEFINIR ESTOS TRES FLUJOS DE EVENTOS!! Podríamos definir diagramas de estados Requisito no funcional asociado al caso de uso Sacar dinero: El tiempo de respuesta para un cliente debe ser <30 sg en el 90% de los casos Ingeniería del Software 42

43 Ejemplo. Cajero automático " :;; + ) 16 Ingeniería del Software 43

44 Análisis Se trabaja con conceptos Especificación más precisa de los requisitos Se utiliza el lenguaje de desarrolladores Facilita comprensión, preparación, modificación y mantenimiento de requisitos Primera aproximación al modelo de diseño Ingeniería del Software 44

45 Artefactos de análisis ( ( '! &' ' ' Ingeniería del Software 45

46 Artefacto: Modelo de Análisis * * ) ' ' * * * * '! &' Ingeniería del Software 46

47 Artefacto: Clases de Análisis Una clase de análisis representa una abstracción de una o mas clases del diseño del sistema Se centra en el tratamiento de los requisitos funcionales Son evidentes en el dominio del problema. Sus atributos, operaciones y relaciones están a un nivel mayor de abstracción. Pueden clasificarse fácilmente en clases de entidad, interfaz y de control. Ingeniería del Software 47

48 Artefacto: Clases de Análisis ' Ingeniería del Software 48

49 Artefacto: Realización de caso de usoanálisis Define como se lleva a cabo y se ejecuta un caso de uso en términos de clases del análisis y de sus objetos de análisis en colaboración. Una realización de caso de uso queda definida por: Diagramas de clases del análisis Diagramas de interacción de objetos del análisis Una descripción textual del flujo de sucesos Ingeniería del Software 49

50 Artefacto: Realización de caso de usoanálisis (Diag. De Clases) Ingeniería del Software 50

51 Artefacto: Realización de caso de usoanálisis (Diag. De Colaboración) Ingeniería del Software 51

52 Artefacto: Realización de caso de usoanálisis: (Desc. Textual) El comprador consulta a través del IU Solicitud de Pago las facturas gestionadas por el sistema para encontrar las recibidas (1,2). El IU Solicitud de Pago utiliza el Gestor de Pedidos para comprobar las facturas con sus correspondientes confirmaciones de pedido Ingeniería del Software 52

53 Artefacto: Paquete del análisis Proporcionan un medio para organizar los artefactos del modelo de análisis en piezas manejables. Son cohesivos y débilmente acoplados Basados en los requisitos funcionales y en el dominio del problema. Generan subsistemas del diseño * ' * ' *! & ' Ingeniería del Software 53

54 Artefacto: Descripción de la Arquitectura Contiene una Vista de la arquitectura del modelo de análisis Descomposición del modelo en paquetes Clases fundamentales: De entidad, importante en dominio De interfaz, comunicación importante De control, con amplia cobertura Generales, centrales y con muchas relaciones Realizaciones de casos de uso Ingeniería del Software 54

55 Flujo de trabajo del análisis 1. Análisis de la arquitectura Identificar paquetes de análisis Identificar clases de entidad Requisitos comunes 2. Analizar (refinar) un caso de uso Identificar clases de análisis Describir interacciones entre los objetos del análisis Capturar req. especiales sobre la realización del CU 3. Analizar una clase Identificar responsabilidades y atributos Identificar relaciones: asoc., agreg. y gener. Capturar req. especiales sobre la realización del CU 4. Analizar un paquete Ingeniería del Software 55

56 Actividades ' ( ( Ingeniería del Software 56

57 Actividades: Análisis de la Arquitectura '! ' ' % % ' Ingeniería del Software 57

58 Actividades: Analizar un caso de uso! (! & ' % ' ' Ingeniería del Software 58

59 Actividades: Analizar una clase! & ' ( ' ' Ingeniería del Software 59

60 Actividades: Analizar un paquete % ' ( ' ' Ingeniería del Software 60

61 Análisis del caso de uso: Validar usuario Validar usuario Realización en análisis Interfaz de caj ero UsuariosDelB anc o (from Logical View) A utenticar (from L ogi cal Vie w) Ingeniería del Software 61

62 Análisis del caso de uso: Validar usuario Secuencia correcta 3: código 1: introducir tarjeta 4: autentica (datos, código) : Cliente del banco 7: visualiza (opciones) 2: teclear código: Interfaz de cajero : Autenticar 5: valida (datos, codigo) 8: seleccioneopcion (opciones) 6: OK : UsuariosDelBanco Ingeniería del Software 62

63 Análisis del caso de uso: Validar usuario. Código incorrecto 3: código 1: introducir tarjeta 4: autentica (datos, código) : Cliente del banco 2: teclear código 8: teclear código 7: visualiza (error) : Interfaz de cajero : Autenticar 5: valida (datos, codigo) 6: Error : UsuariosDelBanco Ingeniería del Software 63

64 Análisis del caso de uso: Transferencia - Suponemos que el usuario ya ha sido identificado (se ha ejecutado el caso de uso anterior). - Ahora selecciona la opción transferencia. Consideramos que la cuenta origen es la de la tarjeta y hay que teclear la destino. - El importe y el número de cuenta destino deben darse juntos. Evitar condiciones de carrera: mirar primero si hay saldo y luego sacar. Transferencia Realización en análisis Interfaz de cajero Transacción Cuenta Ingeniería del Software 64

65 Análisis del caso de uso: Transferencia Secuencia correcta 5: cuenta destino 3: cantidad 1: transferencia 6: transferencia (cuenta, cantidad) 11: OK : Cliente del banco : Interfaz de cajero : Transacción 2: teclee cantidad 4: teclee cuenta destino 8: OK 7: reintegro (cantidad) 9: ingreso (cantidad) 12: transferencia realizada 10: OK cuentaorigen : Cuenta cuentadestino : Cuenta Ingeniería del Software 65

66 Análisis del caso de uso: Transferencia No hay saldo en la cuenta origen 5: cuenta destino 3: cantidad 1: transferencia 6: transferencia (cuenta, cantidad) 9: no hay fondos : Cliente del banco : Interfaz de cajero : Transacción 2: teclee cantidad 7: reintegro (cantidad) 4: teclee cuenta destino 8: no hay saldo 10: no hay fondos cuentaorigen : Cuenta Ingeniería del Software 66

67 Análisis del caso de uso: Transferencia No se puede acceder a la cuenta destino 5: cuenta destino 11: rollback 3: cantidad 1: transferencia 6: transferencia (cuenta, cantidad) 12: error : Cliente del banco : Interfaz de cajero : Transacción 2: teclee cantidad 4: teclee cuenta destino 8: OK 7: reintegro (cantidad) 9: ingreso (cantidad) 10: error 13: error cuentaorigen : Cuenta cuentadestino : Cuenta Ingeniería del Software 67

68 Modelo de clases de análisis Cliente del banco Interfaz de cajero Transacción Cuenta Autenticar UsuariosDelBanco Ingeniería del Software 68

69 Análisis de las clases CLASE CUENTA. Interviene en tres casos de uso: - sacar dinero reintegro (importe) - ingresar dinero ingreso (importe) - transferencia las dos operaciones anteriores atributos - - > saldo Ingeniería del Software 69

70 Análisis de las clases CLASE TRANSACCIÓN Interviene en cuatro casos de uso: - validar usuario autentica (datos, código) atributos - - > código cuenta - sacar dinero retirardinero (importe) - ingresar dinero ingresardinero (importe) - transferencia transferencia (cuenta, cantidad) rollback Ingeniería del Software 70

71 Diseño Se modela el sistema para que de soporte a los requisitos funcionales y no funcionales. Su entrada esencial es el modelo de análisis (una comprensión detallada de los requisitos) Propósitos: Profundizar en la requisitos no funcionales y restricciones dependientes de la plataforma. Crear una entrada apropiada para la implementación Descomponer los trabajos de implementación en partes mas manejables y que permitan concurrencia. Capturar las interfaces entre los subsistemas. Es el centro de atención final de la fase de elaboración e iteraciones iniciales de la fase de construcción Ingeniería del Software 71

72 Artefactos de diseño ( (! & ( ) Ingeniería del Software 72

73 Artefactos de diseño: modelo de diseño Modelo de objetos UML que contiene el diseño de la aplicación. Describe la realización física de los casos de uso: como afectan los requisitos funcionales, no funcionales y otras restricciones. * * ) ) * * * *! & * * ( Ingeniería del Software 73

74 Artefactos de diseño: Clase de diseño Sintaxis del lenguaje de programación Visibilidad de atributos y operaciones (public, private, protected) Traducción de las relaciones Métodos por pseudocódigo Estereotipos que se correspondan con construcciones del lenguaje de programación. Pueden realizar interfaces + ( Ingeniería del Software 74

75 Artefactos de diseño: Realización de un caso de uso-diseño Es una colaboración en el modelo de diseño que describe como se realiza un caso de uso en termino de clases y objetos de diseño Contenido: Diagramas de clases de realización Diagramas de interacción (clases, subsistemas, interfaces) Flujo de sucesos-diseño Requisitos de implementación, -! & '! & Ingeniería del Software 75

76 Artefactos de diseño: Subsistema de Diseño Para organizar los artefactos del diseño en piezas mas manejables. Debe ser cohesivo y débilmente acoplado * ) + * * * * (! Ingeniería del Software & 76

77 Artefactos de diseño: Interfaz Se utilizan para especificar las operaciones que proporcionan las clases y subsistemas de diseño Separan la especificación de funcionalidad en término de operaciones de sus implementaciones en términos de métodos + * + * ( ) Ingeniería del Software 77

78 Artefactos de diseño: Descripción de la Arquitectura Descomposición en subsistemas Traza con clases de análisis Clases fundamentales (abstractas) Clases generales y centrales Realizaciones de caso de uso Ingeniería del Software 78

79 Artefactos de diseño: Modelo de Despliegue Representa una correspondencia entre la arquitectura del Hardware y la arquitectura del Software Describe la distribución física del sistema en nodos de computo. Cada nodo representa un recurso de computo Las relaciones entre nodos representan medios de comunicación entre ellos. La funcionalidad de un nodo se determina por los componentes que se le asignan *. Ingeniería del Software 79

80 Diseño: Actividades ( ( Ingeniería del Software 80

81 Diseño: Actividades 1. Diseño de la arquitectura Identificar nodos y configuración, subsistemas, clases 2. Diseñar un caso de uso Identificar clases de diseño y subsistemas Distribuir comportamiento del CU Capturar requisitos de implementación 3. Diseñar una clase 4. Diseñar un subsistema Ingeniería del Software 81

82 Actividades: Diseño de la Arquitectura ) (! ' % ' % Ingeniería del Software 82

83 Actividades: Diseño de un caso de uso! ' (! & ) ( Ingeniería del Software 83

84 Actividades: Diseño de una clase! & ( ( ' Ingeniería del Software 84

85 Actividades: Diseño de un Subsistema % ( ) ) ( ( Ingeniería del Software 85

86 Diseño del caso de uso: Validar usuario Validar usuario Realizac ión en diseño (from Use Case View) Lec tordetarjetas Pantalla GestorDeCliente Us uariosdelb anco Teclado Transacc ión Ingeniería del Software 86

87 Diseño del caso de uso: Validar usuario Secuencia correcta : Cliente del banco : Lect ordetarjetas : Pantalla : Teclado : GestorDeCliente : Transacción : UsuariosDelBanco 1: leertarjeta 2: introducirtarjeta (tarjet a) 3: datostarjeta (tarjeta) 4: vis ualizar (Introducir PIN) 5: OK 7: introducirpin (PIN) 6: leerpin 8: datospin (PIN) 9: autent ic a (datos, PIN) 10: valida (datos, PIN) 11: OK 12: almacenadatos (datos) 14: visualizar (opciones) 13: visualiza (opciones) Ingeniería del Software 87

88 Diseño del caso de uso: Validar usuario Código incorrecto : Cliente del banco : Lect ordetarjetas : Pantalla : Teclado : GestorDeCliente : Transacción : UsuariosDelBanco 1: leertarjeta 2: introducirtarjeta (tarjet a) 3: datostarjeta (tarjeta) 4: vis ualizar (Introducir PIN) 5: OK 7: introducirpin (PIN) 6: leerpin 8: datospin (PIN) 9: autent ic a (datos, PIN) 10: valida (datos, PIN) 11: E rror 13: visualizar (error PIN) 12: visualiza (error PIN) Hay más escenarios: anular transacción y tres intentos Ingeniería del Software 88

89 Diseño del caso de uso: Transferencia - Suponemos que el usuario ya ha sido identificado (se ha ejecutado el caso de uso anterior). Ahora selecciona la opción transferencia. Transferenc ia (from Use Case View) Realización en diseño, trans ferenc ia Teclado 2 Pantalla GestorDeCliente Trans ac ción Cu entas Cu enta Ingeniería del Software 89

90 Diseño del caso de uso: Transferencia Secuencia correcta : Cliente del banco : Teclado : Pantalla : GestorDeCliente : Transacción : Cuentas : Cuenta 1: opcion (transferencia) 2: transferencia 3: visualizar (Teclee im porte) 4: IntroducirImporte 5: importe 6: visualizar (Teclee cuenta destino) 7: cuentades tino (cuenta) 8: cuentadestino (cuenta) 9: transferencia (cuentaorigen, cuentadestino,importe) 10: reintegro (cuentaorigen, importe) 11: reintegro (importe) 12: OK 13: OK 14: ingreso (cuentadestino, importe) 15: ingreso (im porte) 17: OK 16: OK 18: OK 19: vis ualizar (Transferencia realizada) 20: visualizar (Retire su tarjeta) Ingeniería del Software 90

91 Diseño del caso de uso: Transferencia No hay saldo en la cuenta origen : Cliente del banco : Teclado : Pantalla : GestorDeCliente : Transacción : Cuentas : Cuen ta 1: opcion (transferencia) 2: transferencia 3: visualizar (Teclee im port e) 4: IntroducirImporte 5: importe 6: visualizar (Te clee cuent a destino) 7: cuentades tino (cuenta) 8: cuentadestino (cuenta) 9: t ransferencia (cuentao rigen, cuen tadestin o,impo rt e) 10: reintegro (cuentaorigen, importe) 11: reintegro (importe) 12: no hay saldo 13: no hay saldo 14: no hay fondos 15: visualiz ar ((No hay fondos)) 16: visualizar (Retire su tarjeta) Ingeniería del Software 91

92 Modelo de clases de diseño CajonDinero UsuariosDelBanco Impresora Cliente del banco LectorDeTarjetas GestorDeCliente Transacción Pantalla Cuentas Teclado DarDinero Cuenta Ingeniería del Software 92

93 Diseño de las clases Pantalla Lec tordetarjetas vis ualizar(m ensaje : St ring) c rearpantalla() : Pantalla crearlec tor() : Lect ordetarjetas leertarjeta() : dato s Tarj eta Teclado creartec lado() : Tec lado leerpin() : unpin leeropc ion() : unaopcion leercantidad() : Dinero leernum Cuenta() : unidcuenta Im presora Gesto rdecli ente crear() : GestorDeCliente c reacajerovi rtual() inici ars esion() crearimpresora() : Im pres ora imprimir(mensaje : String) CajonDinero DarDinero crearcajon() : CajonDi nero abrircajon() crear() : DarDinero cerra rcajon() expulsar(im porte : Dinero) contarcantidad() : Dinero Ingeniería del Software 93

94 Diseño de las clases micliente : GestorDeCliente datostarjeta : DatosTarjeta numintentosfallidos : 1..3 = 0 cuentas : Cuentas usuarios : UsuariosDelBanco Transacción almacenardatos(datos : DatosTarjeta) validar(importe : Dinero, cantidad : Dinero) autenticar(datos : DatosTarjeta, PIN : UnPIN) : Boolean retirardinero(importe : Dinero) : Boolean ingresardinero(importe : Dinero) : Boolean trasnsferencia(cuentaorigen : Cuenta, cuentadestino : Cuenta, importe : Dinero) : Boolean GestorDeCliente mitransaccion : Transacción crear() : GestorDeCliente creacajerovirtual() iniciarsesion() visualizar(resultados : String) cuentas : Dictionary Cuentas UsuariosDelBanco usuarios : Dictionary reintegro(cuenta : Cuenta, importe : Dinero) : Boolean ingreso(cuenta : Cuenta, importe : Dinero) : Boolean validar(datos : DatosTarjeta, PIN : UnPIN) : Boolean Cuenta datos : DatosCuenta limitediario : Dinero = reintegro(importe : Dinero) : Boolean ingreso(importe : Dinero) : Boolean Ingeniería del Software 94

95 Clase GestorDeCliente Esperando t arjeta tarjeta int ro ducida Leyendo tarjeta Esperando PIN Recogiendo tarjeta [ > 3 intentos ] PIN introducido( PIN ) Validando PIN [ correcto ] [ incorrec to ] Es perando opción Ingre sando ingreso( importe ) transferencia( cuenta, importe ) reintegro( importe ) Transferencia Reintegrando [ Not OK ] [ OK ] Expulsando dinero dinero retirado Expulsar Ingeniería del Software tarjeta 95

96 Implementación Se implementa el sistema en términos de componentes: ficheros de código fuente, scripts, ficheros de código binarios, ejecutables y similares. Objetivos: planificar las integraciones de sistema necesarias en cada iteración distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de despliegue implementar las clases y subsistemas encontrados durante el diseño probar los componentes individualmente, integrarlos (compilandolos y enlazandolos en uno o más ejecutables) Ingeniería del Software 96

97 Artefactos de implementación ( ( ( $ ( $ ( Ingeniería del Software 97

98 Artefactos de implementación: Modelo de Implementación Cómo los elementos del modelo de diseño (clases) se implementan en términos de componentes (ficheros de código fuente, ejecutables...) Cómo se organizan los componentes (de acuerdo con los mecanismos de estructuración y modularización del entorno de implementación y los lenguajes de programación utilizados) Cómo dependen los componentes unos de otros Ingeniería del Software 98

99 Artefactos de implementación: Modelo de Implementación * * ) $ ) $ * * * * ( Ingeniería del Software 99

100 Artefactos de implementación: Componente Empaquetamiento físico de los elementos de un modelo cada uno puede implementar varios elementos dependiendo del lenguaje que se utilice. Proporcionan las mismas interfaces que los elementos que implementan. Tienen: relaciones de traza con los elementos del diseño que implementan. dependencias de compilación entre ellos (unos deben haberse compilado antes para poder compilar otros). Ingeniería del Software 100

101 Artefactos de implementación: Componente <<executable>> programa que puede ser ejecutado en un nodo <<file>> fichero que contiene código fuente o datos <<library>> librería estática o dinámica <<table>> una tabla de base de datos <<document>> un documento, - ( ( Ingeniería del Software 101

102 Artefactos de implementación: Subsistema de Implementación Forma de organizar los artefactos del modelo de implementación en trozos más manejables. Un subsistema puede estar formado por: componentes interfaces otros subsistemas (recursivamente) Se manifiestan a través de un mecanismo de empaquetamiento concreto de un entorno de implementación determinado. Paquete en Java Proyecto en VB Etc. * * * ) $ * * ( + Ingeniería del Software 102

103 Artefactos de implementación: Interfaz Un componente que implementa una interfaz debe implementar correctamente todas las operaciones del interfaz. Un subsistema que implementa una interfaz debe contener componentes que proporcionen la interfaz u otros subsistemas que la proporcionen. + * * ( + ) $ Ingeniería del Software 103

104 Artefactos de implementación: Descripción de la arquitectura La descomposición del modelo de implementación en subsistemas, sus interfaces y las dependencias entre ellos (cómo vienen dados por los equivalentes del modelo de diseño suele ser innecesario representarlos) Componentes clave (los que tienen traza a clases de diseño significativas arquitectónicamente, y los ejecutables) Ingeniería del Software 104

105 Artefactos de implementación: Plan de Integración de las Construcciones Describe la secuencia de construcciones necesarias en una iteración. Para cada construcción debe describir: funcionalidad que se espera que sea implementada en esa construcción (lista de casos de uso o escenarios o parte de ellos, también puede incluir requisitos adicionales) partes del modelo de implementación afectadas por la construcción (lista de los subsistemas y componentes necesarios para implementar esa funcionalidad) Ingeniería del Software 105

106 Implementación: Actividades ( ( ( ( ( (! Ingeniería del Software 106

107 Actividades: Implementación de la Arquitectura ' % ( % $ Ingeniería del Software 107

108 Actividades: Integrar el Sistema! ( $ ( $ Ingeniería del Software 108

109 Actividades: Implementar un Subsistema % ( ( ) $ ) ( ( Ingeniería del Software 109

110 Actividades: Implementar una Clase ( ( ( Ingeniería del Software 110

111 Actividades: Realizar una Prueba de Unidad ( (! Ingeniería del Software 111

112 Prueba Verificamos el resultado de la implementación probando cada construcción Objetivos de la prueba Planificar las pruebas necesarias para cada iteración (pruebas de sistema y pruebas de integración) Diseñar e implementar las pruebas diseñando los casos de prueba Realizar las diferentes pruebas. Ingeniería del Software 112

113 Artefactos de pruebas Modelo de pruebas Casos de prueba Procedimientos de prueba Componentes de prueba Plan de prueba Defectos Evaluación de la prueba Sistema de pruebas X Componente Caso de prueba Procedimiento de prueba Ingeniería del Software de prueba 113 * X

114 Flujo de trabajo de pruebas 1. Planificar prueba 2. Diseñar prueba Describir casos de prueba de cada construcción Identificar y estructurar los procedimientos de prueba 3. Implementar prueba 4. Realizar pruebas de integración 5. Realizar prueba de sistema 6. Evaluar prueba Ingeniería del Software 114

115 Resumiendo... <<trace>> <<trace>> Caso de uso Realización en análisis Realización en diseño Ingeniería del Software 115

116 Resumiendo... <<trace>> Realización en diseño Realización en implementación <<desing subsystem>> <<trace>> (1:1) <<implem. subsystem>> <<file>> <<file>> Ingeniería del Software 116

117 Un ejemplo: el Proceso Unificado Características del Proceso Unificado Flujos de trabajo fundamentales Iteración genérica División del trabajo en fases Planificar Gestionar los riesgos Recursos Evaluar Ingeniería del Software 117

118 Iteración genérica Incluye: Planificación Flujos de trabajo fundamentales Requisitos Análisis Diseño Implementación Pruebas Evaluación El contenido varía para adaptarse al objetivo de cada fase. Ingeniería del Software 118

119 División del trabajo en fases Fase de inicio: establecer viabilidad Objetivo: Análisis del negocio: casos de uso fundamentales para el negocio Actividades: 1. Delimitar el ámbito (interfaces con otros sistemas) 2. Proponer una arquitectura especialmente en lo nuevo, arriesgado o difícil (expresada en función de algunos modelos) 3. Identificar riesgos críticos (los que afecten a la viabilidad) 4. Demostrar a usuarios y clientes un prototipo (exploratorio) Ingeniería del Software 119

120 División del trabajo en fases Fase de elaboración: factibilidad Objetivo Arquitectura estable para guiar el sistema Estimación de de costes para fases sisguientes con precisión Actividades: 1. Línea base de la arquitectura. Consiste en: modelos, descripción de la arquitectura e implementación ejecutable de la arquitectura. 2. Identificación de riesgos que pueden perturbar los planes y costes posteriores. 3. Especificar niveles para los atributos de calidad: fiabilidad y tiempo de respuesta. 4. Recopilar casos de uso para el 80% de los requisitos funcionales para planificar la fase de construcción. 5. Planificación: personal, coste. Ingeniería del Software 120

121 División del trabajo en fases Fase de construcción Objetivo Versión beta Actividades: 1. Terminar la identificación, descripción y realización de todos los casos de uso. 2. Finalizar el análisis, el diseño la implementación y pruebas. 3. Mantener la integridad de la arquitectura. 4. Monitorizar los riesgos críticos. Ingeniería del Software 121

122 División del trabajo en fases Fase de transición: en el entorno del usuario Objetivo Producto final Actividades: 1. Preparar las actividades, por ejemplo, el lugar. 2. Aconsejar sobre el entorno de funcionamiento. 3. Manuales y documentos para la entrega. 4. Ajustar el software al entorno del usuario. 5. Corregir los defectos detectados en la versión beta. Lecciones aprendidas Asuntos útiles para la versión siguiente Ingeniería del Software 122

123 Un ejemplo: el Proceso Unificado Características del Proceso Unificado Flujos de trabajo fundamentales Iteración genérica Planificar Las fases Las iteraciones Los criterios de evaluación Gestionar los riesgos Recursos Evaluar Ingeniería del Software 123

124 Planificar Varias iteraciones en cuatro fases Información sobre el sistema propuesto Planificar Plan de proyecto Información del dominio Plan de iteración Experiencia pasada Ingeniería del Software 124

125 Planificar las fases Establecer: Asignaciones de tiempo y fecha de entrega por cada fase (inestable hasta fin de elaboración) Hitos principales y criterios de aceptación Iteraciones por fase y qué se realiza en ellas. Depende de la complejidad del sistema. Plan de proyecto: fechas y criterios de objetivos principales y división de fases en iteraciones Pensar a largo plazo Ingeniería del Software 125

126 Planificar las iteraciones Definimos: Planificación de la Iteración: cuanto tiempo, fecha de terminación. Contenido de la Iteración: Contenido. Ya está esbozado en el plan del proyecto pero al comenzar cada iteración se debe detallar: Casos de uso Riesgos técnicos que se deben identificar en forma de casos de uso Cambios que han sufrido los requisitos o defectos encontrados Subsistemas que se deben implementar Personal El plan de la iteración siguiente se va detallando. El número de iteraciones de cada fase esta determinado por la complejidad del sistema. Ingeniería del Software 126

127 Planificar las iteraciones La 1ª iteración suele ser más difícil Ajustar el PU al proyecto y seleccionar herramientas Seleccionar personal y crear equipo. Familiarizarlo con el proyecto y las herramientas Entender el dominio Lista de riesgos Ingeniería del Software 127

128 Planificar los criterios de evaluación Criterios para establecer la satisfacción de los objetivos de cada iteración (medidos u observados): Requisitos funcionales en casos de uso Requisitos no funcionales de esos requisitos funcionales Requisitos no funcionales sueltos Requisitos verificables (pruebas) Requisitos generales (prototipo) Productos intermedios para determinar el progreso del trabajo Ingeniería del Software 128

129 Un ejemplo: el Proceso Unificado Características del Proceso Unificado Flujos de trabajo fundamentales Iteración genérica Planificar Gestionar los riesgos Priorizar los casos de uso Categorías de riesgos Recursos Evaluar Ingeniería del Software 129

130 Riesgos Lista de riesgos: BD Identificador Descripción Prioridad (crítico, significativo, rutinario) Impacto: qué parte del proyecto se ve afectada Monitor: responsable del seguimiento Responsabilidad: reponsable de eliminarlo Contingencia: qué hacer si se materializa Jefe de proyecto celebra reuniones periódicas para revisar el estado de los riesgos Ingeniería del Software 130

131 Riesgos Influencia en el plan de iteraciones Desarrollar prototipo para conocer riesgo Incrementar el esfuerzo Prolongar la planificación Calidad o rendimiento Planificar acciones sobre los riesgos En cada fase o iteración se eliminan o se prepara plan de contingencia No planificarlos: modificaciones, retrasos A veces no se descubren Ingeniería del Software 131

132 Priorizar los casos de uso Los casos de uso (escenarios) guían las iteraciones Se ordenan según el riesgo que conllevan Evitar: cambiar la arquitectura no satisfacer los requisitos (producto no correcto) Los riesgos se transforman en casos de uso que se priorizan Ej: Riesgo: Dar dinero sin haber saldo Caso de uso: habrá un escenario en que se solicite una cantidad mayor que el saldo. Ingeniería del Software 132

133 Priorizar los casos de uso Primeras iteraciones Riesgos relacionados con el ámbito del sistema y arquitectura Últimas iteraciones Añadir más funciones Categorías de riesgos: Específicos Arquitectónicos De requisitos Ingeniería del Software 133

134 Categorías de riesgos Específicos de un producto Técnicos Implementar un caso de uso mitiga el riesgo Deben tratarse uno a uno (no está en el PU) De requisitos Puede crecer Estamos desarrollando el producto correcto? Qué casos de uso aseguran que el sistema puede evolucionar? Solución: requisitos, modelo de negocio» uso real en prototipos Ingeniería del Software 134

135 Categorías de riesgos Arquitectónicos No establecer una arquitectura flexible Fases de inicio y elaboración Cómo determinar casos de uso importantes para la arquitectura correcta? Casos de uso críticos (los más importantes para los usuarios del sistema y los que tienen requisitos no funcionales como rendimiento, tiempo de respuesta,...) Otras categorías de casos de uso: secundarios, auxiliares, opcionales 80% de casos de uso descritos en elaboración para hacer la planificación detallada y estar seguros de haber considerado lo importante para la arquitectura Ingeniería del Software 135

136 Un ejemplo: el Proceso Unificado Características del Proceso Unificado Flujos de trabajo fundamentales Iteración genérica Planificar Gestionar los riesgos Recursos Evaluar Ingeniería del Software 136

137 Recursos Cuánto cuestan las fases de inicio y elaboración? Quién las costea? Cuánto duran? Depende del proyecto Considerar: Hay experiencia? Cómo es la base de componentes? Es una nueva entrega? Es distribuido?... Ingeniería del Software 137

138 Recursos Tiempo: Inicio 5%, elaboración 20%, construcción 65%, transición 10% Recursos Inicio 10%, elaboración 30%, construcción 50%, transición 10% Más incógnitas, más tiempo y recursos en inicio y elaboración. Ingeniería del Software 138

139 Un ejemplo: el Proceso Unificado Características del Proceso Unificado Flujos de trabajo fundamentales Iteración genérica Planificar Gestionar los riesgos Recursos Evaluar Las fases Las iteraciones Ingeniería del Software 139

140 Evaluar iteraciones y fases Jefe de proyecto (documento) Objetivos: evaluar iteraciones según criterios: presupuesto, tiempo, requisitos de calidad, resultados de las pruebas reconsiderar el plan de la siguiente iteración modificar el proceso evaluar y modificar criterios Es frecuente no alcanzar los criterios. Prolongar el trabajo a la iteración siguiente: Modificar o extender el modelo de casos de uso Modificar o extender la arquitectura Modificar o extender los subsistemas desarrollados Buscar otros riesgos Incorporar ciertas habilidades al equipo Puede que solo falte tiempo Ingeniería del Software 140

141 La siguiente iteración A partir de la evaluación anterior, el jefe de proyecto: Determina si se puede pasar a la siguiente iteración Si hay que rehacer, cuándo Planificar en detalle siguiente iteración Actualizar el plan de las iteraciones posteriores a la siguiente Actualizar riesgos y plan del proyecto Evolución del conjunto de modelos Ingeniería del Software 141