un ejemplo: el proceso unificado de desarrollo · un ejemplo: el proceso unificado de desarrollo...

Ingeniería del Software 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


Un ejemplo: el Proceso Unificado

• Características del Proceso Unificado• Flujos de trabajo fundamentales• Iteración genérica• Planificar• Gestionar los riesgos• Recursos• Evaluar



• 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


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.


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 ClasesD. de ObjetosD. de ComponentesD. de Despliegue

Dinámicos(comportamiento)Casos de UsoSecuenciaColaboraciónEstadosActividades

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.

Interacción


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

Comm

Acceso a BD

CommRutinas de Coneccion

Comm

Interfaz de Terminal

Comm

Gestión de Cuentas

Comm

Diagramas de Componentes


Diagramas de Despliegue

Punto de Venta

Servidor Central

Terminal de Consulta

Gestión de Cuentas

C


CRutinas de Coneccion

C

Rutinas de Coneccion

C


C

Rutinas de Coneccion

C

Acceso a BD

C

Control y Análisis

C


Cliente

Venta Normal

Venta en RebajasVendedor

Venta en Oferta

Diagrama de casos de uso


Esperando t arjeta

Leyendo tarjeta

tar jeta int roducida

Esperando PIN

Validando PIN

PIN introducido( PIN )

Recogiendo tarjeta

Es perando opción

[ incorrec to ]

[ > 3 intentos ]

[ correcto ]

Ingresando

ingreso( importe )

Reintegrando

reintegro( importe )

Transferencia

transferencia( cuenta, importe )

Expulsando dinero

[ OK ]

Expulsar tarjeta

dinero retirado

[ Not OK ]

Diagrama de estados


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

cuentaOrigen : Cuenta cuentaDestino : Cuenta

1: transferencia

2: tec lee cant idad

3: cantidad

4: teclee cuenta destino

5: cuenta dest ino

12: transferencia realizada

6: t rans ferencia (cuenta, cantidad)

11 : OK

7: reinteg ro (can tidad)

8: OK9: ingreso (cantidad)

10: OK

Diagrama de colaboración


Diagramas de Secuencia

: Socio : Encargado : Lib ro : Ficha libro : Ficha socio : Préstamo

Coger libro

Solic itar préstamo

Verificar s ituación socio

Sit uación socio ok

Verificar s ituación libro

Situación libro ok

Introducir préstamo

Aut orizar p rést amo


Emitir billete

Pasajero Vendedor Airline

Solicitar pago Reservar plazas

Confirmarplaza reservadaPagar pasaje

Informar alternativas y precios

Verificar existencia vuelo

Dar detalles vuelo

Solicitar pasaje

Seleccionar vuelo

Diagramas de actividad


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

• Beneficios.


...

Entrega

Ciclos

Concepción Elaboración TransiciónConstrucciónIter.

1Iter.

2 ... ...... ... ... ... Iter.n

FasesIterac.

Iterativo - Incremental

• Varios ciclos que concluyen con un producto.• Código fuente, manuales y documentos.• Hitos por fases (Milestones)


Diseño de Arquitectura

Implementación de Arquitectura

Estructura Modelo de Casos de Uso

Descubre Actoresy Casos de Uso

Analista deSistemas

Detalla un Caso de Uso

EspecificaCasos de Uso

Prototipo del Interfaz de Usuario

Diseñador deInterface de Usuario

Análisis de Arquitectura

Prioriza Casos de Uso

Arquitecto

Diseña un Caso de Uso

Analiza un Caso de Uso

Ingeniero deCasos de Uso

Ingeniero deComponentes

Diseña una claseAnaliza

un Paquete

Analiza una Clase Diseña un

Subsistema

Implementa una clase

Implementa Subsistema

Ejecuta TestUnitario

Implementa Test

EvaluaTest

Diseña Test

Ingeniero depruebas

Planifica Test

Integrador deSistemas

Integra Sistema

Ejecuta Testde Integración

Ejecuta test del sistema

El procesoPapeles y actividades

Ingeniero depruebas de integración

Ingeniero depruebas de

sistema


El procesoEl producto (salidas)

Modelo de análisis

Modelo de diseño

Modelo de despliegue

Modelo de implementación

Modelo de pruebas

Modelo de casos de uso

Especificado por

Realizado por

Distribuido por

Implementado por

Verificado por

- Refina los casos de uso otorgándoles más detalle- Asigna la funcionalidad a un grupo de objetos

- Define la estructura estática del sistema.- Refleja los casos de uso como colaboraciones

- Define la configuración de los nodos de procesamiento y las correspondencias entre ellos.

- Incluye los componentes (código fuente) y las relaciones entre los mismos

- Define los casos de prueba para validar los casos de uso


El procesoFases, iteraciones y actividades

Requisitos

Diseño

Implantación

Prueba

Análisis

PlanificaciónAnál. RiesgosPreparación

Elaboración ConstrucciónVerificación

Transición

FASESWorkflow

Iteración-esInicial-es

Iter. #1

Iter. #2

Iter. #3

Iter. #4

Iter. #5

Iter. #6

Iter. #7

(Adaptado de Jacobson, 1999)

Iteración en Fase de Elaboración



• 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



• 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


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



• 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



• Pasos a seguir– Enumerar los requisitos candidatos– Comprender el contexto del sistema– Capturar requisitos funcionales– Capturar requisitos no funcionales

• Se realizan de forma conjunta



TAREAEnumerar requisitos candidatosEntender el contexto del sistemaCapturar requisitos funcionalesCapturar requisitos no funcionales

PRODUCTOS (artifact)

Lista de características

Modelo de negocio o de dominioModelo 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

Caso de uso


1

* *

Actor


Artefactos de requisitos

GlosarioActor

Analista de sistemas

Modelo casos de uso

Especificadorde casos de uso

Caso de uso Descripción de la arquitectura

ArquitectoDiseñador de interfaz de usuario

Prototipo de interfaz de usuario


Flujo de trabajo de la captura de requisitos funcionales (Actividades)

Analista

Arquitecto

Especificador

Diseñador

Encontrar actores y casos de uso

Priorizar los casos de uso

Detallar un caso de uso

Estructurar el modelo de casos de uso

Prototipar la interfaz de usuario


Flujo de trabajo de la captura de requisitos funcionales (Actividades)• Encontrar actores y casos de uso

Analista

Encontrar actores y casos de uso

Glosario

Modelo del negocio

Modelo de casos de uso(esbozado)

Requisitos adicionales

Lista de característ.



• Priorizar casos de uso

Arquitecto

Priorizar casos de uso Descripción de la

arquitectura (vista del modelo de casos de uso)



Glosario



• Detallar un caso de uso

Especificador de casos de uso

Detallar un caso de uso



Glosario

Caso de uso(detallado)



• Prototipar la interfaz de usuario

Diseñador de interfaz de usuario

Prototipar la interfaz de usuario



Glosario

Prototipo de interfaz de usuario

Caso de uso(descrito)



• Estructurar el modelo de casos de uso

Analista de sistemas

Estructurar el modelo de casos

de uso



Glosario

Caso de uso(descrito)


(estructurado)


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ónLí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!!


Caso de uso “Sacar dinero”Flujo de eventos

RESPUESTA DEL SISTEMA

1. Este caso de uso empieza cuando un Cliente ha sido identificadoPresenta 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

8. Recoge el dinero y termina el CU


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


Ejemplo. Cajero automático

Sacar dinero

Ingresardinero

Transf.

Consultarsaldo

Validarusuario

Reponerdinero

Recogerdinero

Cliente del banco

Empleadosucursal

Sacar con visa

Usuario <<extends>>

R1

R4,...

R2, R3,...


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

Descripción de la arquitectura

Realización caso de uso -Análisis

Clase del análisis

Arquitecto

Modelo de análisis

Paquete del análisis

Ingeniero de componentes

Ingeniero de casos de uso


Artefacto: Modelo de Análisis

Sistema deanálisis

*

*

Realización caso de uso -Análisis

Clase del análisis

Paquete delaná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

Clase del análisis

Clase de control

Clase de entidad

Clase de interfaz


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)

Comprador

Planificadorde Pagos

Gestor dePedidos

IU Solicitudde Pago

Confirmaciónde Pedido

Factura

Solicitudde Pago


Artefacto: Realización de caso de uso-análisis (Diag. De Colaboración)

:Planificadorde Pagos

:Gestor dePedidos

:IU Solicitudde Pago

:Confirmaciónde Pedido

:Factura

:Solicitudde Pago

:Comprador

1: Mostrar Facturas6: Planificar pago de Factura

3: Comprobar Factura 2: Mostrar

5: Obtener

4: Obtener

7:Planificar Pago

8: Obtener

9: establecerEstado(Planificado)


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

Realización caso de uso -

Análisis

Clase del análisis

Paquete delanálisis

**

*


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


Flujo de trabajo del análisis

1. Análisis de la arquitecturaIdentificar paquetes de análisis Identificar clases de entidadRequisitos comunes

2. Analizar (refinar) un caso de usoIdentificar clases de análisis Describir interacciones entre los objetos del análisis Capturar req. especiales sobre la realización del CU

3. Analizar una claseIdentificar responsabilidades y atributosIdentificar relaciones: asoc., agreg. y gener.Capturar req. especiales sobre la realización del CU

4. Analizar un paquete


Actividades

Analizar un caso de uso

Arquitecto



Análisis de la arquitectura

Analizar una clase Analizar un paquete


Actividades: Análisis de la Arquitectura

Arquitecto

Análisis de la arquitectura



Descripción de la arquitectura (vista del

modelo de casos de uso)

Paquete del análisis (esbozo)

Clase del análisis (esbozo)

Descripción de la arquitectura (vista del modelo de análisis)


Actividades: Analizar un caso de uso


Analizar un caso de uso





Realización caso de uso - análisis


Actividades: Analizar una clase


Analizar una clase



Clase del análisis (terminada)


Actividades: Analizar un paquete


Analizar un paquete


Paquete del análisis(esbozo)

Paquete del análisis

(terminado)


Validar usuario Reali zación en aná li s is

UsuariosDelBanco

(from Logica l V iew)

A utenti car

(from L ogi ca l V ie w)

Interfaz de cajero

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


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)

8: seleccioneOpcion (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)

8: teclear código


- Suponemos que el usuario ya ha sido identificado (se ha ejecutadoel caso de uso anterior).

- Ahora selecciona la opción “transferencia”. Consideramos que lacuenta origen es la de la tarjeta y hay que teclear la destino.

- El importe y el número de cuenta destino deben darse juntos. Evitarcondiciones 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 CuentaTransacción

Transferencia


Análisis del caso de uso: “Transferencia”Secuencia correcta

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


1: transferencia

2: teclee cantidad

3: cantidad


5: cuenta destino

12: transferencia realizada

6: transferencia (cuenta, cantidad)

11: OK

7: reintegro (cantidad)


10: OK


Análisis del caso de uso: “Transferencia”No hay saldo en la cuenta origen


cuentaOrigen : Cuenta

1: transferencia

2: teclee cantidad

3: cantidad


5: cuenta destino

10: no hay fondos


9: no hay fondos


8: no hay saldo


Análisis del caso de uso: “Transferencia”No se puede acceder a la cuenta destino



11: rollback

1: transferencia

2: teclee cantidad

3: cantidad


5: cuenta destino

13: error


12: error



10: error


Modelo de clases de análisis

Cliente del banco Interfaz de cajero CuentaTransacción

UsuariosDelBancoAutenticar


Análisis de las clases

CLASE CUENTA.

Interviene en tres casos de uso: - sacar dinero

reintegro (importe)

- ingresar dineroingreso (importe)

- transferencialas 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 dineroretirarDinero (importe)

- ingresar dineroingresarDinero (importe)

- transferenciatransferencia (cuenta, cantidad)rollback


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


Realización caso de uso -

diseño

Interfaz

Arquitecto

Modelo de diseño

Subsistema de diseño




Clases del

diseño


Artefactos de diseño: modelo de diseño

Sistema dediseño

*

Realización caso de uso - diseño

* * *

*

Clases del

diseño

Interfaz

*

Subsistema dediseñ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.


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

Clases del diseño

Interfaz

► realiza


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



«trace»


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

► realiza

*


* *

Clases del diseño

Interfaz

*


*


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

Clases del diseño

Interfaz

► realiza


► realiza

*

*


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

Modelo de diseño



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


Nodo

*


Diseño: Actividades

Diseñar un caso de uso

Arquitecto



Diseño de la arquitectura

Diseñar una clase Diseñar un subsistema


1. Diseño de la arquitecturaIdentificar nodos y configuración, subsistemas, clases

2. Diseñar un caso de usoIdentificar clases de diseño y subsistemas Distribuir comportamiento del CU Capturar requisitos de implementación

3. Diseñar una clase4. Diseñar un subsistema

Diseño: Actividades


Actividades: Diseño de la Arquitectura

Arquitecto

Diseño de la arquitectura




Modelo de análisis

SubsistemaInterfaz


Clase de diseño

Descripción arquitectura (vista de modelo de diseño y despliegue)


Actividades: Diseño de un caso de uso

Diseñar un caso de uso





Subsistema

Interfaz

Clase de diseño

Modelo de análisis

Modelo de diseño

Realización casode uso - diseño


Actividades: Diseño de una clase


Diseñar una clase

Interfaz

Clase de diseño

Realización casode uso - diseño

Clase de diseño(completa)

Clase del análisis(completa)


Actividades: Diseño de un Subsistema


Diseñar un subsistema

Interfaz (terminada)

Subsistema (terminado)

Descripción arquitectura (vista modelo de diseño)

Interfaz (esbozada)

Subsistema (esbozado)


Val idar usuario

(from Use Case View)

Realización en diseño

LectorDeTarjetas

Pantalla

Teclado

GestorDeCliente Us uariosDelBanco

Transacción

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


: Cliente del banco :

Lect orDeTarjetas : Pantal la : Teclado

: GestorDeCliente : Transacción : UsuariosDelBanco

2: introduci rTarjeta (tarjet a)3: datosTarjeta (tarjeta)

4: vis ualizar (In troduci r PIN)

1: leerTarjeta

5: OK

6: leerPIN7: introduci rPIN (PIN)

8: datosPIN (PIN)

9: au tent ic a (datos , PIN)

10: valida (datos, PIN)

11: OK

13: visual iza (opciones)

12: almacenaDatos (datos)

14: visualizar (opciones)

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


: Cliente del banco :

Lect orDeTarjetas : Pantal la : Teclado

: GestorDeCliente : Transacción : UsuariosDelBanco

2: introduci rTarjeta (tarjet a)

7: introduci rPIN (PIN)

3: datosTarjeta (tarjeta)

4: vis ualizar ( In troduci r 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: visuali zar (error PIN)

Hay más escenarios: anular transacción y tres intentos

Diseño del caso de uso: “Validar usuario”Código incorrecto


- Suponemos que el usuario ya ha sido identificado (se ha ejecutadoel 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 CuentaCuentas

2

Diseño del caso de uso: “Transferencia”


: Cliente del banco : Teclado : Pantalla

: GestorDeCliente : Transacción : Cuentas : Cuen ta

1: opcion (transferencia)

4: IntroducirImporte

2: transferencia

3: visualizar (Teclee im port e)

5: importe

19 : vis ualizar (Transfe rencia real izada)

20: visuali zar (Reti re su tar jet a)

6: visual izar (Teclee cuent a destino)

9: t ransferencia (cuentaO rigen, cuen taDestino,import e)

10: reintegro (cuentaOrigen, importe)

11: reintegro (importe)

12: OK

13: OK

18: OK

7: cuentaDes tino (cuent a)

8: cuentaDestino (cuenta)

14: ingreso (cuentaDestino, importe)

15: ingreso (im porte)

16: OK17: OK

Diseño del caso de uso: ”Transferencia”Secuencia correcta


: Cliente del banco : Teclado : Pantalla

: GestorDeCliente : Transacción : Cuentas : Cuen ta

1: opcion (transferencia)

4: IntroducirImporte

7: cuentaDes tino (cuent a)

2: transferencia

3: visualizar (Teclee im port e)

5: importe

15: visualiz ar ((No hay fondos))

16: visuali zar (Reti re su tar jet a)

6: visual izar (Teclee cuent a destino)

8: cuentaDestino (cuenta)

9: t ransferencia (cuentaO rigen, cuen taDestino,import e)

14: no hay fondos

10: reintegro (cuentaOrigen, importe)

13: no hay saldo

11: reintegro (importe)

12 : no hay saldo

Diseño del caso de uso: ”Transferencia”No hay saldo en la cuenta origen


Modelo de clases de diseño

CajonDinero

Impresora

LectorDeTarjetas

Pantalla

Teclado

DarDinero

Cliente del banco

GestorDeCliente

Cuenta

UsuariosDelBanco

Transacción

Cuentas


CajonDinero

crearCajon() : CajonDineroabrirCajon()cerra rCajon()contarCantidad() : Dinero

LectorDeTarjetas

crearLec tor() : Lect orDeTarjetasleerTarjeta() : datosTarjeta

Pantalla

vis uali zar(m ensaje : St ring)c rearPantalla() : Pantal la

Teclado

crearTeclado() : TecladoleerPIN() : unPINleerOpcion() : unaOpcionleerCantidad() : DineroleerNumCuenta() : unIDCuenta

DarDinero

crear() : DarDineroexpulsa r(im porte : Dinero)

Gesto rDeCliente

crear() : GestorDeClientecreaCajeroVi rtual()inic iarSesion()

Impresora

crearImpresora() : Im pres oraimprimir(mensaje : String)

Diseño de las clases


Diseño de las clases

GestorDeClientemiTransaccion : Transacción

crear() : GestorDeClientecreaCajeroVirtual()iniciarSesion()visualizar(resultados : String)

TransacciónmiCliente : GestorDeClientedatosTarjeta : DatosTarjetanumIntentosFallidos : 1..3 = 0cuentas : Cuentasusuarios : UsuariosDelBanco

almacenarDatos(datos : DatosTarjeta)validar(importe : Dinero, cantidad : Dinero)autenticar(datos : DatosTarjeta, PIN : UnPIN) : BooleanretirarDinero(importe : Dinero) : BooleaningresarDinero(importe : Dinero) : Booleantrasnsferencia(cuentaOrigen : Cuenta, cuentaDestino : Cuenta, importe : Dinero) : Boolean

UsuariosDelBancousuarios : Dictionary

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

Cuentascuentas : Dictionary

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

Cuentadatos : DatosCuentalimiteDiario : Dinero = 50000

reintegro(importe : Dinero) : Booleaningreso(importe : Dinero) : Boolean


Esperando t arjeta

Leyendo tarjeta

tar jeta int roducida

Esperando PIN

Validando PIN

PIN introducido( PIN )

Recogiendo tarjeta

Es perando opción

[ incorrec to ]

[ > 3 intentos ]

[ correcto ]

Ingresando

ingreso( importe )

Reintegrando

reintegro( importe )

Transferencia

transferencia( cuenta, importe )

Expulsando dinero

[ OK ]

Expulsar tarjeta

dinero retirado

[ Not OK ]

Clase GestorDeCliente


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

(compilándolos y enlazándolos en uno o más ejecutables)


Artefactos de implementación


Interfaz

Arquitecto

Modelo de implementac.

Implementac. subsistema


Integrador de sistemas


Componente

Integración de sistema


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


Artefactos de implementación: Modelo de Implementación

Sistema deimplementac.

**

*

Interfaz

*

Subsistema deimplementac.

**

Componente


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

Componente

«trace»

Clase de diseño

InterfazInterfaz


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.

► r

*

*

Interfaz

*


* *

Componente


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.

Interfaz

► realiza


► realiza

*

*

Componente


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)


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

Integrar sistemas

Arquitecto



Implementación de la arquitectura

Implementar una clase

Implementar un subsistema

Realizar prueba de unidad


Actividades: Implementación de la Arquitectura

Arquitecto

Implementación de la arquitectura


Modelo de análisis

Descripción arquitectura (vista de modelo de diseño y despliegue)

Componente (esbozado y asignado

a un nodo)

Descripción arquitectura (vista de modelo de

implement. y despliegue)


Actividades: Integrar el Sistema

Integrar sistemas






Modelo de diseño

Plan de integración de construcciones


Actividades: Implementar un Subsistema


Implementar un subsistema

Descripción arquitectura (vista de modelo de

implementación)

Plan de integración de construcciones

Subsistema de diseño

Interfaz

Subsistema de implementac.

Interfaz


Actividades: Implementar una Clase


Implementar una clase Componente

(implementado)Interfaz

Clase de diseño(diseñada)


Actividades: Realizar una Prueba de Unidad


Realizar prueba de unidad Componente

(unidades probadas)Interfaz

Clase de diseño(implementada)


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.


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

Componentede prueba

*

Caso de pruebaX X

Procedimientode prueba


1. Planificar prueba2. Diseñar prueba

– Describir casos de prueba de cada construcción– Identificar y estructurar los procedimientos de prueba

3. Implementar prueba4. Realizar pruebas de integración5. Realizar prueba de sistema6. Evaluar prueba

Flujo de trabajo de pruebas


Caso de uso Realizaciónen análisis

<<trace>>

Realizaciónen diseño

<<trace>>

Resumiendo...


Resumiendo...

<<trace>> (1:1)

Realizaciónen diseño

Realizaciónen implementación

<<trace>>

<<implem. subsystem>>

<<file>>

<<file>>

<<desing subsystem>>



• 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


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)



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



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



• 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



• 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


Planificar

Varias iteracionesen cuatro fases

Planificar

Experienciapasada

Plan de proyecto

Plan de iteración

Información sobreel sistema propuesto

Informacióndel 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

• Pensar a largo plazo


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– Lista de riesgos


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



• 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



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



• 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


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.




– Las fases– Las iteraciones


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

• Evolución del conjunto de modelos

un ejemplo: el proceso unificado de desarrollo · un ejemplo: el proceso unificado de desarrollo...

Documents