Una guía rápida para el modelado de casos de uso

El modelado de casos de uso es una herramienta útil para capturar requisitos. Proporciona una representación gráfica de los requisitos de un sistema de software.

Con la publicación del libro de Ivar Jacobson (1991) Ingeniería de software orientada a objetos, un enfoque basado en casos de uso, el modelado de casos de uso se convirtió efectivamente en una técnica de análisis práctica. Hoy en día, Jacobson continúa promoviendo este enfoque para el análisis de sistemas y lo ha actualizado a Use Case 2.0, que es oficialmente uno de los 14 tipos de diagramas UML .

Debido a que el modelo de caso de uso es simple en concepto y apariencia, es relativamente fácil discutir su corrección con personal no técnico (como los clientes).

Un caso de uso no es un procedimiento, proceso o función.

Los Elementos del Diagrama de Casos de Uso

Los elementos de un diagrama de casos de uso son los actores (entidades externas) y el caso de uso mismo. En términos generales, un caso de uso es una unidad funcional (requisito) o servicio en un sistema.

Actor

Un actor es cualquier entidad externa al sistema de diseño, ya sea una persona u otra entidad no humana. Un usuario de un sistema es un ejemplo típico de un actor. Otros tipos de actores incluyen sistemas de software que se están integrando con el sistema actual (por ejemplo, un sistema de base de datos), hardware externo como un sensor, etc.

Hay dos notaciones en la especificación UML :

Usar stickman para actores es más expresivo, pero puede generar confusión si el actor no es realmente una persona, sino una máquina o un dispositivo externo. El símbolo del rectángulo es la notación UML estándar para una clase .

Un actor es un papel en lugar de una persona real 

Un actor representa el rol de la entidad que interactúa con el sistema actual, no una instancia. La notación de actor indica que la entidad es una clase en lugar de una instancia de lectura (es decir, un usuario real John o Mary). La razón por la que un actor es un tipo de clase es que no es el actor mismo, sino el papel que interpreta.

Por ejemplo, un actor puede representar a los clientes de un banco, en lugar de especificar un actor independiente para cada cliente. Asimismo, puede haber otro actor en representación del gerente del banco. Curiosamente, en el mundo real, el gerente de un banco también puede ser cliente del mismo banco. En otras palabras, la misma persona desempeña el papel de cliente y gerente.

Actores primarios vs secundarios

El actor principal de un caso de uso es la parte interesada que requiere que el sistema proporcione sus servicios. Tiene una meta asociada con el sistema, una meta que puede ser satisfecha por la operación del sistema. El actor principal suele ser, aunque no siempre, el actor que desencadena el caso de uso.

El actor secundario es utilizado por el sistema, pero no interactúa con el sistema por sí solo. En otras palabras, los actores secundarios no inician ningún caso de uso.

Los casos de uso generalmente son iniciados por los actores principales. El sistema utiliza un actor secundario como una base de datos a través de un conjunto de casos de uso. La asociación entre casos de uso y participantes representa una comunicación bidireccional.

Por lo tanto, para cada caso de uso iniciado por un actor principal, se debe responder al caso de uso conectado. De manera similar, para cada asociación entre un actor secundario y un caso de uso, la comunicación comienza con el caso de uso y el actor secundario debe responder al inicio.

Caso de uso

Los casos de uso representan las funciones (generalmente requisitos) que se espera que implemente el sistema. Los detalles del caso de uso, excepto su nombre único, no se expresan intuitivamente en el diagrama; Estos detalles se dan en la descripción del caso de uso.

Los casos de uso generalmente son iniciados por actores clave. El sistema utiliza la base de datos y otros participantes auxiliares a través de un conjunto de casos de uso.

La asociación entre casos de uso y actores representa una comunicación bidireccional. Por lo tanto, para cada caso de uso iniciado por el actor principal, se debe dar respuesta a este último. De manera similar, para cada asociación entre el actor secundario y el caso de uso, la comunicación comienza con el caso de uso y el actor secundario debe responder al inicio.

Límite del sistema

El límite del sistema define el sistema de interés en relación con el mundo que lo rodea.

Ejemplo de diagrama de caso de uso: sistema de reservas de aerolíneas

Los casos de uso definen las interacciones entre los actores externos y el sistema para lograr objetivos particulares. Un diagrama de caso de uso contiene cuatro componentes principales

En el diagrama de casos de uso de un sistema de reserva de boletos, el sistema está representado por cajas que contienen muchos casos de uso diferentes. El actor principal es el cliente y el actor secundario es el administrador. El cliente inicia los casos de uso, como reservar, navegar y cancelar vuelos, mientras que el administrador inicia los casos de uso, como actualizar los registros de vuelo, pero se considera un actor secundario en el caso de uso de cancelación de vuelo, ya que solo ayuda a completar los casos de uso iniciados por el cliente.

EDITE ESTE EJEMPLO DE DIAGRAMA DE CASOS DE USO DE UML

Estructuración de casos de uso

De acuerdo con el campo de aplicación y la elección del diseñador, un caso de uso se puede dividir en múltiples casos de uso, que están conectados a través de relaciones < <incluir>> o <<extender>>.

El vínculo de asociación representa una comunicación bidireccional entre un actor y un caso de uso y, por lo tanto, es una relación binaria. Dado que es una comunicación bidireccional, para cada caso de uso iniciado por un actor principal, ese actor debe obtener una respuesta del caso de uso.

De manera similar, para cada comunicación entre un caso de uso y un actor secundario (iniciada por el caso de uso), el actor secundario debe enviar una respuesta al caso de uso.

Generalización

La generalización representa la relación entre

• roles o
• casos de uso.

EDITE ESTA PLANTILLA DE DIAGRAMA DE CASOS DE USO DE UML

Si dos actores están conectados por esta relación, entonces el actor (o caso de uso) al final de la flecha (conectado a la parte inferior del triángulo) es una versión especializada del actor (o caso de uso) en el otro extremo.

Por lo general, el actor (o caso de uso) en el extremo inferior (conectado a la parte inferior del triángulo) se conoce como la versión especializada del actor (o caso de uso) en el otro extremo.

La generalización significa que la versión especializada tiene todas las características de la versión general y posiblemente más.

Incluir   es un tipo especial de relación entre dos casos 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.

EDITE ESTE EJEMPLO DE DIAGRAMA DE CASO DE USO

Extend es otro tipo especial de relación entre dos casos de uso. Si un caso de uso B extiende 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.

EDITE ESTE EJEMPLO DE DIAGRAMA DE CASO DE USO

Notaciones del diagrama de casos de uso

EDITE ESTE EJEMPLO DE DIAGRAMA DE CASOS DE USO EN LÍNEA

9 pasos simples para realizar análisis de casos de uso

1. Determine quién utilizará directamente el sistema. Estas personas son los actores.
2. Elige a uno de estos actores.
3. Defina lo que ese actor quiere hacer con el sistema. Cada cosa que el actor quiere hacer con el sistema se convierte en un caso de uso.
4. Repita los pasos 2 y 3 para todos los demás casos de uso
   . Identifique los roles secundarios y el soporte de roles no humanos para los casos de uso que ha identificado.
5. Dibuje la versión inicial del caso de uso, no complique demasiado las relaciones de casos de uso en este punto
6. Discutir y revisar con los usuarios para validar los objetivos de cada caso de uso (beneficios de la funcionalidad propuesta) Después de las modificaciones, puede continuar detallando los casos de uso en los pasos 8 a 10
7. Para cada caso de uso, decida el proceso más común que seguirá el actor al usar el sistema. Lo que sucedería normalmente.
8. Describa este proceso básico en la descripción del caso de uso.
9. Una vez que esté satisfecho con el proceso básico, considere escenarios alternativos y agréguelos como casos de uso extendido.

Modelo de caso de uso y especificación

No basta con mostrar el diagrama de casos de uso en notación UML. Cada caso de uso va acompañado de un texto que explica el propósito del caso de uso y la funcionalidad que se logra cuando se ejecuta el caso de uso.

Un caso de uso describe una tarea realizada por un actor que produce un resultado de valor comercial para la empresa. Un caso de uso se puede visualizar como un diagrama de caso de uso o en un formato de especificación de texto estructurado .

Escenarios de casos de uso

Un caso de uso consta de una serie de escenarios, cada uno de los cuales representa una instancia específica del caso de uso, correspondiente a entradas específicas del actor o condiciones específicas en el entorno. Cada escenario describe una forma alternativa de comportamiento del sistema, o puede describir fallas o excepciones.

Un caso de uso tiene:

• solo un gol
• Un único punto de partida
• Un único punto final
• Múltiples caminos para ir de principio a fin
  • es decir, especificar el comportamiento para una variedad de condiciones posibles
  • Cada condición puede requerir acción(es) específica(s)

Por ejemplo: el cliente paga la factura:

Hay múltiples caminos para  lograr el objetivo :

• Pago telefónico
• Por correo
• En persona
• por cheque
• en efectivo, etc

Un camino que  no conduce a la meta:

• Se rechaza la tarjeta de crédito

Agrupación de casos de uso con paquetes

También puede: Dibujar paquetes para la categorización lógica de casos de uso en subsistemas relacionados.

EDITE ESTE EJEMPLO DE DIAGRAMA DE CASO DE USO

Especificación detallada del caso de uso

Un caso de uso detallado es una representación textual que describe un flujo de eventos y otra información relacionada con el caso de uso en un formato específico. Una plantilla de caso de uso estándar se usa a menudo para documentar los detalles de un caso de uso

¿Qué es una descripción de caso de uso?

Una descripción de caso de uso es una descripción escrita de la secuencia de pasos que realiza un analista para completar una transacción de sistema completa. Lo inicia un actor, proporciona valor a ese actor y es el objetivo de los actores que trabajan en el sistema.

Actor : cualquier persona o sistema externo al sistema que utiliza o interactúa con el sistema para lograr un objetivo. A cada actor se le asigna un rol para representar su interacción con la solución. Los actores de personas deben nombrarse en forma de roles y no se les deben asignar nombres reales. Los actores generalmente se clasifican como primarios, secundarios o partes interesadas.

Actor principal : el actor que inicia el caso de uso.
Actor secundario: el actor que reacciona o responde a las acciones realizadas por el actor principal.
Partes interesadas: actores fuera del escenario que no interactúan directamente con el caso de uso, pero tienen interés en el resultado del caso de uso.

Flujo de flujo de eventos (ruta) : la secuencia de pasos que los actores y las soluciones deben seguir para ejecutar un caso de uso. En general, un caso de uso consta de una ruta de éxito principal (también denominada básica o principal), una ruta alternativa y una ruta de excepción.

La ruta normal , la entrada del actor y la respuesta del sistema, representa la ruta de éxito más común para lograr los objetivos del actor.

Caminos alternativos : entradas del actor y respuestas del sistema, que representan los otros caminos menos comunes para lograr el objetivo del actor.

Rutas excepcionales : entradas del actor y respuesta del sistema, que representan rutas fallidas cuando no se puede lograr el objetivo del actor.

Descripción del caso de uso
Nombre del caso de uso:	Retirar dinero
Actor(es):	Cliente (primario), Sistema Bancario (secundario)
Descripción resumida:	Permite a cualquier cliente del banco retirar efectivo de su cuenta bancaria.
Prioridad:	Debe tener
Estado:	Nivel medio de detalles
Condición previa:	El cliente del banco tiene una tarjeta para insertar en el cajero automático El cajero automático está en línea correctamente
Condición(es) posterior(es):	El cliente del banco ha recibido su efectivo (y opcionalmente un recibo) El banco ha debitado la cuenta bancaria del cliente y ha registrado los detalles de la transacción.
Ruta básica:	El cliente introduce su tarjeta en el cajero El cajero verifica que la tarjeta es una tarjeta bancaria válida El cajero solicita un código PIN El cliente ingresa su código PIN El cajero automático valida la tarjeta bancaria con el código PIN El cajero automático presenta opciones de servicio que incluyen «Retirar» El cliente elige «Retirar» El cajero presenta opciones de montos El cliente selecciona una cantidad o ingresa una cantidad El cajero verifica que tiene suficiente efectivo en su hopper El cajero automático verifica que el cliente está por debajo de los límites de retiro El cajero verifica fondos suficientes en la cuenta bancaria del cliente El cajero automático debita la cuenta bancaria del cliente El cajero automático devuelve la tarjeta bancaria del cliente El cliente toma su tarjeta bancaria. El cajero automático emite el efectivo del cliente El cliente toma su efectivo
Caminos alternativos:	2a. Tarjeta no valida 2b. Tarjeta al revés 5a. tarjeta robada 5b. PIN inválido 10 a. Efectivo insuficiente en la tolva 10b. Denominación incorrecta de efectivo en la tolva 11a. Retiro por encima de los límites de retiro 12a. Fondos insuficientes en la cuenta bancaria del cliente 14a. Tarjeta bancaria atascada en máquina 15a. El cliente no toma su tarjeta bancaria 16a. Efectivo atascado en máquina 17a. El cliente no toma su efectivo un cajero automático no puede comunicarse con el sistema bancario b El cliente no responde al aviso del cajero automático
Reglas del negocio:	B1: Formato de PIN B2: Número de reintentos de PIN B3: Opciones de servicio B4: Opciones de cantidad B5: Límite de retiro B6: se debe retirar la tarjeta antes de dispensar efectivo
Requerimientos no funcionales:	NF1: Tiempo para completar la transacción NF2: Seguridad para ingreso de PIN NF3: Tiempo para permitir el cobro de tarjeta y efectivo NF4: soporte de idiomas NF5: Apoyo a ciegos y parcialmente ciegos

enlaces relacionados

1. ¿Qué es el lenguaje de modelado unificado?
2. Diapositiva de caso de uso / Notas de clase
3. El papel de los casos de uso en el modelado de requisitos y análisis
4. Una lista de herramientas UML
5. Prueba Visual Paradigm GRATIS
6. Caso de uso: notas para el curso de capacitación
7. ¿Cómo escribir casos de uso efectivos?
8. Capítulo de libro – PDF – Modelo de caso de uso: requisitos de escritura en contexto