El documento describe los diagramas de casos de uso, incluyendo sus elementos principales como actores, casos de uso y las relaciones entre ellos. Explica que los diagramas de casos de uso modelan la funcionalidad de un sistema desde la perspectiva de los usuarios finales a través de la interacción entre actores y casos de uso.

1. Introducción Por muchos años, los analistas han usado escenarios o historias que describen maneras en que un usuario va a interactuar con el sistema. Ivar Jacobson introdujo lo que conocemos como Diagramas de Casos-de-Uso (1994) Se los utiliza para la obtención y modelamiento de requerimientos. Es quizás el diagrama más importante presentado por UML, ya que describe la funcionalidad de una serie de Casos en el que se usaría el sistema a modelar, desde el punto de vista del usuario final

2. Casos de Uso Un Casos de Uso es una secuencia de transacciones en un sistema cuyo resultado proporciona un valor mesurable a un actor individual del sistema. Describe el QUÉ hace el sistema desde la perspectiva del usuario. Conjunto de escenarios relacionados entre si por un objetivo común del usuario.

3. Diagramas de Casos de Uso relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa.

4. Elementos de un DCU Sistema Se debe delimitar las fronteras del sistema desarrollado coma parte del modelamiento de los casos de uso Se lo representa mediante un recuadro donde el nombre del sistema aparece arriba o encima del recuadro.

5. NOMBRE DEL SISTEMA

6. Elementos de un DCU Actores Un actor representa un rol que es desempeñado con respecto al sistema, y no así un usuario individual del sistema. Un mismo usuario puede desempeñar varios roles. El nombre del actor describe el papel desempeñado

7. Tipos de Actores

8. Elementos de un DCU Relaciones entre Actores Cuando varios actores, aparte de su rol, desempeñan también un rol general común puede ser descrito como generalización . Los actores “heredan” el comportamiento y lo extienden de alguna manera. Cajero Supervisor Gerente

9. Elementos de un DCU Casos de Uso Son eventos que se producen entre un actor y un sistema Siempre es iniciado por un actor. El caso de uso proporciona cierto valor al actor. El caso de uso es completo (No dividir un caso de uso en otros más pequeños) Los escenarios de un caso de uso son descritos textualmente utilizando un formato común (plantilla). Un caso de uso debe estar libre de detalles relacionados a la tecnología.

10. EJEMPLO 1

11. Ejemplo 2 Pasajero Empleado Sistema de Reservaciones Realizar Reserva Programar Vuelos Describir Vuelos

12. Ejemplo 3 UML 1.5

13. Elementos de un DCU Relaciones entre Casos de Uso Se representan como una línea que une a los dos casos de uso relacionados, con una flecha en forma de triángulo y con una etiqueta <<extiende>> o <<incluye>> o <<usa>> según sea el tipo de relación. Asociación : Es una línea continua que asocia los actores con su o sus respectivos casos de uso.

14. Inclusión : Indica que el caso de uso que esta incluido dentro del base se ejecuta de forma obligatoria. <<include>> Pago con tarjeta Verificar tarjeta

15. Extensión : Indica que el caso de uso que se esta representando tiene un comportamiento o un uso de carácter opcional. En otras palabras el caso de uso origen extiende el comportamiento del caso de uso de destino. <<Extend>> Hacer Compras Pagar tarjeta crédito

16. Utilizaremos una relación tipo << uses>> cuando nos encontramos con una parte de comportamiento similar en dos casos de uso y no queremos repetir la descripción de dicho comportamiento común. <<uses>>

17. Preguntas claves para la construcción de los CU Habiendo identificado cada uno de los actores podemos preguntar: ¿cuáles son las tareas del actor? ¿qué información crea, guarda, modifica, destruye o lee el actor? ¿debe el actor notificar al sistema los cambios externos? ¿debe el sistema informar al actor de los cambios internos?

18. Como ejemplo esta el caso de una Máquina Recicladora: Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar: Registrar el número de ítemes ingresados. Imprimir un recibo cuando el usuario lo solicita: a. Describe lo depositado b. El valor de cada item c. Total El usuario/cliente presiona el botón de comienzo Existe un operador que desea saber lo siguiente: a. Cuantos ítemes han sido retornados en el día. b. Al final de cada día el operador solicita un resumen de todo lo depositado en el día. El operador debe además poder cambiar: a. Información asociada a ítemes. b. Dar una alarma en el caso de que: i. Item se atora. ii. No hay más papel. Ejemplo:

19. Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien pu ede Imprimir un informe: Como una primera aproximación identificamos a los actores que interactúan con el sistema:

20. Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

21. Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.

22. Entonces, el diseño completo del Diagrama de Caso de Uso es:

23. <<extend>> : indicar en que punto entra en juego el caso de uso que lo extiende (punto de extensión ) EJEMPLOS DE CASOS DE USOS

24. Asociaciones Actor-Caso de Uso (también se pueden mostrar cardinalidades) Generalización Actor-Actor (también pueden darse Caso de Uso-Caso de Uso)

25. Cliente Solicitante Proveedor Empleado Gerente Sistema Burger Queen Ordenar Comida Contratar Personal Controlar Ventas e Inventarios Reordenar Suministros Producir Reportes <<incluye>> <<incluye>>

26. La forma mas popular de un caso de uso es un documento de texto. Título Actor Precondiciones Objetivo Flujo Principal Flujos Alternos Poscondiciones Estructura de casos de uso

27. Título Sección fundamental del caso de uso. Permite identificarlo y comunicar parte de sus características. Ejemplo: Factura_Aprobar

28. Actor Ejemplo: Imaginemos un encargado de atender las llamadas telefónicas de solicitud de servicio. El encargado tiene una meta: registrar la llamada en un sistema computacional e iniciar la solicitud de servicio. El encargado del ejemplo es un actor y tiene una meta. Un actor en un caso de uso es aquel que interactúa con el sistema para lograr una meta. Ejemplos: Encargado de reservaciones, Gerente de Finanzas.

29. Precondiciones Es el estado del sistema que debe cumplirse antes de ejecutar un caso de uso. Generalmente una precondición indica que se ha ejecutado algún otro caso de uso o que se tiene acceso a información que se utilizará en el caso de uso.

30. Objetivo Es el valor o beneficio que el actor desea obtener al ejecutar el caso de uso. Durante la redacción del caso de uso es imprescindible mantener el objetivo en mente para prevenir acciones o pasos que no estén en el alcance del caso de uso. Ejemplos: “Eliminar un registro de inventario”, “Autorizar un contrato de arrendamiento”.

31. Flujo Principal El flujo principal es una serie de pasos que sirve para llegar al objetivo o meta del caso de uso. En un caso de uso el flujo principal es único. El flujo principal define el “camino feliz” del caso de uso. Es decir, la obtención del objetivo (escenario de éxito) sin obstáculos ni interrupciones.

32. Flujos Alternos En un caso de uso pueden existir uno o varios flujos alternos. Los flujos alternos capturan las acciones que pueden desviar el flujo principal. Son útiles para capturar las excepciones funcionales de un sistema así como escenarios alternos de éxito. No tienen como propósito documentar errores de operación de un sistema.

33. Poscondiciones Las poscondiciones definen el estado del sistema después de ejecutar el flujo principal de un caso de uso. Ejemplo. “El sistema autoriza una orden de compra”.

34. DIAGRAMAS DE ACTIVIDADES Los diagramas de actividades muestran las transiciones de estado en que se encuentra el sistema en una determinada transacción. Esta representa un flujo de eventos en un caso de uso.

35. ELEMENTOS Y SU REPRESENTACION Actividad: Transición: Final: Inicio: Decisión:

36. REPRESENTACIÓN Y PARTES DE UN DIAGRAMA DE ACTIVIDADES

37. El diagrama de actividades resalta, precisamente, las actividades.

38. DECISIONES

39. RUTAS CONCURRENTES INDICACIONES

41. Diagrama de Estado Cambios necesarios de los objetos que lo conforman

42. Conforme un sistema interactúa con los usuarios y (posiblemente) con otros sistemas, los objetos que lo conforman pasan por cambios necesarios para ajustar las interacciones. Por esa razón se necesita contar con un mecanismo para cambios en el modelo. Un cambio en un sistema se da debido a que los objetos que componen dicho sistema modificaron su estado como respuesta a los sucesos y al tiempo. Diagrama de estado

43. Estados por los que pasa una lavadora para entregar la ropa limpia.

45. DIAGRAMA DE CLASES Los diagramas de clases representan un conjunto de elementos del modelo que son estáticos, como las clases y los tipos, sus contenidos y las relaciones que se establecen entre ellos.

46. Sirve para visualizar las relaciones entre las clases que involucran el sistema. Elementos Clase atributos, métodos Relaciones Herencia, Asociación Ensamblado Dependencia

47. CLASE ATRIBUTOS ACCIONES ATRIBUTOS Y ACCIONES DE UNA LAVADORA

48. Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). CLASE

49. ATRIBUTOS Representa alguna propiedad de la clase, que se encuentra en todas las instancias de la clase. Definen la estructura de una clase y de sus correspondientes objetos. Nombre_de_la_clase lista_de_atributos Persona nombre edad

50. Los atributos básicos son atributos independientes dentro del objeto. En contraste, los atributos derivados son atributos que dependen de otros atributos. Los atributos derivados dependen de otros atributos del objeto, los cuales pueden ser básicos o derivados . ATRIBUTOS DERIVADOS Notación para atributos derivados. Ejemplo

51. TIPOS DE ATRIBUTOS Public: Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados Private : Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar) Protected : Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven

52. Los valores de los atributos de una clase pueden restringirse. RESTRICCIONES DE LOS ATRIBUTOS

53. OPERACIONES(METODOS) Las operaciones son funciones o transformaciones que se aplican a todos los objetos de una clase particular. La operación puede ser una acción ejecutada por el objeto o sobre el objeto. Tipos de Método

55. Uno-uno Uno-muchos Muchos-muchos Muchos-uno Cardinalidad de relaciones RELACIONES ENTRE CLASES Ensamblados Generalización Asociación Clasificación

56. Indica que una subclase hereda los métodos y atributos especificados por una Superclase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Superclase. GENERALIZACION(HERENCIA)

58. permite asociar objetos que colaboran entre si. ASOCIACION Ejemplo: Los objetos Juan Pérez y UNLaR están relacionadas por la liga estudia-en que describe que &quot;Juan Pérez estudia en la UNLaR&quot;.

59. El grado de una asociación se determina por el número de clases conectadas por la misma asociación. Las asociaciones pueden ser binarias, ternarias, o de mayor grado. GRADO DE ASOCIACION Notación para diagrama de clases describiendo una asociación ternaria.

60. ASOCIACIONES REFLEXIVAS Las asociaciones pueden ser reflexivas , relacionando distintos objetos de una misma clase. Ejemplo: Para una clase persona puede existir una asociación pariente que describe que dos objetos de tipo persona , como Juan Pérez y Laura Pérez son parientes .

61. ATRIBUTOS DE LIGA (O ASOCIACIÓN) Al igual que un atributo de clase es propiedad de la clase, un atributo de asociación (o atributo de liga ) es propiedad de una asociación. La notación es similar a la usada para los atributos de clases, excepto que se añade a la asociación, y no se incorpora un nombre de clase.

62. Asociación como clase

63. ENSAMBLADOS: AGREGACIÓN Y COMPOSICIÓN Son formas especiales de asociación entre un todo y sus partes, en donde el ensamblado está compuesto por sus componentes. Composición (el Objeto base se construye a partir del objeto incluido). Agregación (el objeto base utiliza al incluido para su funcionamiento). COMPOSICION AGREGACION

64. Diagrama de objetos Partiendo del hecho que un objeto es una instancia de clase, tal como se define en la conceptualización básica de la programación orientada a objetos, en UML la representación de un diagrama de objetos se hace de tal forma que teniendo ya una clase, el símbolo del objeto es un rectángulo, pero con el nombre subrayado.

65. El nombre de la instancia específica se encuentra a la izquierda de los dos puntos (:), y el nombre de la clase a la derecha. Por ejemplo, si ya se tuviera una clase llamada “BANCO”, una instancia de esa clase o un objeto instanciado a partir de esa clase se representaría de la siguiente forma: Diagrama de objetos BancoSuperior:BANCO

66. DIAGRAMA DE SECUENCIA Este tipo de diagramas muestra una interacción ordenada según la secuencia de eventos vista a la luz de una línea de tiempo. En particular, se muestran los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo.

67. ELEMENTOS Y SU REPRESENTACIÓN . Intercambio de mensaje entre Objetos y otros elementos: Mensajes ó peticiones Líneas de Vida Tiempo de Ejecución Del Caso de Uso Objetos NOMBRE NOMBRE

68. Muestra cada uno de los eventos que realiza la lavadora en una línea de vida EJEMPLO 1

69. DIAGRAMA DE COLABORACIONES DIAGRAMA DE COMUNICACIONES Este diagrama de nivel dinámico, representa el conjunto de objetos y la interacción que existe entre ellos.

70. ELEMENTOS Y SU REPRESENTACION Objetos Mensajes

71. () () EJEMPLO 1

72. EJEMPLO 2