Gestión de recursos de una unidad de rescate en montaña

3 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADO EN INGENIERIA DE COMPUTADORES GESTION DE RECURSOS DE UNA UNIDAD DE RESCATE EN MONTAÑA RESOURCE MANAGEMENT UNIT MOUNTAIN RESCUE Realizado por Gabriel Moreno Pérez Tutorizado por Eduardo Guzmán de los Riscos Departamento Lenguajes y Ciencias de la Computación UNIVERSIDAD DE MÁLAGA MÁLAGA, Diciembre de 2015 Fecha defensa: El Secretario del Tribunal 4 5 Resumen: Este Trabajo de Fin de Grado va enfocado al desarrollo de un sistema eficaz para gestionar los recursos que componen una Unidad de Rescate en Montaña (URM). Estos recursos son tanto los medios humanos como los materiales, los primeros son los rescatadores, los segundos el material especializado que se emplea en las maniobras de rescate. Mantener información actualizada del estado del material es básico para garantizar la seguridad de las intervenciones de este tipo de unidad. Además saber qué cantidad, tipo y ubicación de dicho material, es básico documentar el empleo de este facilita la trazabilidad de su uso cumpliendo la normativa vigente que regula el trabajo en altura. Como modelo de forma de trabajo de una URM se tomará la perteneciente al Consorcio Provincial de Bomberos de Málaga (CPB Málaga). El sistema desarrollado es una aplicación web que bajo entorno Java Enterprise Edition (Java 2EE) que se ejecutará en un servidor Apache Tomcat y empleará una base de datos en MySql para almacenar la información, de esta forma se facilita el acceso distribuido de la gestión a los diferentes usuarios y el mantenimiento del sistema al estar todo centralizado, además de las ventajas que da un sistema desarrollado en Java que puede ser desplegado con independencia del sistema operativo empleado. Palabras claves: Unidad de Rescate en Montaña, Equipo de Protección Individual (EPI), Trabajo en Altura, Bomberos, Sistema distribuido, Java, Java EE, JSP, Servlet, Apache Tomcat, MySQL. Abstract: This Final Degree Work is focused on developing an effective system to manage the resources that make up a Mountain Rescue Unit (MRU). These resources are both material and human resources, the first are rescuers, the seconds specialized material used in rescue maneuvers. Keeping updated the state of the material information is essential to ensure the safety of interventions of this type of unit. Also knowing what amount, type and location of such material is basic document using this facilitates the traceability of its use complies with rules regulating the work force 6 in height. As a working model of how a URM it will taken one belonging to the Consorcio Provincial de Bomberos de Málaga (CPB Málaga) will be taken. The developed system is a web application on Java 2 Enterprise Edition (Java EE) that will run on an Apache Tomcat server environment and employ a database in MySQL to store information. Thus it facilitates distributed access management to different users and maintenance of the entire system to be centralized, in addition to the advantages that a system developed in Java which can be deployed independently of the operating system used. Keyworks: Mountain Rescue Unit, Personal Protective Equipment (PPE), Work at Height, Firefighters , Distributed System , Java , Java EE , JSP, servlet , Apache Tomcat , MySQL . 7 Contenido 1. Introducción ........................................................................................................................ 8 2. Tecnologías y herramientas utilizadas (breve descripción) ................................................. 9 3. Especificación y Análisis ................................................................................................... 10 4. Diseño del sistema ............................................................................................................ 33 5. Implementación y pruebas ................................................................................................ 37 I. Implementación de una vista ......................................................................................... 39 II. Servlets Controladores .................................................................................................. 41 III. Clases del modelo ...................................................................................................... 43 6. Conclusiones y Trabajos Futuros ...................................................................................... 48 7. Bibliografía ........................................................................................................................ 48 8. Apéndice A. Manual de Usuario ........................................................................................ 48 9. Apéndice B. Manual de Instalación ................................................................................... 73 8 1. Introducción Una Unidad de Rescate en Montaña (URM) es un grupo de especialistas dedicados profesionalmente al rescate en el medio natural. Este tipo de unidad habitualmente está compuesta por personal destinado de un Servicio de Prevención, Extinción de Incendios y Salvamento (SPEIS). Existen otros modelos pertenecientes a otros cuerpos de seguridad o incluso empresas privadas de dan este tipo de servicio. No obstante nos centraremos en aquellos pertenecientes a los SPEIS aunque este sistema puede ser empleado en cualquier tipo de unidad. Independientemente de la naturaleza de una URM, la forma de funcionamiento está determinada por el medio donde desempeñan sus intervenciones, el medio natural, este tipo de servicio cada vez es más demandado debido al aumento de actividades en montaña especialmente por motivaciones deportivas y turísticas. Como modelo tomaremos como modelo de funcionamiento una URM perteneciente a un SPEIS, en este caso a la del Consorcio Provincial de Bomberos de Málaga. Todo componente de un SPEIS cuenta con una formación, unos conocimientos y un equipamiento para dar servicios de rescate en el medio natural, si de esos miembros de un SPEIS se selecciona un grupo y se especializa más en este tipo de intervención mediante formación y material más específico se crea una URM más eficaz para dar respuesta a emergencias en montaña. Debido a la gran cantidad de información que se genera alrededor de este tipo de especialidad y la necesidad de disponer de ésta se desarrolla este sistema de Gestión de Recursos que facilita realizar de forma más eficaz tareas básicas necesarias para el correcto funcionamiento de la URM. La gestión del material empleado en una URM es básica, especialmente en lo relativo a los Equipos de Protección Individual (EPIs), es necesario llevar una trazabilidad del material, conocer su homologación, saber su uso y estado, sus periodos de revisiones y fechas de caducidad, todo motivado por las normas de trabajo en altura que son las que rigen este tipo de actividad. 9 La gestión de las intervenciones es manejar fuentes de información donde se integran los elementos principales de una URM que son el personal perteneciente a ella y el material empleado, con todo esto se obtiene directamente información de lugares sensibles y estadísticas de la tipología del rescate con la que se pueden generar mapas de riesgos e isócronas (tiempos de respuestas) para posibles intervenciones. El objetivo de este proyecto es el desarrollo de un sistema distribuido que pueda realizar el anterior tipo de gestiones que se ha descrito. Como se ha comentado una URM es una parte de un SPEIS, por tanto un subconjunto de personal y de material y de tipos de intervenciones, no es conocido algún sistema que integre toda una gestión para este tipo de servicios, habitualmente se emplea información impreso en papel y documentos redactados por aplicaciones de ofimática, esto genera mucha información redundante y repetida siendo inmanejable un correcto mantenimiento, cierto es que algunos fabricantes de material pueden aportar software de gestión de sus productos pero no tienen en cuenta la integración de toda o gran parte de la información que se ha de gestionar. El sistema se deja abierto para que sea escalable y pueda emplearse en cualquier ámbito de un SPEIS, que básicamente serán intervenciones que emplearán equipamiento específico y su personal. 2. Tecnologías y herramientas utilizadas. El sistema está implementado como una aplicación web utilizando tecnología Java Enterprise Edition (Java EE) con una base de datos relacional contenida en un gestor de base de datos MySql. La ventaja del empleo de Java EE es la independencia de la plataforma donde se ejecuta el sistema y la facilidad del acceso distribuido a ésta, con un simple navegador web se accede, la actualización y el mantenimiento es fácil, solo se tiene que actuar en el servidor donde se encuentre ubicada la aplicación y la base de datos. Para las fases de especificación, análisis y diseño se ha empleado MagicDraw UML, una herramienta para implementar gráficamente diagramas UML que modelan el comportamiento del sistema. 10 Para el desarrollo del sistema de ha empleado el entorno NetBeans 8.0.1, este entorno facilita la integración con el servidor de aplicaciones y el gestor de base de datos necesarios para la ejecución del sistema durante el proceso de implementación. Para el despliegue de la aplicación se ha empleado Apache Tomcat 8.0.28, no obstante cualquier servidor de aplicaciones Java EE puede contener el sistema. El gestor de base de datos es MySql Server 5.5, para acceder a este mediante Java se emplea drivers JDBC que proporciona la funcionalidad necesaria. 3. Especificación y Análisis Mediante los siguientes casos de uso se especifica el modelado del sistema, cada caso de uso describe un requisito funcional. Se ha distinguido en dos tipos de actores en función del tipo de usuario que interacciona con el sistema: • Usuarios Administradores: son aquellos usuarios que tienen acceso a toda la funcionalidad del sistema, realizan consultas, altas y modificaciones de la información. • Usuarios Consulta: son aquellos usuarios que tienen acceso a toda la información en modo de consulta pero con acceso restringido a modificaciones de la información del sistema. Estos usuarios una vez validados podrán interaccionar con el sistema, poseen un perfil utilizado para poder limitar o permitir el uso de las distintas funciones disponibles. El siguiente diagrama de casos de uso muestra la funcionalidad disponible para cada tipo de actor: 11 Figura 1. Actores y casos de uso. Casos de Uso Login Contexto El usuario accederá al sistema mediante previa validación mediante su login y su password. Actores Administradores y usuarios consulta. Precondiciones El usuario debe estar registrado en el sistema. Garantías mínimas Mensaje de error de validación. Garantías de éxito Creación de sesión de usuario y acceso al sistema. Escenario de éxito principal 1. El usuario introduce su login y su password. 2. El sistema comprueba la validez del login y del password. 3. Se crea la sesión de usuario. 4. Se muestra la pantalla principal del sistema. Extensiones Se genera error de validación y se muestra por pantalla. 18 Figura 7. Caso de Uso de alta en inventario. Caso de Uso Búsqueda en Inventario. Contexto El usuario buscará materiales en el catálogo. Actores Administradores y Usuarios Consulta. Precondiciones El usuario debe estar validado en el sistema, la sesión creada y tener permisos de consulta. Garantías mínimas Mensaje de error de no tener resultados de búsqueda en el inventario. Garantías de éxito Datos del material buscado en el inventario. Escenario de éxito principal 1. El usuario accede a la pantalla de búsqueda de material en inventario. 2. El sistema muestra pantalla con campos de búsqueda. 3. El usuario selecciona los campos para realizar la búsqueda. 4. El sistema accede a BBDD y recupera un listado del material inventariado coincidente con la búsqueda 5. Se muestra pantalla de listado del resultado de la búsqueda. 6. El usuario selecciona el material inventariado buscado y se mostrará los datos relativos a éste. Extensiones Se genera mensaje de no recuperar material 19 inventariado y se muestra por pantalla Figura 8. Caso de Uso de búsqueda en inventario. Caso de Uso Editar en Inventario. Contexto El usuario administrador buscará y editará los datos relacionados con un material inventariado. Actores Administradores. Precondiciones 1. El usuario debe estar validado en el sistema, la sesión creada y tener permisos de consulta y modificación. 2. El material a editar debe estar inventariado. Garantías mínimas Mensaje de error de no tener resultados de búsqueda en el inventario. Garantías de éxito Modificación del material inventariado. Escenario de éxito principal 1. El usuario accede a la pantalla de búsqueda de material en inventario. 2. El sistema muestra pantalla con campos de búsqueda. 3. El usuario selecciona los campos para realizar la búsqueda. 4. El sistema accede a BBDD y recupera un listado del material inventariado coincidente con la búsqueda 5. Se muestra pantalla de listado del resultado de la 20 búsqueda. 6. El usuario selecciona el material inventariado a editar. 7. El usuario introduce los datos a modificar del material inventariado. 8. El sistema comprueba la validez actualiza el material inventariado en BBDD. 9. Se muestra mensaje de confirmación de la correcta edición. Extensiones Se genera mensaje de no recuperar material inventariado y se muestra por pantalla. Figura 9. Caso de Uso de editar en inventario. Caso de Uso Alta Revisión de Material. Contexto El usuario administrador y los usuarios de consulta realizarán revisiones de material. Existirán revisiones e inspecciones: 1. Revisión, se hace con cierta periodicidad. 2. Inspección, se hace tras el uso en una actividad. Actores Administradores y Usuarios de Consulta. Precondiciones 1. El usuario debe estar validado en el sistema, la sesión creada y tener permisos de consulta y modificación. 2. El material a revisar debe estar inventariado. 3. El material debe tener número de serie. Garantías mínimas Alta de revisión de material. Garantías de éxito Alta de revisión de material. Escenario de éxito principal 1. El usuario accede a la pantalla de búsqueda de material en inventario. 21 2. El sistema muestra pantalla con campos de búsqueda. 3. El usuario selecciona los campos para realizar la búsqueda. 4. El sistema accede a BBDD y recupera un listado del material inventariado coincidente con la búsqueda 5. Se muestra pantalla de listado del resultado de la búsqueda. 6. El usuario selecciona el material inventariado a realizar la revisión. 7. Se mostrará los datos del material y se dará de alta una revisión, para ello habrá dos formas: a. Desde el listado de histórico de revisiones, de esta forma se generarán revisiones o inspecciones. b. Desde el listado de intervenciones donde se emplee el material. 8. El sistema comprueba la validez y registrará la revisión en BBDD. Extensiones Figura 10. Caso de Uso de alta revisión de material. Caso de Uso Edición Revisión de Material. Contexto El usuario administrador y los usuarios de consulta realizarán revisiones de material. Actores Administradores y Usuarios de Consulta. Precondiciones 1. El usuario debe estar validado en el sistema, la sesión creada y tener permisos de consulta y 22 modificación. 2. Debe existir en BBDD la revisión a modificar. 3. El usuario consulta sólo podrá editar las revisiones que ha creado. Garantías mínimas Modificación de revisión de material. Garantías de éxito Modificación de revisión de material. Escenario de éxito principal 1. El usuario accede a la pantalla de búsqueda de material en inventario. 2. El sistema muestra pantalla con campos de búsqueda. 3. El usuario selecciona los campos para realizar la búsqueda. 4. El sistema accede a BBDD y recupera un listado del material inventariado coincidente con la búsqueda 5. Se muestra pantalla de listado del resultado de la búsqueda. 6. El usuario selecciona el material inventariado a realizar la revisión. 9. Se mostrará los datos del material y se seleccionará la revisión a editar. 10. Se mostrará los datos de la revisión de material a modificar 11. El sistema comprueba la validez y actualizará la revisión en BBDD. Extensiones Figura 11. Caso de Uso de edición de revisión de material. 23 Caso de Uso Alta de Personal. Contexto El usuario administrador dará de alta un nuevo personal. Actores Administradores. Precondiciones El usuario debe estar validado en el sistema, la sesión creada y tener permisos de administración. Garantías mínimas Mensaje de error de personal registrado. Garantías de éxito Alta de nuevo personal. Escenario de éxito principal 1. El usuario introduce los datos del personal a registrar. 2. El sistema comprueba la validez y muestra pantalla de asignar equipo personal. 3. El usuario selecciona el o los equipos disponibles. 4. El sistema registra el nuevo personal en BBDD. 5. Se muestra pantalla confirmación de alta correcta. Extensiones Se genera error personal ya registrado y se muestra por pantalla. Figura 12. Caso de Uso de alta de personal. Caso de Uso Búsqueda de Personal. Contexto El usuario buscará personal registrado. Actores Administradores y Usuarios Consulta. Precondiciones El usuario debe estar validado en el sistema, la sesión creada y tener permisos de consulta. Garantías mínimas Mensaje de error de no tener resultados de búsqueda de personal. Garantías de éxito Datos del personal buscado. 24 Escenario de éxito principal 1. El usuario accede a la pantalla de búsqueda de personal. 2. El sistema muestra pantalla con campos de búsqueda. 3. El usuario selecciona los campos para realizar la búsqueda. 4. El sistema accede a BBDD y recupera un listado del personal coincidente con la búsqueda 5. Se muestra pantalla de listado del resultado de la búsqueda. 6. El usuario selecciona el personal buscado y se mostrará los datos relativos a éste. Extensiones Se genera mensaje de no recuperar personal y se muestra por pantalla Figura 13. Caso de Uso de búsqueda de personal. Caso de Uso Editar Personal. Contexto El usuario administrador buscará y editará los datos relacionados con un personal. Actores Administradores. Precondiciones 1. El usuario debe estar validado en el sistema, la sesión creada y tener permisos de consulta y modificación. 2. El personal a editar debe estar registrado. Garantías mínimas Mensaje de error de no tener resultados de búsqueda del personal. 25 Garantías de éxito Modificación de datos del personal. Escenario de éxito principal 1. El usuario accede a la pantalla de búsqueda de personal. 2. El sistema muestra pantalla con campos de búsqueda. 3. El usuario selecciona los campos para realizar la búsqueda. 4. El sistema accede a BBDD y recupera un listado del personal coincidente con la búsqueda 5. Se muestra pantalla de listado del resultado de la búsqueda. 6. El usuario selecciona el personal a editar. 7. El usuario introduce los datos a modificar del personal. 8. El sistema comprueba la validez y actualiza los datos del personal en BBDD. 9. Se muestra mensaje de confirmación de la correcta edición. Extensiones Se genera mensaje de no recuperar personal y se muestra por pantalla. Figura 14. Caso de Uso de editar personal. Caso de Uso Alta de parte de actividad. Contexto El usuario administrador dará de alta un parte de actividad. Actores Administradores. Precondiciones El usuario debe estar validado en el sistema, la 26 sesión creada y tener permisos de administración. Garantías mínimas Alta de nuevo parte de actividad. Garantías de éxito Alta de nuevo parte de actividad. Escenario de éxito principal 1. El usuario introduce los datos generales del parte de actividad. 2. El usuario buscará el personal interviniente. 3. El sistema mostrará el listado de personal. 4. El usuario seleccionará el personal interviniente y asignará el rango horario de participación en la actividad. 5. El usuario buscará el material a emplear. 6. El sistema mostrará listado del material disponible. 7. El usuario seleccionará el material de la actividad. 8. El sistema registrará en BBDD el nuevo parte de actividad. 9. El sistema mostrará pantalla con detalle del nuevo parte de actividad y la posibilidad de adjuntar ficheros. Extensiones Figura 15. Caso de Uso de alta parte de actividad. Caso de Uso Búsqueda de Parte de Actividad. Contexto El usuario buscará Parte de Actividad Actores Administradores y Usuarios Consulta. Precondiciones El usuario debe estar validado en el sistema, la sesión creada y tener permisos de consulta. Garantías mínimas Mensaje de error de no tener resultados de búsqueda 27 de parte de actividad. Garantías de éxito Datos del parte de actividad buscado. Escenario de éxito principal 1. El usuario accede a la pantalla de búsqueda de parte de actividad. 2. El sistema muestra pantalla con campos de búsqueda. 3. El usuario selecciona los campos para realizar la búsqueda. 4. El sistema accede a BBDD y recupera un listado de partes de actividad coincidente con la búsqueda 5. Se muestra pantalla de listado del resultado de la búsqueda. 6. El usuario selecciona el parte buscado y se mostrará los datos relativos a éste. Extensiones Se genera mensaje de no recuperar parte de actividad y se muestra por pantalla. Figura 16. Caso de Uso de búsqueda de parte de actividad. Caso de Uso Edición de parte de actividad. Contexto El usuario administrador editará un parte de actividad. Actores Administradores. Precondiciones 1. El usuario debe estar validado en el sistema, la sesión creada y tener permisos de administración. 2. El parte de actividad debe existir. Garantías mínimas Edición de parte de actividad. Garantías de éxito Edición de parte de actividad. 34 usuario. El servlet controlador hará uso de una factoría de clases para instanciar la clase del comando solicitado. Figura 22. Patrón Comando. La arquitectura facilita la escalabilidad. La creación de nuevos módulos funcionales implica la creación de las vistas con su correspondiente controlador de módulo y sus comandos. Los módulos funcionales del sistema son los siguientes: 1. Material, se gestiona el catálogo e inventario de material. 2. Zonas, se gestiona el personal asignado a cada zona. 3. Actividades, se gestiona las actividades desarrolladas por la unidad. La funcionalidad de cada módulo está contenida en paquetes independientes con sus distintos comandos y acciones tales como acceso a base de datos y al sistema de archivo. Toda la infraestructura del patrón comando se encapsula un componente que dará servicio a cada módulo funcional A su vez se dispone de componentes con clases para dar soporte a los módulos funcionales, validación en el sistema, acceso a base de datos, y archivos de logs. 35 Figura 23. Clases del Modelo. Las principales entidades que componen el sistema interaccionan entre sí de la siguiente forma: Figura 24. Entidades del sistema y sus relaciones. Cada entidad se encuentra encapsulada en clases tipo JavaBeans facilitando así su reutilización y un mejor control de sus propiedades que será la información almacenada de forma persistente en base de datos. Las clases del modelo hacen uso de estos beans interaccionar con la base de datos tanto para la recuperación como la actualización de la información contenida en esta. Un ejemplo de JavaBeans es la clase PersonalBean representa a un miembro de la URM donde sus atributos contienen información relativa de éste, tales como nombre y apellidos, número profesional y fecha desde que pertenece a la unidad, material asignado e intervenciones en las que ha participado. 36 Figura 25. Beans que representa las entidades del modelo. El sistema utiliza MySql como gestor de base de datos. Cada módulo funcional tendrá clases de acceso a las tablas que almacenan la información que serán empleadas por las clases comando. La gestión de conexión a la base de datos se realizará a través de un pool de conexión que proporciona el servidor de aplicaciones que contendrá la aplicación web. El mismo gestor contiene la base de datos empleada por el componente de identificación utilizado para validarse en el sistema. Las tablas contendrán información relativa al usuario, como el perfil, que en función de este se podrá limitar las distintas opciones disponibles en el sistema. El modelo Entidad Relación de la base de datos del sistema es el siguiente: 37 Figura 26. Modelo Entidad Relación de la Base de Datos. El modelo Entidad Relación del componente de validación es el siguiente: Figura 27. Modelo Entidad Relación del componente de validación. 5. Implementación y pruebas El desarrollo del sistema se ha organizado en función de la estructura del patrón Modelo Vista Controlador. Se han agrupado las vistas, los controladores y las clases del modelo en función del módulo que corresponde, así queda bien estructurada 38 como aplicación web para ser desplegada en un servidor de aplicaciones que soporte Java EE. Mediante el archivo modulos.xml se registran las vistas, los controladores, las clases comando y la factoría de clases que las instancia y forman parte de un módulo funcional. Todo módulo debe registrar esa información en este archivo, por ejemplo, el módulo correspondiente a la gestión de zonas tendría las siguientes entradas: <!-- MÓDULO DE ZONAS --> <modulo codigo="zona"> <controlador paquete="gestorParques.main.servlet" clase="GestionZonasServlet"/> <factoria paquete="gestorParques.main.serverclasses.zonas" clase="FactoriaGestionZonas"> <comandos> <comando codigo="get_zonas" clase="GetZonasCMD"/> <comando codigo="ver_zona" clase="VerZonaCMD"/> <comando codigo="ver_parque" clase="VerParqueCMD"/> <comando codigo="alta_personal" clase="AltaPersonalCMD"/> <comando codigo="alta_persoequ" clase="AltaPersonalEquiposCMD"/> <comando codigo="reg_personal" clase="RegPersonalCMD"/> <comando codigo="list_personal" clase="ListPersonalCMD"/> <comando codigo="get_personal" clase="GetPersonalCMD"/> <comando codigo="deta_personal" clase="DetaPersonalCMD"/> <comando codigo="edit_personal" clase="EditPersonalCMD"/> <comando codigo="mod_personal" clase="ModPersonalCMD"/> <comando codigo="ver_parte" clase="VerParteCMD"/> <comando codigo="ver_equipo" clase="VerEquipoPersonalCMD"/> </comandos> </factoria> <vistas directorio="zonas"> <vista codigo="list_zonas" pagina="gestorParques_listadoZonas.jsp"/> 39 <vista codigo="deta_zona" pagina="gestorParques_detalleZona.jsp"/> <vista codigo="deta_parque" pagina="gestorParques_detalleParque.jsp"/> <vista codigo="alta_personal" pagina="gestorParques_altaPersonal.jsp"/> <vista codigo="alta_persoequ" pagina="gestorParques_altaPersonalEqu.jsp"/> <vista codigo="buscar_personal" pagina="gestorParques_buscarPersonal.jsp"/> <vista codigo="listado_personal" pagina="gestorParques_listadoPersonal.jsp"/> <vista codigo="deta_personal" pagina="gestorParques_detallePersonal.jsp"/> </vistas> </modulo> I. Implementación de una vista Una vista es implementada por un JSP estructurado de la siguiente forma: • Una cabecera donde aparecerá el login del usuario validado, botones para ir al inicio y para cerrar la sesión. Si se trata de la primera vista previa a la validación aparecerá controles para que el usuario se valide en el sistema. • Un menú de opciones que estará condicionado por el perfil del usuario, de forma que en función de los privilegios de éste podrá realizar ciertas operaciones. • Un área de contenido que contendrá la funcionalidad específica de la vista. Todas las vistas mantienen esa estructura. Se emplea JavaScript para controlar desde la parte del cliente que la información introducida en el área de contenido sea coherente. Existe una librería Javascript con funcionalidad común para todas las vistas. Para la implementación de la vista además se utilizan taglist que estructuran de mejor forma el código y facilitan la reusabilidad entre otros JSP. Un taglist hace referencia a una clase Java que aporta información común para todas las vistas, por ejemplo, un taglist que recupera todas las marcas de materiales disponibles en el sistema, para ello existen un clases que acceden a base de datos para obtener esa información y las cachea en memoria mediante una estructura accesible por cada vista gracias al taglist. 40 Figura 28. Estructura de vista generada por JSP. Una de las primeras acciones de un JSP al ser ejecutado es ver la validez de la sesión, en caso existir se continúa con su operativa. El área de contenido está estructurada por un formulario principal que invocará al servlet controlador que le corresponda, le enviará el comando a ejecutar junto a los parámetros necesarios, por ejemplo: <form method="post" action="/GestionMaterialServlet" name="registrarMaterial" onSubmit="return(peticionUnica());"> <input type="hidden" name="<%=NavegacionBean.MODULO_COMANDO%>" value="material"> <input type="hidden" name="<%=NavegacionBean.COMANDO%>" value="reg_catalogo "> ………………………………………………………………………………………………………………………………………….. </form> La anterior llamada en método action del formulario se invocará el servlet controlador GestionMaterialServlet y se le enviará cuál será el comando a ejecutar, en este caso el codificado por “reg_ catalogo”, y el módulo a que pertenece, en este caso al de material. El comando “reg_catalogo” tendrá en el servidor una clase correspondiente en Java que realizará la operativa necesaria. Observar que el valor “reg_material” en el archivo modulos.xml hace referencia la clase del comando a ejecutar: <!-- MÓDULO DE MATERIAL --> <modulo codigo="material"> 41 <controlador paquete="gestorParques.main.servlet" clase="GestionMaterialServlet"/> <factoria paquete="gestorParques.main.serverclasses.material" clase="FactoriaGestionMaterial"> <comandos> …………………………………………………………………………………………........................... <comando codigo="reg_catalogo" clase="RegMaterialCatalogoCMD"/> ………………………………………………………………………………………………………………. </comandos> </factoria> ……………………………………………………………………………………………………………………… </modulo> Todas las vistas están agrupadas en diferentes directorios dentro de la estructura de la aplicación web en función del módulo a que pertenece. II. Servlets Controladores Cada módulo posee un servlet controlador con el que una vista interacciona. Estos servlets controladores se encuentran registrados en el archivo web.xml del directorio WEB-INF de cualquier aplicación Java EE. Como se vio en el apartado de diseño, estos servlets controladores extienden del BaseServlet de Framework empleado. Prácticamente toda la funcionalidad es común entre cada controlador con la salvedad que cada uno distingue el módulo que controla, de esa forma se acceden a las vistas y comandos que les corresponde. Una vez invocado un servlet controlador por una vista, éste se identifica indicando qué módulo controla y posteriormente se invoca su método post public class GestionIntervencionServlet extends BaseServlet { public String identidad() { return("intervencion"); } } El método post implementado en BaseServlet invoca al método procesar () pasándole como parámetros los objetos request y response de la llamada HTTP. En ese método se comprueba cual es el comando solicitado por la vista, a través de la factoría de comandos de instancia la clase correspondiente al comando, y se invoca al método ejecutar () de dicho comando: 42 private void procesar(HttpServletRequest request,HttpServletResponse response) throws ServletException,IOException { try { // Obtención de la factoría de comandos propia del módulo funcional FactoriaComandos factoria = obtenerFactoria(); if (factoria == null) { throw(new Exception()); } // Obtención del comando a ejecutar a partir del código de operación indicado. Comando cmd = factoria.obtenerComando(entrada.getNavegacion().getComand o()); if (cmd == null) { throw(new Exception()); } // Obtención de un bean de salida tras ejecutar el comando con los parámetros entrada. salida = cmd.ejecutar(entrada); } catch(Exception e) { salida = errorEjecucion(entrada); } // Se emite la respuesta a la peticion HTTP. responderPeticion(request,response,salida); } A continuación se muestra el código del método obtenerComando() que emplea una factoría de clases para instanciar un comando. Recibe como parámetro el código del comando solicitado. public Comando obtenerComando(String operacion) { Comando comando = null; try { String nombreClase = (String)comandos.get(operacion); -> comandos es un Hashmap que mapea modulos.xml Class clase = Class.forName(nombreClase); comando = (Comando)clase.newInstance(); } catch(Exception e) { comando = null; } return(comando); } 43 III. Clases del modelo Las clases del modelo se encuentran agrupadas en paquetes independientes en función del módulo a las que pertenece. Podemos distinguir clases comando y clases auxiliares, estas últimas son, por ejemplo, aquellas que tienen funcionalidad para el acceso a la base de datos. Un comando implementa la interfaz Comando del Framework, tal interfaz tiene el método abstracto ejecutar() que debe ser implementado en el correspondiente comando. package framework.main.serverclasses.general; public interface Comando { /** * Método a implementar por todas las clases que actúen como * <i>comandos</i>. * @param datosEntrada Bean con los datos * requeridos para las tareas de procesamiento que ha de * llevar a cabo el comando. * @return Bean con los datos resultado del procesamiento. */ public abstract DatosComandoBean ejecutar(DatosComandoBean datosEntrada); } La clase DatosComandoBean es un bean que contiene tanto los parámetros necesarios para la ejecución del comando, como los resultados generados por éste, en general estos datos serán los existentes en la sesión de usuario, los de la petición http, y los de la navegación, estos últimos contienen los resultados y la vista a mostrar al usuario del sistema. Un comando podrá finalizar de forma exitosa (lo deseado) o errónea, para ello implementa métodos privados que realizarán las acciones a tomar según sea el caso, sólo existe un método en caso de éxito, mientras que en función de la naturaleza del error, existirán distintos métodos que manejen el error. A continuación se muestra el código del comando AltaCatalogoCMD, perteneciente al módulo de material, cuya función es de mostrar la vista de creación de un nuevo material en el catálogo, se trata de un comando bastante básico pero que sigue la estructura empleada en este tipo de clase. /** * Muestra formulario alta de material en catalogo * @author Gabi */ public class AltaCatalogoCMD implements Comando { /** 50 Tras esto aparecerá la pantalla de inicio, para acceder al sistema es necesario disponer de un usuario y una clave válida, a su vez el usuario tendrá un perfil válido que le permitirá realizar distintas acciones: Pantalla de validación. Un usuario puede tener perfil de administrador o de consulta: • Perfil de administrador, podrán realizar modificaciones sobre la información del sistema. • Perfil de consulta, el más restrictivo, realizará sólo consultas de los datos salvo la excepción de poder crear revisiones de material. Una vez validado en el sistema se muestra la pantalla de inicio. En ella se muestra en la parte superior una cabecera con controles para cerrar la sesión y volver a la página de inicio. Además se informa del login del usuario registrado. A la izquierda aparece las opciones disponibles sobre cada módulo funcional, y en la parte central un listado de las zonas donde la URM tiene personal y material asignado. Las opciones disponibles son las siguientes: 1. Gestión de Material a. Alta en Catálogo b. Catálogo c. Alta en Inventario. d. Inventario. 2. Gestión de Zonas a. Zonas. 51 b. Ata de personal. c. Personal 3. Gestión de Actividades. a. Alta de Parte. b. Partes. La pantalla inicial coincide con la opción Zonas de la gestión de zonas, se muestra un listado con las zonas de la provincia de Málaga donde están asignadas a los componentes de la URM. Pantalla de inicio. Módulo de Gestión de Material La gestión de material se basa en dos conceptos, catálogo e inventario: • Catálogo, está compuesto por material de rescate que puede disponer la unidad, no implica a que se disponga de éste. • Inventario, es todo el material perteneciente al catálogo que existe físicamente en la unidad. Para que un material pueda ser inventariado, debe estar previamente catalogado. A continuación se detallará la funcionalidad disponible de este módulo, todas accesibles desde el menú desplegable de Gestión de Material. 52 Alta en Catálogo: Para poder acceder a esta opción, el usuario tendrá que disponer de permisos de edición. Esto quiere decir que podrá realizar acciones administrativas de modificación y eliminación de datos del sistema. El alta se realiza en dos pasos, uno donde se introducen los datos generales del material, y otro donde se agregan las certificaciones que cumplen en función de la categoría del material. Tras esto, se pueden añadir archivos adjuntos de imágenes y documentos en formato JPEG y PDF respectivamente para complementar la información. Todo material catalogado es de un tipo y pertenece a una categoría. El sistema está configurado para material del tipo Rescate en Altura y las categorías disponibles de esta tipología. Pantalla de alta en catálogo Los campos de esta pantalla son los siguientes: • Nombre: nombre comercial del material, campo obligatorio. • Marca: marca del material, seleccionado desde un desplegable, campo obligatorio. • Tipo: tipo del material, seleccionado desde un desplegable, campo obligatorio. • Categoría: categoría en función del tipo de material, seleccionado desde un desplegable, campo no obligatorio. • Descripción: breve descripción del material, campo obligatorio. 53 Al pulsar el botón continuar, aparece la pantalla de petición de certificaciones, tales certificaciones serán las que cumple la categoría del material que se va a crear. Si el material no cumple certificación se podrá continuar finalizando su alta en el sistema. Tras el alta, se muestra una pantalla con los datos del material y la posibilidad de adjuntar archivos que complemente la información de éste. Petición de certificaciones. Pantalla de detalle de material. 54 Catálogo. Búsqueda, listado y edición de material del catálogo, cualquier usuario puede acceder a esta opción salvo la opción de edición que realiza modificaciones. Mediante un formulario inicial se solicitan campos de búsqueda para poder filtrar resultados, para realizar una búsqueda es necesario al menos indicar el tipo de material. El resultado de la búsqueda se muestra como un listado de forma que podrá acceder desde ahí al detalle del material que se mostrará una pantalla con toda la información relativa a éste, y con la posibilidad de realizar modificaciones siempre y cuando el usuario tenga permisos de edición: Pantalla de búsqueda con filtro. 55 Listado resultado de la búsqueda. Detalle del material con botón de modificación. El proceso de edición (modificación) es similar a los pasos de alta en catálogo. Alta en Inventario Como se ha comentado, un alta en inventario implica que el material a inventariar ha de estar catalogado. Para ello al seleccionar esta opción aparecerá la misma pantalla de búsqueda en catálogo con sus correspondientes campos para filtrar y 56 hacer más certera la búsqueda. El resultado será un listado donde aparecerá el material a inventariar y tendrá asociado un botón de alta. También se podrá realizar un alta si sacamos el detalle ya que aparecerá otro botón de alta: Alta desde listado. Alta desde detalle de material. Una vez pulsada el alta se nos muestra un formulario para configurar información relacionada con la forma del proceso de alta en inventario, como por ejemplo, dar múltiples altas de un mismo tipo de material catalogado. 57 Pantalla inicial de alta en inventario. Los campos (todos obligatorios) para configurar el alta son los siguientes: • Número de altas, un desplegable para seleccionar el número de elementos que se darán de alta simultáneamente, • Con número de serie, el material a inventariar posee un número de serie que lo identifica de forma unívoca del resto de material. • Con mes/año de fabricación, el material a inventariar tiene fecha de fabricación. • Con año de caducidad, el material a inventariar tiene año de caducidad. • Zona, será la zona a que pertenecerá el material inventariado. • Clase de material, el material a inventariar podrá ser de uso individual (asignado a un equipo personal) o de uso colectivo. Al pulsar el botón continuar se mostrará la pantalla donde se introducirán los datos propios del material a inventariar. En la siguiente pantalla se muestra cómo se darían de alta en el inventario dos elementos: 58 Pantalla de alta en inventario. Para facilitar completar los campos del formulario, se pueden replicar los valores de las fechas de todos los elementos a dar de alta en el inventario. Para ello existe en el primer elemento a inventariar el check “Replicar valores”. Todos los campos salvo la observación son obligatorios. Existe un check para productos del fabricante Petzl donde la fecha de fabricación se obtiene de forma automática por el número de serie, por ejemplo, 14161CE8752, los dos primeros dígitos 14, indican el año (2014), y los tres siguientes, 161, el día del año, que corresponde al mes de junio, se genera como mes y año de fabricación 06/2014. La finalización del alta en inventario concluye con un mensaje de éxito en caso de todo correcto, o de error en caso de ocurrir algún problema. Todo material inventariado tendrá inicialmente un estado de alta. Existe un caso particular para las altas de cuerdas y repartidores de carga, este tipo de material es muy sensible y requiere un mantenimiento bastante exhaustivo. Tanto una cuerda como un repartidor poseen una longitud, además una cuerda puede ser nueva o el resultado de partir una cuerda existente en el inventario y por circunstancias, por ejemplo, un roce, debe ser cortada y de ahí pueden crearse nuevos tramos de cuerda útiles. En este caso, durante el proceso de alta se selecciona que la cuerda no será nueva, la pantalla de alta mostrará las cuerdas 59 disponibles para ser cortada y generar tantas cuerdas como previamente se ha seleccionado: Alta de cuerda a partir de una inventariada. Se seleccionará la cuerda origen y se asignará el código y los metros de las cuerdas a inventariar. Se hace un control que la suma de los metros de las nuevas cuerdas no superen a la de la cuerda original. Una vez finalizada el alta la cuerda origen pasará al estado de baja y las cuerdas generadas mantendrán las fechas de compra, caducidad y puesta en servicio de la cuerda padre. Inventario. Con esta opción de menú los usuarios podrán realizar búsquedas, modificaciones del inventario de material y altas de revisiones de material inventariado. Al igual que la opción de Catálogo, para poder realizar ediciones el usuario debe tener un perfil adecuado para ello. 66 Alta de Personal Se muestra pantalla con formulario de alta para un nuevo miembro de la URM. Sólo un usuario con perfil de administrador podrá realizar altas de personal. Alta de personal Los campos del formulario son los siguientes: • Numero profesional, campo obligatorio. • Nombre, campo obligatorio. • Apellidos, campo obligatorio. • Teléfono, campo obligatorio. • E-mail, campo obligatorio. • Estado, en alta por defecto, campo obligatorio. • Zona, se selecciona de un desplegable con las zonas disponibles, campo obligatorio. • Turno, turno de trabajo al que está asignado, campo no obligatorio. Al continuar el alta se muestra pantalla con la información introducida y un listado de los equipos personales de la zona de donde se podrá asignar uno de los que están disponibles con un check asociado a estos. Los asignados muestran el número profesional del componente que lo tiene. 67 Asignación de equipo personal. El alta se completa pulsando el botón de alta. Los datos del nuevo componente de la URM se almacena en BBDD. Personal. Opción para realizar búsquedas sobre los miembros de la unidad. Si el usuario tiene perfil de administrador puede realizar modificaciones de los datos. Pantalla de búsqueda filtrada Esta pantalla tiene campos para poder filtrar los datos a recuperar. • Estado, activo o inactivo. • Zona, por defecto todas las zonas disponibles. • Apellidos, no obligatorio. • Número profesional, no obligatorio El resultado de la búsqueda es un listado del personal que cumple el filtro de búsqueda. Además se muestra el filtro aplicado y da opción para realizar una nueva búsqueda. 68 Listado aplicando el filtro del número profesional. Para acceder a la ficha del personal se pulsa el botón ver y se muestra junto a los datos, el equipo que tiene asignado y las intervenciones donde ha participado y las horas empleadas en ellas. Se pueden realizar filtros según la tipología de la intervención. Sobre el equipo asignado se puede mostrar un listado de los elementos que lo componen. Sobre el listado de histórico de intervenciones, se puede sacar un detalle de la intervención similar al disponible en el módulo de actividades que se verá a continuación. Mediante el botón editar se realizan modificaciones de los datos. Detalle de personal. 69 La siguiente pantalla siguiente muestra un equipo personal y los elementos que lo componen, este material está inventariado. Material que forma parte de un equipo personal. El proceso de modificación es similar al de alta. Módulo de Actividades. Este módulo funcional gestiona la información de las actividades de la URM. Una actividad puede ser una práctica, retenes preventivos o una intervención (rescate), a su vez se catalogan en función de la naturaleza de ésta: Tipo de Actividad Categoría de Actividad Prácticas • Cartografía/Orientación (Solo Prácticas). • Descenso de cañones. • Espeleología. • Montaña. • Vía Ferrata. Intervención Retén preventivo Evento deportivo. 70 Alta de Parte Para acceder a esta opción el usuario debe tener permisos de administración. Al pulsar la opción se muestra un formulario donde se agrega los datos del nuevo parte de actividad. Alta de parte de actividad. La información a completar en el formulario es la siguiente: • Datos generales: • Estado, abierto o cerrado. • Fecha y hora de inicio, campo obligatorio. • Fecha y hora de fin, campo obligatorio. • Tipo de actividad, campo obligatorio. • Categoría de la actividad, campo obligatorio. • Zona donde se desarrolla la actividad, campo obligatorio. • Lugar o localización, campo obligatorio. • Descripción de la actividad, campo obligatorio. 71 • Listado de personal interviniente. • Listado de material empleado. Tanto el listado de personal como el de material tienen un botón de Agregar/Quitar, al pulsarse se muestran las pantallas correspondientes para agregar personal y material disponible. • Listado de personal: Detalle de personal interviniente. Se agrega personal, cada uno puede tener una fecha de inicio para la incorporación en la actividad, así como para la finalización. Asociado a cada uno con el check de copiar fechas se asigna automáticamente la fecha de la actividad. • Listado de material: Detalle de material empleado. En el listado se distinguen las cuerdas empleadas del resto del material, a su vez el material se agrupa por zonas. 72 La pantalla de Agregar/Quitar el material es la siguiente: Agregar/Quitar material. Esta pantalla tiene un filtro de búsqueda de material. Al menos debe filtrarse por zona. El resultado de la búsqueda muestra el material disponible dividido en cuerdas y repartidores, y el resto del material. Si están asignados al parte de actividad en caso de los primeros aparecen seleccionados con su correspondiente check de usar en el resto del material usar es un desplegable donde se selecciona la cantidad a utilizar. Para quitar el material simplemente de deselecciona la cuerda o repartidor, o se seleccionan cero elementos. Partes. Opción para realizar búsquedas de partes de actividad, si el usuario tiene permisos de administrador podrá realizar cambios sobre la información. 73 Pantalla de búsqueda de partes de actividad. Una vez seleccionado los campos para filtrar la búsqueda se muestra un listado con los campos que coinciden con el filtro. Desde este listado se accede a la información de cada parte pudiéndose realizar ediciones sobre éste, tales como agregar personal y material o archivos adjuntos (imágenes, pdf). Listado de partes. Apéndice B. Manual de Instalación Instalación en servidor de aplicaciones Apache Tomcat. La aplicación completa se empaqueta en el archivo GestorParques.war. El propio entorno de desarrollo genera este archivo que contiene todos los JSPs, servlets y clases compiladas de la aplicación. Además de archivos de configuración, imágenes, 74 etc, que forman parte de la aplicación. Este archivo se genera en el directorio dist del proyecto del entorno de desarrollo NetBeans. Para desplegar este archivo en Apache Tomcat se emplea la aplicación Manager. Para ello es necesario disponer un usuario válido con perfil manager-gui que estará en el archivo tomcat-users.xml del directorio conf de Tomcat: <role rolename="manager-gui"/> <role rolename="manager-script"/> <role rolename="admin-gui"/> <user password="admin" roles="manager-gui,manager-script,admingui,admin" username="admin"/> La URL para acceder a la aplicación Manager es la siguiente: http:// <IP_SERVER>:8080/manager/html IP_SERVER la dirección IP del servidor donde se encuentra alojado Apache Tomcat. La aplicación muestra un formulario web donde aparecen las aplicaciones que están desplegadas en el servidor. Bajo éstas se encuentra la funcionalidad para desplegar el archivo war. Para ello está la opción Archivo WAR a desplegar que mostrará un diálogo donde seleccionar el war. Despliegue de la aplicación desde Manager. Una vez desplegada la aplicación esta será mostrada en el interfaz del Manager: 75 Despliegue de GestorParques. La aplicación se despliega en el directorio \webapps\GestorParques del servidor Tomcat. Se observa el directorio \webapps\Componentes. Este contiene el archivo de configuración y los logs que genera el componente de validación, en validación.xml se indica la url y los datos de usuario para acceder a la base de datos de acceso al sistema: <?xml version="1.0"?> <configuracion> <parametro> <nombre>DSN</nombre> <valor>jdbc:mysql://localhost/validacion</valor> </parametro> <parametro> <nombre>user</nombre> <valor>validacion</valor> </parametro> <parametro> <nombre>password</nombre> <valor>validacion</valor> </parametro> </configuracion> Instalación de Base de Datos Para ello es necesario disponer del archivo de script modeloDDBB.sql, este archivo es generado con el comando de MySql mysqldump de la forma siguiente: