Arquitectura del Sistema y Propósitos Principales

Este sistema de gestión administrativa está diseñado específicamente para optimizar los procesos internos de organismos legislativos y oficinas gubernamentales. La solución técnica se fundamenta en el ecosistema Java, utilizando el stack tecnológico SSM (Spring, Spring MVC, MyBatis) para el backend y Vue.js para la interfaz de usuario. El enfoque principal reside en dos módulos críticos: la gestión de asistencia del personal y el control de correspondencia oficial.

Mediente el uso de una arquitectura desacoplada, el sistema garantiza un flujo de trabajo estandarizado. El módulo de asistencia automatiza el registro de entradas y salidas, proporcionando datos precisos para la evaluación del desempeño. Por otro lado, el módulo de correspondencia gestiona el ciclo de vida completo de los documentos: desde la recepción y registro hasta la distribución y respuesta, asegurando que la comunicación institucional sea fluida y trazable.

Stack Tecnológico Utilizado

• Spring Framework: Actúa como el núcleo del sistema, gestionando la inversión de control (IoC) y la inyección de dependencias (DI). Esto permite un bajo acoplamiento entre los componentes del negocio y facilita las pruebas unitarias.
• Spring MVC: Se encarga de la capa web, separando la lógica de control, los modelos de datos y la visualización. Proporciona un manejo eficiente de las peticiones HTTP y la validación de formularios.
• MyBatis: Como framework de persistencia, permite un control total sobre las consultas SQL, mapeando objetos Java con registros de la base de datos de manera flexible y optimizada.
• Vue.js: En el frontend, se utiliza para construir una interfaz reactiva. Gracias al DOM virtual, la experiencia del usuario es ágil, actualizando componentes de forma dinámica sin recargar la página completa.

Implementación de Seugridad y Autenticación

La seguridad se implementa mediante un sistema de tokens de acceso (JWT o similares) gestionados a través de interceptores de Spring. A continuación, se muestra un ejemplo de la lógica de autenticación y generación de sesiones:

@RestController
@RequestMapping("/api/auth")
public class Control Acceso {

    @Autowired
    private UsuarioServicio usuarioServicio;

    @Autowired
    private SesionServicio sesionServicio;

    @PostMapping("/validar")
    public RespuestaServidor autenticar(@RequestParam String cuenta, @RequestParam String clave) {
        // Búsqueda de usuario con wrapper de consulta
        UsuarioModelo usuario = usuarioServicio.buscarUno(new QueryWrapper<UsuarioModelo>().eq("cuenta_usuario", cuenta));
        
        if (usuario == null || !usuario.getClaveAcceso().equals(clave)) {
            return RespuestaServidor.error("Credenciales no válidas");
        }
        
        // Generación de identificador único de sesión
        String hashAcceso = sesionServicio.crearIdentificador(usuario.getid(), cuenta, "usuarios", usuario.getPerfil());
        return RespuestaServidor.ok().put("token", hashAcceso);
    }
}

Para la persistencia de las sesiones activas, se utiliza un servicio que actualiza o inserta el token en la base de datos, definiendo un tiempo de expiración controlado:

@Service
public class SesionServicioImpl implements SesionServicio {

    @Override
    public String crearIdentificador(Long idUsuario, String login, String tabla, String rol) {
        // Verificar si ya existe una sesión activa
        SesionEntidad sesionExistente = this.selectOne(new EntityWrapper<SesionEntidad>()
            .eq("id_usuario", idUsuario).eq("rol_asignado", rol));
        
        String cadenaToken = UtilidadSeguridad.generarUUID(32);
        Calendar calendario = Calendar.getInstance();
        calendario.add(Calendar.MINUTE, 60); // Sesión válida por 1 hora
        
        if (sesionExistente != null) {
            sesionExistente.setTokenAcceso(cadenaToken);
            sesionExistente.setFechaExpiracion(calendario.getTime());
            this.updateById(sesionExistente);
        } else {
            this.insert(new SesionEntidad(idUsuario, login, tabla, rol, cadenaToken, calendario.getTime()));
        }
        return cadenaToken;
    }
}

Estructura de Datos de Sesiones

La base de datos MySQL almacena la información de acceso para validar la persistencia de los usuarios conectados. La estructura de la tabla de sesiones se define de la siguiente manera:

CREATE TABLE `tbl_sesiones` (
  `id_registro` bigint(20) NOT NULL AUTO_INCREMENT,
  `usuario_id` bigint(20) NOT NULL COMMENT 'ID del empleado',
  `nombre_cuenta` varchar(100) NOT NULL COMMENT 'Nombre de acceso',
  `origen_tabla` varchar(100) DEFAULT NULL COMMENT 'Referencia de entidad',
  `rol_usuario` varchar(100) DEFAULT NULL COMMENT 'Nivel de permisos',
  `clave_token` varchar(200) NOT NULL COMMENT 'Token de validación',
  `creado_en` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `expira_en` timestamp NOT NULL,
  PRIMARY KEY (`id_registro`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Metodología de Pruebas del Sistema

El aseguramiento de la calidad se realiza mediante pruebas de caja negra y validación de flujos de trabajo. El proceso incluye:

• Pruebas de Funcionalidad: Verificación de los módulos de asistencia, carga de documentos y gestión de roles.
• Validación de Límites: Pruebas de entrada de datos para asegurar que los campos obligatorios y los formatos de correspondencia sean correctos.
• Control de Concurrencia: Asegurar que múltiples usuarios puedan registrar su asistencia simultáneamente sin colisiones en la base de datos.
• Pruebas de Intercepción: Garantizar que las rutas protegidas redirijan correctamente al login si el token de sesión ha expirado o es inexistente.