1. Análisis y Diseño Orientado a Objetos

5. Flujo de eventos principal : El caso de uso comienza cuando el sistema le solicita al cliente el número de PIN. El cliente puede ahora digitar su PIN por medio del teclado. El cliente confirma lo ingresado por medio de la tecla Enter. El sistema luego verifica si el PIN es válido. Si el PIN es válido, el sistema comunica la aceptación, y termina el caso de uso. Flujo de eventos exepcional ( Cancelación ): El cliente puede cancelar la transacción en cualquier momento presionando la tecla Cancel, y por lo tanto se reinicia el caso de uso. No se realiza ningun cambio en la cuenta del cliente. Casos de uso: Validar Cliente en un Cajero CASOS DE USO

6. Flujo de eventos exepcional ( Re-digitación del PIN ): El cliente puede borrar el PIN en cualquier momento antes confirmar lo ingresado y reingresar un nuevo PIN. Flujo de eventos exepcional ( PIN no válido ): Si el cliente ingresa un número de PIN inválido, el caso de uso comienza nuevamente. Si esto ocurre tres veces seguidas, el sistema cancela la transacción, indicándole al cliente que por 60 segundos no podrá interactuar con la máquina. CASOS DE USO

7. Cuando se posee suficiente conocimiento, usualmente se emplea un diagrama de secuencia para describir cada flujo de eventos incluido en el caso de uso . CASOS DE USO 1. Flujo de eventos principal 2. Cancelación 3.Re-digitación del PIN 4.PIN no válido

11. CASOS DE USO

12. Es común que la misma funcionalidad del sistema sea accedida a partir de varios casos de uso. Por ejemplo, la funcionalidad de buscar un producto puede ser accedida desde el ingreso de pedidos, desde las consultas de productos, o desde los reportes de ventas por producto. ¿Cómo hago para no repetir el texto de esta funcionalidad en todos los casos de uso que la acceden? La respuesta es simple: sacando esta funcionalidad a un nuevo caso de uso, que es usado por los casos de los cuales fue sacada. Este tipo de relaciones se llama relaciones de uso y se representa por una línea punteada desde el caso que ‘usa a’ al caso que es ‘usado’. CASOS DE USO - Relaciones

17. CASOS DE USO - Relaciones La definición de las relaciones de uso y extensión deja una zona sin definir: ¿Qué pasa con la funcionalidad que es común a varios casos de uso, pero al mismo tiempo es opcional? Por ejemplo, pensemos en la impresión de un comprobante, algo que el usuario de un sistema puede o no hacer en distintos casos de uso. Si uno se guía por la funcionalidad común a varios casos, piensa que el caso de uso imprimiendo comprobante es usado por otros casos, pero si se guía por la opcionalidad, piensa que extiende a otros casos. Como esto no queda claro a partir de la bibliografía, creemos conveniente que este tipo de situaciones se especifiquen como extensione s, ya que de esta forma podemos remarcar gráficamente la opcionalidad de la relación.