Tutorial de análisis de casos de uso

¿Qué es un diagrama de casos de uso?

Los diagramas de casos de uso de UML son la forma principal de requisitos de sistema/software para nuevos programas de software en desarrollo. El propósito de un diagrama de casos de uso es visualizar qué debe hacer el sistema (qué); en esta etapa, no considera cómo (cómo) hacerlo.

Una vez que se especifica un caso de uso, se puede representar en una representación textual y visual (es decir, un diagrama de caso). Un concepto clave del modelado de casos de uso es que nos ayuda a diseñar el sistema desde la perspectiva del usuario final. Es una técnica efectiva para comunicar el comportamiento del sistema en términos de usuario al especificar todos los comportamientos del sistema visibles externamente.

En otras palabras, el uso del sistema debe verse desde afuera, es decir, el sistema no debe verse desde adentro, sino desde un nivel superior para determinar la funcionalidad que el sistema debe brindar a los actores externos.

Propósito de los diagramas de casos de uso

Los diagramas de casos de uso generalmente se desarrollan en las primeras etapas de desarrollo, y las personas a menudo usan el modelado de casos de uso para los siguientes propósitos.

• Especificar el contexto de un sistema
• Capturar los requisitos de un sistema
• Validar la arquitectura de un sistema
• Impulse la implementación y genere casos de prueba
• Desarrollado por analistas, expertos en dominios y usuarios finales objetivo juntos

Una forma estándar de diagrama de casos de uso se define en el lenguaje de modelado unificado, como se muestra en el ejemplo de un diagrama de casos de uso a continuación.

EDITE ESTE EJEMPLO DE DIAGRAMA DE CASO DE USO

Elementos del diagrama de casos de uso

Actores

Cada caso de uso tendrá al menos un actor, que puede entenderse como al menos un participante (rol), que no necesariamente es una persona, pero puede ser otro sistema o dispositivo. Un actor puede interactuar con más de un caso de uso y un caso de uso puede interactuar con más de un actor.

Los actores no son necesariamente personas, es decir, usuarios, pero en realidad pueden no ser personas, es decir, sistemas o tiempo.

La mayoría de las veces, los usuarios son personas que están involucradas en el diagrama de casos de uso, como clientes, empleados, supervisores, etc.

Actores humanos vs no humanos

De vez en cuando, el sistema se ve afectado por varios eventos para realizar ciertas funciones en una situación dada. Por ejemplo, cuando se pasa una auditoría, el sistema envía una carta de manera proactiva para notificar a las personas; Entonces, ¿el envío de la carta se realiza automáticamente por el sistema? Este caso de uso en realidad se desencadena por el tiempo, entonces el actor es Timer; por ejemplo, este caso de uso puede verse como «enviar automáticamente una carta a las 5:00 todos los días», entonces el actor que desencadena este evento (enviar una carta) no es el sistema, sino el actor del temporizador.

Actores primarios vs secundarios

Un actor principal es un actor que utiliza el sistema para lograr un objetivo. Los casos de uso documentan las interacciones entre el sistema y los actores para lograr los objetivos del actor principal. Los actores secundarios son los actores a los que el sistema necesita ayudar para lograr los objetivos del actor principal.

• Los actores pueden ser primarios o secundarios. Los actores primarios inician interacciones con el sistema.
• El sistema suele solicitar ayuda a los actores secundarios y un actor secundario nunca inicia el caso de uso.

Tenga en cuenta que: El símbolo de un actor no diferencia entre un actor principal y un actor secundario; la diferencia debe inferirse de las descripciones de los casos de uso (también llamadas narraciones de casos de uso).

Por ejemplo:

Un funcionario de préstamos bancarios quiere revisar la solicitud de préstamo de un cliente, y parte del proceso implica una verificación de la calificación crediticia en tiempo real.

EDITE ESTE EJEMPLO DE DIAGRAMA DE CASO DE USO

• Nombre del caso de uso. Revisar una solicitud de préstamo
• Actor principal. oficial de préstamo
• Actor Secundario. Sistema de calificación crediticia

¿Cómo identifico a los actores?

Dado que un actor no es necesariamente una persona, sino que puede ser un sistema externo, un dispositivo o un temporizador, encontramos un actor más específico al hacer las siguientes preguntas

• ¿Quién utilizará el sistema una vez que se haya desarrollado?
• ¿De quién o qué otros sistemas necesitará el sistema para obtener datos?
• ¿Para quién o para qué otros sistemas proporcionará datos el sistema?
• ¿Con qué otros sistemas se asociará el sistema?
• ¿Quién mantendrá y administrará el sistema?

Estas preguntas nos ayudan a abstraer a los actores del sistema. Usando los cajeros automáticos como ejemplo, responder a estas preguntas nos permite encontrar más actores, es decir,

• El operador es responsable de mantener y administrar el sistema ATM
• Los cajeros automáticos también necesitan comunicarse con los servidores back-end para obtener información sobre las cuentas de los usuarios.

Caso de uso

Un caso de uso representa una funcionalidad (generalmente un requisito) que se espera que el sistema implemente. Los detalles de un caso de uso, aparte de su nombre único, no se representan visualmente en el diagrama; estos detalles se dan en la narrativa (descripción textual) del caso de uso.

Un caso de uso es una lista de acciones o pasos de eventos que normalmente definen las interacciones entre los roles de los actores y el sistema para lograr un objetivo. Los casos de uso son una técnica útil para identificar, aclarar y organizar los requisitos del sistema. Un caso de uso consiste en un conjunto de secuencias de posibles interacciones entre el sistema y el usuario que definen la funcionalidad a lograr y las soluciones a los errores que se puedan encontrar.

¿Cómo identificar casos de uso?

Una vez que encontramos a los actores, podemos determinar los casos de uso del sistema en función de los actores, principalmente observando qué servicios necesita cada actor del sistema o cómo los actores usan el sistema. La identificación de casos de uso puede comenzar con las siguientes preguntas (para cada participante).

• ¿Por qué los actores usan el sistema?
• ¿El participante crea, modifica, elimina, accede y almacena datos en el sistema? Si es así, ¿cómo realiza el actor estas operaciones?
• ¿El actor notifica al sistema de ciertos eventos externos?
• ¿El sistema notifica al actor sobre ciertos eventos internos?

Juntando lo anterior, el diagrama de casos de uso del sistema ATM se puede representar de la siguiente manera.

El caso de uso se presenta mediante puntos suspensivos, de algo estático o dinámico, o de una tarea o un sistema.

Límite del sistema

Los límites del sistema describen el sistema agrupando casos de uso en límites rectangulares, y los límites del sistema en Visual Paradigm proporcionan el comportamiento de contención de casos de uso.

Los actores son roles (actores humanos o actores no humanos) que interactúan con el sistema en desarrollo. Por lo tanto, los actores deben ubicarse fuera de los límites del sistema e interactuar con los casos de uso que se ubican dentro de los límites del sistema.

Tenga en cuenta que: 

Un actor se define por los límites del sistema. Si el límite del sistema que queremos definir se limita al propio cajero automático, entonces el servidor backend es un sistema externo y se puede abstraer como actor.

Si el límite del sistema que queremos definir se extiende a todo el sistema bancario, donde tanto los cajeros automáticos como los servidores backend son parte de todo el sistema bancario, entonces el servidor backend ya no se abstrae como actor.

Relación

Después de aprender acerca de estos tres símbolos clave, continúe con el conocimiento de las relaciones y el dibujo de diagramas de casos de uso. Se dibuja una relación directa entre un participante y un caso de usuario, y la relación se utiliza como una línea sin flechas, lo que indica una relación bidireccional, denominada línea de enlace.

Un caso de uso se puede dividir en varios casos de uso que están conectados por relaciones <<include>>, <<extend>> o <<generalization>> (que se describen más adelante en esta publicación).

Relación de enlace de comunicación

Esto representa una comunicación bidireccional entre un actor y un caso de uso y, por lo tanto, es una relación binaria.

EDITE ESTE EJEMPLO DE DIAGRAMA DE CASO DE USO

<<Incluir>> Relación

Una relación de inclusión significa que el caso de uso incluirá otros casos de uso. El propósito de Incluir relación es usar Incluir relación para reducir la repetición de describir el mismo caso de uso nuevamente. Si muchos casos comparten la misma función de porción, entonces la función se puede separar y otros casos de uso se pueden incluir en el caso.

Por ejemplo, el bibliotecario necesita leer el código para registrar el libro prestado cuando se retira el libro, y también necesita leer el código para registrar el libro devuelto cuando se devuelve el libro, ya que leer el código es una parte repetitiva de la acción. , se puede convertir en un caso de uso separado y dejar que el libro prestado y el libro devuelto incluyan este caso.

EDITE ESTE EJEMPLO DE DIAGRAMA DE CASO DE USO

Si un caso de uso A incluye otro caso de uso B, entonces la implementación de A requiere la implementación de B para completar su tarea. Sin embargo, B es independiente de sí mismo. Es decir, B no necesita saber nada sobre A. B también se puede incluir en cualquier otro caso de uso.

<<Extender>> Relación

Si un caso de uso B amplía otro caso de uso A, entonces la implementación de A puede incluir condicionalmente la implementación de B para completar su tarea. Es decir, en algunos casos, A puede completar su tarea sin B. Sin embargo, dependiendo de las condiciones descritas, A puede requerir B. En este caso, B depende de B. Sin embargo, dependiendo de las condiciones descritas, A puede requerir B En este caso, B depende de A y no puede existir solo. Por esta razón, B no puede extenderse a más de un caso de uso. La narrativa del caso de uso de A incluirá los pasos de ejecución que requiere de B; este punto se llama el punto de extensión.

EDITE ESTE EJEMPLO DE DIAGRAMA DE CASO DE USO

Veamos otro ejemplo en el que el sistema ordena productos automáticamente cuando no hay inventario para que el gerente no tenga que ejecutar el pedido directamente. Vea el diagrama de caso de uso a continuación:

EDITE ESTE EJEMPLO DE DIAGRAMA DE CASO DE USO

Relación de generalización

La relación generalizada es similar a la relación generalizada del lenguaje orientado a objetos en los diagramas de clases y se puede aplicar a la generalización de roles (actores) y casos de uso.

Por ejemplo, en el sistema de reservas, hay dos tipos de métodos de reserva: «reservar boleto por teléfono» y «reservar boleto por Internet», y el caso de uso base «reservar boleto», por lo que puede usar la generalización para moldear el caso, y agregue <<essential>> al caso de uso principal (reserva) para indicar la relación generalizada.

EDITE ESTE EJEMPLO DE DIAGRAMA DE CASO DE USO

Discutir las relaciones en el diagrama de casos de uso

• En un diagrama de casos de uso general, solo representamos las relaciones entre actores y casos de uso, es decir, las asociaciones de comunicación entre ellos.
• Además, también podemos describir la generalización entre participantes y actores, y las relaciones de inclusión, extensión y generalización entre casos de uso.
• Usamos estas relaciones para adaptar el modelo de caso de uso existente y extraer información común para su reutilización, lo que hace que el modelo de caso de uso sea más fácil de mantener.
• Sin embargo, debemos tener cuidado al elegir estas relaciones en la aplicación. Generalmente, estas relaciones aumentan el número de casos de uso y relaciones, aumentando así la complejidad del modelo de casos de uso.
• Además, el modelo de casos de uso generalmente se ajusta una vez que se completa, por lo que no es necesario apresurarse a abstraer las relaciones entre los casos de uso en la etapa inicial del modelado de casos de uso.

Caso de uso: el flujo de eventos

El diagrama de casos de uso nos brinda una visión general de la funcionalidad del sistema, podemos saber qué participantes interactuarán con el sistema y qué servicios necesita obtener cada actor del sistema.

El caso de uso describe la conversación entre los actores y el sistema, pero los detalles de esta conversación no están representados en el diagrama de casos de uso, por lo que para cada caso de uso podemos describir los detalles de esta conversación en términos de un flujo de eventos.

Escenarios de casos de uso y flujo de eventos: retiro de dinero en cajeros automáticos

Por ejemplo, el caso de «Retiro» en un sistema ATM se puede representar mediante un flujo de eventos de la siguiente manera:

Escenario normal – Retiro de fondos – Flujo básico de eventos:

1. El usuario inserta la tarjeta de crédito
2. Introduce el PIN
3. Ingrese el monto del retiro
4. retira efectivo
5. Salga del sistema y recupere la tarjeta de crédito

Pero esto solo describe el escenario normal del caso de uso de retiro. Como un sistema ATM real, también debemos considerar varios otros escenarios que pueden ocurrir, tales como:

• tarjetas de crédito no válidas,
• contraseñas incorrectas,
• saldo de efectivo insuficiente en la cuenta del usuario, etc.

Todas estas posibles situaciones (tanto normales como anormales) se denominan escenarios del caso de uso y los escenarios también se denominan instancias del caso de uso. Los escenarios también se denominan instancias de casos de uso. Entre los diversos escenarios de un caso de uso, el escenario más común es descrito por el proceso básico, mientras que otros escenarios son descritos por procesos alternativos.

Escenarios alternativos

Para el caso de uso de «Retiro» en un sistema de cajero automático, podemos obtener algunos procesos alternativos de la siguiente manera.

Retiro – procesos de eventos alternativos.

1. Escenario alternativo I: el usuario puede optar por no participar en cualquier paso del proceso básico e ir al paso 5 del proceso básico.
2. Proceso alternativo II: en el paso 1 del proceso básico, el usuario inserta una tarjeta de crédito no válida, el sistema muestra un error y sale de la tarjeta de crédito, y finaliza el caso de uso.
3. Proceso alternativo III: En el paso 2 del proceso básico, el usuario ingresa una contraseña incorrecta, el sistema muestra un error y solicita al usuario que vuelva a ingresar la contraseña y regrese al paso 2 del proceso básico; después de tres entradas de contraseña incorrectas, el sistema confisca la tarjeta de crédito y finaliza el caso de uso.
4. …

Al combinar el escenario básico y los escenarios alternativos, se pueden describir claramente todas las diversas situaciones que pueden ocurrir en un caso de uso. Al describir el flujo de eventos de un caso de uso, queremos describir todos los escenarios posibles tanto como sea posible para garantizar la integridad de los requisitos.

Modelo de Caso de Uso vs Diagramas de Caso de Uso

Es importante evitar la idea errónea de que un diagrama de casos de uso que consta de actores y casos de uso es un modelo de casos de uso, porque un diagrama de casos de uso es solo una representación visual de los servicios que puede proporcionar el sistema, lo que nos da una idea general de los funcionalidad del sistema.

El modelo de casos de uso consta de un diagrama de casos de uso y una descripción detallada de cada caso de uso, la especificación de casos de uso, que se proporciona como plantilla en el RUP.

Breve descripción
Una breve descripción de la función y el propósito del caso de uso.

Flujo de eventos 
El flujo de eventos debe representar todos los escenarios, incluidos los escenarios básicos y alternativos.

Escenarios de casos de uso
Incluyen escenarios de éxito y escenarios de falla, y los escenarios son principalmente una combinación de flujos básicos y alternativos.

Requisitos especiales
Describa los requisitos no funcionales (incluidos el rendimiento, la confiabilidad, la disponibilidad, la escalabilidad, etc.) y las restricciones de diseño (sistema operativo, herramientas de desarrollo, etc.) asociadas con el caso de uso.

Condición previa
El estado en el que debe estar el sistema antes de que se pueda ejecutar el caso de uso.

Condiciones posteriores
El conjunto de estados en los que puede encontrarse el sistema después de que se ejecuta el caso de uso.

Una especificación de caso de uso es esencialmente una representación textual, con la opción de usar diagramas de estado, diagramas de actividad o diagramas de secuencia para ayudar a describir el flujo de eventos con mayor claridad. Cualquier representación gráfica de interfaces de usuario y procesos, u otros gráficos, es decir, estructuras alámbricas, se pueden adjuntar al caso de uso siempre que ayuden a mejorar la claridad de la representación.

Por ejemplo:

• Los diagramas de actividad son útiles para describir procesos de decisión complejos,
• Los diagramas de transición de estado son útiles para describir el comportamiento del sistema relacionado con el estado, y
• los diagramas de secuencia son apropiados para describir mensajes basados ​​en el tiempo.

Herramientas de caso de uso

Versión en línea

La versión gratuita de la herramienta de dibujo Visual Paradigm Online (VP Online) es compatible con UML, ERD y organigramas. Puede dibujar rápidamente diagramas de casos de uso con el intuitivo editor de dibujos UML. Esta herramienta UML gratuita no tiene anuncios, no tiene un período de acceso limitado y no tiene restricciones como la cantidad de diagramas, la cantidad de formas, etc. Dibuje UML libremente. Dibuja UML libremente. eres el propietario de los diagramas que creas para fines personales y no comerciales.

Version de escritorio

Visual Paradigm Community Edition , disponible desde 2004, proporciona un software UML gratuito solo con fines no comerciales, que respalda a los usuarios que están dando sus primeros pasos en el modelado UML, así como a aquellos que necesitan un software de modelado UML gratuito y multiplataforma para uso personal, como aplicar UML en proyectos de estudiantes.

Referencias

• ¿Qué es el diagrama de casos de uso?
• Tipos de actor en el modelo de caso de uso
• Identificar los requisitos del usuario con diagramas de casos de uso
• ¿Qué es la especificación de casos de uso?
• Historia de usuario frente a caso de uso para el desarrollo de software ágil
• Enfoque basado en casos de uso para el desarrollo ágil

Recursos UML

• ¿Qué es UML?
• ¿Por qué modelado UML?
• Descripción general de los 14 tipos de diagramas UML