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

Ciclo de vida de un proceso unificado

Ejemplo:Videoclub Automtico1Captura de requisitosEl 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.1Encontrar actores y casos de usos1.1.1Identificar actoresUsuario: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.1Identificar Caso de UsoAlquilar 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.2Describir modelo de Caso de Uso.

1.2Detallar casos de usos1.2.1Disear diagramas de estados

1.2.2Descripcin del caso de usoPrecondicinEl usuario ha pulsado en el videoclub alquilar pelculaFlujo de eventosCamino 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.PoscondicinEl 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 usoPelcula: 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.3Definir prototipo de interfaz unificado

1Anlisis y Diseo1.1Analizar los casos de uso (identificar clases y describir interacciones).

Diagrama de Colaboraciones:

1.2Analizar 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 clienteActualizar la informacin sobre las pelculasActualizar el balance de la empresaOtras responsabilidades provenientes de otros casos de uso:Gestionar el envo de recordatoriosGestionar la devolucin de la PelculaGestionar la carga y descarga de pelculas1.3DiseoDisear 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 AnlisisFicha de pelculayFicha de clientedel caso de uso alquilar pelcula.Ficha de pelcula y Ficha de cliente que se generalizaron en el anlisis de la claseFicha, 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 AnlisisI.UsuarioI.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 AnlisisI.UsuarioeI.PelculasI.Pelculas se absorbe en la clase de diseo I.Usuario con objeto de reunir en una sola clase todas las interfaces grficas.Clase de AnlisisClase de DiseoRequisito de Diseo

I.UsuarioI.UsuarioActiva

GestorGestor

I.PelculasAbsorbida en I.Usuario

Lista Fichas ClientesIncluida para manejar Clientes

Lista Fichas PelculasIncluida para manejar Pelculas

Ficha PelculaFicha Pelcula

Ficha ClienteFicha Cliente

I.DispensadorI.Dispensador

I.Sistema Contable (1)I.SC.LocalDel modelo de Despliegue

I.Sistema Contable (2)I.SC.CentralDel modelo de Despliegue. Activa

I.BancoI.Banco

Diagrama de Clases de Diseo:

Diagrama de secuencia:

Disear clases de Diseo (identificar operaciones, atributos, relaciones)1)Identificar operaciones:Identificando los mensajes a los que debe responder en el diagrama de secuenciaAnalizando 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+entregarPelculaRecibo()+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 MtodoActualizarPelculade 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 */VoidActualizarPelicula (Cliente, codigoPeli) {Pelcula = BuscaPelicula en listaFichaPelculas (codigoPeli);Pelcula