Diagramas UML - LadyCD/Gestion-Estres GitHub Wiki
Diagramas UML
Esta página reúne los diagramas UML del diseño del sistema, correspondientes a la actividad de Sprint 2 "Diseñar arquitectura de tres capas" y "Diseñar modelo de datos".
Diagrama de Casos de Uso
| Campo | Detalle |
|---|---|
| Actores | Empleados, Health Connect y RRHH |
| Descripción general | Este modelo ilustra las interacciones de los distintos actores con la solución tecnológica. El colaborador realiza el registro inicial previa aceptación de la autorización para el tratamiento de datos personales y sensibles, efectúa el ingreso a la plataforma, sincroniza su dispositivo wearable, diligencia las evaluaciones de autorreporte, monitorea su estado de estrés, recibe notificaciones preventivas con recomendaciones, examina sus tendencias históricas, documenta eventos cotidianos y adapta las sugerencias. Asimismo, la plataforma Health Connect opera como un componente externo encargado de suministrar las variables fisiológicas, en tanto que el área de Seguridad y Salud en el Trabajo o Gestión Humana dispone únicamente de información consolidada y despersonalizada. La generación de notificaciones se define como una derivación del proceso de monitoreo que se activa exclusivamente ante mediciones elevadas, mientras que la vista analítica organizacional se delimita condicionalmente por encontrarse fuera del alcance contemplado para la entrega inicial del prototipo. |
| Diagrama |
Diagrama de Clases
| Campo | Detalle |
|---|---|
| Entidades principales | Usuario: datos personales y laborales, y rol (trabajador o SST/TH).Consentimiento: autorización para el tratamiento de datos (Ley 1581 de 2012).DispositivoVinculado: wearable conectado mediante Health Connect.SenalFisiologica: frecuencia cardíaca y HRV, solo en memoria.Cuestionario: chequeo diario y escala mensual de autorreporte.LineaBase: valores de referencia individuales de cada usuario.Deteccion: nivel de estrés (bajo, moderado o alto) y su desviación respecto a la línea base.Alerta: aviso preventivo con sugerencia y valoración del usuario.PreferenciaSugerencia: personalización de las sugerencias.Actividad: eventos laborales y sociales que contextualizan el estrés.ReporteAgregado: resumen anónimo por área y periodo. |
| Descripción general | Representa las entidades del sistema y la forma en que se relacionan. El usuario es el centro del modelo: otorga consentimientos, vincula un dispositivo, responde cuestionarios, registra actividades, personaliza sus sugerencias y genera detecciones. Cada detección combina la señal fisiológica, el cuestionario y la línea base individual para clasificar el nivel de estrés y, cuando este es alto, dispara una alerta. La señal fisioló |
| gica es una clase transitoria que solo existe en memoria y se descarta tras el cálculo, en aplicación del principio de minimización de datos. El reporte agregado resume las detecciones por área y periodo sin identificar a ningún trabajador. | |
| Diagrama |
Diagrama de Componentes
| Campo | Detalle |
|---|---|
| Componentes principales | Capa de presentación: app móvil Android (Java) con cuestionario y dashboard, y panel web de SST/TH (fuera del prototipo del 40 %).Capa de integración de datos: wearable (Wear OS), Health Connect (SDK de Android) y servicio de sincronización (lectura cada 15 minutos o más).Capa de gestión organizacional (backend Spring Boot): API REST con autenticación y control de roles, servicios de detección, alertas y reportes agregados, y base de datos MySQL. |
| Descripción general | Muestra la arquitectura del sistema en tres capas con responsabilidades independientes. La capa de presentación contiene la app móvil Android y el panel web para SST, este último fuera del alcance del prototipo. La capa de integración de datos toma las señales fisiológicas del wearable a través de Health Connect y las entrega a la app mediante un servicio de sincronización. La capa de gestión organizacional es el backend, cuya API REST controla la autenticación y los roles, y expone los servicios de detección, alertas y reportes sobre una base de datos MySQL que guarda únicamente el indicador de estrés derivado. |
| Diagrama |
Diagrama de Secuencia
| Campo | Detalle |
|---|---|
| Flujo representado | Sincronización de señales fisiológicas, detección del nivel de estrés y generación de alerta preventiva. |
| Descripción general | Describe el flujo principal del sistema en el tiempo. Cada cierto intervalo, el wearable deja sus datos de frecuencia cardíaca y HRV en Health Connect, la app los lee y los envía al backend, que calcula el nivel de estrés, guarda únicamente ese nivel y descarta la señal cruda. Si el nivel es alto, el backend registra la alerta y la envía a la app, que notifica al trabajador con un consejo preventivo. Luego el trabajador valora la alerta y esa respuesta se devuelve al backend para quedar registrada. |
| Diagrama |
Diagrama de Despliegue
| Campo | Detalle |
|---|---|
| Nodos principales | Wearable (dispositivo): Wear OS, sensor de frecuencia cardíaca y HRV.Smartphone Android (dispositivo): app móvil en Java y Health Connect.Servidor (entorno de ejecución): Spring Boot con API REST y los servicios de detección, alertas y reportes agregados.MySQL (base de datos): almacena solo el indicador de estrés derivado.Navegador web (dispositivo): panel de SST / Talento Humano, fuera del prototipo del 40 %. |
| Descripción general | Indica dónde se ejecuta cada parte del sistema. El wearable (Wear OS) se conecta por Bluetooth de baja energía al smartphone Android, que ejecuta la app en Java y Health Connect. El teléfono se comunica por HTTPS con el servidor Spring Boot, que a su vez usa MySQL por JDBC. El navegador con el panel de SST se conectaría al mismo servidor por HTTPS, y la nota del diagrama recuerda que la señal cruda no se almacena, en cumplimiento de la privacidad desde el diseño. |
| Diagrama |
Autora: Sandra Carolina Bohórquez Díaz