Casos de uso

Casos de uso

Andrea Cruz Arellano Y Julio César Sánchez Méndez

Indice:

1.Clasificación a la que pertenece (UML)____________________________________2

2.Nomenclatura__________________________________________________________3

3.¿Qué información se representa con este tipo de diagrama?________________11

4.Reglas de construcción_________________________________________________12

5.Errores comunes_______________________________________________________17

6.Ejemplo_______________________________________________________________23

7.Video _________________________________________________________________31

8.Referencias___________________________________________________________32

1.- CLASIFICACION A LA QUE PERTENECE (UML)

Es utilizado para representar los actores externos que interactúan con el sistema de información y a través de que funcionalidades (casos de uso o requisitos funcionales) se relacionan. El diagrama de casos de uso es uno de los diagramas incluidos en UML clasificado dentro del grupo de diagramas de comportamiento.

2.-Nomenclatura.

Un diagrama de casos de uso está compuesto, principalmente, de 3 elementos: Actores, Casos de uso y Relaciones.

Actores.

Se representan con una imagen de un “muñeco de palo” con el nombre del actor debajo.

Es algo o alguien externo al sistema que interactúa de forma directa con el sistema. Cuando decimos que interactúa nos referimos a que aporta información, recibe información o inicia una acción.

Tipos de actores

Los usuarios: se muestran como “perfiles o roles” que identifican a un tipo de usuario, pero no al usuario en sí.

Los actores: como sistemas se ven como entes que también interactúan con el propio sistema.

Casos de uso

Es una secuencia de acciones que hace el sistema y que producen un resultado que puede percibir un usuario. Se utiliza para representar una de las funcionalidades que realiza el sistema. Se representan con una elipse que incluye en su interior el nombre del caso de uso.

Relaciones

Las relaciones conectan los casos de uso con los actores o los casos de uso entre sí. Cuando conectan un actor con un caso de uso representa que ese actor interactúa de alguna manera con ese caso de uso y se representa con una línea continua y el uso de una etiqueta distintiva con la acción a realizar.

Tipos de relaciones

<<include>>: Se utiliza para representar que un caso de uso utiliza siempre a otro caso de uso. Es decir, un caso de uso se ejecutará obligatoriamente (lo incluye, lo usa). Se representa con una flecha discontinua que va desde el caso de uso de origen al caso de uso que se incluye.

<<extend>>: Este tipo de relaciones se utilizan cuando un caso de uso tiene un comportamiento opcional, reflejado en otro caso de uso. Es decir, un caso de uso puede ejecutar, normalmente dependiendo de alguna condición o flujo del programa, otro caso de uso. Se representa con una flecha discontinua que va desde el caso de uso opcional al original.

Generalización: Consiste en hacer que un elemento herede el comportamiento de otro. Aunque se puede utilizar entre casos de uso, es más común utilizarlo entre actores, haciendo que uno de los actores tenga acceso a las funcionalidades de otro. Se representa con una flecha con la punta hueca que va desde el elemento que hereda al elemento heredado.

10

3.-¿Qué información se representa con este tipo de diagrama?

Representar las interacciones entre actores (usuarios o sistemas externos) y un sistema de software. Estos diagramas se centran en lo que un sistema hace desde la perspectiva del usuario, en lugar de cómo lo hace.

11

4.- Reglas de construcción

• El caso de uso debe describir qué debe hacer el sistema a desarrollar en su interacción con los actores y no cómo debe hacerlo. Es decir, debe describir sólo comportamiento observable externamente, sin entrar en la funcionalidad interna del sistema.
• El nombre del caso de uso debe ilustrar el objetivo que pretende alcanzar el actor al realizarlo.

12

• La invocación de unos casos de uso desde otros casos de uso (lo que se conoce como inclusión, o extensión si es condicional, en UML), sólo debe usarse como un mecanismo para evitar repetir una determinada secuencia de pasos que se repite en varios casos de uso. Nunca debe usarse para expresar posibles menús de la interfaz de usuario.

13

• Se debe ser cuidadoso al usar estructuras condicionales en la descripción del caso de uso, ya que los clientes y usuarios no suelen estar familiarizados con este tipo de estructuras, especialmente si son complejas.
• En los diagramas de casos de uso, debe evitarse que se crucen las líneas que unen los actores a los casos de uso.

14

• Los casos de uso no son algo aislado, deben considerarse en su contexto.
• La elaboración de casos de uso no es una actividad analítica, sino sintética.
• No se trata de analizar y desmenuzar algo que ya existe, sino de crear (junto con los clientes) una concepción común del sistema software a desarrollar.
• Buscar una comunicación real entre actores y sistema.
• No complicar las cosas.

15

• Hay que revisar los casos de uso cuidadosamente, junto con el usuario.

• Los casos de uso deben describir la interacción entre el actor y el software sin ambigüedad.

• Permiten expresar tanto requisitos funcionales como no funcionales.

• Expresan el funcionamiento del sistema como un TODO (no de sus partes).

16

5.- Errores comunes

• Errores en la identificación de actores

Los errores introducidos en esta etapa se deben a no entender quiénes son los actores del sistema. En algunos casos se incluyen actores que realmente no lo son.

17

• Errores de identificacion de casos de uso

Un error común en la identificación de casos de uso es confundir las opciones del menú o funciones del sistema con los propios casos de uso. Esto va en contra de la idea de que los casos de uso deben representar lo que el usuario necesita del sistema, no las acciones específicas que puede realizar a través del menú

18

• Errores en la especificación de casos de uso

La técnica de casos de uso es para especificar requisitos, no para el diseño del sistema. Errores comunes incluyen detalles de diseño como componentes de ventanas, algoritmos o bases de datos. Es crucial evitar vaguedades como "etc" o "así sucesivamente" para una estimación precisa del esfuerzo necesario y evitar retrasos por cambios tardíos en requisitos.

19

• Errores en el uso de relaciones entre casos de uso

Los errores al incluir relaciones entre casos de uso se deben a confundirlos con procesos de diagramas de flujo de datos de Yourdon. Se aconseja limitar a dos niveles las relaciones "include" o "extend" en un diagrama de casos de uso para evitar esta confusión.

20

Otro error frecuente es crear un caso de uso que es incluido por un solo caso de uso; por ejemplo, muestra el caso de uso "Buscar Cliente" , el cual es incluido solo por el caso de uso ” Actualizar clientes„ . Se debe tener en cuenta que los casos de uso incluidos deben obtenerse luego de haber realizado las especificaciones de los casos de uso, ya que en ese momento es que se determinaran cuales son los pasos que se repiten entre los diferentes casos de uso y es allí donde se determinan las relaciones de tipo "include".

21

Se puede encontrar bibliografıa en la que se emplea la relacion "use" entre casos de uso. Se debe tener en cuenta que dicha relacion corresponde a versiones anteriores a UML version 1.3, por lo que su utilizacion debe evitarse

22

6.- Ejemplo

Ejemplo de clinica veterinaria. Se requiere el diseño de una aplicación que gestione los tramites a realizar en una clínica veterinaria en base a las siguientes premisas:

• La clínica veterinaria almacena datos de contacto de todos sus clientes como pueden ser: Nombre, Apellidos, DNI, Fecha de nacimiento, Teléfono o Email. Estos datos son introducidos y gestionados por los auxiliares, que ejercen las funciones administrativas.

23

• Además se almacena información de cada uno de las mascotas de las que es dueño cada cliente. Obviamente, cada cliente puede tener más de una mascota, pero cada mascota solo puede pertenecer a un único cliente. Se permite, además, cambiar el dueño de una mascota por otro.
• Al dar de alta un nuevo animal, se comprobará en el registro del REIAC (Red Española de Identificación de Animales de Compañía) si el animal está correctamente dado de alta. Este proceso unicamente se hará en animales que tengan la obligación de estar identificados.

24

• Cada vez que un veterinario realiza una consulta sobre un animal, esta queda almacenada incluyendo datos básicos como: Tiempo de consulta, Identificación de la persona que lo ha tratado, Animal tratado, Importe total, Resolución, Recetas… Para calcular el tiempo de la consulta el veterinario tendrá un botón en la aplicación donde pueda pulsar cuando comienza la consulta para calcular el tiempo a modo de cronómetro y otro botón para finalizar.

25

• En caso de que el animal se quede ingresado en la clínica, el cliente debe ser capaz de acceder al estado en tiempo real del animal. Además podrá comunicarse con una cámara que tendrá el animal colocada, donde podrá ver su situación actual. La gestión de estas cámaras no corresponde al sistema, sino que se utilizará una aplicación ya presente en el veterinario.

26

• Las recetas y otros documentos relacionados con el servicio se incluirán en un gestor de contenidos que ya está en funcionamiento en la clínica veterinaria.
• Una vez terminado el servicio, el cliente no tiene por qué realizar inmediatamente el pago, sino que puede identificarse posteriormente en la aplicación vía web y realizar el pago. Si el cliente tarda más de una semana se efectuará un recargo sobre el precio inicial.
• Además, el cliente debe ser capaz de obtener un histórico de todas las consultas que ha recibido cualquiera de sus mascotas.

27

Diagrama de casos de uso del actor "Auxiliar"

28

Diagrama de casos de uso del actor "Cliente"

29

Diagrama de casos de uso del actor "Veterinario"

• No obstante, dependiendo del nivel de profundidad, el diagrama puede variar significativamente descomponiendo, añadiendo, omitiendo o fusionando alguno de los casos de uso que se han expuesto.

30

Video de los diagramas de caso de uso

31

Referencias

• Diagrama de casos de uso. Teoría y ejemplos (diagramasuml.com)
• Diagrama de casos de uso. Teoría y ejemplos. (2024, 30 enero). DiagramasUML.com. https://diagramasuml.com/casos-de-uso/
• Pow Sang Portillo, J. A. La Especificación de Requisitos con Casos de Uso: Buenas y Malas Prácticas. Pontificia Universidad Católica del Perú. http://inform.pucp.edu.pe/~jpowsang/papers/japowsang-sisoft03.pdf
• Vega, M. (2010, octubre). Casos de uso UML. https://lsi2.ugr.es/~mvega/docis/casos%20de%20uso.pdf
• Guía para la redacción de casos de uso | Marco de Desarrollo de la Junta de Andalucía. https://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/416#Caracteristicas

32