Documente Academic
Documente Profesional
Documente Cultură
CAJERO AUTOMTICO
El siguiente ejercicio muestra las diferentes actividades que se realizan dentro del desarrollo
de un producto software siguiendo el Proceso Unificado. Este ejemplo desarrolla el caso de
estudio de un cajero automtico mostrando las actividades en cada flujo de trabajo, as
como el resultado de cada una de dichas actividades.
Requisitos
Actividad: Lista de Requisitos Funcionales
R1. El cliente debe validarse en el sistema para poder realizar cualquier operacin en el cajero
automtico.
R2. Si el cliente intenta sacar una cantidad que supera el saldo de su cuenta, el cajero le avisar
de que no es posible sacar esa cantidad
R3. Si el cliente intenta sacar una cantidad que supera el lmite diario, el cajero le avisar de
que no es posible y volver a solicitar una cantidad
Descripcin: El caso de uso comienza con la identificacin del cliente. El cliente usa el caso de
uso para ingresar dinero en su cuenta.
En este caso, adems, presentamos los dos flujos de eventos de forma paralela para que se
observe que existe una funcionalidad compartida.
Flujo de eventos del caso de uso Flujo de eventos del caso de uso
Ingresar Dinero Sacar Dinero
9. Recoge la tarjeta y
fin del caso de uso
Con el fin de aplicar la reutilizacin, se crea un nuevo caso de uso que involucra la
funcionalidad compartida.
Camino bsico
ACTOR SISTEMA
Caminos alternativos
Evento 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
Camino bsico
ACTOR SISTEMA
5. Devuelve la tarjeta.
6. Recoge la tarjeta.
Caminos alternativos
Evento 4: La cantidad solicitada supera el lmite diario. Se indica el error y se vuelve a pedir
otra cantidad.
Camino bsico
ACTOR SISTEMA
8. Devuelve la tarjeta.
Camino alternativo
Evento 6. Notifica al usuario que la cantidad no coincide con el dinero introducido y permite que
se repita la operacin desde el principio.
do/ Validar ()
CantidadesValidadas [OK]
/ mostrar (Operacin finalizada con xito)
Camino bsico
ACTOR SISTEMA
9. Se expulsa la tarjeta
10. Recoge la tarjeta 11. El sistema vuelve a la situacin inicial del cajero y fin
del caso de uso
Caminos alternativos
Diagrama de clases
Camino Bsico: Sacar dinero
Faltara:
Diagrama de clases:
Agregacin y composicin
Diagramas de Interaccin:
En este caso nos fijamos en la interaccin de los diferentes elementos en el tiempo
Diagrama de Secuencia
En este caso, refinamos el caso de uso: Aadimos la clase Cuentas que asocia nmero de
cuenta con una instancia de la clase Cuenta. La clase Transaccin ya no actuar directamente
sobre Cuenta
Realizacin en diseo del caso de Uso: Ingresar Dinero
Refinar en diseo el caso de Uso de Transferencia
Toda esta temtica tiene un fin y yo creo que es la de que el alumno sepa
por qu hacer uso de este modelado, para que le sirve o le va a servir.
Este modelado es de gran ayuda porque adquir los conocimientos acerca
de este modelado a objetos muy usado en la industria de la
programacin. Con sus caractersticas particulares me percat de que se
obtiene muchos beneficios al hacer uso de este modelado a objetos por
ejemplo la reutilizacin nos permite hacer uso otra vez de la estructura
del software. La robustez dice que es la capacidad que tiene de actuar
ante situaciones inesperadas, su Portabilidad que nos dice que se puede
utilizar en diferentes entornos. El encapsulamiento nos permite contener
informacin que solo nosotros o el desarrollador podr ver, herencia esta
nos dice que un objeto puede adquirir caractersticas de una clase es
decir de un conjunto de objetos. El polimorfismo es otro de los elementos
que permite cambiar de forma con solo llamar una funcin, tambin se
habl de otros elementos ms como modularidad y relacin. Bueno en
conclusin final la investigacin de los temas amplio mis conocimientos
como aprendiz de programacin y siento que si aplico bien lo aprendido
no tendr tantas complicaciones a la hora de programar.
Conclusiones