Departamento de Informática Segundo semestre de Repaso para Certamen 1

Transcripción

1 Universidad Técnica Federico Santa María ILI-236 Fundamentos de Ing. de SW Departamento de Informática Segundo semestre de 2011 Caso: Sistema de control de cajeros Repaso para Certamen 1 Su compania ha sido contratada para desarrollar el software de control de uno nuevo tipo de cajeros. Estos cajeros tienen un lector de banda magnética, un lector de huellas, una consola (pantalla + teclado) para la interacción con el cliente, una ranura para depositar sobres de deposito, un dispensador de dinero, una impresora de recibos, y un interruptor (bajo llave) que es usado por un operador para iniciar o detener el cajero. El cajero se comunica con el banco vía un enlace de red. El cajero automático solo puede atender a un cliente a la vez. Para iniciar una sesión, el cliente deberá insertar una tarjeta bancaria en cajero automático y teclear su código personal (PIN). El numero de la tarjeta y el PIN se enviarán al banco como parte de cada transacción (para su validación). El cliente podrá realizar una o más transacciones por sesión. El cajero retendrá la tarjeta hasta que el cliente indica que no desea efectuar más transacciones, momento en que le será devuelta la tarjeta (excepto en las situaciones descritas mas abajo). El cajero debe ofrecer los siguiente servicios: Un cliente debe ser capaz de hacer retiros de dinero de cualquier cuenta asociada a la tarjeta. El banco debe aprobar cada transacción de retiro antes de que se dispense cualquier dinero. Un cliente debe ser capaz de hacer depósitos (dinero en efectivo y/o cheques) a cualquier cuenta asociada a la tarjeta. Para realizar un deposito, el cliente debe colocar el dinero en un sobre de deposito, ingresar el monto del depósito (este valor sera usado para verificar la validez del deposito), y depositar el sobre. El deposito se verifica en forma manual, después de que el operador retire el sobre del cajero. Debe obtenerse la aprobación del banco antes de físicamente aceptar el sobre. Un cliente debe ser capaz de hacer una transferencia de dinero entre dos cuentas vinculadas a la tarjeta. Un cliente debe ser capaz de consultar el saldo de cualquier cuenta asociada a la tarjeta. Un cliente puede cancelar cualquier transacción en curso, pulsando la tecla Cancelar en vez de responder la siguiente pregunta del cajero. El cajero automático le comunicará cada transacción al banco, cada transacción debe ser autorizada por el banco. Normalmente, una transacción se considera finalizada por el banco una vez que ha sido aprobado. En el caso de depósitos, un segundo mensaje se enviará al banco indicando que el cliente ha depositado el sobre. Si el cliente no deposita el sobre en el tiempo de espera, o presiona Cancelar, no se enviara el segundo mensaje al banco, y el depósito no se completara. Para autorizar transacciones sobre el limite diario de $ , el cajero le pedirá al cliente que coloque el dedo índice derecho en el lector de huellas. Si el banco determina que el PIN del cliente no es válido, el cliente tendrá que volver a introducir el PIN antes de que una transacción puede continuar. Si el cliente se equivoca tres veces en ingresar el PIN, la tarjeta sera retenida por la máquina, y el cliente deberá ponerse en contacto con el banco para recuperarla. Si una transacción falla por cualquier otra razón que no sea PIN incorrecto, el cajero automático le mostrara al cliente una explicación del problema, y luego le preguntará al cliente si el/ella quiere realizar otra transacción. El cajero automático imprimirá un recibo por cada transacción exitosa, que muestra la fecha y hora, la ubicación de la máquina, el tipo de operación, la(s) cuenta(s) afectada(s), el monto de la transacción, y el saldo disponible de la cuenta afectada (la cuenta destino en el caso de transferencias). El cajero tiene un interruptor (bajo llave) que es usado por el operador para iniciar y detener el servicio a clientes. Después de usar el interruptor para prender la maquina, el operador debe ingresar el total de efectivo que hay dentro de la maquina (el operador debe contar el efectivo en forma manual antes de prender el cajero). El cajero sólo se puede apagar cuando no está atendiendo a un cliente. El mismo interruptor se usa para apagar la maquina. Cuando el cajero esta apagado, el operador puede retirar los sobres de deposito que están dentro 1

2 del cajero, como también hacerle mantención a la maquina (agregar mas efectivo, colocar nuevo rollo de papel para los recibos, etc.) El cajero también mantendrá un registro interno de las transacciones efectuadas, para facilitar la resolución de las problemas que surgen por fallos de hardware en el medio de una transacción. Se guardara un registro cada vez que el cajero automático se pone en marcha o se apague, y también por cada mensaje (deposito, retiro) enviado al Banco (junto con la respuesta de vuelta, si se espera una). Estos registros pueden incluir el número de la tarjeta usada, como también el monto de la transacción, pero por seguridad, nunca deben incluir el código PIN ingresado. Ejercicios con respecto al Caso 1. Identifique algunos requerimientos funcionales. Sol. El enunciado es una larga lista de requerimientos. Asegúrense de escribirlos como requerimientos, p.ej., El cliente puede depositar dinero en una cuenta asociada a su tarjeta bancaria, El sistema imprimirá el resultado final de transacciones exitosas, etc. 2. Identifique algunos requerimientos no-funcionales. Sol. No hay mucha información acerca de requerimientos no-funcionales en este enunciado. Un posible requisito no-funcional habla acerca de la seguridad de las transacciones, p.ej., La comunicación con el banco debe realizarse en forma segura. Otra fuente de requisitos no-funcionales: privacidad de datos. Por ejemplo, Un cliente no debe poder acceder a cuentas ajenas. 3. Desarrolle un diagrama de casos de uso para el sistema. Sol. Identificamos tres actores: Cliente, Banco y Operador (extraídos directamente del enunciado). El Cliente y Banco interactúan a través del sistema para llevar a cabo transacciones, así que incluimos el caso de uso Realizar transacción. Pero antes de poder realizar una serie de transacciones, el Cliente debe autentificarse, ingresando su tarjeta y PIN. Entonces, agregamos un nuevo caso de uso Iniciar sesión que representa la lógica de autentificacion. Como uno siempre debe autentificarse antes de realizar una transacción, Realizar transacción «include» Iniciar sesión. 2

3 El cajero se puede usar para realizar distintos tipos de transacciones, así que hemos incluido cuatro nuevos casos de usos, uno para cada tipo de transacción mencionado en el enunciado (Realizar deposito, Realizar retiro, Consultar saldo, Realizar transferencia). Estos son especializaciones del caso de uso Realizar transacción, usamos la flecha correspondiente en el diagrama. El cliente puede presionar el botón Cancelar en cualquier momento durante una transacción, en cuyo caso el cajero cancela la transacción actual. Así que agregamos el caso de uso Cancelar transacción, pero, como se relaciona con el resto de los casos de uso? Recuerden que A -«extends» B significa que A extiende la funcionalidad de B bajo determinadas condiciones. Como solo podemos cancelar transacciones no finalizadas, agregaremos un «extends» desde Realizar transacción. En este caso, la condición es que el cliente oprimió el botón Cancelar. En forma similar, agregamos el caso de uso Imprimir comprobante, que solo ocurrirá si la transacción se completo en forma exitosa. Esto queda mas claro con la siguiente notación, donde hemos indicado los puntos de extensión del caso de uso Realizar transacción: Finalmente, hay tres casos de uso asociado a Operador: Encender cajero, Apagar cajero y Mantener cajero. El primero representa el caso en que el Operador prende la maquina, incluye ingresar el monto de dinero disponible en la maquina. Apagar cajero y Mantener cajero son dos casos de uso separados, porque puede que el Operador apague el cajero sin realizarle mantención, pero si quiere realizarle una mantención, debe apagarlo primero (y por eso hay un «include» entre los dos casos de uso). No mencionamos el registro de transacciones en nuestro diagrama, pero puede agregarse un nuevo caso de uso Registrar transacciones, el cual seria incluido dentro de Realizar transacción. 4. Desarrolle en formato expandido de un caso de uso que represente un proceso fundamental del sistema. Sol. Nos saltamos esta parte por falta de tiempo. 5. Desarrolle un DSS para el escenario mas importante del mismo caso de uso. Sol. Nuestra primera versión del DSS para Iniciar sesión: 3

4 Este diagrama trata de modelar el siguiente escenario: (a) El Cliente ingresa una tarjeta (ingresartarjeta). (b) El Sistema verifica si esta tarjeta realmente es una tarjeta bancaria valida (estarjetabancaria) (c) Mientras el PIN ingresado no sea valido (loop, máximo de tres intentos): i. Si es una tarjeta valida (opt), el Cliente ingresa un PIN (ingresarpin) ii. El Sistema valida la tarjeta, enviando el PIN y # de tarjeta al Banco (validartarjeta) iii. El Banco le indica al Sistema si la tarjeta es valida o no. Usamos el operador sd para colocarle nombre al diagrama, para poder reutilizarlo en otros diagramas. Este diagrama esta bien para una primera versión, pero puede ser refinado. Algunos aspectos que pueden ser mejorados: Los nombres de la operaciones, atributos. En la practica, el Cliente inserta la tarjeta en el LectorTarjeta, y no en el Sistema. Lo mismo con el PIN: el Cliente ingresa el PIN al Sistema a través de la Consola. El diagrama anterior no indica que pasa si el Cliente ingresa mal tres veces el PIN y tampoco especifica que pasa si la tarjeta ingresada no es una tarjeta bancaria. Nueva versión: 4

5 En esta versión, el Cliente inserta la tarjeta en el LectorTarjeta, y el LectorTarjeta le avisa al Sistema que una tarjeta fue ingresada. No incluí la interacción entre Cliente y LectorTarjeta en el diagrama porque solo nos interesan las interacciones directas con el Sistema en un DSS. El Sistema revisa si es una tarjeta bancaria, usando algún algoritmo local. Si la tarjeta bancaria no es valida (segundo fragmento del alt), el Sistema le pide al LectorTarjeta que devuelva la tarjeta. Si la tarjeta bancaria es valida (primer fragmento del alt), entonces el Cliente tiene tres intentos para ingresar el código PIN correcto, a través de la Consola. Al igual que el caso del LectorTarjeta, este diagrama no muestra la interacción entre el Cliente y Consola. Si después de tres intentos, el PIN aun no corresponde a la tarjeta, el Sistema le pide al LectorTarjeta que se trague la tarjeta. Si el cajero no se traga ni devuelve la tarjeta, iniciamos correctamente una sesión y el cliente puede realizar transacciones: 6. Desarrolle un modelo de dominio con los conceptos y atributos clave, y las relaciones entre conceptos, con su cardinalidad. Sol. Tampoco alcanzamos a desarrollar el modelo de dominio. Algunos candidatos a conceptos: Cajero, Consola, LectorTarjeta, Impresora, LectorHuellas, Cliente, Tarjeta, Cuenta, Banco, Transaccion, Retiro, Deposito, etc. Algunas relaciones entre conceptos: 1) relación de composición entre Cajero y sus partes, 2) un Banco tiene 0..* clientes, un Cliente tiene 1..* tarjetas, etc., 3) Retiro es-una Transacción, Deposito es-una Transacción, etc., y 4) Clase de asociación para llevar registro de transacciones. Otros tipos de ejercicios 1. Preguntas cortas sobre definiciones 2. Fundamentar porque un ejemplo dado es un requisito/caso de uso/modelo de domino/... valido/no valido. 3. Dada una descripción de un escenario/conceptos/..., como modelaría la... 5