Ejemplo de un caso, donde se da el ciclo de vida de un

proceso unificado

Ciclo de vida de un proceso

unificado

Ejemplo: Videoclub Automtico

1 CAPTURA DE REQUISITOS

El sistema a desarrollar, es un sistema software que hay que incorporar dentro

de un dispensador automtico de pelculas, un videoclub automtico, como los
que hay en gasolineras y tiendas abiertas 24 horas. Este videoclub tiene las
facilidades usuales, como sacar pelculas, devolverlas, etc. Y tambin otros
como, que se pueda reservar una pelicula, notificando al usuario que ya esta
disponible mediante un mensaje SMS o recordatorios a los clientes que no han
devueltos pelculas via SMS. El pago ha de hacerse con tarjeta de crdito. El
videoclub reporta a la central de la empresa via internet.

1.1 ENCONTRAR

ACTORES Y CASOS DE USOS

1.1.1 Identificar actores

Usuario: Es la persona que utilizara el sistema, para buscar pelculas,

solicitarlas, pagarlas y obtenerlas del dispensador.

Operario: Es la persona que realizara las tareas de mantenimiento del

dispensador de pelculas, es decir, sustituira viejas pelculas por nuevas. Para
ello utilizara el sistema para dar de alta y baja las pelculas.

Banco: Representa a la entidad externa, con lo que el sistema debe contactar

para admitir y realizar los pagos con tarjeta de los clientes.

Dispensador: Representa al dispositivo mecnico, donde estn almacenados

las pelculas, que el sistema debe controlar, para dar la pelcula alquilada al
cliente, o que este la pueda devolver.

Operador Telefnico: Es la entidad externa, con lo que el sistema debe

contactar para enviar mensajes SMS, a los clientes.

Sistema Contable: Representa el sistema informtico externo de la empresa,

con el que el sistema videoclub debe contactar, para notificar los pagos
realizados en cada momento.

1.1.1 Identificar Caso de Uso

Alquilar pelcula: El usuario utiliza este caso de uso para mirar qu pelculas
hay, seleccionar una, pagarla y retirarla del dispensador. Debe obtener un
recibo.
Devolver pelcula: El usuario inicia este caso cuando devuelve la pelcula.
Recibe una notificacin confirmandole la devolucin. Si ha tenido retraso
deber abonar una penalizacin.
Dar de alta: El operario incia este caso cuando introduce una nueva pelcula
en el dispensador.
Dar de baja: El operario inicia este caso cuando retira una pelcula del
dispensador.
Mandar recordatorio: El operario inicia este caso cuando fija en el sistema el
tiempo mximo permitido por el alquiler de cada pelcula.

1.1.2 Describir modelo de Caso de Uso.

1.2 DETALLAR

CASOS DE USOS

1.2.1 Disear diagramas de estados

1.2.2 Descripcin del caso de uso

Precondicin
El usuario ha pulsado en el videoclub alquilar pelcula
Flujo de eventos
Camino bsico:
1. El usuario inicia el caso de uso buscando en la pantalla la pelcula que
ms le gusta. El sistema le muestra la informacin de cada pelcula, por
orden alfabtico, as como si esta prestada, reservada o disponible.
2. El usuario selecciona una pelicula en la pantalla. El sistema le pide los
datos de su tarjeta de crdito y gestiona el pago con la entidad bancaria
adecuada.
3. El banco emite una verificacin y el pago es aceptado. El sistema ordena
al dispensador que proporcione la pelcula elegida y que genere el recibo.
Asimismo notifica al sistema contable la transaccin bancaria realizada.
Finalmente actualiza los datos histricos del usuario y marca la pelcula
como alquilada y no disponible si no hay ms copias.
Caminos alternativos:

1. En 2 puede que el pago no sea aceptado por el banco o que el usuario

haya alcanzado el tope de sus alquileres por dia. Hay que notificarselo al
usuario y terminar.
2. En 1 puede que la pelicula este alquilado y el usuario quiera reservarla.
En este caso hay que omitir una notificacin de reserva.
Poscondicin
El caso acaba cuando el usuario tiene la pelcula y un recib, o si pelcula y una
notificacin de pago rechazado, o sin pelcula pero con la reserva hecha, o sin
pelcula, porpque no le gusta ninguna.
Atributos del caso de uso
Pelcula: Prestada, reservada o disponible.
Cliente (usuario): datos, tarjeta de crdito, nmero de pelculas alquiladas.
Informacin a mostrar: Sobre pelculas, sobre peticin de datos, sobre
resultad del alquiler realizado.

1.3 DEFINIR

PROTOTIPO DE INTERFAZ UNIFICADO

1 ANLISIS Y DISEO

1.1 Analizar los casos de uso (identificar clases y describir interacciones).

Diagrama de Colaboraciones:

1.2 Analizar cada clase de anlisis (identificar, responsabilidad, atributos y

relaciones.
Responsabilidades de la clase Gestor:
La responsabilidad de esta clase en el Caso de Uso "Alquilar Pelcula" es
Ordenar Pelcula, que implica:

Solicitar Datos de Pago mediante la tarjeta de crdito.

Ordenar al banco el pago y su verificacin.
Ordenar al dispensador la entrega al usuario de la pelcula y del recibo.
Actualizar la informacin sobre el cliente
Actualizar la informacin sobre las pelculas
Actualizar el balance de la empresa

Otras responsabilidades provenientes de otros casos de uso:

Gestionar el envo de recordatorios

Gestionar la devolucin de la Pelcula

Gestionar la carga y descarga de pelculas

1.3 Diseo
Disear la arquitectura (identificar nodos y configuraciones, clases
relevantes).

Modelo despliegue videoclub.

Clases relevantes videoclub.

Disear Casos de usos (identificar clases de diseo, interacciones

entre objetos).

Requisito especial sobre las clases de Anlisis Ficha de pelcula y Ficha

de cliente del caso de uso alquilar pelcula.
Ficha de pelcula y Ficha de cliente que se generalizaron en el
anlisis de la clase Ficha, deben poder manejarse de una manera
organizada y eficiente, por lo que es necesario crear clases de diseos,
que manejen listas de cada tipo de Ficha.
Requisito especial sobre la clase Anlisis I.Usuario I.Usuario debe ser
una clase activa, ya que debe estar lista para responder a cualquier
peticin del usuario en cualquier momento (como cancelar un alquiler
mientras se procesa o salir del sistema mientras este busca la
informacin de una pelcula).
Unificacin de las clases Anlisis I.Usuario e I.Pelculas I.Pelculas se
absorbe en la clase de diseo I.Usuario con objeto de reunir en una
sola clase todas las interfaces grficas.

Clase
de Clase
Anlisis
Diseo
I.Usuario
I.Usuario
Gestor
Gestor
I.Pelculas
Lista
Clientes
Lista

deRequisito
Diseo
Activa

de

Absorbida
en
I.Usuario
FichasIncluida
para
manejar
Clientes
FichasIncluida
para

Pelculas
Ficha Pelcula
Ficha Cliente
I.Dispensador
I.Sistema
Contable (1)
I.Sistema
Contable (2)

Ficha Pelcula
Ficha Cliente
I.Dispensador
I.SC.Local

I.Banco

I.Banco

I.SC.Central

manejar
Pelculas

Del modelo de
Despliegue
Del modelo de
Despliegue.
Activa

Diagrama de Clases de Diseo:

Diagrama de secuencia:

Disear clases
relaciones)

de

Diseo

(identificar

operaciones,

atributos,

1) Identificar operaciones:
Identificando los mensajes a los que debe responder en el diagrama de
secuencia
Analizando las responsabilidades de la clase de anlisis de la que deriva.
A menudo implican una o varias operaciones.
Contemplando los requisitos especiales de la clase de anlisis de la que
deriva, por ejemplo el acceso a un gestor BBDD.
Aadir la visibilidad de cada operacin.
Usar la sintaxis del lenguaje de implementacin a utilizar.
Las operaciones de la clase diseo necesitan soportar todo los roles que la
clase desempea en las diferentes realizaciones de casos de uso.

Gestor
+solicitarDatosPago():
datosTC
+ordenarPeli():
RetornoOperacin
+entregarPelculaRecib
o()
+actualizarBalance()
+actualizarCliente()
+actualizarPelculas()
+recordatorios()
+devolverPelcula():
RetornoOperacin
+cargarPelcula
+descargarPelcula

I.Banco
+ordenar
Pago
RetornoPago

():

Identificar Atributo:

Los atributos deben ser los requeridos para realizar sus operaciones.
Hay que tener en cuenta los atributos obtenidos en la fase de Anlisis.
Los tipos de atributos se restringen a los tipos disponibles en el lenguaje
de programacin a usar.
Hay que reutilizar tipos de atributos.
Si una clase de diseo resulta compleja por culpa de sus atributos, se
pueden agrupar atributos en clases independientes.

Identificar Asociaciones, Agregaciones y Generalizaciones:

Estudiar el diagrama de secuencias y ver qu asociaciones o

agregaciones son necesarias.
Agrupar objetos en agregaciones para mandarles mensajes a todos ellos.
Estudiar asociaciones creadas en la fase de anlisis.
Si el lenguaje de programacin no soporta el mecanismo de
generalizacin o herencia se deben emplear los mecanismos de
asociacin y agregacin.

En la operacin devolverPelicula() se ha estimado que es mejor que

exista esta agregacin entre las clases.
Ficha Pelcula y Ficha Cliente, para evitar el tener que recorrer las dos
listas buscando primero la pelcula y despus al cliente.

Describir estados de objetos:

Diagrama de estados de la clase FichaCliente

Decribir los mtodos:

Descripcin del Mtodo ActualizarPelcula de la clase Gestor
/* En el diagrama de colaboraciones del caso de uso AlquilarPelcula, se
observa que la operacin Actualizar F. Pelculas se realiza despus de Acualizar
F. Cliente, por lo que se puede pasar al mtodo el cliente que la ha alquilado */
Void ActualizarPelicula (Cliente, codigoPeli) {
Pelcula = BuscaPelicula en listaFichaPelculas (codigoPeli);
Pelcula <- es alquilada por Cliente;
Pelcula <- es alquilada en esta fecha y Hora
}

1 IMPLEMENTACIN
1.1 IMPLEMENTAR ARQUITRECTURA
a) Identificar componenetes e incorporarlos al modelo

Agrupar clases por tipos en un componente (ficheros .h y .cpp en el

lenguaje C++)
A cada clase activa se le asignar un componente ejecutable.

Diagrama de componentes para las clases Ficha, ListaFichas, FichaPelculas y

FichaClientes.

b) Asignar componentes a los nodos.

De acuerdo con el Modelo de Despliegue.
Clases activas asignadas a nodos independientes.

1.2 IMPLEMENTAR

LAS

CLASES

DE

DISEO

a) Generar cdigo fuente desde la descripcin de la clase de diseo.

En este paso slo se genera la signatura de las operaciones. Las

operaciones en s se implementan ms adelante.
En cuanto a las asociaciones y agregaciones, su generacin es delicada.
Lo normal es que una asociacin que se recorre en una direccin se
implemente con una referencia, representada con un atributo en el
objeto que referencia y el nombre del atributo ser el rol del extremo
opuesto. La multiplicidad del extremo opuesto indicar si la referencia
ser un puntero simple o una coleccin de punteros.

Declaracin de la clase FichaCliente en C++

Class FichaCliente {
Private:
TarjetaCredito datosTarjetaCredito;
String NombreApellidos;
Int NumeroAlquiladas;
Int MaximoAlquiler;
Public:
Void devuelve (int codigoPelicula);
Void alquila (int codigoPelicula);
Bool maximoAlcanzado ();
};

b) Implementar las operaciones.

Cada operacin definida por la clase de diseo ha de implementarse

mediante mtodos.

Implementacin del Mtodo ActualizarPelcula de la clase Gestor

/* En el diagrama de colaboraciones del caso de uso Alquilar Pelcula, la
operacin Actualizar F. Pelculas se realiza despus de Acualizar F. Cliente, por
lo que se puede pasar al mtodo el cliente que la ha alquilado */
Void Gestor: ActualizarPelicula (Ficha Cliente *ptrFC, int codigoPeli) {
FichaPelicula *ptrFP;
Try {//Se busca la pelcula
PtrFP= listaFichaPelculas.BuscaPelicula (codigoPeli);
}

Catch (ErrorNoEncontrada) {
// No debera pasar en ejecucin real pero sirve para depurar
Cerr<<Error A: llamada a Gestor: ActualizarPelicula no valida<<endl;
}
Catch (ErrorYaAlquilada) {
// No debera pasar en ejecucin real pero sirve para depurar
Cerr<<Error B: llamada a Gestor: ActualizarPelicula no valida<<endl;
}
Catch (ErrorYaReservada) {
// No debera pasar en ejecucin real pero sirve para depurar
Cerr<<Error C: llamada a Gestor: ActualizarPelicula no valida<<endl;
}
PtrFP->alquiladaPor (ptrFC); //Se notifica quin la alquil
PtrFP->alquiladaHoy (); //Se estampa fecha de alquiler
}

c) Realizar Pruebas de Unidad (de los Componentes Individuales)

Pruebas de especificacin (pruebas de caja negra), que verifican el

comportamiento de la unidad observable externamente.
Pruebas de estructura (prueba de caja blanca), que verifica la
implementacin interna de la unidad. Para cada componente se estudiar
su implementacin interna y se tratar de verificar su correcto
comportamiento algortmico.

d) Integrar el Sistema
Los objetivos de la integracin del sistema son dos:

Crear un plan de integracin de los componentes en el sistema.

Integrar cada componente antes de que sea sometido a las pruebas de
integracin.
Ser necesario incluir algunos componentes como stubs para poder
desarrollar las pruebas de integracin.
Es importante implementar casos de uso completos y a ser posible los
ms importantes.
Probablemente la implementacin de cada caso de uso podr requerir
varios componentes.

1 PRUEBAS
1.1 PLANIFICAR

DISEAR

LAS PRUEBAS

Principios generales:

Disear las pruebas de Integracin de Componentes. Se utilizan para

verificar que los componentes interaccionan entre s de un modo
apropiado despus de haber sido integrados en el sistema. Se toman
como Casos de Prueba los casos de uso del diseo.
Para ello se utiliza el Diagrama de Secuencia correspondiente y se
disean combinaciones de entrada y salida del sistema que lleven a
distintas utilizaciones de las clases, y en consecuencia de los
componentes, que participan en el diagrama.
Disear las pruebas del Sistema. Se usa para probar que el sistema
funciona globalmente de forma correcta. Cada prueba del sistema prueba
combinaciones de casos de uso bajo condiciones diferentes. Se prueba el
sistema como un todo probando casos de uso unos detrs de otros y, si
es posible, en paralelo. Se trata de ver que cada caso de uso funciona
adecuadamente en distintas configuraciones hardware, de carga, con
varios actores a la vez, en distinto orden, etc.

Diseo de Prueba 32 de Caso de uso Alquilar Pelcula

Precondicin: el sistema tiene todas las pelculas cargadas, ninguna alquilada
1. Introducir usuario Fulanito Prueba32 (usuario admitido por el banco sin
lmite de crdito)
2. Seleccionar segunda pelcula (hay 3 copias)
3. Alquilarla
4. Recoger Pelcula y Recibo
5. Salir del sistema
6. Introducir usuario Fulanito Prueba32
7. Seleccionar segunda pelcula (hay 2 copias)
8. Alquilarla
9. Recoger Pelcula y Recibo
10. Salir del sistema
11. Introducir usuario Fulanito Prueba32
12. Seleccionar segunda pelcula (hay 1 copias)
13. Alquilarla
14. Recoger Pelcula y Recibo

15. Salir del sistema

16. Introducir usuario Fulanito Prueba32
17. Seleccionar segunda pelcula (no debe haber copias)
18. El sistema debe ofrecer la posibilidad de reservar
19. Reservar
20. Salir del sistema

1.2 REALIZAR

PRUEBAS DE INTEGRACIN Y SISTEMA

Realizar las Pruebas de Integracin:

Ejecutar las pruebas.

Comparar los resultados de las pruebas con los resultados esperados y
ver las diferencias.
Analizar los componentes y las pruebas diseadas que presentaron esas
discrepancias para un posible rediseo del componente o cambios en la
prueba.

Realizar la Prueba del Sistema:

La prueba del sistema puede empezar cuando las pruebas de

integracin indican que el sistema satisface los requisitos de calidad
fijados durante las pruebas. Por ejemplo, el 90% de las pruebas de
integracin se realizan con el resultado esperado.
La prueba del sistema se lleva a cabo de forma similar que las pruebas
de integracin.
Los diseadores de las pruebas evalan los resultados de la prueba,
fundamentalmente a partir de dos mtricas:
1. Completitud de la prueba: indica el porcentaje de casos de
prueba que han sido ejecutados correctamente y el porcentaje de
cdigo que ha sido probado.
2. Fiabilidad: se basa en el anlisis de la tendencia en los errores
detectados y de los resultados esperados. Lo usual es que el nmero
de errores se incremente rpidamente al inicio de las pruebas, se
mantenga estable posteriormente durante un tiempo y finalmente
empiece a decrecer. Basndose en el anlisis de la tendencia de los
errores detectados se puede sugerir realizar pruebas adicionales,
relajar el criterio de pruebas si los objetivos de calidad se pusieron
muy altos, o revisar la parte del sistema que no cumple los
requisitos de calidad.