Rup Ejemplo

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

Rumbaug, Ed. Addison Wesley, 1999
Ingeniería del Software 1

Un ejemplo: el Proceso Unificado
• Características del Proceso Unificado

• Flujos de trabajo fundamentales
• Iteración genérica
• Planificar
• Gestionar los riesgos
• Recursos
• Evaluar


– UML
– Basado en casos de uso
– Centrado en la arquitectura
– Iterativo-Incremental
– Modelos del proceso
• Planificar
• 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

UML - Diagramas
• Ofrecen distintas perspectivas de una abstracción de

la realidad
• Un mismo elemento puede aparecer en distintos
diagramas
• En el modelo de un sistema no hay motivo para que
aparezcan obligatoriamente todos los elementos.
Estáticos(estructura) Dinámicos(comportamiento)
D. de Clases Casos de Uso
D. de Objetos Secuencia
Interacción
D. de Componentes Colaboración
D. de Despliegue Estados
Actividades

Diagrama de clases
Mot or Piloto Vendedor de billetes
1..4 1..2 1
1 * *
Avión 1 * Vuelo 1 * Reserva
*
{ disjunta, completa }
1
Avión militar Avión comercial Línea aérea
{ disjunta, completa }
Avión de carga Avión de pasajeros

Diagramas de Componentes
Control y Análisis
Interfaz de Terminal
Comm
Comm
Gestión de Cuentas Acceso a BD

Rutinas de Coneccion
Comm Comm
Comm

Diagramas de Despliegue
Servidor Central Control y Análisis
Acceso a BD C
C
Terminal de Consulta
Interfaz de Terminal
C C
Punto de Venta
C
Gestión de Cuentas Interfaz de Terminal
C C

Diagrama de casos de uso
V enta Normal
V enta en Rebajas
C liente V endedor
V enta en Oferta
Diagrama de estados
E s perando
t arj eta
tarjeta int ro duc ida

Ley endo
tarjeta
E s p erando
PIN
P IN introducido( P IN )
[ inc orrec to ]
Rec ogiendo V alidando
tarjeta PIN
[ > 3 intentos ]
[ c orrec to ]
Es perand o
opc ión
trans ferenc ia( c uenta, im porte )

i ngres o ( im por te )
reintegro( im porte )
Ingre sando
Trans ferenc ia
Reintegrando
[ OK ]
Ex puls ando
dinero
[ Not OK ]
dinero retirado
E x puls ar
Ingeniería del Software tarjeta 13
Diagrama de colaboración
5: c u enta dest in o
3: c antidad
6: t rans ferenc i a (c uenta, c anti dad)

1: trans ferenc ia
11 : OK
: Cliente del banc o : Interfaz de ca jero : Trans acc ión
7: rei nteg ro (can ti dad)

2: te c lee cant id ad
9: ingreso (cantidad)
8: OK
4: te clee c uenta des tino
10: OK
12: transferencia realizada
cuentaOrigen : Cuenta cuentaDestino : Cuenta

Diagramas de Secuencia
: Lib ro : Fic ha soc io : Ficha libro : P rés tam o

: S ocio : E nc argado
Coger libro
S olic itar prés tam o
V erific ar s ituac ión s oc io
S it uac i ón s o cio ok
V erific ar s ituac ión libro
S ituación libro ok
Introduc ir prés tam o
A ut oriz ar p rést amo

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

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.
Iterativo - Incremental
• Varios ciclos que concluyen con un producto.

• Código fuente, manuales y documentos.
• Hitos por fases (Milestones)
Entrega
Ciclos ...
Fases Concepción Elaboración Construcción Transición

Iter. Iter. Iter.
Iterac. 1 2
... ... ... ... ... ...
n

El proceso
Papeles y actividades
Analista de Descubre Actores Estructura Modelo Planifica Diseña Evalua Ingeniero de

Sistemas y Casos de Uso de Casos de Uso Test Test Test pruebas
Especifica Detalla un Integra Integrador de

Casos de Uso Caso de Uso Sistema Sistemas
Diseñador de Prototipo del Ejecuta Test Ingeniero de

Interface de Usuario Interfaz de Usuario de Integración pruebas de
integración
Arquitecto Prioriza Análisis de Diseño de Implementación

Ingeniero de
Casos de Uso Arquitectura Arquitectura de Arquitectura Ejecuta test
pruebas de
del sistema
sistema
Ingeniero de Analiza un Diseña un

Casos de Uso Caso de Uso Caso de Uso
Implementa
Analiza Diseña una clase
una Clase Analiza Diseña un Implementa
una clase
Ingeniero de un Subsistema Implementa Ejecuta Test Test
Componentes Paquete Subsistema Unitario

El proceso
El producto (salidas)
- Refina los casos de uso

otorgándoles más detalle
Modelo de
- Asigna la funcionalidad a
Especificado por análisis un grupo de objetos
- Define la estructura
Realizado por Modelo de estática del sistema.
diseño - Refleja los casos de uso
como colaboraciones
Modelo de Distribuido por
casos de uso - Define la configuración
Modelo de de los nodos de
despliegue procesamiento y las
correspondencias entre
Implementado por ellos.
- Incluye los componentes
Modelo de
(código fuente) y las
implementación relaciones entre los
mismos
Verificado por - Define los casos de

Modelo de prueba para validar los
pruebas casos de uso

El proceso
Fases, iteraciones y actividades
FASES
Planificación
Workflow Anál. Riesgos
Elaboración Construcción Transición
Verificación
Preparación
Requisitos
Iteración en
Fase de Elaboración
Análisis
Diseño
Implantación
Prueba
Iteración-es Iter. Iter. Iter. Iter. Iter. Iter. Iter.

Inicial-es #1 #2 #3 #4 #5 #6 #7
(Adaptado de Jacobson, 1999)

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


– Requisitos
– Análisis
– Diseño
– Implementación
– Pruebas
• Planificar
• 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

TAREA PRODUCTOS (artifact)

Enumerar requisitos Lista de características
candidatos
Entender el contexto Modelo de negocio o de
del sistema dominio
Capturar requisitos Modelo de casos de uso
funcionales
Capturar requisitos no Requisitos suplementarios
funcionales 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
1
Modelo de casos de uso Sistema de casos de uso
* *
Ingeniería del Software Caso de uso 32

Actor
Artefactos de requisitos
Analista de Especificador Diseñador de Arquitecto

sistemas de casos de uso interfaz de usuario
Modelo casos Actor Glosario Caso de uso Prototipo Descripción de

de uso de interfaz la arquitectura
de usuario

Flujo de trabajo de la captura de
requisitos funcionales (Actividades)
Encontrar actores y
Estructurar el modelo
Analista casos de uso
de casos de uso
Priorizar los casos de

Arquitecto
uso
Detallar un caso de
Especificador uso
Prototipar la interfaz
Diseñador de usuario

• Encontrar actores y casos de uso
Modelo del Analista Modelo de

negocio casos de uso
(esbozado)
Requisitos Encontrar actores y

adicionales casos de uso
Glosario
Lista de
característ.
• Priorizar casos de uso
Modelo de Arquitecto
casos de uso
Requisitos Priorizar casos de

Descripción de la
adicionales uso
arquitectura (vista del
modelo de casos de uso)
Glosario
• Detallar un caso de uso
Modelo de Especificador de
casos de uso casos de uso
Requisitos Detallar un caso de

Caso de uso
adicionales uso
(detallado)
Glosario

• Prototipar la interfaz de usuario
Modelo de
casos de uso Diseñador de
interfaz de usuario
Requisitos
adicionales
Prototipar la interfaz
Prototipo
de usuario
de interfaz
de usuario
Caso de uso
(descrito)
Glosario
• Estructurar el modelo de casos de uso
Modelo de
casos de uso Analista de
sistemas
Requisitos
adicionales
Estructurar el
Modelo de
modelo de casos
casos de uso
de uso
(estructurado)
Caso de uso
(descrito)
Glosario
Caso de uso “Validar usuario”
Flujo de eventos
ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA
1. Este caso de uso empieza 2. Pide la clave de identificación

cuando un Cliente introduce una
tarjeta en el cajero
3. Introduce la clave 4. Comprueba la clave
5. Si es válida presenta las opciones

disponibles y se termina el caso de
uso
CAMINOS ALTERNATIVOS
Línea 3. El cliente cancela la transacción

Línea 4. La clave no es válida y se reinicia el caso de uso. Si ocurre tres
veces se cancela la transacción y no se devuelve la tarjeta
¡¡HAY QUE DEFINIR ESTOS DOS FLUJOS DE EVENTOS!!

Caso de uso “Sacar dinero”
Flujo de eventos
ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA
1. Este caso de uso empieza cuando

un Cliente ha sido identificado
Presenta las opciones de
operaciones disponible
2. Selecciona la operación de 3. Pide la cantidad a retirar.

Reintegro
4. Introduce la cantidad requerida 5. Procesa la petición 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

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
Validar
R2, R3,...
usuario
Usuario
Sacar <<extends>>
dinero Sacar
con visa
Ingresar
dinero
Transf. R4,...
Cliente
del banco
Consultar
saldo
Reponer
dinero
R1
Empleado Recoger
sucursal dinero

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
Arquitecto Ingeniero de Ingeniero de

casos de uso componentes
Modelo de Descripción de la Realización caso Clase del Paquete del

análisis arquitectura de uso -Análisis análisis análisis

Artefacto: Modelo de Análisis
* *
Sistema de Paquete del

análisis análisis
* * *
*
Clase del Realización caso

análisis de uso -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
Clase del
análisis
Clase de Clase de Clase de

entidad interfaz control

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

análisis (Diag. De Clases)
Confirmación
de Pedido
Gestor de
Pedidos
Factura
IU Solicitud
de Pago
Comprador
Planificador Solicitud
de Pagos de Pago

análisis (Diag. De Colaboración)
5: Obtener
:Confirmación
4: Obtener de Pedido
:Gestor de
Pedidos
3: Comprobar Factura
2: Mostrar
:Factura
1: Mostrar Facturas
9: establecerEstado(Planificado)
6: Planificar pago de Factura
:IU Solicitud 7:Planificar Pago

de Pago
:Comprador
8: Obtener
:Planificador :Solicitud
de Pagos de Pago

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
*
Paquete del
análisis
*
*
Clase del Realización
análisis caso de uso -
Aná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 arquitectura
Identificar paquetes de análisis
Identificar clases de entidad
Requisitos comunes
2. Analizar (refinar) un caso de uso
Identificar clases de análisis
Describir interacciones entre los objetos del análisis
Capturar req. especiales sobre la realización del CU
3. Analizar una clase
Identificar responsabilidades y atributos
Identificar relaciones: asoc., agreg. y gener.
Capturar req. especiales sobre la realización del CU
4. Analizar un paquete
Actividades
Análisis de la
Arquitecto arquitectura
Analizar un caso de
Ingeniero de
uso
casos de uso
Analizar una clase Analizar un paquete

Ingeniero de
componentes

Actividades: Análisis de la Arquitectura
Modelo de Paquete del

casos de uso Arquitecto análisis (esbozo)
Requisitos Clase del

adicionales análisis (esbozo)
Análisis de la
arquitectura
Descripción de la
Descripción de la
modelo de análisis)
modelo de casos de uso)

Actividades: Analizar un caso de uso
Modelo de
casos de uso Ingeniero de casos
de uso
Realización caso
Requisitos de uso - análisis
adicionales
Analizar un
caso de uso
Clase del
Descripción de la
análisis (esbozo)

Actividades: Analizar una clase
Ingeniero de
Realización caso
componentes
de uso - análisis
Analizar una
clase Clase del análisis
(terminada)
Clase del
análisis (esbozo)

Actividades: Analizar un paquete
Ingeniero de
Descripción de la componentes
Analizar un
Paquete del
paquete
análisis
(terminado)
Paquete del
análisis(esbozo)

Análisis del caso de uso: “Validar usuario”
V ali dar usuario Re ali z ac i ón en aná li sis
Interfaz de caj ero Usuarios DelB 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)

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

Análisis del caso de uso: “Validar usuario”.
Código incorrecto
3: código
4: autentica (datos, código)

1: introducir tarjeta
7: visualiza (error)
: Cliente del banco 2: teclear código : Interfaz de cajero : Autenticar
5: valida (datos, codigo)

8: teclear código
6: Error
: UsuariosDelBanco

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

Secuencia correcta
5: cuenta destino
3: cantidad
6: transferencia (cuenta, cantidad)

1: transferencia
11: OK
: Cliente del banco : Interfaz de cajero : Transacción
2: teclee cantidad 7: reintegro (cantidad)
8: OK
4: teclee cuenta destino
10: OK
12: transferencia realizada

No hay saldo en la cuenta origen
5: cuenta destino
3: cantidad

1: transferencia
9: no hay fondos

8: no hay saldo
10: no hay fondos
cuentaOrigen : Cuenta

No se puede acceder a la cuenta destino
5: cuenta destino 11: rollback
3: cantidad

1: transferencia
12: error
8: OK
10: error
13: error

Modelo de clases de análisis
Cliente del banco Interfaz de cajero Transacción Cuenta
Autenticar UsuariosDelBanco

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
transferencia (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
Arquitect Ingeniero de Ingeniero de

o casos de uso componentes
Realización
caso de uso -
diseño
Modelo de Modelo de Descripción de Clases Interfaz Subsistema de

diseño despliegue la arquitectura del diseño
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
funcionales y otras restricciones.
* *
Sistema de Subsistema de
diseño diseño
* * * *
* *
Interfaz
Clases Realización caso
del de uso - diseño
diseño

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
► realiza
Interfaz
Clases del
diseño
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»
Realización caso Realización caso

de uso - análisis de uso - diseño

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
Subsistema de
diseño
► realiza
* * * *
Clases del Interfaz

Realización caso
Ingeniería del Software diseño 76
de uso - diseño
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
► realiza *
Interfaz
Clases del *
diseño
► realiza
Subsistema de
diseño
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
Descripción de
la arquitectura
Modelo de
diseño
Artefactos de diseño: Modelo de
Despliegue
• Representa una correspondencia entre la
arquitectura del Hardware y la arquitectura
del Software Modelo de
• Describe la distribución física del sistema en despliegue
nodos de computo.
• Cada nodo representa un recurso de
computo *
• Las relaciones entre nodos representan

medios de comunicación entre ellos. Nodo
• La funcionalidad de un nodo se determina
por los componentes que se le asignan

Diseño: Actividades
Diseño de la
Diseñar un caso de
Ingeniero de uso
casos de uso
Diseñar una clase Diseñar un

Ingeniero de subsistema
componentes

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
Subsistema
Modelo de Interfaz
Arquitecto
casos de uso
Clase de
diseño
Requisitos
adicionales Diseño de la
arquitectura
Modelo de
despliegue
Modelo de
análisis Descripción de la Descripción arquitectura
arquitectura (vista del (vista de modelo de
modelo de análisis) diseño y despliegue)

Actividades: Diseño de un caso de uso
Realización caso
Modelo de de uso - diseño
casos de uso Ingeniero de
casos de uso
Requisitos
adicionales Clase de
diseño
Diseñar un caso de
uso
Modelo de
análisis Subsistema
Modelo de Modelo de Interfaz

diseño despliegue

Actividades: Diseño de una clase
Realización caso
de uso - diseño Ingeniero de
componentes
Clase de
diseño
Diseñar una clase Clase de diseño
(completa)
Interfaz
Clase del análisis

(completa)

Actividades: Diseño de un Subsistema
Ingeniero de
Descripción arquitectura
componentes
(vista modelo de diseño)
Subsistema
(terminado)
Subsistema
(esbozado) Diseñar un
subsistema
Interfaz
Interfaz (terminada)
(esbozada)

Diseño del caso de uso: “Validar usuario”
V al id ar usuario Realización en diseño

(fro m Use Ca se V i e w)
LectorDeTarjetas
GestorDeCliente Us uariosDelB anco
P antalla
Tec lado
Transac ción

Secuencia correcta
: : Pa ntal la : Tec lado
: Cliente del banc o : Ges torDeCliente : Tran s ac c ión : Us uariosDelB anc o
Lec t orDeTarj etas
1: l eerTarj eta
2: i ntroduc i rTarj eta (tarjet a)

3: datos Tarjeta (tarjeta)
4: vis ualiz ar (In troduci r P IN)
5: OK
6: leerP IN
7: introduc i rP IN (PIN)
8: datos P IN (P IN)
9: au tent ic a (datos , PIN)
10: valida (datos , P IN)
11: OK
12: alm ac enaDatos (datos )
13: vi s ual iz a (opc iones)

14: vis ualiz ar (opc iones )

Código incorrecto
: : Pa ntal la : Teclado
: Cliente del banco : GestorDeCliente : Tran sacc ión : UsuariosDelB anco
Lect orDeTarj etas
1: l eerTarj eta
2: i ntroduci rTarj eta (tarjet a)

3: datosTarjeta (tarjeta)
4: vis ualizar (In troduci r P IN)
5: OK
6: leerP IN
7: introduc i rP IN (PIN)
8: datosP IN (P IN)
9: au tent ic a (datos , PIN)
10: valida (datos, P IN)
11: E rror
12: visualiza (error P IN)

13: visu ali zar (error P IN)
Hay más escenarios: anular transacción y tres intentos

Diseño del caso de uso: “Transferencia”
- Suponemos que el usuario ya ha sido identificado (se ha ejecutado
el caso de uso anterior). Ahora selecciona la opción “transferencia”.
Trans ferenc ia Realizac ión en dis eño,

(fro m Use Ca se V i e w)
trans ferenc ia
2
Tec lado
P antalla
Ges torDeCliente Trans ac c ión Cu entas Cu enta

Diseño del caso de uso: ”Transferencia”
Secuencia correcta
: Teclado : P antalla
: Cliente del banco : Ges torDeCliente : Transacción : Cuentas : Cuen ta
1: opcion (transferencia)
2: trans ferencia
3: visu aliz ar (Tecl ee im port e)
4: IntroducirIm porte
5: im porte
6: vi sual izar (Te clee cuent a desti no)
7: cu entaDes ti no (cuent a)
8: cuentaDes tino (c uenta)
9: t ransferenc ia (cuentaO rigen, c uen taDestin o,im po rt e)
10: reintegro (cuentaOrigen, im porte)
11: reintegro (im porte)
12: OK
13: OK
14: ingreso (cuentaDestino, im porte)
15: ingre so (im porte)
16: OK
17: OK
18: OK
19 : vis ualizar (Tra nsfe renci a real izada)
20: visu ali zar (Reti re su tarjet a)

Diseño del caso de uso: ”Transferencia”
No hay saldo en la cuenta origen
: Tec lado : P antalla
: Cliente del banco : GestorDeCliente : Trans ac ción : Cuentas : Cuen ta
1: opc ion (trans ferencia)

2: transferenc ia
3: visu aliz ar (Tecl ee im port e)
4: IntroducirIm porte
5: im porte
6: vi sual iz ar (Te c lee c uent a des ti no)
7: c u entaDes ti no (cuent a)
8: cuentaDes tino (c uenta)
9: t rans ferenc ia (cuentaO rigen, c uen taDestin o,im po rt e)
10: reintegro (cuentaOrigen, im porte)
11: reintegro (im porte)
12 : no ha y saldo
13: no hay saldo
14: no hay fondos
15: visualiz ar ((No hay fondos))
16: visu ali zar (Reti re s u tarjet a)

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

Diseño de las clases
P antalla Lec torDeTarjetas
vis uali zar(m ensaj e : S t ri ng) crearLec tor() : Lect orDe Tarj eta s
c rearP antall a() : P antal la leerTarjeta() : dato sTarj eta
Tecla do
crearTeclado() : Teclado
leerP IN() : unP IN
leerOpcion() : unaOpcion Gesto rDeCli ente
leerCantidad() : Dinero
leerNum Cuenta() : unIDCuenta crear() : GestorDeClie nte
creaCajeroVi rtual()
inici arS esion()
Im presora
c rearIm p resora() : Im pres ora

im prim ir(m ensaje : S tring) CajonDinero
DarDinero crearCajon() : CajonDi nero

abrirCajon()
crear() : DarDinero cerra rCajon()
ex p ulsa r(im porte : Dinero) contarCantidad() : Dinero
Diseño de las clases
Transacción
miCliente : GestorDeCliente
datosTarjeta : DatosTarjeta
numIntentosFallidos : 1..3 = 0 GestorDeCliente
cuentas : Cuentas miTransaccion : Transacción
usuarios : UsuariosDelBanco
crear() : GestorDeCliente
almacenarDatos(datos : DatosTarjeta) creaCajeroVirtual()
validar(importe : Dinero, cantidad : Dinero) iniciarSesion()
autenticar(datos : DatosTarjeta, PIN : UnPIN) : Boolean visualizar(resultados : String)
retirarDinero(importe : Dinero) : Boolean
ingresarDinero(importe : Dinero) : Boolean
trasnsferencia(cuentaOrigen : Cuenta, cuentaDestino : Cuenta, importe : Dinero) : Boolean
Cuentas UsuariosDelBanco
cuentas : Dictionary usuarios : Dictionary
reintegro(cuenta : Cuenta, importe : Dinero) : Boolean validar(datos : DatosTarjeta, PIN : UnPIN) : Boolean
ingreso(cuenta : Cuenta, importe : Dinero) : Boolean
Cuenta
datos : DatosCuenta
limiteDiario : Dinero = 50000
reintegro(importe : Dinero) : Boolean

Ingeniería del Software : Dinero) : Boolean
ingreso(importe 94
Clase GestorDeCliente
E s perando
t arj eta
tarjeta int ro duc ida

Ley endo
tarjeta
E s p erando
PIN
P IN introducido( P IN )
[ inc orrec to ]
Rec ogiendo V alidando
tarjeta PIN
[ > 3 intentos ]
[ c orrec to ]
Es perand o
opc ión
trans ferenc ia( c uenta, im porte )

i ngres o ( im por te )
reintegro( im porte )
Ingre sando
Trans ferenc ia
Reintegrando
[ OK ]
Ex puls ando
dinero
[ Not OK ]
dinero retirado
E x puls ar
Ingeniería del Software tarjeta 95
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
Arquitecto Integrador de Ingeniero de

sistemas componentes
Integración de
sistema
Interfaz
Modelo de Descripción de la Modelo de Componente Implementac.
implementac. arquitectura despliegue subsistema

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 de Subsistema de
implementac. implementac.
*
* *
*
Componente Interfaz

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

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
«trace»
Clase de
diseño Componente
Interfaz Interfaz
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
Subsistema de
– otros subsistemas (recursivamente) implementac.
• Se manifiestan a través de un mecanismo
de empaquetamiento concreto de un ► r
entorno de implementación determinado. *
– Paquete en Java * *
– Proyecto en VB
– Etc. Componente Interfaz

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.
► realiza *
Interfaz
Componente *
► realiza
Subsistema de
implementac.
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
Implementación de la
Integrador de Integrar sistemas

sistemas
Implementar un
Ingeniero de subsistema
componentes Implementar una Realizar prueba de
clase unidad

Actividades: Implementación de la
Arquitectura
Modelo de Arquitecto
casos de uso Componente
(esbozado y asignado
a un nodo)
Modelo de
análisis Implementación de la
arquitectura
Descripción arquitectura (vista de modelo de
(vista de modelo de implement. y despliegue)
diseño y despliegue)

Actividades: Integrar el Sistema
Requisitos
adicionales Integrador de
sistemas
Modelo de Plan de integración
casos de uso de construcciones
Modelo de Integrar sistemas

diseño
Modelo de
implementac.
Modelo de
implementac.

Actividades: Implementar un Subsistema
(vista de modelo de Ingeniero de
implementación) componentes
Subsistema de
Plan de integración implementac.
de construcciones
Implementar un
subsistema
Subsistema de Interfaz
diseño
Interfaz

Actividades: Implementar una Clase
Ingeniero de
componentes
Clase de diseño
(diseñada)
Implementar una
clase Componente
(implementado)
Interfaz

Actividades: Realizar una Prueba de
Unidad
Ingeniero de
componentes
Clase de diseño
(implementada)
Realizar prueba de
unidad Componente
(unidades probadas)
Interfaz

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
* X
X Procedimiento Componente
Caso de prueba
de prueba de prueba
Flujo de trabajo de pruebas
1. Planificar prueba
2. Diseñar prueba
– Describir casos de prueba de cada construcción
– Identificar y estructurar los procedimientos de prueba
3. Implementar prueba
4. Realizar pruebas de integración
5. Realizar prueba de sistema
6. Evaluar prueba

Resumiendo...
<<trace>> <<trace>>
Caso de uso Realización Realización

en análisis en diseño

Resumiendo...
<<trace>>
Realización Realización
en diseño en implementación
<<desing subsystem>> <<implem. subsystem>>

<<trace>> (1:1)
<<file>>
<<file>>


– División del trabajo en fases
• Planificar
• 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


• Planificar
– Las fases
– Las iteraciones
– Los criterios de evaluación
• Recursos
• Evaluar

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

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


• Planificar
– 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


• Planificar
• Recursos
• Evaluar

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.


• Planificar
• Recursos
• Evaluar
– 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

Rup Ejemplo

Cargado por

Información del documento

Descripción original:

Título original

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

Rup Ejemplo

Cargado por

Copyright:

Formatos disponibles

UN EJEMPLO: EL PROCESO

El proceso unificado de desarrollo, Ivar Jacobson, Grade Booch, James

Ingeniería del Software 1

• Características del Proceso Unificado

Ingeniería del Software 2

• Características del Proceso Unificado

• Unificación de tres metodologías de desarrollo

– OOSE: Object Oriented Software Engineering (Casos de Uso)

– Booch (Diseño) Booch, G.

– OMT: Object Modeling Technique (Análisis) Rumbaugh, J.

Ingeniería del Software 4

• Es más que un proceso de desarrollo software

Ingeniería del Software 5

• UML es un lenguaje de modelado

Ingeniería del Software 6

Ingeniería del Software 7

• Ofrecen distintas perspectivas de una abstracción de

Ingeniería del Software 8

Mot or Piloto Vendedor de billetes

Avión de carga Avión de pasajeros

Ingeniería del Software 9

Gestión de Cuentas Acceso a BD

Ingeniería del Software 10

Servidor Central Control y Análisis

Gestión de Cuentas Interfaz de Terminal

Ingeniería del Software 11

tarjeta int ro duc ida

trans ferenc ia( c uenta, im porte )

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

7: rei nteg ro (can ti dad)

cuentaOrigen : Cuenta cuentaDestino : Cuenta

Ingeniería del Software 14

: Lib ro : Fic ha soc io : Ficha libro : P rés tam o

S olic itar prés tam o

V erific ar s ituac ión s oc io

V erific ar s ituac ión libro

Introduc ir prés tam o

A ut oriz ar p rést amo

Ingeniería del Software 15

Pasajero Vendedor Airline

Dar detalles vuelo

Solicitar pago Reservar plazas

Ingeniería del Software 16

• Usuario: alguien o algo.

• Edificio: estructura, servicios, electricidad, fontanería,...

Ingeniería del Software 18

Ingeniería del Software 19

• División del proyecto.

• Varios ciclos que concluyen con un producto.

Fases Concepción Elaboración Construcción Transición

Ingeniería del Software 21

Analista de Descubre Actores Estructura Modelo Planifica Diseña Evalua Ingeniero de

Especifica Detalla un Integra Integrador de

Diseñador de Prototipo del Ejecuta Test Ingeniero de

Arquitecto Prioriza Análisis de Diseño de Implementación

Ingeniero de Analiza un Diseña un

Ingeniería del Software 22

- Refina los casos de uso

Verificado por - Define los casos de

Ingeniería del Software 23

Iteración-es Iter. Iter. Iter. Iter. Iter. Iter. Iter.

(Adaptado de Jacobson, 1999)