Informe — Sistema de Administración Comunitaria

1. Descripción del problema

En numerosos edificios y condominios la administración se maneja con planillas aisladas, cuadernos de conserjería o conversaciones por mensajería. Esta dispersión dificulta conocer el estado de los gastos comunes, produce conflictos al reservar espacios compartidos y vuelve lento el control de visitas y paquetes. El proyecto resuelve este problema mediante una aplicación de escritorio que centraliza la información relevante de la comunidad. El sistema permite registrar operaciones, aplicar reglas de negocio y conservar los datos entre ejecuciones.

2. Análisis del problema

El sistema modela la operación cotidiana de un condominio. Su núcleo es SistemaCondominio, que concentra los registros y las reglas de negocio; la interfaz JavaFX, implementada en CondominioApp, permite que los usuarios ingresen y consulten información sin manipular directamente las estructuras internas.

Actores y roles

Conserje: inicia sesión, registra residentes, visitas, paquetes, pagos y reservas; además puede eliminar reservas.
Administrador: hereda las funciones del conserje y administra residentes y conserjes.
Residente: es una entidad registrada y vinculada a un departamento; en esta versión no inicia sesión directamente.

Entidades principales

Departamento y su deuda acumulada.
Reserva de un EspacioComun.
GastoComun, Paquete y Visita.
Persona, Conserje, Admin y Residente.

Entorno externo

El usuario opera formularios, listas y botones de JavaFX.
El reloj del sistema entrega fechas y horas a visitas y paquetes.
El sistema de archivos local conserva el estado en datos/condominio.dat.

La interacción central ocurre cuando un usuario autenticado solicita una operación desde la interfaz. La aplicación delega la acción al sistema, que valida permisos y restricciones, modifica las entidades involucradas y guarda el estado. Por ejemplo, una reserva válida bloquea el espacio para la fecha indicada, agrega el costo de limpieza al departamento y al gasto común activo, y luego actualiza el archivo de persistencia.

3. Definición de requerimientos

Requerimientos funcionales

ID	Requerimiento	Regla de negocio asociada
RF-01	El sistema debe permitir iniciar y cerrar sesión como conserje o administrador.	Las funciones operativas requieren una sesión activa; las administrativas exigen que la sesión corresponda a `Admin`.
RF-02	Debe permitir registrar residentes asociados a un departamento.	Se rechaza un RUT duplicado; más de un residente puede pertenecer al mismo departamento.
RF-03	Debe permitir crear y eliminar reservas de espacios comunes.	No se permite reservar el mismo espacio en la misma fecha dos veces. Al crear una reserva se agrega su costo de limpieza a la deuda y al gasto común activo.
RF-04	Debe registrar visitas y paquetes, incluyendo el estado de entrega del paquete.	Las operaciones quedan asociadas al conserje o administrador que las registra.
RF-05	Debe registrar pagos de gastos comunes.	No se permite pagar un monto menor o igual a cero ni superior a la deuda pendiente.
RF-06	Debe mantener disponibles los cambios realizados por distintos usuarios y entre ejecuciones.	Los cambios se guardan automáticamente en `datos/condominio.dat`; al cerrar sesión se conserva el estado del sistema, pero la sesión activa no se guarda por seguridad.

Casos de uso principales

CU-01 · Crear reserva de espacio común

Actor: Conserje o Administrador. Precondición: sesión iniciada y departamento existente. Flujo: el usuario selecciona el espacio, la fecha y el departamento; el sistema verifica disponibilidad, crea la reserva, incorpora el costo de limpieza al gasto común y guarda los cambios. Resultado: la reserva aparece en el listado o se informa un conflicto de fecha.

CU-02 · Registrar y entregar un paquete

Actor: Conserje o Administrador. Precondición: sesión iniciada y departamento válido. Flujo: se registra la descripción del paquete y el sistema conserva la fecha de recepción y el responsable. Posteriormente se selecciona un paquete pendiente y se marca como entregado. Resultado: se registra fecha de entrega y cambia el estado visual del paquete.

CU-03 · Administrar residentes y conserjes

Actor: Administrador. Precondición: sesión iniciada como administrador. Flujo: selecciona un residente o conserje, actualiza sus datos o lo elimina. También puede agregar nuevos conserjes. Resultado: el sistema valida permisos, datos obligatorios y valores únicos relevantes antes de guardar.

CU-04 · Mantener cambios entre sesiones de usuario

Actores: Conserje y Administrador. Precondición: un primer usuario ha registrado o modificado un dato y luego cierra sesión. Flujo: un segundo usuario inicia sesión, ingresa al mismo módulo y consulta el registro creado o actualizado previamente. Resultado: los cambios permanecen disponibles para el nuevo usuario, respetando los permisos de cada rol.

Casos de prueba definidos desde los requerimientos

Prueba	Caso de uso	Datos de entrada	Resultado esperado
CP-01	CU-01	Quincho, fecha futura, departamento 101.	Se crea la reserva, se agrega el costo de limpieza y se actualiza el listado.
CP-02	CU-01	Mismo quincho y misma fecha de CP-01.	El sistema rechaza la operación e informa que el espacio ya está reservado.
CP-03	CU-02	Paquete para departamento 102; luego seleccionar el paquete.	Primero queda pendiente y luego aparece como entregado con fecha de entrega.
CP-04	CU-03	Administrador modifica el correo de un residente y agrega un conserje.	Los controles administrativos están disponibles y los cambios se conservan.
CP-05	CU-04	Un conserje registra un paquete; luego cierra sesión e ingresa un administrador.	El paquete registrado por el conserje permanece visible para el administrador, conservando su descripción, estado y responsable de recepción.

4. Diseño de alto nivel

La solución adopta una arquitectura simple por capas: la interfaz JavaFX captura las acciones del usuario; SistemaCondominio concentra la lógica del dominio y los permisos; las clases de entidad representan los datos; finalmente, el mecanismo de serialización conserva el estado en un archivo local. Esta separación evita que la interfaz implemente reglas de negocio críticas por sí sola.

Diagrama de clases UML

Diagrama UML de clases del sistema. — Figura 1. Diagrama de clases de alto nivel. Se destacan la herencia desde Persona, la especialización Admin de Conserje y la composición gestionada por SistemaCondominio.

Diagrama de secuencia: crear una reserva

Diagrama de secuencia para el caso de uso crear una reserva. — Figura 2. Secuencia del caso de uso CU-01. La validación de disponibilidad ocurre antes de generar cargos y guardar los cambios.

5. Implementación y documentación del código

El proyecto fue desarrollado en Java con interfaz gráfica JavaFX. Las clases de dominio están separadas de la interfaz y se utilizan colecciones Map y List para organizar los registros. La persistencia se implementó mediante serialización de Java: el sistema guarda el estado completo de las entidades en datos/condominio.dat después de cada operación relevante y ejecuta un guardado final al cerrar la aplicación.

El código fuente contiene comentarios y documentación Javadoc en las clases y métodos principales, especialmente en las reglas de persistencia, autenticación y autorización. No se incluyen los archivos HTML generados por Javadoc porque son derivados y redundantes respecto del código fuente.

Decisión de diseño: las validaciones de permisos se aplican dentro de SistemaCondominio, no solo ocultando controles en la interfaz. Así, un conserje no puede ejecutar una operación administrativa aun cuando una vista fuera modificada.

6. Pruebas, dificultades y bugs

Las capturas se obtuvieron desde la aplicación en ejecución. Para CP-05 se utiliza una prueba de continuidad entre usuarios: un conserje registra un paquete, cierra sesión y posteriormente un administrador ingresa al sistema para comprobar que el mismo registro continúa disponible.

Panel principal con sesión de Administrador activa.

Figura 3. Acceso por rol. El encabezado identifica al usuario Administrador como sesión activa. Además, el menú incluye el módulo “Administrar Conserjes”, disponible únicamente para este rol. Esta evidencia valida RF-01 y los permisos administrativos definidos en CU-03.

Reserva creada correctamente en el listado.

Figura 4. Reserva registrada. La lista muestra la reserva creada con su espacio, fecha, departamento y costo de limpieza. El resultado confirma la creación correcta de una reserva, correspondiente a la prueba CP-01.

Mensaje de error por conflicto de reserva.

Figura 5. Prevención de conflicto. El mensaje de error confirma que la regla de disponibilidad bloqueó una segunda reserva para el mismo espacio y fecha. Este resultado corresponde a la prueba CP-02.

Figura 6. Estado de paquetería. El paquete aparece marcado como entregado y registra la fecha de entrega. El cambio de estado confirma el resultado esperado para la prueba CP-03.

Vista de administración de conserjes para Administrador.

Figura 7. Permisos administrativos. La vista presenta las opciones para agregar, modificar y eliminar conserjes. Su disponibilidad durante una sesión de Administrador evidencia que estas operaciones se restringen a dicho rol, como se definió en CP-04.

Registro creado por un conserje y visible para un administrador.

Figura 8. Continuidad de cambios entre usuarios. El registro creado durante la sesión del conserje permanece disponible cuando el administrador inicia sesión y consulta el mismo módulo. Esto confirma la conservación de cambios entre usuarios establecida en CP-05.

Dificultades encontradas y cómo se resolvieron

Dificultad	Solución aplicada
Los datos se perdían al cerrar la aplicación.	Se implementó serialización de las entidades y guardado automático con un archivo temporal para reducir el riesgo de corrupción durante la escritura.
Los identificadores de paquetes, reservas y gastos comunes podían repetirse tras reiniciar.	Al cargar los datos se calcula el ID máximo almacenado y se restaura el contador estático con el siguiente valor disponible.
Un conserje podía ver las mismas pantallas que un administrador si se controlaba solo la interfaz.	Se agregó una clase `Admin` que hereda de `Conserje` y se validan permisos dentro de `SistemaCondominio`.
Se debía impedir que dos vecinos reservaran el mismo espacio y fecha.	Antes de crear la reserva, el sistema recorre las reservas existentes y rechaza la operación cuando coinciden espacio y fecha.
Se incorporó el rol Admin después de crear archivos persistidos por una versión anterior.	Al cargar un archivo previo, el sistema verifica si existe un administrador inicial y lo agrega sin borrar los datos anteriores.

Limitaciones y bugs conocidos de la versión actual

Al eliminar una reserva se conserva el cargo de limpieza ya agregado al gasto común, porque se interpreta como registro contable. Una futura mejora podría permitir anular el cargo según una política de cancelación.
Las contraseñas se almacenan como texto dentro del archivo serializado; para un sistema productivo deberían protegerse con hash y utilizar una base de datos con control de acceso.
La validación de RUT, correo electrónico, teléfono y fechas pasadas puede mejorarse con reglas de formato más estrictas.
La aplicación utiliza almacenamiento local, por lo que aún no permite acceso concurrente desde varios computadores.

7. Código fuente y contenido de la entrega

La versión comprimida del código fuente está incluida dentro de esta entrega y se puede descargar desde el siguiente enlace relativo:

Descargar código fuente comprimido del proyecto (.zip)

El archivo contiene solamente el código fuente escrito para el proyecto, el README.md y el Makefile. No contiene archivos compilados, configuraciones del IDE, datos locales persistidos ni código fuente externo. La dependencia externa utilizada es JavaFX Controls; su instalación mediante JavaFX SDK y VM options se explica en el README.