Guía de diagramas de casos de uso de UML: conceptos, composición y ejemplos

Ⅰ. ¿Qué es el diagrama de casos de uso UML?

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.

Ⅱ. El papel del diagrama de casos de uso UML

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

Ⅲ. La composición del diagrama de casos de uso UML

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.

participantes

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").

caso de uso

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.