Proceso Unificado (Parte I)

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
Ingeniera del Software
Un ejemplo: el Proceso Unificado
Caractersticas del Proceso Unificado

Flujos de trabajo fundamentales
Iteracin genrica
Planificar
Gestionar los riesgos
Recursos
Evaluar

UML
Basado en casos de uso
Centrado en la arquitectura
Iterativo-Incremental
Modelos del proceso

Iteracin genrica
Planificar
Recursos
Evaluar
El Proceso Unificado (UP)

Unificacin de tres metodologas de desarrollo
basadas en el paradigma orientado a objetos.
OOSE: Object Oriented Software Engineering (Casos de Uso)
Jacobson, I.
Booch (Diseo) Booch, G.
OMT: Object Modeling Technique (Anlisis) Rumbaugh, J.
El Proceso Unificado (UP)

Es ms que un proceso de desarrollo software
un marco de trabajo que puede especializarse
Basado en componentes conectados a travs de

interfaces
Utiliza UML - Unified Modeling Language
Dirigido por casos de uso
Iterativo e incremental
UML
UML es un lenguaje de modelado
Permite la construccin 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 construccin:
Elementos: bloques bsicos
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: Interaccin, Estados...
Agrupacin: Paquetes
Anotacin: Notas
Relaciones:
Dependencia (Relacin de Uso)

Asociacin (Relacin estructural)
Generalizacin (Representacin de la herencia.)
Realizacin
UML - Diagramas
Ofrecen distintas perspectivas de una abstraccin 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.
Estticos(estructura)
D. de Clases
D. de Objetos
D. de Componentes
D. de Despliegue
Dinmicos(comportamiento)
Casos de Uso
Secuencia
Colaboracin
Estados
Actividades
Interaccin
Diagrama de clases
Motor
1..4
1
Avin
Vendedor de billetes
Piloto
1..2
Vuelo
Reserva
{ disjunta, completa }
1
Avin militar
Avin comercial
Lnea area
{ disjunta, completa }
Avin de carga
Avin de pasajeros
Diagramas de Componentes
Control y Anlisis
Interfaz de Terminal
Comment
Comment
Gestin de Cuentas
Comment
Rutinas de Coneccion
Comment
Acceso a BD
Comment
10
Diagramas de Despliegue
Servidor Central
Control y Anlisis
Comment
Acceso a BD
Comment
Comment
Terminal de Consulta
Comment
Punto de Venta
Comment
Comment
Gestin de Cuentas
Comment
Comment
11
Diagrama de casos de uso
V enta Normal
C liente
Venta en Rebajas
Vendedor
V enta en Oferta
12
Diagrama de estados
Es perando
t arj eta
tarjeta int ro ducida
Leyendo
tarjeta
E sp erando
PIN
P IN introducido( P IN )
[ incorrec to ]
Rec ogiendo
tarjeta
[ > 3 intentos ]
Validando
PIN
[ correc to ]
Es perand o
opc in
i ngres o ( im porte )
trans ferencia( cuenta, im porte )

reintegro( im porte )
Ingre sando
Reintegrando
Transferenc ia
[ OK ]
Ex pulsando
dinero
[ Not OK ]
dinero retirado
E xpulsar
tarjeta
13
Diagrama de colaboracin
5: c u enta des t in o
3: c antidad
1: trans ferenc ia
6: t rans ferenc i a (c uenta, c anti dad)
11 : OK
: Interfaz de ca jero
: Cliente del banc o
2: te c lee c ant id ad
: Trans ac cin
7: r ei nteg ro (c an ti dad)
9: ingres o (c antidad)
4: te c lee c uenta des tino
8: OK
10: OK
12: trans ferenc ia realiz ada
c uentaOrigen : Cuenta
c uentaDes tino : Cuenta
14
Diagramas de Secuencia
: S oc io
: E ncargado
: Lib ro
: Fic ha socio
: Fic ha libro
: P rstam o
Coger libro
S olicitar prs tam o

V erific ar situac in socio
S it uaci n s o cio ok
V erificar situac in libro
S ituacin libro ok
Introducir prs tam o
A ut orizar p rst amo
15
Diagramas de actividad
Pasajero
Solicitar pasaje
Vendedor
Airline
Verificar
existencia vuelo
Dar detalles vuelo
Informar alternativas
y precios
Seleccionar vuelo
Solicitar pago Reservar plazas

Confirmar
plaza reservada
Pagar pasaje
Emitir billete
16
Dirigido por casos de uso

Usuario: alguien o algo.
Una interaccin con el usuario es un caso de uso.
Un caso de uso:
Es una funcin 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 diseo e implementacin.
Pruebas.
Se desarrollan y evolucionan junto a la arquitectura del

sistema.
17
Edificio: estructura, servicios, electricidad, fontanera,...
Agrupa aspectos estructurales y dinmicos
significativos
Influencias: plataforma (BBDD, SO, protocolo de
comunicacin,...), aspectos legales, componentes
reusables disponibles, requisitos no funcionales,...
Es una vista del diseo completo que hace visibles las
caractersticas principales.
Cmo se relacionan casos de uso y arquitectura?
Funcin y forma
18
Tareas:
Crear una arquitectura inicial no especfica 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.
Evolucin.
19
Iterativo - Incremental
Divisin del proyecto.

Una iteracin produce un incremento.
Iteraciones controladas.
Factores para la seleccin en una iteracin:
La iteracin trata un grupo de casos que extienden la
funcionalidad.
La iteracin trata los riesgos ms importantes.
Incremento no siempre es aditivo.

Cada iteracin:
casos relevantes-diseo quiado por arquitecturaimplementar-verificar
Beneficios.
20
Iterativo - Incremental
Varios ciclos que concluyen con un producto.
Cdigo fuente, manuales y documentos.
Hitos por fases (Milestones)
21
El proceso
Papeles y actividades
Analista de
Sistemas
Especifica
Casos de Uso
Diseador de
Interface de Usuario
Disea
Test
Analiza un
Caso de Uso
Analiza
una Clase
Analiza
un
Paquete
Implementacin
de Arquitectura
Ingeniero de
pruebas
Integrador de
Sistemas
Ejecuta Test
de Integracin
Prototipo del
Interfaz de Usuario
Ingeniero de
Casos de Uso
Evalua
Test
Integra
Sistema
Detalla un
Caso de Uso
Anlisis de
Diseo de
Arquitecto Prioriza
Casos de Uso Arquitectura Arquitectura
Ingeniero de
Componentes
Planifica
Test
Descubre Actores Estructura Modelo

y Casos de Uso de Casos de Uso
Ingeniero de
pruebas de
integracin
Ingeniero de
Ejecuta test
pruebas de
del sistema
sistema
Disea un
Caso de Uso
Disea
una clase
Implementa
una clase
Disea un
Subsistema Implementa
Subsistema
Implementa
Test
Ejecuta Test
Unitario
22
El proceso
El producto (salidas)
#
#$
%
#!
#
#!
&
#
'
"
&
(&
#!
)
23
El proceso
Fases, iteraciones y actividades

$+ +
*
$
*
"
#
/
'$
/0
/1
/2
/3
/4
6 777(
24
El proceso

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
Iniciacin, Elaboracin, Construccin, Transicin
Dentro de cada fase hay varias iteraciones
Una iteracin representa un ciclo de desarrollo completo.
El nfasis en cada flujo de trabajo es diferente dependiendo de la
fase
25
El proceso
26

Requisitos
Anlisis
Diseo
Implementacin
Pruebas
Iteracin genrica
Planificar
Recursos
Evaluar
27
Captura de requisitos
La captura de requisitos es complicada
Creamos cdigo para otros
Los usuarios no los conocen y les cuesta especificarlos de
forma precisa
Suelen ser varios usuarios sin una visin global
Los requisitos cambian
Las condiciones en las que se especifico un requisito varian
28
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
29
Pasos a seguir
Enumerar los requisitos candidatos

Comprender el contexto del sistema
Capturar requisitos funcionales
Capturar requisitos no funcionales
Se realizan de forma conjunta
30
TAREA
Enumerar requisitos
candidatos
Entender el contexto
del sistema
Capturar requisitos
funcionales
Capturar requisitos no
funcionales
PRODUCTOS (artifact)
Lista de caractersticas
Modelo de negocio o de
dominio
Modelo de casos de uso
Requisitos suplementarios
o casos individuales
31
Artefactos de requisitos
Actores
Casos de uso
Varios diagramas para diferentes perspectivas
Descripcin de la arquitectura
Glosario
Prototipo de la interfaz de usuario
1
Sistema de casos de uso
*
*
Caso de uso
32
Artefactos de requisitos
33
Flujo de trabajo de la captura de

requisitos funcionales (Actividades)
34

Encontrar actores y casos de uso
"
#$
35

Priorizar casos de uso
!
%
36

Detallar un caso de uso
37

Prototipar la interfaz de usuario
38

Estructurar el modelo de casos de uso
39
Caso de uso Validar usuario

Flujo de eventos
ACCIN DEL ACTOR
RESPUESTA DEL SISTEMA
1. Este caso de uso empieza

cuando un Cliente introduce una
tarjeta en el cajero
2. Pide la clave de identificacin
3. Introduce la clave
4. Comprueba la clave
5. Si es vlida presenta las opciones
disponibles y se termina el caso de
uso
CAMINOS ALTERNATIVOS
Lnea 3. El cliente cancela la transaccin
Lnea 4. La clave no es vlida y se reinicia el caso de uso. Si ocurre tres
veces se cancela la transaccin y no se devuelve la tarjeta
HAY QUE DEFINIR ESTOS DOS FLUJOS DE EVENTOS!!
40
Caso de uso Sacar dinero

Flujo de eventos
ACCIN 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 operacin de
Reintegro
3. Pide la cantidad a retirar.
4. Introduce la cantidad requerida
5. Procesa la peticin y da el dinero

solicitado.
Devuelve la tarjeta y genera un
recibo
6. Recoge la tarjeta.
7. Recoge el recibo
8. Recoge el dinero y termina el CU
41
Caso de uso Sacar dinero

Flujo de eventos
CAMINOS ALTERNATIVOS
Lnea 5: La cantidad solicitada supera el saldo. Se indica el error y se

cancela la operacin.
Lnea 5: La cantidad solicitada supera el lmite diario. Se indica el error y
se vuelve a pedir otra cantidad.
Lnea 5: En el cajero no hay dinero.
HAY QUE DEFINIR ESTOS TRES FLUJOS DE EVENTOS!!

Podramos 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
42
Ejemplo. Cajero automtico

"
6 06
8
+
99 :
;;
+
)
16
43
Anlisis
Se trabaja con conceptos

Especificacin ms precisa de los requisitos
Se utiliza el lenguaje de desarrolladores
Facilita comprensin, preparacin,
modificacin y mantenimiento de requisitos
Primera aproximacin al modelo de diseo
44
Artefactos de anlisis
'
!
&
'
'
'
45
Artefacto: Modelo de Anlisis
)
'
'
'
!
&
'
46
Artefacto: Clases de Anlisis

Una clase de anlisis representa una abstraccin de
una o mas clases del diseo del sistema
Se centra en el tratamiento de los requisitos
funcionales
Son evidentes en el dominio del problema.
Sus atributos, operaciones y relaciones estn a un
nivel mayor de abstraccin.
Pueden clasificarse fcilmente en clases de entidad,
interfaz y de control.
47
Artefacto: Clases de Anlisis
'
48
Artefacto: Realizacin de caso de usoanlisis

Define como se lleva a cabo y se ejecuta un caso de
uso en trminos de clases del anlisis y de sus
objetos de anlisis en colaboracin.
Una realizacin de caso de uso queda definida por:
Diagramas de clases del anlisis
Diagramas de interaccin de objetos del anlisis
Una descripcin textual del flujo de sucesos
49
Artefacto: Realizacin de caso de usoanlisis (Diag. De Clases)
50
Artefacto: Realizacin de caso de usoanlisis (Diag. De Colaboracin)
51
Artefacto: Realizacin de caso de usoanlisis: (Desc. Textual)

El comprador consulta a travs 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
52
Artefacto: Paquete del anlisis

Proporcionan un medio para organizar los artefactos
del modelo de anlisis en piezas manejables.
Son cohesivos y dbilmente acoplados
Basados en los requisitos funcionales y en el dominio
del problema.
Generan subsistemas del diseo
*
'
*
!
'
&
'
53
Artefacto: Descripcin de la Arquitectura

Contiene una Vista de la arquitectura del modelo de
anlisis
Descomposicin del modelo en paquetes
Clases fundamentales:
De entidad, importante en dominio

De interfaz, comunicacin importante
De control, con amplia cobertura
Generales, centrales y con muchas relaciones
Realizaciones de casos de uso
54
Flujo de trabajo del anlisis

1. Anlisis de la arquitectura
Identificar paquetes de anlisis
Identificar clases de entidad
Requisitos comunes
2. Analizar (refinar) un caso de uso

Identificar clases de anlisis
Describir interacciones entre los objetos del anlisis
Capturar req. especiales sobre la realizacin del CU
3. Analizar una clase

Identificar responsabilidades y atributos
Identificar relaciones: asoc., agreg. y gener.
Capturar req. especiales sobre la realizacin del CU
4. Analizar un paquete
55
Actividades
'
56
Actividades: Anlisis de la Arquitectura
'
!
'
'
%
'
57
Actividades: Analizar un caso de uso
(
!
&
%
'
'
'
58
Actividades: Analizar una clase
!
&
'
'
'
59
Actividades: Analizar un paquete
(
%
'
'
'
60
Anlisis del caso de uso: Validar usuario
V ali dar usuario
Interfaz de caj ero
Re ali z ac i n en an li sis
UsuariosDelB anc o
A utenti car
(fro m L o g i ca l V i e w)
(fr om L og i ca l V ie w)
61
Anlisis del caso de uso: Validar usuario

Secuencia correcta
3: cdigo
1: introducir tarjeta
: Cliente del banco
4: autentica (datos, cdigo)
7: visualiza (opciones)
2: teclear cdigo : Interfaz de cajero
: Autenticar
5: valida (datos, codigo)
8: seleccioneOpcion (opciones)
6: OK
: UsuariosDelBanco
62
Anlisis del caso de uso: Validar usuario.

Cdigo incorrecto
3: cdigo
1: introducir tarjeta
: Cliente del banco
4: autentica (datos, cdigo)
7: visualiza (error)
2: teclear cdigo : Interfaz de cajero
: Autenticar
8: teclear cdigo
5: valida (datos, codigo)
6: Error
: UsuariosDelBanco
63
Anlisis del caso de uso: Transferencia

- Suponemos que el usuario ya ha sido identificado (se ha ejecutado
el caso de uso anterior).
- Ahora selecciona la opcin transferencia. Consideramos que la
cuenta origen es la de la tarjeta y hay que teclear la destino.
- El importe y el nmero de cuenta destino deben darse juntos. Evitar
condiciones de carrera: mirar primero si hay saldo y luego sacar.
Transferencia
Interfaz de cajero
Realizacin en anlisis
Transaccin
Cuenta
64

Secuencia correcta
5: cuenta destino
3: cantidad
1: transferencia
6: transferencia (cuenta, cantidad)
: Interfaz de cajero
: Cliente del banco
11: OK
: Transaccin
7: reintegro (cantidad)
2: teclee cantidad
9: ingreso (cantidad)
4: teclee cuenta destino
8: OK
10: OK
12: transferencia realizada
cuentaOrigen : Cuenta
cuentaDestino : Cuenta
65

No hay saldo en la cuenta origen
5: cuenta destino
3: cantidad
1: transferencia
9: no hay fondos
: Transaccin
: Cliente del banco

2: teclee cantidad
8: no hay saldo
10: no hay fondos
66

No se puede acceder a la cuenta destino
5: cuenta destino
11: rollback
3: cantidad
1: transferencia
12: error
: Cliente del banco

2: teclee cantidad
: Transaccin
8: OK
9: ingreso (cantidad)
10: error
13: error
cuentaDestino : Cuenta
67
Modelo de clases de anlisis
Cliente del banco
Interfaz de cajero
Transaccin
Autenticar
Cuenta
UsuariosDelBanco
68
Anlisis 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
69
Anlisis de las clases

CLASE TRANSACCIN
Interviene en cuatro casos de uso:
- validar usuario
autentica (datos, cdigo)
atributos - - > cdigo cuenta
- sacar dinero
retirarDinero (importe)
- ingresar dinero
ingresarDinero (importe)
- transferencia
transferencia (cuenta, cantidad)
rollback
70
Diseo
Se modela el sistema para que de soporte a los requisitos
funcionales y no funcionales.
Su entrada esencial es el modelo de anlisis (una comprensin
detallada de los requisitos)
Propsitos:
Profundizar en la requisitos no funcionales y restricciones
dependientes de la plataforma.
Crear una entrada apropiada para la implementacin
Descomponer los trabajos de implementacin en partes mas
manejables y que permitan concurrencia.
Capturar las interfaces entre los subsistemas.
Es el centro de atencin final de la fase de elaboracin e

iteraciones iniciales de la fase de construccin
71
Artefactos de diseo
!
&
72
Artefactos de diseo: modelo de diseo

Modelo de objetos UML que contiene el diseo de la
aplicacin.
Describe la realizacin fsica de los casos de uso:
como afectan los requisitos funcionales, no
funcionales y otras restricciones.
*
*
)
*
*
(
!
&
73
Artefactos de diseo: Clase de diseo

Sintaxis del lenguaje de programacin
Visibilidad de atributos y operaciones (public, private,
protected)
Traduccin de las relaciones
Mtodos por pseudocdigo
Estereotipos que se correspondan con
construcciones del lenguaje de programacin.
Pueden realizar interfaces
+
74
Artefactos de diseo: Realizacin de un

caso de uso-diseo
Es una colaboracin en el modelo de diseo que
describe como se realiza un caso de uso en termino
de clases y objetos de diseo
Contenido:
Diagramas de clases de realizacin

Diagramas de interaccin (clases, subsistemas, interfaces)
Flujo de sucesos-diseo
Requisitos de implementacin
,
!
!
&
'
&
75
Artefactos de diseo: Subsistema de

Diseo
Para organizar los artefactos del diseo en piezas
mas manejables.
Debe ser cohesivo y dbilmente acoplado
*
)
+
(
!
&
76
Artefactos de diseo: Interfaz

Se utilizan para especificar las operaciones que
proporcionan las clases y subsistemas de diseo
Separan la especificacin de funcionalidad en
trmino de operaciones de sus implementaciones en
trminos de mtodos
*
(
*
)
77
Artefactos de diseo: Descripcin de la

Arquitectura
Descomposicin en subsistemas
Traza con clases de anlisis
Clases fundamentales (abstractas)
Clases generales y centrales
Realizaciones de caso de uso
78
Artefactos de diseo: Modelo de

Despliegue
Representa una correspondencia entre la
arquitectura del Hardware y la arquitectura
del Software
Describe la distribucin fsica del sistema en
nodos de computo.
Cada nodo representa un recurso de
computo
Las relaciones entre nodos representan
medios de comunicacin entre ellos.
La funcionalidad de un nodo se determina
por los componentes que se le asignan
79
Diseo: Actividades
80
Diseo: Actividades
1. Diseo de la arquitectura
Identificar nodos y configuracin, subsistemas, clases
2. Disear un caso de uso

Identificar clases de diseo y subsistemas
Distribuir comportamiento del CU
Capturar requisitos de implementacin
3. Disear una clase

4. Disear un subsistema
81
Actividades: Diseo de la Arquitectura
'
%
'
82
Actividades: Diseo de un caso de uso
!
&
(
!
'
)
(
83
Actividades: Diseo de una clase
!
(
&
(
'
84
Actividades: Diseo de un Subsistema
(
%
(
(
85
Diseo del caso de uso: Validar usuario
V al id ar usuario
Realizac in en diseo
(fro m Use Ca se V i e w)
Lec torDeTarjetas
GestorDeCliente
Us uariosDelB anco
Pantalla
Teclado
Transacc in
86

Secuencia correcta
: Cliente del banco
:
Lect orDeTarj etas
: Pa ntal la
: Tec lado
: GestorDeCliente
: Tran s acc in
: Usuarios DelB anc o
1: l eerTarj eta
2: i ntroduci rTarj eta (tarjet a)
3: datosTarjeta (tarjeta)
4: vis ualiz ar (In troduci r P IN)
5: OK
6: leerP IN
7: introduci rP IN (PIN)
8: datosP IN (P IN)
9: au tent ic a (datos , PIN)

10: valida (datos , P IN)
11: OK
12: alm ac enaDatos (datos)
14: visualiz ar (opc iones )
13: vi sual iz a (opciones)
87

Cdigo incorrecto
: Cliente del banc o
:
Lec t orDeTarj etas
: Pa ntal la
: Teclado
: Ges torDeCliente
: Tran sacc in
: Us uarios DelB anco
1: l eerTarj eta
2: i ntr oduci rTarj eta (tarjet a)
3: datosTarjeta (tarjeta)
4: vis ualiz ar ( In troduci r P IN)
5: OK
6: leerPIN
7: introduci rPIN ( PIN)

8: datosP IN (PIN)
9: au tent ic a (datos , PIN)

10: valida (datos, P IN)
11: E rror
13: vis u ali z ar (error PIN)
12: vis ualiza (error P IN)
Hay ms escenarios: anular transaccin y tres intentos

88
Diseo del caso de uso: Transferencia

- Suponemos que el usuario ya ha sido identificado (se ha ejecutado
el caso de uso anterior). Ahora selecciona la opcin transferencia.
Transferenc ia
(fro m Use Ca se V i e w)
Realizacin en dis eo,

trans ferenc ia
2
Teclado
Pantalla
GestorDeCliente
Trans ac cin
Cu entas
Cu enta
89

Secuencia correcta
: Cliente del banco
: Teclado
1: opcion (transferencia)
: P antalla
: Ges torDeCliente
: Transac cin
: Cuentas
: Cuen ta
2: trans ferenc ia
3: vis u aliz ar ( Tecl ee im port e)
4: IntroducirImporte
5: im porte
6: vi s ual izar (Te c lee cuent a des ti no)
7: c u entaDes ti no ( cuent a)
8: c uentaDestino (c uenta)
9: t ransferencia (cuentaO rigen, c uen taDestin o,impo rt e)
10: reintegro (cuentaOrigen, im porte)
11: reintegro (im porte)
12: OK
13: OK
14: ingreso (c uentaDes tino, im porte)
15: ingre so (im porte)
16: OK
17: OK
18: OK
19 : vis ualiz ar (Tra ns fe renci a real iz ada)
20: vis u ali zar ( Reti re su tar jet a)
90

No hay saldo en la cuenta origen
: Cliente del banco
: Tec lado
1: opcion (transferencia)
: P antalla
: Ges torDeCliente
: Transacc in
: Cuentas
: Cuen ta
2: transferencia
3: visu alizar (Tecl ee im port e)
4: Introduc irIm porte
5: im porte
6: vi sual izar (Te c lee c uent a desti no)
7: cu entaDes ti no (cuent a)
8: cuentaDestino (cuenta)
9: t rans ferencia (c uentaO rigen, cuen taDes tin o,im po rt e)
10: reintegro (cuentaOrigen, im porte)
11: reintegro (im porte)
12 : no ha y saldo
13: no hay s aldo
14: no hay fondos
15: visualiz ar ((No hay fondos))
16: visu ali zar (Reti re su tarjet a)
91
Modelo de clases de diseo

CajonDinero
UsuariosDelBanco
Impresora
Cliente del banco
LectorDeTarjetas
GestorDeCliente
Transaccin
Pantalla
Cuentas
Teclado
DarDinero
Cuenta
92
Diseo de las clases

P antalla
vis uali zar(m ensaj e : S t ri ng)
c rearP antall a() : P antal la
Lec torDeTarjetas
c rearLec tor() : Lec t orDe Tarj eta s
leerTarjeta() : dato s Tarj eta
Tec la do
crearTec lado() : Tec lado
leerP IN() : unP IN
leerOpc ion() : unaOpcion
leerCantidad() : Dinero
leerNum Cuenta() : unIDCuenta
Gesto rDeCli ente

c rear() : GestorDeClie nte
c reaCajeroVi rtual()
inici arS esion()
Im presora
c rearIm p resora() : Im pres ora
im prim ir(m ens aje : String)
DarDinero
crear() : DarDinero
ex p ulsa r(im porte : Dinero)
CajonDinero
crearCajon() : CajonDi nero
abrirCajon()
cerra rCajon()
contarCantidad() : Dinero
93
Diseo de las clases

Transaccin
miCliente : GestorDeCliente
datosTarjeta : DatosTarjeta
numIntentosFallidos : 1..3 = 0
cuentas : Cuentas
usuarios : UsuariosDelBanco
GestorDeCliente
miTransaccion : Transaccin
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
Cuentas
crear() : GestorDeCliente
creaCajeroVirtual()
iniciarSesion()
visualizar(resultados : String)
cuentas : Dictionary
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 = 50000
reintegro(importe : Dinero) : Boolean
Ingeniera del
Software : Dinero) : Boolean
ingreso(importe
94
Clase GestorDeCliente
Es perando
t arj eta
tarjeta int ro ducida
Leyendo
tarjeta
E sp erando
PIN
P IN introducido( P IN )
[ incorrec to ]
Rec ogiendo
tarjeta
[ > 3 intentos ]
Validando
PIN
[ correc to ]
Es perand o
opc in
i ngres o ( im porte )
trans ferencia( cuenta, im porte )

reintegro( im porte )
Ingre sando
Reintegrando
Transferenc ia
[ OK ]
Ex pulsando
dinero
[ Not OK ]
dinero retirado
E xpulsar
tarjeta
95
Implementacin
Se implementa el sistema en trminos de
componentes: ficheros de cdigo fuente, scripts,
ficheros de cdigo binarios, ejecutables y similares.
Objetivos:
planificar las integraciones de sistema necesarias en cada
iteracin
distribuir el sistema asignando componentes ejecutables a
nodos en el diagrama de despliegue
implementar las clases y subsistemas encontrados durante el
diseo
probar los componentes individualmente, integrarlos
(compilandolos y enlazandolos en uno o ms ejecutables)
96
Artefactos de implementacin
$
97
Artefactos de implementacin: Modelo de

Implementacin
Cmo los elementos del modelo de diseo (clases) se
implementan en trminos de componentes (ficheros de
cdigo fuente, ejecutables...)
Cmo se organizan los componentes (de acuerdo con
los mecanismos de estructuracin y modularizacin del
entorno de implementacin y los lenguajes de
programacin utilizados)
Cmo dependen los componentes unos de otros
98
Artefactos de implementacin: Modelo de

Implementacin
*
)
)
$
*
*
*
*
(
99
Artefactos de implementacin:
Componente
Empaquetamiento fsico 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 diseo que
implementan.
dependencias de compilacin entre ellos (unos deben haberse
compilado antes para poder compilar otros).
100
Componente
<<executable>> programa que puede ser ejecutado en
un nodo
<<file>> fichero que contiene cdigo fuente o datos
<<library>> librera esttica o dinmica
<<table>> una tabla de base de datos
<<document>> un documento
,
(
(
101
Subsistema de Implementacin
Forma de organizar los artefactos del
modelo de implementacin en trozos ms
manejables.
Un subsistema puede estar formado por:
componentes
interfaces
otros subsistemas (recursivamente)
Se manifiestan a travs de un mecanismo

de empaquetamiento concreto de un
entorno de implementacin determinado.
Paquete en Java
Proyecto en VB
Etc.
*
)
$
+
*
*
(
102
Artefactos de implementacin: 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.
*
(
*
)
$
103
Descripcin de la arquitectura
La descomposicin del modelo de implementacin en
subsistemas, sus interfaces y las dependencias entre
ellos (cmo vienen dados por los equivalentes del
modelo de diseo suele ser innecesario
representarlos)
Componentes clave (los que tienen traza a clases de
diseo significativas arquitectnicamente, y los
ejecutables)
104
Artefactos de implementacin: Plan de

Integracin de las Construcciones
Describe la secuencia de construcciones necesarias
en una iteracin.
Para cada construccin debe describir:
funcionalidad que se espera que sea implementada en esa
construccin (lista de casos de uso o escenarios o parte de
ellos, tambin puede incluir requisitos adicionales)
partes del modelo de implementacin afectadas por la
construccin (lista de los subsistemas y componentes
necesarios para implementar esa funcionalidad)
105
Implementacin: Actividades
(
(
(
106
Actividades: Implementacin de la
Arquitectura
'
%
%
107
Actividades: Integrar el Sistema
!
(
$
$
108
Actividades: Implementar un Subsistema
)
$
(
)
(
(
109
Actividades: Implementar una Clase
110
Actividades: Realizar una Prueba de

Unidad
111
Prueba
Verificamos el resultado de la implementacin
probando cada construccin
Objetivos de la prueba
Planificar las pruebas necesarias para cada iteracin (pruebas
de sistema y pruebas de integracin)
Disear e implementar las pruebas diseando los casos de
prueba
Realizar las diferentes pruebas.
112
Artefactos de pruebas
Modelo de pruebas
Casos de prueba
Procedimientos de prueba
Componentes de prueba
Plan de prueba
Defectos
Evaluacin de la prueba
Sistema de pruebas
Caso de prueba
X
Procedimiento
de prueba
Componente
de prueba
113
Flujo de trabajo de pruebas

1. Planificar prueba
2. Disear prueba
Describir casos de prueba de cada construccin
Identificar y estructurar los procedimientos de prueba
3. Implementar prueba
4. Realizar pruebas de integracin
5. Realizar prueba de sistema
6. Evaluar prueba
114
Resumiendo...
<<trace>>
Caso de uso
<<trace>>
Realizacin
en anlisis
Realizacin
en diseo
115
Resumiendo...
<<trace>>
Realizacin
en implementacin
Realizacin
en diseo
<<desing subsystem>>
<<trace>> (1:1)
<<implem. subsystem>>
<<file>>
<<file>>
116

Iteracin genrica
Divisin del trabajo en fases
Planificar
Recursos
Evaluar
117
Iteracin genrica
Incluye:
Planificacin
Requisitos
Anlisis
Diseo
Implementacin
Pruebas
Evaluacin
El contenido vara para adaptarse al objetivo de cada

fase.
118

Fase de inicio: establecer viabilidad
Objetivo:
Anlisis 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 difcil (expresada en funcin de algunos modelos)
3. Identificar riesgos crticos (los que afecten a la viabilidad)
4. Demostrar a usuarios y clientes un prototipo (exploratorio)
119

Fase de elaboracin: factibilidad
Objetivo
Arquitectura estable para guiar el sistema
Estimacin de de costes para fases sisguientes con precisin
Actividades:
1. Lnea base de la arquitectura. Consiste en: modelos, descripcin
de la arquitectura e implementacin ejecutable de la arquitectura.
2. Identificacin 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 construccin.
5. Planificacin: personal, coste.
120

Fase de construccin
Objetivo
Versin beta
Actividades:
1. Terminar la identificacin, descripcin y realizacin de todos los
casos de uso.
2. Finalizar el anlisis, el diseo la implementacin y pruebas.
3. Mantener la integridad de la arquitectura.
4. Monitorizar los riesgos crticos.
121

Fase de transicin: 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 versin beta.
Lecciones aprendidas
Asuntos tiles para la versin siguiente
122

Iteracin genrica
Planificar
Las fases
Las iteraciones
Los criterios de evaluacin

Recursos
Evaluar
123
Planificar
Varias iteraciones
en cuatro fases
Plan de proyecto
Informacin sobre
el sistema propuesto
Informacin
del dominio
Planificar
Plan de iteracin
Experiencia
pasada
124
Planificar las fases

Establecer:
Asignaciones de tiempo y fecha de entrega por cada fase
(inestable hasta fin de elaboracin)
Hitos principales y criterios de aceptacin
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
divisin de fases en iteraciones
Pensar a largo plazo
125
Planificar las iteraciones

Definimos:
Planificacin de la Iteracin: cuanto tiempo, fecha de terminacin.
Contenido de la Iteracin: Contenido. Ya est esbozado en el plan del
proyecto pero al comenzar cada iteracin se debe detallar:
Casos de uso
Riesgos tcnicos 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 iteracin siguiente se va detallando.

El nmero de iteraciones de cada fase esta determinado por la
complejidad del sistema.
126
Planificar las iteraciones

La 1 iteracin suele ser ms difcil
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
127
Planificar los criterios de evaluacin

Criterios para establecer la satisfaccin de los
objetivos de cada iteracin (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
128

Iteracin genrica
Planificar
Priorizar los casos de uso
Categoras de riesgos
Recursos
Evaluar
129
Riesgos
Lista de riesgos:
Identificador
Descripcin
Prioridad (crtico, 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 peridicas para
revisar el estado de los riesgos
130
Riesgos
Influencia en el plan de iteraciones
Desarrollar prototipo para conocer riesgo

Incrementar el esfuerzo
Prolongar la planificacin
Calidad o rendimiento
Planificar acciones sobre los riesgos

En cada fase o iteracin se eliminan o se prepara plan de
contingencia
No planificarlos: modificaciones, retrasos
A veces no se descubren
131

Los casos de uso (escenarios) guan las iteraciones
Se ordenan segn 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.
132

Primeras iteraciones
Riesgos relacionados con el mbito del sistema y arquitectura
ltimas iteraciones
Aadir ms funciones
Categoras de riesgos:
Especficos
Arquitectnicos
De requisitos
133
Especficos de un producto
Tcnicos
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?
Solucin: requisitos, modelo de negocio
uso real en prototipos
134
Arquitectnicos
No establecer una arquitectura flexible
Fases de inicio y elaboracin
Cmo determinar casos de uso importantes para la
arquitectura correcta?
Casos de uso crticos (los ms importantes para los usuarios del
sistema y los que tienen requisitos no funcionales como
rendimiento, tiempo de respuesta,...)
Otras categoras de casos de uso: secundarios, auxiliares,

opcionales
80% de casos de uso descritos en elaboracin para hacer la
planificacin detallada y estar seguros de haber considerado
lo importante para la arquitectura
135

Iteracin genrica
Planificar
Recursos
Evaluar
136
Recursos
Cunto cuestan las fases de inicio y elaboracin?
Quin las costea? Cunto duran?
Depende del proyecto
Considerar:
Hay experiencia?
Cmo es la base de componentes?
Es una nueva entrega?
Es distribuido?
...
137
Recursos
Tiempo:
Inicio 5%, elaboracin 20%, construccin 65%, transicin 10%
Recursos
Inicio 10%, elaboracin 30%, construccin 50%, transicin
10%
Ms incgnitas, ms tiempo y recursos en inicio y

elaboracin.
138

Iteracin genrica
Planificar
Recursos
Evaluar
Las fases
Las iteraciones
139
Evaluar iteraciones y fases

Jefe de proyecto (documento)
Objetivos:
evaluar iteraciones segn criterios: presupuesto, tiempo, requisitos
de calidad, resultados de las pruebas
reconsiderar el plan de la siguiente iteracin
modificar el proceso
evaluar y modificar criterios
Es frecuente no alcanzar los criterios. Prolongar el trabajo a la

iteracin 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
140
La siguiente iteracin
A partir de la evaluacin anterior, el jefe de proyecto:
Determina si se puede pasar a la siguiente iteracin

Si hay que rehacer, cundo
Planificar en detalle siguiente iteracin
Actualizar el plan de las iteraciones posteriores a la siguiente
Actualizar riesgos y plan del proyecto
Evolucin del conjunto de modelos
141

Proceso Unificado (Parte I)

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proceso Unificado (Parte I)

Cargado por

Copyright:

Formatos disponibles

UN EJEMPLO: EL PROCESO

The unified software development process, Ivar Jacobson, Grade

Ingeniera del Software

Un ejemplo: el Proceso Unificado

Caractersticas del Proceso Unificado

Ingeniera del Software

Un ejemplo: el Proceso Unificado

Flujos de trabajo fundamentales

Ingeniera del Software

El Proceso Unificado (UP)

Ingeniera del Software

El Proceso Unificado (UP)

Basado en componentes conectados a travs de

Ingeniera del Software

Ingeniera del Software

UML - Elementos y relaciones

Estructurales: Clases, Casos de Uso,

Dependencia (Relacin de Uso)

Ingeniera del Software

Ingeniera del Software

Ingeniera del Software

Ingeniera del Software

Ingeniera del Software

Diagrama de casos de uso

Ingeniera del Software

trans ferencia( cuenta, im porte )

Ingeniera del Software

6: t rans ferenc i a (c uenta, c anti dad)

: Cliente del banc o

4: te c lee c uenta des tino

12: trans ferenc ia realiz ada

Ingeniera del Software

c uentaDes tino : Cuenta

S olicitar prs tam o

Ingeniera del Software

Solicitar pago Reservar plazas

Dirigido por casos de uso

Qu debe hacer el sistema para cada usuario?

Se desarrollan y evolucionan junto a la arquitectura del

Ingeniera del Software

Ingeniera del Software

Divisin del proyecto.

Incremento no siempre es aditivo.

Ingeniera del Software

Ingeniera del Software

Descubre Actores Estructura Modelo

Ingeniera del Software

Fases, iteraciones y actividades

Fases, iteraciones y actividades

Ingeniera del Software

Fases, iteraciones y actividades

Ingeniera del Software

Un ejemplo: el Proceso Unificado

Ingeniera del Software

Ingeniera del Software

Ingeniera del Software

Enumerar los requisitos candidatos

Se realizan de forma conjunta

Ingeniera del Software

Ingeniera del Software

Modelo de casos de uso

Sistema de casos de uso

Ingeniera del Software

Flujo de trabajo de la captura de