Diagrama de Casos de Uso
Muestra las interacciones entre los actores del sistema (Administrador y Monitor) y las funcionalidades del SGMSC, agrupadas por módulo.
SGMSC — Use Case Diagram
flowchart LR
classDef actor fill:#1565C0,stroke:#1565C0,color:#fff,rx:50%
classDef uc fill:#E3F2FD,stroke:#1565C0,color:#0d47a1,rx:10px
classDef sys fill:#F3E5F5,stroke:#6A1B9A,color:#4A148C,rx:10px,font-weight:bold
ADMIN([👤 Administrador]):::actor
MON([👤 Monitor]):::actor
subgraph SYS [🖥️ SGMSC — Sistema de Gestión de Monitores y Salas de Cómputo]
direction TB
subgraph AUTH [Autenticación]
CU01(CU-01\nIniciar sesión):::uc
end
subgraph USUARIOS [Gestión de Usuarios]
CU02(CU-02\nRegistrar usuario):::uc
CU03(CU-03\nListar / Editar / Eliminar usuarios):::uc
end
subgraph SALAS [Gestión de Salas]
CU04(CU-04\nRegistrar sala de cómputo):::uc
CU05(CU-05\nRegistrar horario de funcionamiento):::uc
end
subgraph ASIGNACIONES [Gestión de Asignaciones]
CU06(CU-06\nAsignar monitor a sala/horario):::uc
CU07(CU-07\nConsultar asignaciones activas):::uc
end
subgraph CAMBIOS [Gestión de Cambios de Turno]
CU08(CU-08\nGestionar solicitudes de cambio):::uc
CU11(CU-11\nRegistrar solicitud de cambio de turno):::uc
CU12(CU-12\nConsultar estado de solicitudes):::uc
end
subgraph HORARIO [Consulta de Horario]
CU10(CU-10\nConsultar horario semanal):::uc
end
end
ADMIN --> CU01
ADMIN --> CU02
ADMIN --> CU03
ADMIN --> CU04
ADMIN --> CU05
ADMIN --> CU06
ADMIN --> CU07
ADMIN --> CU08
MON --> CU01
MON --> CU10
MON --> CU11
MON --> CU12
CU06 -. "include: valida conflictos" .-> VLD{Validar solapamiento}:::sys
CU11 -. "include: valida reemplazante" .-> VLD2{Validar reemplazante}:::sys
Actor
Administrador — gestión total del sistema
Actor
Monitor — consulta y solicita cambios de turno
Casos Admin
CU-01 al CU-08 (8 casos de uso)
Casos Monitor
CU-09, CU-10, CU-11, CU-12 (4 casos)
«include»
Validación de solapamiento de horarios
Acceso
Autenticación con JWT y roles ADMIN/MONITOR
Diagrama de Clases
Representa las entidades del dominio del SGMSC con sus atributos, métodos y relaciones (asociación, composición y dependencia).
SGMSC — Class Diagram
classDiagram
direction TB
class Usuario {
+id int
+nombre String
+cedula String
+password String
+rol String
+login() String
+logout() void
+actualizarPerfil() void
}
class Sala {
+id int
+nombre String
+descripcion String
+registrar() Sala
+actualizar() void
+eliminar() void
}
class Horario {
+id int
+id_sala int
+diaSemana String
+horaInicio String
+horaFin String
+registrar() Horario
+verificarSolapamiento() bool
}
class Asignacion {
+id int
+id_horario int
+id_monitor int
+fechaAsignacion Date
+asignar() Asignacion
+cancelar() void
+verificarDuplicado() bool
}
class SolicitudCambio {
+id int
+id_solicitante int
+id_reemplazante int
+id_horario int
+fechaSolicitud Date
+estado String
+registrar() SolicitudCambio
+aprobar() void
+rechazar() void
+consultarEstado() String
}
Usuario --> Sala : asignado a
Sala --> Horario : tiene horarios
Horario --> Asignacion : cubierta por
Usuario --> Asignacion : monitor asignado
Usuario --> SolicitudCambio : solicita o reemplaza
Entidades
5 clases principales + 3 enumeraciones
Clave primaria
Todos los modelos usan id entero auto-incremental
Integridad
FK con ON DELETE RESTRICT en todas las relaciones
Seguridad
Password hasheado con bcrypt antes de persistir
BD
MySQL 8.x como motor de base de datos
Rendimiento
< 1 segundo para listas de hasta 200 registros
Diagrama de Secuencia
Modela el flujo temporal del proceso más crítico del sistema: Solicitud de Cambio de Turno, desde el login del monitor hasta la aprobación/rechazo por el administrador.
Secuencia: Solicitud de Cambio de Turno
sequenceDiagram
autonumber
participant M as Monitor
participant FE as Frontend React
participant API as API Node/Express
participant DB as Base de Datos MySQL
participant ADM as Administrador
rect rgb(227, 242, 253)
Note over M, DB: FASE 1 - Autenticacion del Monitor
M ->> FE : Ingresa cedula y contrasena
FE ->> API : POST /auth/login
API ->> DB : SELECT usuario WHERE cedula
DB -->> API : Usuario id, nombre, rol
API ->> API : bcrypt.compare password
alt Credenciales validas
API -->> FE : 200 OK - JWT token, rol MONITOR
FE -->> M : Redirige a Dashboard
else Credenciales invalidas
API -->> FE : 401 Unauthorized
FE -->> M : Muestra error de autenticacion
end
end
rect rgb(232, 245, 233)
Note over M, DB: FASE 2 - Consulta de Horario Asignado
M ->> FE : Navega a Mis Horarios
FE ->> API : GET /asignaciones/mias Bearer JWT
API ->> DB : SELECT asignaciones JOIN horarios WHERE id_monitor
DB -->> API : Lista de asignaciones con horario y sala
API -->> FE : 200 OK lista sala, dia, horaInicio, horaFin
FE -->> M : Muestra tabla con horario semanal
end
rect rgb(243, 229, 245)
Note over M, DB: FASE 3 - Registrar Solicitud de Cambio
M ->> FE : Selecciona turno a intercambiar
M ->> FE : Escoge monitor reemplazante y confirma
FE ->> API : POST /solicitudes id_horario, id_reemplazante
API ->> DB : SELECT usuario WHERE id reemplazante AND rol MONITOR
alt Reemplazante existe
API ->> DB : INSERT SolicitudCambio estado PENDIENTE
DB -->> API : SolicitudCambio creada con id
API -->> FE : 201 Created - estado PENDIENTE
FE -->> M : Solicitud enviada, estado Pendiente
else Reemplazante no encontrado
API -->> FE : 404 Not Found
FE -->> M : Monitor reemplazante no existe
end
end
rect rgb(255, 243, 224)
Note over ADM, DB: FASE 4 - Revision por el Administrador
ADM ->> FE : Navega a Solicitudes de Cambio
FE ->> API : GET /solicitudes?estado=PENDIENTE Bearer JWT
API ->> DB : SELECT FROM solicitudes WHERE estado PENDIENTE
DB -->> API : Lista de solicitudes pendientes
API -->> FE : 200 OK lista id, solicitante, reemplazante, horario
FE -->> ADM : Muestra lista de solicitudes pendientes
ADM ->> FE : Selecciona solicitud y decide
alt Aprobar solicitud
FE ->> API : PATCH /solicitudes/id estado APROBADA
API ->> DB : UPDATE solicitudes SET estado APROBADA
DB -->> API : 1 row updated
API -->> FE : 200 OK estado APROBADA
FE -->> ADM : Solicitud aprobada exitosamente
else Rechazar solicitud
FE ->> API : PATCH /solicitudes/id estado RECHAZADA
API ->> DB : UPDATE solicitudes SET estado RECHAZADA
DB -->> API : 1 row updated
API -->> FE : 200 OK estado RECHAZADA
FE -->> ADM : Solicitud rechazada
end
end
rect rgb(252, 228, 236)
Note over M, DB: FASE 5 - Monitor Consulta Estado Final
M ->> FE : Navega a Mis Solicitudes
FE ->> API : GET /solicitudes/mias Bearer JWT
API ->> DB : SELECT FROM solicitudes WHERE id_solicitante
DB -->> API : Lista con estados actualizados
API -->> FE : 200 OK lista id, estado APROBADA o RECHAZADA
FE -->> M : Muestra estado final de su solicitud
end
Flujo principal
Cambio de turno con 5 fases diferenciadas
Alternativas
Manejo de errores en login, reemplazante y decisión
Seguridad
Todos los endpoints usan Bearer JWT
Arquitectura
MVC 3 capas: React → Node/Express → MySQL
Estado
PENDIENTE → APROBADA | RECHAZADA
Trazabilidad
Historial completo de cada solicitud en BD