Este documento describe los conceptos básicos de los casos de uso como herramienta de análisis y diseño orientado a objetos. Define actores como elementos externos que interactúan con el sistema, y casos de uso como las funciones que debe realizar el sistema. Explica los flujos principales y excepcionales de un caso de uso, así como las relaciones entre casos de uso como uso, inclusión y extensión.

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

2. CASOS DE USO Los casos de uso describen bajo la forma de accciones y reacciones el comportamiento de un sistema desde el punto de vista de un usuario ; permiten definir los límites del sistema y las relaciones entre el sistema y el entorno. El modelo de Casos de Uso emplea dos conceptos básicos: Actor y Caso de Uso

3. Estos conceptos permiten definir: que elementos externos al sistema interactuan con él ( Actor ) y qué funciones deben ser realizadas por el sistema ( Caso de Uso ) CASOS DE USO actor

4. La definición de un caso de uso incluye la descripción de todos los comportamientos que representa: la secuencia principal diferentes variaciones del comportamiento normal todas las condiciones de excepción que pueden ocurrir La dinámica de un caso de uso puede ser especificada en forma textual o mediante diversos diagramas UML ( secuencia, máquina de estados o colaboración ) CASOS DE USO

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

8. Los actores no forman parte del sistema. Un actor puede: solamente ingresar información al sistema solamente recibir información del sistema ingresar y recibir información del sistema Usualmente estos actores aparecen en la descripción del dominio, en las entrevistas con los usuarios y/o con los expertos. Por ejemplo: sistema de alumnado: alumno, profesor, etc. sistema de stock: sist. facturación, vendedor Actor

9. Quién está interesado en ciertos requerimientos? En qué lugar de la organización el sistema será usado? Quién se beneficiará con el uso del sistema? Quién suministrará al sistema esta información, usará esta información, y eliminará esta información? Quién mantendrá el sistema? El sistema usará recursos externos? Una misma persona desarrollará diferentes roles? El mismo rol será desempeñado por varias personas? El sistema interactuará con un sistema preexistente? Actor – Formas de Identificarlo

10. Un Caso de Uso modela el diálogo entre un actor y el sistema. El conjunto de todos los casos de uso de un sistema constituye todas las formas en que el sistema puede ser empleado. Casos de Uso para un Sistema de Stock Recepción de mercadería Dar de baja un item Consulta sobre existencia Mantener información de usuarios Mantener información de proveedores Mantener información de mercaderías CASOS DE USO

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

13. Las características de las relaciones de uso son: Aparecen como funcionalidad común, luego de haber especificado varios casos de uso. Los casos usados son casos de uso en sí mismos. El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la diferencia con las extensiones, que son opcionales. CASOS DE USO - Include

14. Muchas veces, la funcionalidad de un caso de uso incluye un conjunto de pasos que ocurren sólo en algunas oportunidades. Supongamos que estamos especificando un sistema en el cual los clientes pueden ingresar pedidos interactivamente, y que dentro de la funcionalidad del ingreso de pedidos el usuario puede solicitar al sistema que le haga una presentación sobre los nuevos productos disponibles, sus características y sus precios. CASOS DE USO - Extensión

15. CASOS DE USO - Extensión Las extensiones tienen las siguientes características: Representan una parte de la funcionalidad del caso que no siempre ocurre. Son un caso de uso en sí mismas. No necesariamente provienen de un error o excepción. En su libro, Jacobson ejemplifica los casos de uso con ir a cenar a un restaurant. Para él, tomar café después de cenar es un ejemplo de una extensión.

16. CASOS DE USO - Extensión La pregunta que surge claramente es ¿cuál es la diferencia entre una alternativa y una extensión? La respuesta puede derivarse de las características de cada uno: Una extensión es un caso de uso en sí mismo, mientras que una alternativa no. Una alternativa es un error o excepción, mientras que una extensión puede no serlo. De todas formas, en la práctica aparecen dudas con respecto a la conveniencia de considerar algo optativo en un caso como una alternativa o una extensión, sobre todo porque no queda claro si algo puede ser visto como un caso de uso en sí mismo o no. Como regla aproximada en este caso podemos pensar que si algo opcional debe ser expresado con más de un paso, seguramente es una extensión y no una alternativa.

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.

18. Un caso de uso es una secuencia de operaciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y otros sistemas. Un actor es una entidad externa al sistema que se modela y que puede interactuar con él. Un ejemplo de actor puede ser un usuario o cualquier otro sistema. CASOS DE USO - Sintesis