Diagramas UML

👥

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

🗃

Modelo Entidad Relación

Representa la estructura de la base de datos del SGMSC con sus entidades, atributos y relaciones para MySQL 8.x.

SGMSC — Entity Relationship Diagram

🗃

Motor

MySQL 8.x con InnoDB

🔑

PKs

INT AUTO_INCREMENT en todas las tablas

🔗

FKs

ON DELETE RESTRICT en todas las relaciones

🔒

Unicidad

UNIQUE constraint en cedula de usuario

📊

Estado solicitud

ENUM: PENDIENTE, APROBADA, RECHAZADA

🧩

Cardinalidad

Relaciones 1 a N entre todas las entidades