Proyecto eMERGENCYMAP

Integrantes:

- Constanza acosta jara. |rol usm: 202330019-5

- josefa castillo carrasco. |rol usm: 202430002-4

- rodrigo hernandez julio. |rol usm: 202221053-2

- ignacio Torres oda. |rol usm: 202221054-0

FECHA: 01 de julio, 2026.

ASIGNATURA: elo329 (Diseño y programación orientados a objetos).

PROFESOR: agustín gonzalez.

Descripción del problema a abordar

En entornos como campus universitarios grandes (Ej. UTFSM), la gestión de incidentes y emergencias suele centralizarse en canales verbales analógicos (tales como de forma presencial o llamadas telefónicas). Sin embargo, los operadores carecen de herramientas visuales dinámicas para registrar, mapear y hacer seguimiento de los problemas en tiempo real a medida que son reportados por la comunidad (por medio de llamadas o personalmente). Los sistemas tradicionales basados puramente en texto y llamadas ralentizan el diagnóstico situacional como también la toma de decisiones ante eventos complejos.

análisis del problema

En el contexto de la UTFSM, existe la necesidad de una aplicación central de control con una interfaz gráfica interactiva que permita al operador (guardia) "marcar" geográficamente un incidente mediante una pulsación (clic) directo sobre el plano digital del recinto, para así mejorar la conexión operativa entre la recepción del reporte y su representación visual. Nuestro sistema automatiza la activación de alarmas visuales y sonoras en la central, mantener un control estricto de qué emergencias siguen activas, permitir su desactivación manual una vez resueltas y almacenar un historial diario para auditorías posteriores sin que los datos se pierdan al cerrar el programa.

A continuación, se presentan los entes que participan en el problema:

· Guardia (operador): Ente interno y usuario principal del sistema. Interactúa con la interfaz gráfica para registrar incidentes mediante coordenadas geoespaciales (clic directo sobre el plano digital del recinto), realiza la monitorización en pantalla y desactiva manualmente las alertas una vez resueltas en terreno.

· Subsistema Multimedia (Alertas): Componente interno encargado de automatizar los estímulos visuales y sonoros de la central. Modifica dinámicamente el estado de la interfaz mediante marcadores parpadeantes y desencadena alarmas acústicas en tiempo de ejecución de manera concurrente al evento.

· Módulo de Persistencia de Datos: Mecanismo interno que interactúa con el sistema de archivos de la máquina. Su función es estructurar y almacenar permanentemente un historial diario de las emergencias resueltas, previniendo la pérdida de información tras el cierre de la aplicación.

· Comunidad Universitaria: Ente externo al software que actúa como el disparador del flujo operativo al notificar los incidentes a la central de forma analógica (llamadas o presencial). Define las variables de entrada de la situación (tipo de incidente, criticidad y localización aproximada).

Definición del sistema:

El sistema nominado “EmergencyMAP” se define como una aplicación de escritorio interactiva para el control centralizado de emergencias, construida bajo el paradigma de Programación Orientada a Objetos. La lógica está delimitada por la interfaz gráfica que procesa pulsaciones del mouse para la captura de coordenadas sobre un mapa digitalizado del campus. El sistema se encarga de coordinar de manera síncrona los estados de las alertas, la activación/desactivación de estímulos multimedia y la gestión de la persistencia de datos en archivos locales antes de la finalización de su ciclo de vida.

Interacciones con el medio externo:

La frontera entre el sistema y su entorno externo se gestiona mediante dos flujos de interacción principales:

1. Flujo de Entrada: La comunidad universitaria (medio externo) genera un reporte verbal (presencial o vía telefónica). El Guardia (operador) actúa como puente traduciendo este estímulo externo en datos digitales mediante la pulsación del mouse sobre la pantalla, lo que gatilla la instanciación dinámica de los objetos de emergencia dentro del sistema.

2. Flujo de Salida: Una vez que una emergencia es marcada como "Resuelta" por el operador, el sistema interactúa con el medio externo (el sistema operativo y el disco duro de la computadora) inyectando flujos de salida de texto (I/O) para escribir y consolidar el historial diario en un archivo de texto (.txt) local de forma permanente.

Definición de requerimientos

El sistema desarrollado ha considerado los siguientes casos de uso:

CU001: Registrar emergencia

Nombre | Registrar emergencia.
Propósito | Permitir el registro de una nueva emergencia dentro del campus para su monitoreo y gestión.
Actores | Guardia.
Pre-condiciones | El sistema de monitoreo debe estar activo y el mapa del campus correctamente cargado.
Evento | El guardia recibe un reporte de emergencia.
Curso normal de eventos |
Paso | Actor (Guardia) | Sistema
1 | Recibe un reporte de emergencia. | -
2 | Hace clic sobre el mapa indicando la ubicación del incidente. | -
3 | - | Despliega una selección del tipo de emergencia (Incendio, disturbio, médica).
4 | - | Despliega un diálogo para ingresar una descripción breve.
5 | - | Registra la emergencia en el modelo.
6 | - | Muestra un marcador visual en el mapa y añade el incidente a la lista lateral.
7 | - | Activa una alarma sonora (si no se encuentra activa previamente).
Curso alternativo de eventos | 7.1. Si la alarma sonora ya se encuentra activa, se omite el paso 7 del flujo principal.
Requerimientos no funcionales | El marcador visual y la alerta sonora deben activarse en un tiempo de respuesta menor a 1 segundo tras el registro.
Autor | Desarrolladores.

Tabla 1: Descripción del caso de uso “Registrar emergencia”.

CU002: Resolver emergencia

Nombre | Resolver emergencia.
Propósito | Permitir que una emergencia activa sea marcada como resuelta.
Actores | Guardia.
Pre-condiciones | Debe existir al menos una emergencia activa registrada y visible en el sistema.
Evento | El guardia decide dar por finalizada la gestión de una emergencia.
Curso normal de eventos |
Paso | Actor (Guardia) | Sistema
1 | Selecciona una emergencia activa desde la vista lateral. | -
2 | Presiona la opción “Resolver seleccionada”. | -
3 | - | Cambia el estado de la emergencia a “resuelta”.
4 | - | Desactiva el marcador visual de la emergencia, y si no quedan más incidentes activos en el sistema, detiene la alarma sonora.
5 | - | Registra la emergencia en el historial del sistema.
Curso alternativo de eventos | 4.1. Si quedan otros incidentes activos en el sistema, la alarma sonora continúa encendida.
Requerimientos no funcionales | La actualización del estado y el cese de las alertas visuales deben ser inmediatos.
Autor | Desarrolladores.

Tabla 2: Descripción del caso de uso “Resolver emergencia”.

CU003: Detener programa y consultar historial

Nombre | Detener programa y consultar historial.
Propósito | Guardar los registros del día, visualizar el historial de emergencias resueltas y finalizar la ejecución de la aplicación.
Actores | Guardia.
Pre-condiciones | La aplicación se encuentra en ejecución y recopilando datos de la jornada.
Evento | El guardia presiona el botón “STOP” para finalizar el monitoreo.
Curso normal de eventos |
Paso | Actor (Guardia) | Sistema
1 | Presiona el botón “STOP” en el panel lateral. | -
2 | - | Guarda las emergencias registradas en el archivo físico (archivo de texto).
3 | - | Lee y carga el archivo de registros.
4 | - | Muestra una ventana emergente con la información cargada.
5 | Visualiza la información disponible y cierra la ventana emergente. | -
6 | - | Finaliza su ejecución de forma segura.
Curso alternativo de eventos | 2.1. Si ocurre un error al escribir en el archivo físico, se notifica un error de persistencia antes de intentar continuar.
Requerimientos no funcionales | La persistencia en el archivo físico debe realizarse garantizando la integridad de los datos de la sesión actual.
Autor | Desarrolladores.

Tabla 3: Descripción del caso de uso “Detener programa y consultar historial”.

Diseño

A continuación, presentamos el diagrama de clases de este proyecto:

Figura 1: Diagrama de clases del programa EmergencyMAP.

Adicionalmente, se han confeccionado los siguientes diagramas de secuencia para los casos de uso descritos previamente:

Figura 2: Diagrama de secuencia del caso de uso CU001.

Figura 3: Diagrama de secuencia del caso de uso CU002.

Figura 4: Diagrama de secuencia del caso de uso CU003.

PRUEBAS | RESULTADOS

Los resultados finales de nuestro proyecto respecto a los casos de uso planteados son los siguientes:

- CU001: Registrar emergencia.

Figura 5: Para hacer el registro de la emergencia, se hace clic en el mapa en el edificio donde se ha reportado una emergencia y selecciona el tipo de emergencia.

Figura 6: Luego de seleccionar el tipo de emergencia, se despliega una ventana para ingresar la descripción del incidente.

Figura 7: Al quedar registrado un incidente activo, se observa su información en el panel lateral, se activa un marcador visual parpadeante y la alarma sonora.

- CU002: Resolver emergencia.

Figura 8: En esta prueba, se observan varios incidentes activos en el sistema, en el panel lateral se selecciona la emergencia que se desea resolver, y luego se presiona la opción “Resolver seleccionada”.

Figura 9: El incidente que fue seleccionado a resolver, desaparece de la vista lateral y el marcador visual (color azul) se desactiva, en este ejemplo, al existir otras emergencias activas, la alarma sonora sigue activa.

- CU003: Detener programa y consultar historial.

Figura 10: Al finalizar el programa con el botón “STOP”, se presenta la ventana emergente con el registro de los incidentes del día, luego, al presionar “Aceptar” se cierra el programa.

VERSIÓN COMPRIMIDA DEL CÓDIGO DESARROLLADO

Puede acceder a la versión comprimida (descargable) del proyecto mediante el siguiente enlace:

è EmergencyMAP.zip

Además, se proporciona el enlace al repositorio donde se desarrolló el proyecto:

è Repositorio EmergencyMAP