El diagrama de casos de uso es una vista que se utiliza para describir las funciones del sistema compuestas por actores, casos de uso y la relación entre ellos. Es observable por usuarios externos llamados diagramas de modelo de funcionalidad del sistema. Los diagramas de casos de uso se utilizan a menudo durante la fase de análisis de requisitos.
Antes de desarrollar un sistema, la tarea más importante es obtener las necesidades del usuario, y las más importantes entre las necesidades del usuario son los requisitos funcionales del sistema propuestos por los usuarios. Podemos utilizar diagramas de casos de uso para expresar visualmente las necesidades del usuario.
Diagrama de casos de uso visual
Los elementos principales de un diagrama de casos de uso incluyen actores, casos de uso y las relaciones entre elementos. Además de esto, los diagramas de casos de uso también pueden contener anotaciones y restricciones.
1. Concepto de participantes
Los actores son entidades externas que interactúan con el sistema principal. Los participantes pueden ser personas, subsistemas, otros sistemas, etc. fuera del sistema.
Cada actor es en realidad un conjunto de roles. En UML, un actor se representa gráficamente utilizando una forma humana y se le asigna un nombre. Como se muestra en la imagen siguiente, el "lector" participa en el sistema de préstamo de la biblioteca.
actores del diagrama de casos de uso
Los actores deben estar fuera de los límites del sistema, no ser parte del sistema.
2. Cómo identificar a los participantes
Al modelar casos de uso, identificar a los actores es el primer paso en el modelado de diagramas de casos de uso. Entonces, ¿cómo determinar los participantes del sistema ? Podemos pensarlo a partir de las siguientes ideas:
(1) Los objetos de servicio del sistema, como los lectores en el sistema de préstamo de la biblioteca;
(2) Personas que brindan apoyo para completar el trabajo, como el personal de la biblioteca en el sistema de préstamo de la biblioteca, que necesita usar el sistema para ayudar a los lectores a completar el préstamo, la devolución de libros y los recordatorios;
(3) Mantenedor del sistema: la persona responsable de instalar, mantener y administrar el sistema. En este caso, el sistema debe proporcionar funciones relevantes para ayudar a dicho personal a completar el trabajo de instalación, mantenimiento y administración;
(4) Dispositivos externos: necesidad de transmitir información o leer información desde dispositivos externos, como lectores de tarjetas;
(5) Otros sistemas o subsistemas: como el sistema financiero en el sistema de préstamos. El sistema financiero no es una función del sistema de préstamos, pero el sistema de préstamos necesita transmitirle información para completar el trabajo fino atrasado;
(6) Hora: en un momento programado, se produce automáticamente un evento específico, como una copia de seguridad automática, un recordatorio regular, etc.;
(7) Eventos específicos: por ejemplo, la recepción automática de pedidos en el sistema de comida para llevar está impulsada por eventos de generación de pedidos.
Al identificar a los participantes , tenga en cuenta lo siguiente:
(1) Los participantes están ubicados fuera del sistema, no forman parte del sistema;
(2) Los participantes interactúan con el sistema a través de los límites del sistema;
(3) Aunque los íconos de los participantes están representados por íconos con forma humana, los participantes no son necesariamente personas, y también pueden ser otros subsistemas, otros sistemas, tiempo, temperatura y otros factores.
3. Relaciones entre los participantes
La principal relación entre los participantes es la generalización. La generalización está representada por una flecha triangular abierta y sólida que apunta a participantes más generales y termina en el extremo del participante "específico". Una relación de generalización es una relación entre lo general y lo particular (concreto). En una relación de generalización, uno o más participantes concretos pueden compartir una descripción abstracta de un participante. La siguiente figura muestra las relaciones generalizadas entre los participantes en un sistema de préstamo bibliotecario:
Relación de generalización entre participantes en el sistema de préstamo bibliotecario.
jubilados , etc. debajo del lector son participantes "específicos". La generalización de participantes puede entenderse como: un participante "específico" es un participante "general", como un miembro de la facultad que es una especie de lector. En la generalización de actores, los casos de uso que son ejecutables por un actor "general" se representan como ejecutables por un actor "concreto" ("especial").
1. El concepto de casos de uso.
Un caso de uso es un servicio del sistema o una unidad funcional que los participantes pueden experimentar. Define un objetivo que el sistema debe alcanzar. Un caso de uso sólo define un comportamiento del sistema pero no revela la estructura interna del sistema.
La mayor ventaja de los casos de uso es que describen funciones del sistema desde la perspectiva del usuario. Gráficamente, un caso de uso está representado por una elipse sólida con el nombre del caso de uso dentro o debajo de la elipse:
Caso de uso de préstamo de libros
2. Identificar casos de uso
Los casos de uso se pueden identificar a través de los siguientes puntos:
(1) ¿Qué funciones necesita el participante del sistema para respaldar su trabajo?
(2) ¿Los participantes necesitan consultar alguna información en el sistema?
(3) ¿Los participantes necesitan cambiar alguna información en el sistema, como crear, modificar y eliminar operaciones?
(4) ¿Es necesario notificar a los participantes sobre eventos específicos o cambios en el estado del sistema?
(5) ¿Qué eventos externos en el sistema impulsarán al sistema a realizar funciones relevantes en respuesta?
(6) ¿El sistema proporciona funciones relevantes para ayudar al personal de mantenimiento a mantener el sistema?
3. Puntos clave de identificación de casos de uso
(1) Los casos de uso identificados deben reflejar los objetivos del sistema, es decir, "qué hacer" en lugar de "cómo hacerlo", lo que significa que los casos de uso no son detalles de la implementación del sistema;
(2) Definir casos de uso desde la perspectiva de los participantes (usuarios) en lugar de desde la perspectiva del sistema;
(3) Los casos de uso deben proporcionar resultados valiosos a los participantes, en lugar de una colección de acciones;
(4) Evite caer en descomposición funcional y descomposición escalonada;
(5) Cada participante debe tener un caso de uso ejecutable y cada caso de uso debe estar asociado con al menos un participante.
4. Nombrar casos de uso
Después de determinar los casos de uso del sistema, es necesario nombrar cada caso de uso. La denominación de los casos de uso debe describir los objetivos alcanzados por los participantes desde la perspectiva del usuario. Se pueden utilizar los siguientes métodos de denominación:
verbo + objeto
Es decir, el nombre del caso de uso debe tener la forma de frase verbo-objeto. Como elegir cursos, pedir prestados libros, pedir productos y pagar con tarjetas de crédito.
5. Granularidad de los casos de uso
La granularidad de los casos de uso se refiere al grado en que un caso de uso refina o integra las funciones del sistema. También se puede decir que es la cantidad de servicios del sistema o unidades funcionales incluidas en un caso de uso. Si la granularidad del caso de uso es demasiado gruesa o demasiado grande, el caso de uso contendrá más funciones del sistema y viceversa. Si la granularidad de los casos de uso es demasiado basta, será difícil comprender el sistema. Si la granularidad es demasiado fina, el modelo de casos de uso será demasiado grande, lo que provocará dificultades en el diseño. Si el caso de uso es demasiado detallado, puede caer en una descomposición funcional, como por ejemplo:
Granularidad del caso de uso inicial
De hecho, muchas empresas en el sistema incluyen operaciones de agregar, eliminar, modificar y verificar. Hacerlo no puede proporcionar ningún objetivo significativo para los usuarios, pero ignorará el propósito real de los usuarios.
Lo anterior "agregar, eliminar, modificar y verificar" no es más que la gestión de usuarios, que es el verdadero propósito de los participantes. Quizás sea mejor manejar el caso de uso anterior de la siguiente manera:
Reducción de granularidad de casos de uso
El caso de uso Administrar usuarios representa un objetivo o tarea para los administradores del sistema. Si hay que agregar altas, eliminaciones, modificaciones y consultas, sería mejor expresarlo de la siguiente manera.
Después de la optimización de la granularidad del caso de uso
Otro error que se comete a menudo en el modelado de casos de uso es tratar los pasos como casos de uso. Por ejemplo, el siguiente parece perfecto, pero es obvio que los pasos de la operación se consideran casos de uso:
Pasos de operación como ejemplos de errores de casos de uso
Los pasos anteriores no son más que completar el objetivo del usuario como participante: el registro. Por lo tanto, se debe cambiar a lo siguiente:
Después de la optimización del caso de uso
En el modelado de casos de uso, el tercer error común es tratar las actividades del sistema como casos de uso. En el siguiente diagrama de casos de uso, establecer objetos de conexión, crear objetos de comando y ejecutar declaraciones SQL son actividades dentro del sistema que el usuario no puede percibir. No son el propósito del usuario y al usuario no le importa. Entonces este diagrama de casos de uso es inexacto:
Ejemplo de error de caso de uso de actividad del sistema
El cuarto error común en el modelado de casos de uso es nombrar los casos de uso utilizando una perspectiva del sistema.
Utilice la perspectiva del sistema para nombrar ejemplos de errores de casos de uso
De los dos diagramas de casos de uso anteriores, ¿cuál es mejor? Obviamente, el de la derecha es mejor que el de la izquierda, porque el caso de uso de la derecha se nombra desde la perspectiva del usuario, mientras que el caso de uso de la izquierda se nombra desde la perspectiva del sistema, y los usuarios se sentirán confundidos después. viéndolo.
6. Especificación de casos de uso
El diagrama de casos de uso generalmente describe los requisitos funcionales del usuario (funciones o servicios proporcionados por el sistema), pero cada caso de uso debe describirse en detalle para que las personas sepan qué se supone que debe hacer específicamente el caso de uso. En otras palabras, el modelo de casos de uso consiste esencialmente en un diagrama de casos de uso y una descripción detallada de cada caso de uso (especificación de caso de uso).
Una especificación de caso de uso debe contener el siguiente contenido:
(1) La identificación y nombre del caso de uso;
(2) Participantes involucrados en el caso de uso;
(3) Una breve descripción del caso de uso;
(4) Otros casos de uso relacionados;
(5) Condiciones previas para la ejecución del caso de uso
(6) Flujo de eventos básico;
(7) Flujo de eventos alternativo;
(8) Condiciones posteriores para la ejecución de casos de uso;
(9) Otra información, como requisitos no funcionales, restricciones de diseño, estado de revisión de casos de uso, preparador, registros de modificación, etc.
Las relaciones entre casos de uso incluyen principalmente tres tipos: generalización, inclusión y expansión.
Cuando varios casos de uso tienen atributos o comportamientos similares, podemos abstraer sus puntos comunes en un caso de uso principal y otros casos de uso como casos de uso secundarios de una relación de generalización. Los casos de uso secundarios heredan los atributos y comportamientos del caso de uso principal. La relación de generalización de casos de uso puede entenderse como diferentes rutas de implementación para el mismo propósito comercial.
La relación de generalización se representa gráficamente mediante una implementación con una flecha triangular hueca que apunta desde el caso de uso secundario al caso de uso principal.
Relación de generalización del diagrama de casos de uso
En el ejemplo anterior, " Método de pago 1 " y " Método de pago 2 " son casos de uso secundario de "Pago". El caso de uso principal "Pago" no proporciona métodos de pago específicos, solo proporciona los atributos e interfaces necesarios para el pago e implementa funciones de pago específicas en sus casos de uso secundarios.
Durante el proceso de modelado del sistema, algunas funciones deben usarse repetidamente en diferentes escenarios comerciales. Estas funciones utilizadas repetidamente se pueden separar para formar un caso de uso separado y, al ejecutar funciones relacionadas, las funciones públicas separadas se pueden incluir en el proceso principal. La relación de inclusión de casos de uso puede describir esta situación. Además, si un caso de uso básico tiene demasiadas funciones, también se puede dividir en varios casos de uso pequeños. Los casos de uso contenidos se denominan casos de uso del proveedor y los casos de uso que contienen otros casos de uso se denominan casos de uso del cliente.
En UML, la relación de inclusión está representada por una flecha punteada con el estereotipo <<incluir>>. La flecha apunta desde el caso de uso básico (incluido el caso de uso/caso de uso del cliente) al caso de uso incluido (caso de uso del proveedor).
El diagrama de casos de uso contiene relaciones.
El siguiente es un ejemplo específico. En este ejemplo, el lector desea tomar prestado el libro previamente. Necesita ejecutar el caso de uso del libro de consulta antes de poder tomar prestado el libro. Por lo tanto, el caso de uso del libro de consulta se incluirá en el. Caso de uso de préstamo previo de libros Al mismo tiempo, el lector debe haber iniciado sesión en el sistema al tomar prestado libros previamente y el sistema ha guardado su estado de inicio de sesión antes de poder realizar la operación de préstamo previo. El caso de uso de verificación de identidad también se incluirá en el caso de uso del libro previo al préstamo. Consultar libros no es solo una función básica requerida por un lector, sino también un proceso operativo necesario para otras funciones. La verificación de identidad no solo se utiliza al tomar prestados libros previamente, sino también al realizar funciones como consultar registros de préstamos y pagar multas. Es más apropiado proponer la verificación de identidad por separado para formar un caso de uso:
Relación de inclusión del libro de préstamo anticipado del lector
Los casos de uso básicos proporcionan puntos de extensión, en los que se pueden agregar nuevos comportamientos. Los casos de uso de extensión proporcionan un conjunto de fragmentos de inserción que se pueden insertar en los puntos de extensión del caso de uso básico.
· El caso de uso base solo proporciona puntos de extensión sin conocer ningún detalle del caso de uso de extensión.
· Un caso de uso base está completo incluso sin un caso de uso extendido, a diferencia de una relación de inclusión.
· Un caso de uso puede proporcionar múltiples puntos de extensión y cada punto de extensión puede aparecer varias veces.
· En circunstancias normales, la ejecución del caso de uso básico no involucrará el caso de uso extendido. Las funciones del caso de uso extendido solo se ejecutarán cuando ocurran condiciones o eventos específicos.
En UML, una relación de extensión se representa mediante una flecha discontinua con el estereotipo <<extender>>. Las flechas apuntan desde casos de uso extendidos a casos de uso básicos.
Relación de extensión del diagrama de casos de uso
El siguiente ejemplo es un fragmento de diagrama de caso de uso en un sistema de préstamo de biblioteca:
Los lectores pagan multas para ampliar las relaciones
En este ejemplo, pagar una multa es un caso de uso básico para el lector y un caso de uso extendido para devolver el libro. "Pagar multa", como caso de uso extendido de "Devolver libros", sólo se ejecutará bajo las siguientes condiciones:
(1) Los libros del lector están vencidos o tienen buenos registros por otros motivos y no han sido pagados en su totalidad;
(2) El lector elige pagar la multa al mismo tiempo después de devolver el libro.
Lo anterior es el contenido relevante sobre los diagramas de casos de uso de UML. Todos los casos de diagramas de casos de uso anteriores se dibujan utilizando ProcessOn.
Mapas mentales y diagramas de flujo colaborativos en línea gratuitos Uso gratuito 
![[Compartir información útil] Domina 14 tipos de diagramas UML en 10 minutos](https://cdn.processon.io/admin/knowledge/article_thumb_img/66d142e1990fed148692bd89.png)
