10 consejos para crear un diagrama de casos de uso profesional

¿Qué es la modelización de casos de uso?

La modelización de casos de uso es una respuesta sencilla a la pregunta: ¿Qué quiere el usuario (cliente)? Permite representar visualmente lo que el usuario desea lograr al utilizar el producto final, que puede ser un sistema, un programa de software, un programa, etc. La modelización de casos de uso es una técnica útil que proporciona a los desarrolladores de software una base sólida para desarrollar sistemas que satisfagan las necesidades del cliente.

Aunque la notación aplicada en los diagramas de casos de uso puede parecer sencilla y no transmitir muchos detalles, la forma en que se recopilan, organizan y desarrollan los casos de uso influye enormemente en la dirección del ciclo de vida del desarrollo de software, y por tanto en la calidad del producto de software final.

10 consejos prácticos para la modelización de casos de uso

En este artículo, repasaremos diez consejos para maximizar la efectividad de la elaboración de diagramas de casos de uso. No explicaremos en detalle qué es un caso de uso, sino que cubriremos algunos conceptos clave sobre modelización UML, diagramas de casos de uso y captura de requisitos.

1. Piensa desde la perspectiva del usuario final

Es claro que necesitas conocer las expectativas de los usuarios para construir un sistema de software que funcione, y este principio es particularmente importante en la modelización de casos de uso. Muchas personas malinterpretan la modelización de casos de uso como un proceso para modelar funciones del sistema, lo cual puede ser incorrecto. Para ser precisos, la modelización de casos de uso es una forma de modelar lo que los usuarios desean. Cada caso de uso en un diagrama de casos de uso debe generar un objetivo observable a través de la interacción del usuario con el software o sistema final. A veces, un objetivo del usuario es el mismo que una función del sistema, pero esto no siempre es cierto. Por ejemplo, ‘Iniciar sesión’ es una función del sistema, pero definitivamente no es un objetivo del usuario: nadie inicia un programa, inicia sesión y se va! Por lo tanto, cuanto más funciones del sistema dibujes en un diagrama de casos de uso, menos efectivo será el modelo de casos de uso para expresar las verdaderas expectativas del usuario durante todo el proceso de desarrollo de software. Por eso, al desarrollar un modelo de casos de uso, intenta expresar todo pensando primero desde la perspectiva del usuario final.

2. Evita nombres largos para los casos de uso

Si estás leyendo un diagrama de casos de uso preparado para un sistema de cajero automático, ¿cuál de los siguientes casos de uso te gustaría ver en el diagrama? ‘Retirar efectivo’ y ‘Retirar efectivo y actualizar el saldo en la cuenta’. El segundo caso de uso parece más descriptivo, ¿verdad? ¿Qué pasa si tienes 50+ casos de uso diferentes con un nombre tan largo? Probablemente ya no quieras leer el diagrama y quizás tus ojos se cansen.

Una de las razones por las que necesitamos modelado es que queremos comprender un sistema de software complejo de manera sencilla y fácil. Por eso, el UML nos ha proporcionado muchas clases diferentes de notaciones, cada una de las cuales representa una perspectiva específica para describir un sistema de software completo. Este ‘espíritu’ también se aplica a la nomenclatura de casos de uso. Si intentamos nombrar casos de uso con descripciones detalladas, ¿por qué no usamos simplemente un archivo de texto? Para que un diagrama de casos de uso sea fácil de entender, es importante mantener los nombres de los casos de uso cortos, pero al mismo tiempo descriptivos. Mantén los nombres cortos y deja la descripción detallada para la parte de descripción de los casos de uso.

3. El actor es un rol, no una persona real

Algunas personas tratan de representar a los empleados en una organización como actores en un diagrama de casos de uso, lo que termina generando un diagrama con Peter, Mary, Daisy, etc. Recuerde que un actor representa un rol único que comprende personas, sub-sistemas o cualquier otra entidad con características únicas y que comparte los mismos objetivos y expectativas.

4. Modelar un caso de uso común con relación

Un caso de uso representa un objetivo del usuario, que puede lograrse mediante una serie de pasos. Cuando se encuentran exactamente los mismos pasos entre casos de uso, se puede crear opcionalmente un nuevo caso de uso para los pasos comunes y conectarlo con los casos de uso que desencadenan dichos pasos. Al utilizar un caso de uso incluido, queda claro que los casos de uso que lo incluyen comparten efectivamente el mismo conjunto de pasos representados por el caso de uso incluido, sin ninguna ambigüedad.

5. Modelar el comportamiento excepcional

La relación Extend puede utilizarse para especificar cuándo y cómo el comportamiento de un caso de uso puede ser desencadenado por otro caso de uso. La extensión tiene lugar en puntos de extensión definidos en el caso de uso extendido. El caso de uso extendido define los pasos que pueden ser ejecutados por el caso de uso extendido bajo condiciones específicas.

6. Modelar un escenario con flujo de eventos

Un caso de uso representa un objetivo del usuario, que puede lograrse mediante una secuencia de pasos. Algunas personas tratan de modelar los pasos directamente en el diagrama de casos de uso, conectando al actor y el caso de uso con muchas asociaciones, fingiendo que son los pasos, lo cual es definitivamente incorrecto. En cambio, los pasos del caso de uso pueden describirse adecuadamente en el editor de flujo de eventos del caso de usoeditor de flujo de eventos.

El editor de flujo de eventos está en formato de tabla, donde cada fila representa un paso del caso de uso. Puede escribir los pasos allí, con o sin flujo condicional. También puede aplicar formato al texto para resaltar ideas clave.

7. Utilice adecuadamente los estereotipos para la categorización

El estereotipo es un mecanismo que le permite introducir notación específica del dominio además de las estándar. Un estereotipo se muestra entre un par de guillemetes, encima del nombre de la forma cuando se aplica el estereotipo. El uso adecuado del estereotipo ayuda a los lectores a comprender más fácilmente las diferencias entre los casos de uso.

8. Modelar el flujo detallado del sistema con diagrama de secuencia

Diagrama de secuenciale permite modelar el comportamiento del sistema representando la comunicación e intercambio de mensajes entre objetos a lo largo del tiempo. Pero, ¿por dónde empezar? En lugar de adivinar qué interacción modelar, puede comenzar refiriéndose a lo que necesita el usuario, que es exactamente lo que un modelo de casos de uso busca presentar.

Sabemos que cada caso de uso representa un objetivo único del usuario. Dibujar un diagrama de secuencia a partir de un caso de uso implica que va a modelar lo que el sistema informático debería hacer para cumplir con el usuario. Idealmente, no habrá ningún diseño redundante, ya que todos los diagramas de secuencia se crean a partir de casos de uso, que representan lo que el usuario desea.

9. Aplicar el mismo ancho a los casos de uso cuando sea apropiado

Dado que los nombres de los casos de uso tienen longitudes diferentes, es normal que los casos de uso tengan anchos distintos. Para que el diagrama sea más atractivo y más fácil de leer, sería conveniente ajustarlos al mismo ancho.

10. Colocar actores y casos de uso de manera significativa

Un diagrama de casos de uso con actores y casos de uso colocados al azar es definitivamente una pesadilla para los lectores. Uno debe examinar cuidadosamente el diagrama para encontrar la información que desea entre los actores y casos de uso dispersos. Sería conveniente colocar las formas de manera ordenada. También puede agrupar casos de uso con formas de paquete si es necesario.