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

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

Un ejemplo: el Proceso Unificado

• Características del Proceso Unificado • Flujos de trabajo fundamentales

• Iteración genérica • Planificar

• Gestionar los riesgos • Recursos

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

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.

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

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

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

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

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.

Diagrama de clases

Avión militar Avión comercial

Avión de carga Avión de pasajeros Motor

Avión 1..4

1

Piloto Vendedor de billetes

Reserva * 1 Vuelo * 1 1..2 * * 1 Línea aérea 1 * 1 1..4 _1..2 * 1 * 1 * 1 * * 1 { disjunta, completa } { disjunta, completa }

Control y Análisis Comment Acceso a BD Comment Rutinas de Coneccion Comment Interfaz de Terminal Comment Gestión de Cuentas Comment

Diagramas de Componentes

Diagramas de Despliegue

Punto de Venta Servidor Central Terminal de Consulta Gestión de Cuentas Comment Interfaz de Terminal Comment Rutinas de Coneccion Comment Rutinas de Coneccion Comment Interfaz de Terminal Comment Rutinas de Coneccion Comment Acceso a BD Comment Control y Análisis Comment

Cliente

Venta Normal

Venta en Rebajas

Vendedor

Esperando t arj eta

Leyendo tarjeta

tarjeta int ro ducida

Esp erando PIN

Validando PIN

PIN introducido( PIN )

Recogiendo tarjeta Es perando opción [ incorrec to ] [ > 3 intentos ] [ correcto ] Ingresando i ngreso( importe ) Reintegrando reintegro( importe ) Transferencia transferencia( cuenta, importe )

Expulsando dinero

[ OK ]

[ Not OK ]

: Cliente del banco : Interfaz de ca jero : Transacción

cuentaOrigen : Cuenta cuentaDestino : Cuenta

1: transferencia

2: teclee cant id ad 3: cantidad

4: teclee cuenta destino 5: cuenta dest in o

12: transferencia realizada

6: t rans ferencia (cuenta, cantidad)

11 : OK

7: rei ntegro (can tidad) 8: OK

9: ingreso (cantidad)

10: OK

Diagramas de Secuencia

: Socio : Encargado : Libro : Ficha socio : Ficha libro : Préstamo Coger libro

Solicitar préstamo

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

Pasajero _{Vendedor Airline}

Solicitar pago Reservar plazas

Confirmar plaza reservada Pagar pasaje Informar alternativas y precios Verificar existencia vuelo

Dar detalles vuelo Solicitar pasaje

Seleccionar vuelo

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.

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

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.

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 arquitectura-implementar-verificar

Iterativo - Incremental

• Varios ciclos que concluyen con un producto. • Código fuente, manuales y documentos.

Diseño de

Arquitectura Implementación de Arquitectura Estructura Modelo de Casos de Uso Descubre Actores y Casos de Uso Analista de Sistemas Detalla un Caso de Uso Especifica Casos de Uso Prototipo del Interfaz de Usuario Diseñador de Interface de Usuario Análisis de Arquitectura Prioriza Casos de Uso Arquitecto Diseña un Caso de Uso Analiza un Caso de Uso Ingeniero de Casos de Uso Analiza Implementa Evalua Test Diseña

Test Ingeniero de_pruebas Planifica Test Integrador de Sistemas Integra Sistema Ejecuta Test de Integración Ejecuta test del sistema

El proceso

Papeles y actividades

Ingeniero de pruebas de integración Ingeniero de pruebas de sistema

El proceso

El producto (salidas)

! " # # $ % # ! # % # ! & # & ' ( & # ! )

El proceso

Fases, iteraciones y actividades

* $ * " $ + + , - . # # / / / 0 / 1 / 2 / 3 / 4 '$ 5 6 777(

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

El proceso

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

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

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

Captura de requisitos

• Pasos a seguir

– Enumerar los requisitos candidatos – Comprender el contexto del sistema – Capturar requisitos funcionales

– Capturar requisitos no funcionales

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

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

Sistema de casos de uso Modelo de casos de uso

1

Flujo de trabajo de la captura de

Flujo de trabajo de la captura de

requisitos funcionales (Actividades)

• Encontrar actores y casos de uso

!

Flujo de trabajo de la captura de

requisitos funcionales (Actividades)

• Priorizar casos de uso

% !

Flujo de trabajo de la captura de

requisitos funcionales (Actividades)

• Detallar un caso de uso

Flujo de trabajo de la captura de

requisitos funcionales (Actividades)

• Prototipar la interfaz de usuario

Flujo de trabajo de la captura de

requisitos funcionales (Actividades)

• Estructurar el modelo de casos de uso

Caso de uso “Validar usuario”

Flujo de eventos

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

ACCIÓN DEL ACTOR

1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero

3. Introduce la clave

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

Caso de uso “Sacar dinero”

Flujo de eventos

RESPUESTA DEL SISTEMA

1. Este caso de uso empieza cuando un Cliente ha sido identificado

Presenta las opciones de operaciones disponible

3. Pide la cantidad a retirar.

5. Procesa la petición y da el dinero solicitado.

Devuelve la tarjeta y genera un recibo

ACCIÓN DEL ACTOR

2. Selecciona la operación de Reintegro

4. Introduce la cantidad requerida

6. Recoge la tarjeta. 7. Recoge el recibo

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:

Ejemplo. Cajero automático

+ " + ) 8 99 : ;; 16 6 06

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

Artefactos de análisis

! & ' ' ' _' ( (

Artefacto: Modelo de Análisis

) ' * * ! & ' ' ' * * * *

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.

Artefacto: Clases de Análisis

Artefacto: Realización de caso de

uso-aná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

Artefacto: Realización de caso de

uso-análisis (Diag. De Clases)

Artefacto: Realización de caso de

uso-análisis (Diag. De Colaboración)

Artefacto: Realización de caso de

uso-aná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…”

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

! & ' ' * * *

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

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

Actividades

( (

Actividades: Análisis de la Arquitectura

' ! % ' ' % '

Actividades: Analizar un caso de uso

( ! % ' ' ! & '

Actividades: Analizar una clase

( ' ! & ' '

Actividades: Analizar un paquete

( % ' ' '

Vali dar usuario _{Re alización en análisis}

UsuariosDelBanco

(from Logical View)

A utenti car

(from L ogi cal Vie w)

Interfaz de caj ero

Análisis del caso de uso: “Validar usuario”

Secuencia correcta

: Interfaz de cajero : Cliente del banco

1: introducir tarjeta 2: teclear código

3: código

: Autenticar 4: autentica (datos, código)

: UsuariosDelBanco

5: valida (datos, codigo) 6: OK

7: visualiza (opciones)

Análisis del caso de uso: “Validar usuario”.

Código incorrecto

: Interfaz de cajero : Cliente del banco

1: introducir tarjeta

2: teclear código 3: código

: Autenticar 4: autentica (datos, código)

: UsuariosDelBanco

5: valida (datos, codigo)

6: Error 7: visualiza (error)

- 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.

Análisis del caso de uso: “Transferencia”

Realización en análisis

Interfaz de cajero Transacción Cuenta

Análisis del caso de uso: “Transferencia”

Secuencia correcta

: Cliente del banco : Interfaz de cajero : Transacción

cuentaOrigen : Cuenta cuentaDestino : Cuenta 1: transferencia

2: teclee cantidad 3: cantidad

4: teclee cuenta destino 5: cuenta destino

12: transferencia realizada

6: transferencia (cuenta, cantidad)

11: OK

7: reintegro (cantidad) 8: OK

9: ingreso (cantidad)

Análisis del caso de uso: “Transferencia”

No hay saldo en la cuenta origen

: Cliente del banco : Interfaz de cajero : Transacción 1: transferencia

2: teclee cantidad 3: cantidad

4: teclee cuenta destino 5: cuenta destino

10: no hay fondos

6: transferencia (cuenta, cantidad) 9: no hay fondos

7: reintegro (cantidad) 8: no hay saldo

Análisis del caso de uso: “Transferencia”

No se puede acceder a la cuenta destino

: Cliente del banco : Interfaz de cajero : Transacción

cuentaOrigen : Cuenta cuentaDestino : Cuenta 11: rollback

1: transferencia

2: teclee cantidad 3: cantidad

4: teclee cuenta destino 5: cuenta destino

13: error

6: transferencia (cuenta, cantidad)

12: error

7: reintegro (cantidad)

8: OK 9: ingreso (cantidad) 10: error

Modelo de clases de análisis

Cliente del banco Interfaz de cajero Transacción Cuenta

UsuariosDelBanco Autenticar

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

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

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

Artefactos de diseño

! & ( ₎ ( (

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

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

(

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 ! & ! & ' ,

-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

+ * * * * ) *

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 ( + + * *

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

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

.

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

Actividades: Diseño de la Arquitectura

! % ' ' ) ( %

Actividades: Diseño de un caso de uso

( ! ) ( ' ! &

Actividades: Diseño de una clase

( ( ! & '

Actividades: Diseño de un Subsistema

( ( ) % ( )

Validar usuario

(from Use Case View)

Realización en diseño LectorDeTarjetas Pantalla Teclado GestorDeCliente Us uariosDelBanco Transacción

: Cliente del banco : Lect orDeTarj etas

: Pa ntalla : Teclado

: GestorDeCliente : Tran sacción : UsuariosDelBanco

2: i ntroduci rTarj eta (tarjet a)

3: datosTarjeta (tarjeta)

4: vis ualizar (Introducir PIN) 1: leerTarjeta

5: OK

6: leerPIN 7: introduci rPIN (PIN)

8: datosPIN (PIN)

9: autent ic a (datos , PIN)

10: valida (datos, PIN) 11: OK

13: vi sualiza (opciones)

12: almacenaDatos (datos)

14: visualizar (opciones)

Diseño del caso de uso: “Validar usuario”

: Cliente del banco : Lect orDeTarjetas

: Pa ntalla : Teclado

: GestorDeCliente : Tran sacción : UsuariosDelBanco

2: introducirTarjeta (tarjet a)

7: introducirPIN (PIN)

3: datosTarjeta (tarjeta)

4: vis ualizar (In troducir PIN) 1: leerTarjeta

5: OK

6: leerPIN 8: datosPIN (PIN)

9: au tent ic a (datos , PIN)

10: valida (datos, PIN) 11: E rror 12: visualiza (error PIN)

13: visu alizar (error PIN)

Diseño del caso de uso: “Validar usuario”

- Suponemos que el usuario ya ha sido identificado (se ha ejecutado el caso de uso anterior). Ahora selecciona la opción “transferencia”.

Transferencia

(from Use Case View)

Realización en diseño, transferenc ia

Teclado

Pantalla

GestorDeCliente Transacción Cu entas Cu enta

2

: Cliente del banco : Teclado : Pantalla : GestorDeCliente : Transacción : Cuentas : Cuen ta 1: opcion (transferencia)

4: IntroducirImporte

2: transferencia

3: visu alizar (Teclee im port e) 5: importe

19 : vis ualizar (Tra nsfe rencia realizada) 6: visualizar (Te clee cuent a destino)

9: t ransferencia (cuentaO rigen, cuen taDestin o,impo rt e) 10: reintegro (cuentaOrigen, importe)

11: reintegro (importe) 12: OK 13: OK 18: OK 7: cu entaDes ti no (cuent a) 8: cuentaDestino (cuenta)

14: ingreso (cuentaDestino, importe) 15: ingre so (im porte)

16: OK 17: OK

Diseño del caso de uso: ”Transferencia”

: Cliente del banco : Teclado : Pantalla : GestorDeCliente : Transacción : Cuentas : Cuen ta

1: opcion (transferencia)

4: IntroducirImporte

7: cu entaDes tino (cuent a)

2: transferencia

3: visu alizar (Teclee im port e)

5: importe

15: visualiz ar ((No hay fondos)) 6: visualizar (Te clee cuent a destino)

8: cuentaDestino (cuenta)

9: t ransferencia (cuentaO rigen, cuen taDestin o,impo rt e)

14: no hay fondos

10: reintegro (cuentaOrigen, importe)

13: no hay saldo

11: reintegro (importe) 12 : no ha y saldo

Diseño del caso de uso: ”Transferencia”

Modelo de clases de diseño

CajonDinero Impresora LectorDeTarjetas Pantalla Teclado DarDinero Cliente del banco

GestorDeCliente

Cuenta UsuariosDelBanco

Transacción

CajonDinero

crearCajon() : CajonDinero abrirCajon()

LectorDeTarjetas

crearLec tor() : Lect orDe Tarjeta s leerTarjeta() : dato sTarjeta

Pantalla

vis ualizar(m ensaje : St ring) c rearPantalla() : Pantalla Tecla do crearTeclado() : Teclado leerPIN() : unPIN leerOpcion() : unaOpcion leerCantidad() : Dinero leerNumCuenta() : unIDCuenta DarDinero Gesto rDeCliente

crear() : GestorDeClie nte creaCajeroVirtual()

iniciarSesion() Impresora

crearImp resora() : Im pres ora imprimir(mensaje : String)

Diseño de las clases

GestorDeCliente miTransaccion : Transacción crear() : GestorDeCliente creaCajeroVirtual() iniciarSesion() visualizar(resultados : String) Transacción miCliente : GestorDeCliente datosTarjeta : DatosTarjeta numIntentosFallidos : 1..3 = 0 cuentas : Cuentas usuarios : UsuariosDelBanco 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

UsuariosDelBanco usuarios : Dictionary

validar(datos : DatosTarjeta, PIN : UnPIN) : Boolean Cuentas

cuentas : Dictionary

reintegro(cuenta : Cuenta, importe : Dinero) : Boolean ingreso(cuenta : Cuenta, importe : Dinero) : Boolean

Esperando t arj eta

Leyendo tarjeta

tarjeta int ro ducida

Esp erando PIN

Validando PIN

PIN introducido( PIN )

Recogiendo tarjeta Es perando opción [ incorrec to ] [ > 3 intentos ] [ correcto ] Ingresando i ngreso( importe ) Reintegrando reintegro( importe ) Transferencia transferencia( cuenta, importe )

Expulsando dinero

[ OK ]

[ Not OK ]

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

Artefactos de implementación

( $ ( $ ( ( (

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)

Artefactos de implementación: Modelo de

Implementación

) $ * * * ( * ) $ * *

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).

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

-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 + * * * ) $ * *

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.

( + ) + * *

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

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)

Implementación: Actividades

( ( ( ( ( ( !

Actividades: Implementación de la

Arquitectura

( ' % % $

Actividades: Integrar el Sistema

( ( !

Actividades: Implementar un Subsistema

( ( % ) ( ) $ (

Actividades: Implementar una Clase

(

(

Actividades: Realizar una Prueba de

Unidad

(

!

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

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 X

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

Caso de uso Realización en análisis <<trace>> Realización en diseño <<trace>>

Resumiendo...

Resumiendo...

<<trace>> (1:1)

Realización

en diseño en implementaciónRealización

<<trace>>

<<implem. subsystem>>

<<file>> <<file>>

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

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.

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)

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.

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.

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

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

Planificar

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

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

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.

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

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

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

Riesgos

• Lista de riesgos:

– 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

• BD

• Jefe de proyecto celebra reuniones periódicas para revisar el estado de los riesgos

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

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.

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

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

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

Un ejemplo: el Proceso Unificado

• Características del Proceso Unificado • Flujos de trabajo fundamentales

• Iteración genérica • Planificar

• Gestionar los riesgos • Recursos

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? – ...

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.

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

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

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