Caso de Uso
Validar Tarjeta y Clave (Refinado)
Actores primarios:
Cliente del Banco, Consorcio, Banco
Interesados y Objetivos:
Cliente del Banco: quiere realizar una operación con el ATM de manera rápida, para lo que debe validar su tarjeta y contraseña.
Consorcio: Quiere identificar correctamente el banco del cliente y mediar en la validación de manera eficaz.
Banco: Quiere identificar correctamente la identidad de la tarjeta.
Precondiciones:
El cliente tiene una cuenta en uno de los bancos del consorcio, así como una tarjeta emitida por el mismo.
Garantía de éxito (post-condiciones):
La tarjeta se valida correctamente.
Escenario Principal de Éxito:
1. El ATM pide al cliente que inserte la tarjeta de crédito.
2. El cliente inserta la tarjeta de crédito.
3. El ATM acepta la tarjeta de crédito y lee el número de tarjeta y el código del banco.
4. El ATM pide la contraseña al cliente.
5. El cliente teclea la contraseña.
6. El ATM envía el número de tarjeta, el código del banco y la contraseña al consorcio.
7. El consorcio envía el número de tarjeta y la contraseña al banco correspondiente.
8. El banco notifica la aceptación al consorcio.
9. El consorcio notifica la aceptación al cajero automático.
Escenario Alternativo:
La tarjeta es ilegible
1. El ATM notifica al cliente de que la tarjeta no se puede leer
2. El ATM expulsa la tarjeta.
3. El ATM vuelve a la situación inicial.
1. El consorcio notifica el rechazo al cajero automático.
2. El cajero automático notifica el rechazo al cliente y pide que teclee de nuevo la
contraseña.
3. Se ha repetido este escenario alternativo menos de 3 veces y el flujo continua en 5
(en el escenario principal).
4. Se ha repetido este escenario alternativo más de 3 veces:
1. El ATM retene la tarjeta.
2. El ATM notifica al cliente que la tarjeta queda retenida.
3. El ATM notifica al consorcio que la tarjeta queda retenida.
4. El consorcio notifica al banco que la tarjeta queda retenida.
5. El ATM vuelve a la situación inicial.
Requisitos especiales:
- Pantalla táctil en panel grande y plano. El texto debe ser visible desde un 50cms.
- Respuesta del ATM en menos de 5 secs, el 90% de las veces.
- Recuperación robusta cuando el acceso mediante comunicaciones falla.
- Posibilidades de internacionalización de texto.
- Comunicaciones cifradas.
Lista de variaciones de tecnología y datos:
a. Distintos tipos de tarjeta de crédito, dependiendo de los bancos emisores.
b. Se introduce la contraseña mediante un teclado o en la pantalla táctil.
c. En el futuro, creemos que se utilizarán otrás técnicas de identificación basadas en biometría.
Frecuencia de ocurrencia:
Puede ser casi continua.
Temas abiertos:
1.Explorar el tema de recuperación en caso de fallo de sistemas externos.
2.¿Qué modificaciones se necesitan para idiomas y paises distintos?
Retirar Efectivo(Refinado)
Actores primarios:
Cliente del Banco, Consorcio, Banco
Interesados y Objetivos:
Cliente del Banco: quiere retirar dinero de manera rápida, quiere que se anote la transacción en su cuenta de manera correcta, quiere la devolución de su tarjeta y quizá un recibo de la transacción.
Consorcio: Quiere identificar correctamente el banco del cliente y mediar en la transacción de manera eficaz.
Banco: Quiere identificar correctamente la cuenta del cliente, y anotar la transacción.
Precondiciones:
El cliente tiene una cuenta en uno de los bancos del consorcio, ha introducido su tarjeta, y contraseña, y ésta se ha validado correctamente por el banco correspondiente. El cliente selecciona retirar efectivo.
Garantía de éxito (post-condiciones):
El cliente obtiene su dinero, la transacción se anota.
Escenario Principal de Éxito:
1. El ATM pide al cliente que teclee la cantidad.
2. El cliente teclea una cantidad.
3. El ATM comprueba que la cantidad está dentro de los límites.
4. El ATM genera una transacción y la envía al consorcio.
5. El consorcio pasa la transacción al banco.
6. El banco aprueba la transacción.
7. El banco actualiza la cuenta.
8. El banco envía al consorcio la notificación de aceptación y el nuevo
saldo de la cuenta.
9. El consorcio envía al ATM la notificación de aceptación y el saldo.
10. El ATM entrega el dinero al cliente.
11. El cliente toma el dinero.
12. El ATM pregunta al cliente si quiere un recibo.
13. El cliente contesta SI.
14. El ATM imprime un recibo y pide al cliente que lo tome.
15. El cliente toma el recibo.
16. El ATM pregunta al cliente si quiere hacer otra operación.
17. El cliente contesta NO.
18. El ATM expulsa la tarjeta de crédito e indica al cliente que la tome.
19. El cliente toma la tarjeta de crédito.
20. El ATM vuelve a la situación inicial.
Flujos Alternativos:
* El cliente pulsa la tecla CANCELAR.
1. El ATM expulsa la tarjeta de crédito e indica al cliente que la tome.
2. El cliente toma la tarjeta de crédito.
3. El ATM vuelve a la situación inicial.
*La cantidad excede el límite superior o inferior, se vuelve a 1.
*El banco no aprueba la transacción.
1. El banco envía al consorcio la indicación de rechazo.
2. El consorcio envía al ATM la notificación de rechazo.
3. El ATM muestra un mensaje.
4. Se vuelve al caso de uso "Realizar Operación" para que el usuario seleccione un tipo de transacción.
*El usuario no toma el dinero después de 30secs.
1. El ATM indica al cliente que tome el dinero y emite una señal sonora.
2. El cliente toma el dinero y el flujo sigue en 11.
*El cliente no toma el dinero después de 30 secs.
1. El ATM retiene el dinero y la tarjeta.
2. El ATM muestra un mensaje al cliente.
3. El ATM notifica al consorcio de la retención.
4. El consorcio notifica al banco de la retención.
5. El ATM vuelve a la situación inicial.
*El cliente contesta NO y el flujo continua en 16.
*El cliente contesta SI y el flujo continua en el paso 1 del caso de uso "Realizar Operación"
(timeouts de comunicaciones, rotura de elementos mecánicos del cajero, etc.)
Validar Tarjeta y Clave (Refinado)
Requisitos especiales:
1.Pantalla táctil en panel grande y plano. El texto debe ser visible desde un 50cms.
2.Respuesta del ATM en menos de 5 secs, el 90% de las veces.
3.Recuperación robusta cuando el acceso mediante comunicaciones falla.
4.Posibilidades de internacionalización de texto.
5.Comunicaciones cifradas.
Lista de variaciones de tecnología y datos:
a. Se teclea la cantidad mediante un teclado o en la pantalla táctil.
b. En lugar de imprimir un recibo se podría mandar un SMS o un e-mail.
Frecuencia de ocurrencia:
Puede ser casi continua.
Temas abiertos:
1.Explorar el tema de recuperación en caso de fallo de sistemas externos.
2.¿Qué modificaciones se necesitan para idiomas y paises distintos?
Modelo de Objetos
Identificar Objetos y Clases
1.Seleccionar nombres en los requisitos.
2.Añadir clases adicionales procedentes de nuestro conocimiento del dominio.
3.Eliminar redundancias.
4.Eliminar clases irrelevantes.
5.Eliminar clases vagas.
6.Separar atributos.
7.Separar métodos.
8.Eliminar objetos de diseño.
9.Resultado: Preparar diccionario de clases.
Seleccionar Nombres en los Requisitos
Se desea diseñar el software necesario para una red bancaria provista de cajeros automáticos (ATMs), que serán compartidos por un consorcio de bancos. Cada banco dispone de una serie de servidores, provistos de software propio, que llevan la información sobre sus cuentas y procesa las transacciones que actúan sobre dichas cuentas. A estos servidores están conectados las estaciones de cajero, que son propiedad del banco y en las que operan cajeros humanos, que pueden crear cuentas e introducir transacciones sobre ellas. Los cajeros automáticos aceptan tarjetas de crédito, interaccionan con el usuario, se comunican con un ordenador central para llevar a cabo las transacciones, entregan dinero en efectivo al usuario e imprimen recibos. El sistema llevará el registro de las transacciones efectuadas, cumplirá características aceptables de seguridad y manejará accesos concurrentes a la misma cuenta. El coste de desarrollo de la parte compartida del sistema se dividirá entre los bancos que forman parte del consorcio en función del número de clientes provistos de tarjetas de crédito.
Software,Red bancaria,Cajero automático (ATM), Consorcio de bancos, Banco,Servidores, Cuenta bancaria,Información sobre la cuenta,Transacción de cajero,Estaciones de cajero, Cajero humano, Tarjeta de crédito, Usuario, Ordenador central, Transacción Remota,Dinero en efectivo, Recibo,Sistema,Registro de transacciones,Características de seguridad,Acceso a la cuenta,Coste de desarrollo,Parte compartida,Cliente.
Eliminar redundancias.
Cliente y Usuario son la misma clase. Nos quedamos con Cliente por adaptarse mejor al concepto.
Eliminar clases irrelevantes.
Coste de desarrollo no tiene nada que ver con el problema, queda fuera del sistema.
Eliminar clases vagas.
Sistema, Características de seguridad, Red bancaria y Parte compartida pueden considerarse vagas.
Separar atributos
Los atributos definen datos asociados a un objeto, en lugar de objetos (un atributo objeto se representa mediante una relación).
En el ejemplo, pueden considerarse atributos Información sobre la cuenta, (atributo de Cuenta bancaria), Dinero en efectivo y Recibo (atributos de Cajero automático), que pasan a ser clases
eliminadas.
Separar métodos
Observación: algunos nombres (por ejemplo, Llamada telefónica) definen realmente operaciones o eventos.
Eliminar objetos de diseño
Todas las clases que corresponden más a la solución del problema que a la situación real, deben considerarse objetos de diseño y eliminarse en la fase del análisis.
En el ejemplo, eliminaremos Registro de transacciones, Línea de comunicaciones, Acceso a la cuenta y Software.
Estaciones de cajero, Cajero humano,Tarjeta de crédito,Ordenador central, Cliente.
No hay comentarios:
Publicar un comentario