Casos de uso en UML: Cómo redactar especificaciones de casos de uso efectivas

Mostrar un diagrama de casos de uso utilizando únicamenteUMLla notación no es suficiente. Cada caso de uso va acompañado de texto que explica el propósito del caso de uso y la funcionalidad que se completa cuando se ejecuta el caso de uso. Las especificaciones de casos de uso se crean típicamente de forma iterativa durante las fases de análisis y diseño.

  • Primero, se escribe una breve descripción solo de los pasos necesarios para el flujo normal del caso de uso (es decir, qué funcionalidad proporciona el caso de uso).
  • A medida que avanza el análisis, estos pasos se desarrollan con más detalle.
  • Finalmente, se añaden flujos alternativos y de excepción al caso de uso.
  • Cada proyecto puede adoptar una plantilla estándar de casos de uso para crear especificaciones de casos de uso.

Caso de uso frente a especificación de caso de uso

Un caso de uso describe una tarea realizada por un actor que aporta valor empresarial. Un caso de uso puede visualizarse como un diagrama de casos de uso y/o un formato de especificación textual estructurado:

Use Case vs. Use Case Specification

Los casos de uso (tareas que el cliente desea realizar) pueden ser:

  • Interacción — Los casos de uso del sistema describen cómo un actor interactúa con el sistema para alcanzar una meta empresarial definida.
  • Manual — Una secuencia de acciones realizadas por el actor.
  • Automatizado — Una secuencia de pasos ejecutados por un programa o script.

Características de un caso de uso

Un caso de uso tiene:

  • Solo un objetivo
  • Un punto de inicio
  • Un punto de finalización
  • Múltiples caminos desde el inicio hasta el final
    • Es decir, especifica el comportamiento para diversas condiciones posibles
    • Cada condición puede requerir acciones específicas

Characteristics of a Use Case

Por ejemplo — El cliente paga una factura:

Customer Pays a Bill

Existen múltiples caminos paraalcanzar el objetivo:

  • Por teléfono
  • Por correo
  • En persona
  • Por cheque
  • En efectivo, etc.

Caminos queno conducen al objetivo:

  • Tarjeta de crédito rechazada

Enfoque ágil de casos de uso

El modelo de casos de uso y sus casos de uso individuales evolucionan de forma incremental con el tiempo. No todos los casos de uso del modelo necesitan especificarse al mismo nivel de detalle.

Justo a tiempo y justo lo necesario

Los casos de uso pueden redactarse a diferentes niveles de detalle y alcance, cada uno con un propósito:

  • Resumen: Una descripción general y una visión de alto nivel de una función del sistema o un proceso empresarial.
  • Nivel de objetivo del usuario: Descripciones relacionadas con tareas delos objetivos del usuarioy cómo interactúan con el sistema; descripciones de procesos empresariales específicos. Los casos de uso de objetivos del usuario suelen considerarse al nivel de las tareas principales del usuario.

Ejemplo: Retirar efectivo de un cajero automático es una tarea útil y sería un caso de uso de nivel principal, pero introducir su PIN no estaría en este nivel porque apoya la tarea principal.

  • Subfunción: Descripciones de actividades de nivel inferior que completan partes de un caso de uso principal.

Agile Use Case Approach

Nota: Algunos casos de uso pueden especificarse completamente hasta el nivel II. Deja de hacerlo cuando tengas justo el detalle suficiente, obtenido de forma oportuna y justa.

Especificación detallada del caso de uso

Un caso de uso detallado es una representación textual que describe una secuencia de eventos junto con otra información relevante del caso de uso en un formato determinado. Las personas suelen adoptar una plantilla estándar de casos de uso para documentar la información detallada de los casos de uso.

Detailed Use Case Specification

Plantilla de caso de uso – Ejemplo de retiro de efectivo en cajero automático

Como se mencionó anteriormente, los casos de uso tienen diversos estilos de notación (por ejemplo, diagramáticos, UML, formato textual). Independientemente del estilo de notación utilizado, debe ser fácil de entender. Puedes usar una plantilla como la deAlistair Cockburn, o elegir la plantilla que mejor se adapte a tu equipo.

Especificación del caso de uso
Nombre del caso de uso: Retirar efectivo
Actores: Cliente (principal), Sistema bancario (secundario)
Descripción breve: Permite a cualquier cliente bancario retirar efectivo de su cuenta bancaria.
Prioridad: Debe tener
Estado: Detalles medios
Precondiciones: El cliente bancario tiene una tarjeta para insertar en el ATM
El ATM está en línea y funcionando normalmente
Postcondiciones:
  • El cliente bancario ha recibido efectivo (y comprobante opcional)
  • El banco ha cargado la cuenta del cliente y registrado los detalles de la transacción
Flujo básico:
  1. El cliente inserta su tarjeta en el ATM
  2. El ATM valida que la tarjeta es una tarjeta bancaria válida
  3. El ATM solicita la entrada del PIN
  4. El cliente ingresa su PIN
  5. El ATM valida la tarjeta bancaria contra el PIN
  6. El ATM presenta las opciones de servicio, incluyendo «Retiro»
  7. El cliente selecciona «Retiro»
  8. El ATM presenta las opciones de monto
  9. El cliente selecciona una cantidad o ingresa una cantidad
  10. El ATM verifica que haya efectivo suficiente disponible en la máquina
  11. El ATM verifica que el cliente esté por debajo del límite de retiro
  12. El ATM verifica que haya fondos suficientes disponibles en la cuenta bancaria del cliente
  13. El ATM carga la cuenta bancaria del cliente
  14. El cajero automático devuelve la tarjeta bancaria del cliente
  15. El cliente toma su tarjeta bancaria
  16. El cajero automático entrega efectivo al cliente
  17. El cliente toma su efectivo
Flujos alternativos: 2a. Tarjeta inválida
2b. Tarjeta insertada al revés
5a. Tarjeta robada
5b. PIN inválido
10a. Efectivo insuficiente en la máquina
10b. Denominación de efectivo incorrecta en la máquina
11a. El retiro excede el límite de retiro
12a. Fondos insuficientes en la cuenta bancaria del cliente
14a. La tarjeta bancaria se queda atrapada en la máquina
15a. El cliente no toma la tarjeta bancaria
16a. El efectivo se queda atrapado en la máquina
17a. El cliente no toma el efectivo

  • El cajero automático no puede comunicarse con el sistema bancario
  • El cliente no responde a las indicaciones del cajero automático
Reglas de negocio: B1: Formato de PIN
B2: Número de intentos de PIN
B3: Opciones de servicio
B4: Opciones de monto
B5: Límites de retiro
B6: La tarjeta debe ser tomada antes de que se entregue el efectivo
Requisitos no funcionales: NF1: Tiempo para completar la transacción
NF2: Seguridad de la entrada del PIN
NF3: Tiempo permitido para recoger la tarjeta y el efectivo
NF4: Soporte para idiomas
NF5: Soporte para usuarios ciegos y con visión parcial

Dejar una contestacion