Este documento presenta el diseño e implementación de un sistema web para el monitoreo de faros y boyas meteorológicas en Venezuela. El sistema permite almacenar datos recibidos de las boyas, visualizar su ubicación en un mapa e inspeccionar gráficas estadísticas. El proyecto siguió la metodología RUP y utilizó herramientas como PostgreSQL, CakePHP y Linux. La interfaz diseñada ofrece funcionalidades como administración de usuarios, registro y consulta de datos, y monitoreo en tiempo real de las boyas
1. Diseño e Implementación de un
Sistema Web Para el Monitoreo
de Faros y Boyas
KAREN PIOTROWSKI
TUTOR ACADÉMICO: PROF. EDNA RUCKHAUS
TUTOR INDUSTRIAL: LIC. ZORELLY GONZÁLEZ
2. Agenda de la
presentación
I. Introducción
II. Objetivos
III. Alterinfo
IV. Conceptos teóricos
V. Herramientas
VI. Metodología
VII. Desarrollo
VIII. Video demostrativo
IX. Conclusiones
X. Preguntas
3. I. Introducción
• Las boyas meteorológicas:
• Delimitan áreas.
• Ayudan en la navegación.
• Permiten monitorear zonas costeras y
oceánicas.
• En Venezuela no se tiene:
• Un sistema de recolección y consulta de
datos meteorológicos.
• Registro de datos meteorológicos marítimos.
• Estudios climáticos del territorio marítimo.
4. I. Introducción
• Es por esto que surge la necesidad de
un sistema que permita:
• Recolección y almacenamiento de datos
meteorológicos.
• Despliegue de datos en una interfaz.
• Monitoreo de boyas a través de un mapa.
5. II. Objetivos de la pasantía
Desarrollo de una aplicación web para el Sistema de Monitoreo de Faros y
Boyas, que permita almacenar datos recibidos por boyas meteorológicas,
visualizar las boyas sobre un mapa y consultar gráficas de estadísticas de una
boya para una fecha determinada.
Objetivo general:
6. II. Objetivos de la pasantía
Objetivos específicos:
Diseño e implementación de la base de datos
Diseño e implementación de la interfaz de usuario
Generación de gráficas de estadísticas
7. II. Objetivos de la pasantía
Objetivos específicos:
Procesamiento automático de archivos de datos
Módulo administrativo
Envío de notificaciones al operador de las boyas
8. III. Alterinfo
Desarrollo de proyectos y servicios tecnológicos.
Experiencia en:
• Automatización y control industrial.
• Electrónica de potencia.
• Integración de sistemas.
• Seguridad informática.
• Firmas electrónicas.
9. III. Alterinfo
Dirección General
Dirección de
Gestión
Administrativa
Mercadeo Ventas
Dirección de Gestión
Comercial
Operaciones Mercadeo Ventas
Dirección de
Gestión Técnica
Proyectos Servicios
10. IV. Conceptos
teóricos
1. Arquitectura MVC
2. Convenciones sobre
configuraciones
3. Listas de Control de
Acceso
4. Particionamiento de
tablas
5. Índices
6. Diseño web
Responsive
7. Diseño de interfaz Flat
11. 1. Arquitectura MVC
2. Convenciones sobre
configuraciones
3. Listas de Control de
Acceso
4. Particionamiento de
tablas
5. Índices
6. Diseño web
Responsive
7. Diseño de interfaz Flat
Modelo
Vista Controlador
12. 1. Arquitectura MVC
2. Convenciones sobre
configuraciones
3. Listas de Control de
Acceso
4. Particionamiento de
tablas
5. Índices
6. Diseño web
Responsive
7. Diseño de interfaz Flat
Paradigma de diseño de software
Busca reducir la cantidad de decisiones que deben
tomar los desarrolladores
Con esto se gana simplicidad sin perder flexibilidad
13. 1. Arquitectura MVC
2. Convenciones sobre
configuraciones
3. Listas de Control de
Acceso
4. Particionamiento de
tablas
5. Índices
6. Diseño web
Responsive
7. Diseño de interfaz Flat
Paradigma de diseño de software
Busca reducir la cantidad de decisiones que deben
tomar los desarrolladores
Con esto se gana simplicidad sin perder flexibilidad
Access Request Objects (AROs)
• Objetos solicitantes
Access Control Objects (ACOs)
• Objetos solicitados
14. 1. Arquitectura MVC
2. Convenciones sobre
configuraciones
3. Listas de Control de
Acceso
4. Particionamiento de
tablas
5. Índices
6. Diseño web
Responsive
7. Diseño de interfaz Flat
División física de una tabla lógica en
fragmentos físicos disjuntos más pequeños
Beneficios:
◦ Mejor desempeño de ciertas consultas.
◦ La mayoría de los registros accedidos con
mayor frecuencia se encuentran en una
única partición o en unas pocas
particiones.
◦ Las inserciones o eliminaciones en bulk
pueden realizarse simplemente agregando
o eliminando una partición.
15. 1. Arquitectura MVC
2. Convenciones sobre
configuraciones
3. Listas de Control de
Acceso
4. Particionamiento de
tablas
5. Índices
6. Diseño web
Responsive
7. Diseño de interfaz Flat
Estructuras de acceso auxiliares
Aceleran la obtención de registros
Brindan formas alternativas para
acceder a los registros
No afectan la ubicación física de los
datos primarios en el disco
16. 1. Arquitectura MVC
2. Convenciones sobre
configuraciones
3. Listas de Control de
Acceso
4. Particionamiento de
tablas
5. Índices
6. Diseño web
Responsive
7. Diseño de interfaz Flat
17. 1. Arquitectura MVC
2. Convenciones sobre
configuraciones
3. Listas de Control de
Acceso
4. Particionamiento de
tablas
5. Índices
6. Diseño web
Responsive
7. Diseño de interfaz Flat
19. VI. Metodología
• Metodología de desarrollo de Software
• Orientada a Objetos
• Provee un plan específico para cada fase
• Evitar el desperdicio de recursos
• Reducir costos inesperados
RUP
Inicio Elaboración Construcción Transición
21. • Estudio de antecedentes.
• Identificación de los usuarios del sistema.
• Captura de requerimientos.
•Identificación de los casos de uso.
• Diagrama de casos de uso.
Fases:
1. Inicio
2. Elaboración
3. Construcción
22. • Estudio sobre otros sistemas en el mercado
• Buscar características similares
• Mejor perspectiva sobre cómo debería de
estructurarse este sistema
• Reforzar la importancia de la creación de este
sistema
Fases:
1. Inicio
2. Elaboración
3. Construcción
Investigación previa
23. Usuario de la Armada
Usuario Temporal
Administrador
Fases:
1. Inicio
2. Elaboración
3. Construcción
Usuarios del sistema
24. Fases:
1. Inicio
2. Elaboración
3. Construcción
• Selección de las herramientas
• Diseño de la base de datos
• Especificación de los CU
• Diagrama de clases
• Arquitectura del sistema
• Prototipo no funcional
25. Fases:
1. Inicio
2. Elaboración
◦ Diagrama ERE
◦ Arquitectura
3. Construcción
Buoyerrors
States
Types
Buoys
Users
GroupsAros
Acos
Months
Parameters
Buoyerrors Types
Buoys
Users
GroupsAros
Acos
26. Fases:
1. Inicio
2. Elaboración
◦ Diagrama ERE
◦ Arquitectura
3. Construcción
PostgreSQL
Modelo
Controlador
Vista
Dispatcher
Cliente
Command
(StatesShell)
Tasks
(AddStateTask)
Cron Jobs
Console
CakePHP
Linux
27. • Configuraciones iniciales y creación de la base de datos
• Generación de una estructura inicial del mismo
• Login, logout y CRUD para el usuario administrador
• Script para el particionamiento de la tabla de estados
• Integración de estilo a la interfaz de usuario
• Implementación de cada uno de los casos de uso
• Las tres capas de la arquitectura MVC
Fases:
1. Inicio
2. Elaboración
3. Construcción
a) Implementación
b) Pruebas
c) Documentación
¿En qué consistió esta etapa?
28. • Particionar la tabla de estados por rangos de un mes
• Documentación oficial de PostgreSQL
1. Creación de la tabla
2. Función que crea las particiones y los índices (Por ID de la
boya y por fecha)
3. Función que indica en qué partición deben insertarse los
nuevos registros
4. Trigger que ejecuta la función anterior luego de cada
inserción
Fases:
1. Inicio
2. Elaboración
3. Construcción
a) Implementación
b) Pruebas
c) Documentación
Particionamiento de tablas
33. • Almacenamiento de los datos
recibidos por las boyas.
• Archivos de texto
• Gnome Schedule -> Cron Jobs
• Es ejecutado por el Sistema Operativo
automáticamente en intervalos de una
hora
Fases:
1. Inicio
2. Elaboración
3. Construcción
a) Implementación
b) Pruebas
c) Documentación
Procesamiento de archivos
34. Fases:
1. Inicio
2. Elaboración
3. Construcción
a) Implementación
b) Pruebas
c) Documentación
• Sólo es enviado un correo
• Solicitud de actualización de boyas.
• Desplazamiento de boyas
Notificaciones
• Códigos recibidos desde las boyas
• No comprometen la veracidad de los datos
• Se asocian a los estados de las boyas
Alertas
• Códigos que indican que la boya presenta
fallas
• Los datos pueden no ser válidos
• Los archivos son descartados
Errores
36. Fases:
1. Inicio
2. Elaboración
3. Construcción
a) Implementación
b) Pruebas
c) Documentación
• Una clase de prueba para cada modelo
• PHPUnit
• Proceso iterativo
Pruebas
unitarias
• Datos de 150 boyas para 5 años
• Script de generación de datos aleatorios
• Más de 6 millones de registros
Pruebas
de estrés
• Recursividad en las consultas
• Tener los estados más recientes de las boyas
a la mano
• Creación de índices en las particiones
Correcciones
37. Documentación del código fuente
• Durante toda la etapa de implementación
• Asegurar la mantenibilidad
Manuales
• Manual de instalación y configuración
• Manual de administrador o desarrollador
• Manual de usuario
Fases:
1. Inicio
2. Elaboración
3. Construcción
a) Implementación
b) Pruebas
c) Documentación
40. IX. Conclusiones y recomendaciones
• Diseño e implementación de un sistema web para el monitoreo de
boyas
• Cambios en la perspectiva, nuevos requerimientos y maneras de
mejorar el rendimiento.
Trabajos futuros
• Zonificación de las boyas
• Caracterización de los datos
• Base de datos histórica