Análisis de caso de uso: un estudio de caso

¿Qué son los casos de uso?

Un  caso de uso  es una técnica de captura y documentación de requisitos que se puede escribir en texto sin formato para describir de manera narrativa las acciones e interacciones de los participantes que utilizan el sistema. Finalmente, la funcionalidad del sistema debe satisfacer el propósito para el cual las partes interesadas usan el sistema.

Antes de usar texto para documentar una descripción de caso de uso, primero podemos usar un diagrama de caso de uso para resaltar el propósito del actor que usa el sistema. Con la representación gráfica, puede comprender rápidamente la imagen completa a vista de pájaro. Defina el alcance del sistema (límites del sistema) e identifique los objetivos principales de los actores (llamados casos de uso) que respaldan el uso de las funcionalidades o servicios del sistema.

Los diagramas de casos de uso son buenos para la comunicación del equipo, y es una naturaleza humana: usar gráficos a menudo es mejor que comunicarse a través de palabras.

Una vez que el equipo tiene una comprensión inicial y un consenso sobre la apariencia general del sistema, el analista de requisitos abre el óvalo: caso de uso y describe el proceso de diálogo entre los actores y el sistema en un formato correcto y fácil de leer.

Aumente gradualmente la precisión de los casos de uso de simples a complejos. No se atasque en detalles complicados al principio, no sea que invierta demasiado espíritu en el diseño y la descripción incorrectos. Los diagramas de casos de uso ayudan a pasar de lo simple a lo complejo y reducen las falacias innecesarias.

Como se puede ver en la figura, el alcance del diseño de este sistema es «sistema de pedido de libros en línea», uno de los principales participantes que usan este sistema es «cliente en línea», el propósito de los participantes que usan este sistema es «libros de pedidos».

Los «libros de pedidos» son el caso de uso del sistema, y ​​el actor es el «cliente en línea». Después de determinar el propósito de los participantes, registraremos los detalles del propósito en la narrativa del texto, es decir, registraremos la interacción entre los participantes y la operación del sistema para lograr el propósito. Esto se llama descripción de caso de uso.

La siguiente tabla describe un caso de uso simple de «Libros de pedidos».

Origen del caso de uso

El caso de uso fue publicado por primera vez por el gigante del software Jacobson en 1992, lo que tuvo un impacto considerable en la tecnología moderna orientada a objetos. Además, las especificaciones UML ( Lenguaje Unificado de Modelado ) formuladas conjuntamente por los llamados “los 3 Amigos” — Booch, Jacobson y Rumbaugh y que han sido revisadas por OMG se han incluido como una parte importante de las principales especificaciones estándar.

Aquí están las definiciones de casos de uso de varios gigantes del software.

• “Un caso de uso es un documento narrativo que describe la secuencia del proceso de un actor que usa el sistema para completar un evento” [Jacobson92].
• “Un caso de uso es un conjunto de escenarios (flujo de eventos), que están relacionados con el propósito de uso común del sistema” [Fowler97].
• “Un caso de uso es una secuencia de acciones que un actor (generalmente una persona, pero quizás una entidad externa, como otro sistema) realiza dentro de un sistema para lograr un objetivo particular” [Rosenberg99].
• “Un caso de uso es un actor (generalmente un usuario, pero quizás una entidad externa, como otro sistema externo), una serie de acciones para lograr un objetivo específico en la interacción con el sistema interno”.

En el libro “The Unified Modeling Language User Guide”, se da la definición de Caso de Uso:

• “Un caso de uso describe un conjunto de secuencias, en las que cada secuencia representa la interacción de las cosas fuera del sistema (sus actores) con el sistema mismo (y sus abstracciones clave)”.
• “El caso de uso describe una serie de secuencias, cada una de las cuales expresa la interacción entre cosas fuera del sistema (participantes) y el sistema mismo (y sus abstracciones clave)”.

De la discusión anterior, podemos obtener las características relacionadas con el caso de uso:

• Un caso de uso es un documento narrativo descrito en lenguaje natural (como narración en inglés). En términos generales, un caso de uso no involucra gráficos o gramática de lenguaje de programación (como Java) para describir.
• El escenario descrito en el caso de uso es exactamente lo que los actores esperan lograr (obtener) su objetivo (Objetivo) a partir de la interacción y comunicación con el sistema.
• Por ejemplo, «Comprar artículos» es exactamente el propósito del consumo del consumidor:
  «Los consumidores revisan los bienes comprados y el cajero registra los bienes comprados y cobra el pago. Una vez completado, el consumidor se va con los bienes”.
• Un caso de uso puede tener un escenario normal y con múltiples escenarios de excepción. El escenario normal describe el proceso normal de interacción entre los participantes y el sistema; mientras que en el proceso de interacción con el sistema, si se tiene en cuenta la ocurrencia de excepciones, dependiendo de la complejidad de la situación, se puede describir en el “camino alternativo” en el escenario normal” o se puede describir en otro escenario para excepciones complejas.
• El sistema proporcionará una serie de funciones para interactuar con los participantes, pero los participantes no necesitan saber qué está pasando en el sistema o cómo hacerlo, el sistema solo necesita enviar los resultados a los participantes. Por lo tanto, para los participantes, el sistema es (o un grupo de casos de uso) una caja negra.
• La descripción del caso de uso enfatiza lo que el sistema debe hacer (qué hacer), no cómo hacerlo (cómo hacerlo). Por lo tanto, los detalles de la implementación no deben describirse en la descripción del caso de uso.
• El actor llega directamente al sistema operativo. En el diagrama de casos de uso, aunque el actor se representa como un ícono de “figura de palitos”, el participante puede no ser necesariamente una persona real. El participante también puede ser un sistema externo y puede necesitar obtener alguna información de este sistema.

Otros diagramas UML

• ¿Qué es el diagrama de clases?
• ¿Qué es el diagrama de componentes?
• ¿Qué es el Diagrama de Despliegue?
• ¿Qué es el diagrama de objetos?
• ¿Qué es el diagrama de paquete?
• ¿Qué es el diagrama de estructura compuesta?
• ¿Qué es el diagrama de perfil?
• ¿Qué es el diagrama de casos de uso?
• ¿Qué es el diagrama de actividades?
• ¿Qué es el diagrama de máquina de estado?
• ¿Qué es el diagrama de secuencia?
• ¿Qué es el diagrama de comunicación?
• ¿Qué es el diagrama general de interacción?
• ¿Qué es el diagrama de tiempo?
• ¿Qué es el diagrama de colaboración UML?