9. Nombres de casos de uso: verbos, intención y claridad
9.1 Introducción
El nombre de un caso de uso parece un detalle menor, pero influye mucho en la calidad del análisis. Un buen nombre permite entender rápidamente qué objetivo busca un actor y qué valor entrega el sistema.
Cuando los nombres son ambiguos, técnicos o demasiado pequeños, el diagrama y la especificación se vuelven difíciles de interpretar. Por ejemplo, Presionar aceptar no expresa un objetivo; Confirmar reserva sí lo hace.
Nombrar bien ayuda a descubrir errores de alcance, granularidad y enfoque. Si no podemos poner un nombre claro, probablemente el caso de uso todavía no está bien definido.
9.2 Regla general para nombrar
Una regla práctica es nombrar cada caso de uso con un verbo en infinitivo seguido de un objeto significativo. El verbo indica la acción principal y el objeto indica sobre qué se realiza esa acción.
Ejemplos: Solicitar turno, Registrar paciente, Consultar agenda, Cancelar reserva.
Este formato no es una obligación absoluta, pero ayuda a mantener consistencia y claridad en la documentación.
9.3 Verbos adecuados
Los verbos deben expresar la intención del actor, no un detalle de interfaz o una operación interna. Algunos verbos frecuentes en casos de uso son:
- Registrar
- Consultar
- Solicitar
- Cancelar
- Modificar
- Confirmar
- Autorizar
- Generar
- Emitir
- Administrar
El verbo debe elegirse según el resultado buscado. No es lo mismo Consultar turno que Solicitar turno o Cancelar turno.
9.4 Nombres claros frente a nombres débiles
Un nombre claro expresa un objetivo completo y entendible. Un nombre débil suele describir un paso, una pantalla, un botón, una operación técnica o una frase demasiado general.
9.5 Evitar nombres basados en pantallas
Un caso de uso no debe nombrarse como si fuera una pantalla. Las pantallas son parte de la interfaz; el caso de uso representa un objetivo del actor.
Ejemplos de nombres débiles:
- Pantalla de turnos.
- Formulario de paciente.
- Ventana de confirmación.
- Menú de reportes.
Nombres más adecuados serían: Consultar turnos, Registrar paciente, Confirmar reserva y Generar reporte.
9.6 Evitar nombres basados en botones
Un botón puede ser parte de la interacción, pero no representa por sí solo el objetivo del actor. Nombrar casos de uso como botones produce casos demasiado pequeños y dependientes de la interfaz.
Por ejemplo:
| Nombre basado en botón | Nombre orientado al objetivo |
|---|---|
| Presionar confirmar | Confirmar turno |
| Hacer clic en buscar | Consultar disponibilidad |
| Seleccionar guardar | Registrar paciente |
| Presionar imprimir | Emitir comprobante |
9.7 Evitar nombres técnicos
Los nombres técnicos suelen ser comprensibles para desarrolladores, pero no para usuarios o responsables del negocio. Además, enfocan el caso de uso en la implementación y no en el objetivo externo.
Ejemplos de nombres técnicos poco adecuados:
- Ejecutar endpoint de reserva.
- Insertar registro en tabla turnos.
- Actualizar flag de estado.
- Enviar request a API externa.
- Renderizar grilla de resultados.
Estos detalles pueden ser importantes para el diseño o la implementación, pero no para nombrar un caso de uso.
9.8 Evitar nombres demasiado generales
Algunos nombres son tan amplios que no explican un objetivo concreto. Por ejemplo, Gestionar turnos puede incluir consultar, solicitar, modificar, cancelar, confirmar y reasignar turnos.
Cuando un nombre usa verbos como gestionar, administrar o manejar, conviene revisar si realmente representa un caso de uso o si agrupa varios casos diferentes.
9.9 Evitar nombres demasiado pequeños
El extremo opuesto también es problemático. Un caso de uso no debería representar un paso mínimo que no tiene valor propio para el actor.
Ejemplos de nombres demasiado pequeños:
- Ingresar documento.
- Seleccionar fecha.
- Elegir opción.
- Validar campo.
- Mostrar mensaje.
Estas acciones pueden aparecer dentro del flujo de un caso de uso mayor, pero normalmente no justifican un caso de uso independiente.
9.10 Usar el lenguaje del negocio
Los nombres deben ser comprensibles para quienes conocen el dominio del problema. En un sistema médico, términos como turno, consulta, profesional, paciente y agenda son más útiles que nombres técnicos internos.
Usar lenguaje del negocio facilita la validación con usuarios y evita que los casos de uso se transformen en documentación exclusiva del equipo técnico.
9.11 Mantener consistencia
La lista de casos de uso debe mantener un criterio uniforme. Si se usa el verbo Registrar para crear información nueva, conviene no alternarlo sin necesidad con Crear, Cargar o Dar de alta, salvo que haya una diferencia real de significado.
La consistencia ayuda a leer el modelo completo. Por ejemplo:
- Registrar paciente.
- Registrar profesional.
- Registrar turno presencial.
Si los nombres siguen un patrón, el modelo resulta más claro y profesional.
9.12 Nombrar desde el actor principal
El nombre debe reflejar el objetivo del actor principal. Si el actor principal es el Paciente, Solicitar turno expresa mejor su intención que Recibir solicitud de turno, que describe el punto de vista del sistema.
En general, los casos de uso se nombran desde el valor externo, no desde la actividad interna del software.
9.13 Ejemplo aplicado a sistema de turnos
En un sistema de turnos médicos, algunos nombres adecuados podrían ser:
| Actor principal | Caso de uso | Objetivo expresado |
|---|---|---|
| Paciente | Solicitar turno | Obtener una reserva para una consulta médica. |
| Paciente | Cancelar turno | Dejar sin efecto una reserva existente. |
| Médico | Consultar agenda diaria | Conocer los pacientes asignados para el día. |
| Recepcionista | Registrar turno presencial | Reservar un turno para un paciente atendido en recepción. |
| Administrador | Configurar horarios de atención | Definir disponibilidad de profesionales. |
9.14 Cómo revisar un nombre
Para revisar si un nombre es adecuado, se pueden aplicar estas preguntas:
- ¿Expresa un objetivo completo del actor?
- ¿Usa un verbo claro en infinitivo?
- ¿Evita detalles de interfaz?
- ¿Evita detalles técnicos de implementación?
- ¿Tiene valor observable al finalizar?
- ¿Es comprensible para usuarios y equipo técnico?
- ¿Mantiene consistencia con otros nombres del modelo?
9.15 Cambiar nombres durante el análisis
Es normal cambiar nombres durante el análisis. A medida que se entiende mejor el dominio, algunos nombres se vuelven más precisos. Por ejemplo, Gestionar solicitudes puede transformarse en Solicitar turno, Aprobar solicitud y Cancelar solicitud.
Renombrar no es un problema; al contrario, suele ser señal de que el equipo está aclarando el modelo. Lo importante es que los cambios se actualicen en diagramas, especificaciones, requisitos y pruebas relacionadas.
9.16 Errores frecuentes
Al nombrar casos de uso, suelen aparecer estos errores:
- Usar nombres de pantallas o formularios.
- Nombrar acciones de botones.
- Usar lenguaje técnico de implementación.
- Crear nombres demasiado generales.
- Crear nombres demasiado pequeños.
- Usar verbos distintos para acciones equivalentes sin motivo.
- No reflejar el objetivo del actor principal.
9.17 Qué debes recordar de este tema
- Un buen nombre expresa el objetivo del actor.
- Conviene usar verbo en infinitivo más objeto significativo.
- El nombre debe evitar pantallas, botones y detalles técnicos.
- Los nombres demasiado generales suelen ocultar varios casos de uso.
- Los nombres demasiado pequeños suelen ser pasos dentro de otro caso de uso.
- El lenguaje del negocio facilita la validación con usuarios.
- La consistencia mejora la claridad del modelo completo.
9.18 Conclusión
Nombrar correctamente los casos de uso es una práctica simple, pero muy importante. Un nombre claro permite entender el objetivo, validar el alcance y comunicar la funcionalidad sin depender de detalles técnicos.
Cuando el nombre expresa intención y valor, el resto del análisis se vuelve más ordenado. En el próximo tema estudiaremos los niveles de detalle: casos de uso de negocio, de usuario y de sistema.