Casos de uso¶
Los nueve casos de uso del sistema, con sus actores y qué parte de cada uno está construida.
El documento original de casos de uso trae una tabla de trazabilidad que da por hechos los reportes y la evaluación de alertas. Acá la columna de estado dice lo que el sistema hace.
Actores¶
| Actor | Rol en el sistema | Alcance |
|---|---|---|
| Administrador de MRG | admin, platform_admin |
Administración global: clientes, usuarios, dispositivos y claves. Opera entre clientes |
| Operario de MRG | operario |
Monitorea, consulta históricos y atiende alertas. Sin configuración avanzada |
| Administrador del cliente | cliente_admin |
Gestiona los usuarios de su empresa, sus disposiciones de dashboard y sus alertas |
| Operario del cliente | cliente_operario |
Visualiza tiempo real e históricos de su máquina |
La autenticación y la autorización son transversales a todos los casos de uso. El modelo está en seguridad.
Los nueve casos de uso¶
| Caso de uso | Actores | Estado verificado | |
|---|---|---|---|
| UC-01 | Autenticación de usuario | todos | ✅ implementado |
| UC-02 | Gestión de usuarios y roles, multi-cliente | administradores | ✅ implementado |
| UC-03 | Monitoreo en tiempo real | todos | ◑ parcial |
| UC-04 | Consulta histórica y trazabilidad | todos | ◑ parcial |
| UC-05 | Gestión de alertas y notificaciones | todos | ◑ parcial, sin el núcleo |
| UC-06 | Reportes manuales | administradores | ✗ solo maqueta sobre datos de prueba |
| UC-07 | Reportes automáticos por correo | administradores | ✗ solo maqueta sobre datos de prueba |
| UC-08 | Logs y eventos del sistema | administradores | ✅ implementado |
| UC-09 | Estado y conectividad del dispositivo Edge | administradores | ✅ implementado |
UC-01 · Autenticación de usuario — ✅¶
Iniciar sesión y recibir los permisos del rol.
Qué existe: identidad delegada en un proveedor externo, verificación de firma contra claves públicas con comprobación de emisor, audiencia y vencimiento; sesión del lado del servidor en el BFF; rechazo de cuentas revocadas o deshabilitadas en cada petición; guardia de cambio de contraseña obligatorio en el primer ingreso.
Lo que el caso de uso pedía y no está: el bloqueo tras intentos fallidos. Lo gestiona el proveedor de identidad, no el sistema, así que su política no está documentada acá.
UC-02 · Gestión de usuarios y roles — ✅¶
Alta, baja y modificación de usuarios, empresas y asignaciones de rol.
Qué existe: catálogo de permisos en base de datos, siete roles, invitaciones por correo con activación en el primer ingreso, y la excepción de operadores de plataforma que pueden administrar clientes de los que no son miembros.
Es, por volumen de trabajo, el caso de uso más grande del sistema — y excede lo que el anteproyecto pedía: ver bitácora de alcance.
UC-03 · Monitoreo en tiempo real — ◑¶
Ver el estado actual de la máquina.
Qué existe: la cadena completa de datos del PLC al dashboard, con 14 de los 32 widgets consumiendo métricas reales sobre 10 variables.
Qué falta: los otros 18 widgets siguen con datos simulados, y 3 de los 14 literales de consulta nunca van a devolver datos por el defecto de composición del identificador de variable. Ver catálogo de variables.
"Tiempo real" tiene además un techo medible: el ciclo de lectura es de un segundo y el reenvío a la nube cada cinco, así que el dato llega al dashboard con varios segundos de retraso. Y si el PLC no responde, ese retraso puede escalar a minutos: calidad y resiliencia.
UC-04 · Consulta histórica y trazabilidad — ◑¶
Consultar lo ocurrido en un rango de tiempo.
Qué existe: todas las mediciones persistidas con identificador de evento determinista e idempotencia por cliente, con índices diseñados para las dos consultas que el dashboard hace, y ocho agregaciones disponibles.
Qué falta, y es importante para la trazabilidad: la calidad del dato no viaja. Una lectura fallida no produce punto, y en la serie es indistinguible de una máquina detenida. No hay forma de reconstruir si un hueco fue una parada o un fallo de lectura.
Tampoco hay política de retención en ninguna base: nada expira, y nadie decidió que así fuera.
UC-05 · Gestión de alertas y notificaciones — ◑ sin el núcleo¶
Detectar una condición anómala, notificar y registrar su atención.
| Pieza | Estado |
|---|---|
| Definir reglas de alarma (alta, baja, modificación) | ✅ existe |
| Almacén de notificaciones y su API | ✅ existe |
| Índice preparado para que un motor lea lo reciente | ✅ existe |
| Evaluar las reglas contra los datos que ingresan | ✗ no existe |
Es el caso de uso que sostiene el objetivo 5 del anteproyecto
Está todo salvo la pieza que lo hace funcionar. El sistema permite definir alertas y nunca las dispara.
Presentar este caso de uso como implementado porque existe su CRUD sería engañoso.
Por FE-ADR-014, el objetivo 5 se declara no alcanzado y el módulo no se expone en
el MVP: el ítem «Alertas» del menú queda deshabilitado con un cartel «Pendiente» y la
campana de notificaciones se oculta. El código no se borra. El detalle está en la
bitácora de alcance.
Para la defensa: el caso de uso es demostrable hasta la definición de la regla, y ahí se detiene a propósito. Esa frontera está marcada en la propia interfaz.
UC-06 y UC-07 · Reportes manuales y automáticos — ✗¶
Generar informes bajo demanda, y enviarlos por correo periódicamente.
No existe el servicio. No hay módulo de reportes en la API del Cloud: ni manejador, ni servicio, ni endpoint.
Pero la interfaz existe y parece funcionar
El frontend tiene la sección completa —listado, generación, descarga y reportes programados— y funciona: se puede entrar, generar uno, verlo aparecer y descargarlo.
Está construida íntegramente sobre datos de prueba que viven en la memoria del proceso que atiende cada petición. Un reporte generado no contiene datos de ninguna máquina, y puede desaparecer entre una visita y la siguiente.
Es el caso más engañoso del sistema: un usuario que recorra la aplicación concluye, con toda razón, que la función existe. Por eso está advertido en las dos guías de usuario que la mencionan.
Los informes están listados como componente del alcance y como entregable del anteproyecto.
UC-08 · Logs y eventos del sistema — ✅¶
Consultar la actividad registrada, con filtros y exportación.
Qué existe: servicio de logs con su API, políticas de retención en el modelo de datos, y registro estructurado en los tres componentes.
La limitación está en la planta, no en la nube: los registros de la Raspberry Pi rotan en tres archivos de 10 MB por servicio, así que un incidente de hace más de unas horas no se puede investigar. Ver monitoreo.
UC-09 · Estado y conectividad del dispositivo Edge — ✅¶
Ver si una Raspberry Pi está viva, si alcanza al PLC y cómo está de recursos.
Qué existe: consultas de estado, de salud y de telemetría que el Cloud inicia hacia el dispositivo, con permiso propio e independiente del de administración, porque ver el estado de una máquina es parte de la operación diaria.
Dos salvedades:
- Las consultas viajan sin autenticación, como riesgo aceptado:
SYS-ADR-005. - El mecanismo que permitiría enterarse sin preguntar —que la Pi avise por su cuenta— no está implementado en ninguno de los dos extremos. Si el Cloud no pregunta, no se entera.
Lo que el conjunto muestra¶
De los nueve casos de uso: cuatro implementados, tres parciales y dos inexistentes.
Los dos inexistentes y el núcleo faltante del quinto tienen algo en común: son las funciones que convierten datos en acción —alertar y reportar—. Lo construido captura, almacena y muestra; lo que falta es lo que le diría a alguien que haga algo.
No es casual: es la consecuencia del reordenamiento del cronograma que registra la bitácora. Las capas de abajo se construyeron últimas y consumieron el tiempo de las de arriba.
Relacionado¶
- Historias de usuario — las
US-0xxque estos casos de uso agrupan - Matriz de evidencias — objetivo por objetivo