Date post: | 03-Oct-2018 |
Category: |
Documents |
Upload: | phungnguyet |
View: | 218 times |
Download: | 1 times |
FACULTAD DE INFORMÁTICA
DEPARTAMENTO DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES
PROYECTO DE FIN DE CARRERA DE INGENIERÍA TÉCNICA EN
INFORMÁTICA DE SISTEMAS
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos
subterráneos
Autor: Dña. Sandra Vázquez Abrodos
Tutor: D. Antonino Santos del Riego
A Coruña, 15 de Septiembre de 2005
D. ANTONINO SANTOS DEL RIEGO, Profesor titular de la
Universidade da Coruña.
HACE CONSTAR QUE: La memoria titulada “Diseño e
implementación de un sistema gestor de espeleosocorro para rescates
en entornos subterráneos” ha sido realizada por Dña. SANDRA
VÁZQUEZ ABRODOS, bajo mi dirección, en el Departamento de
Tecnologías de la Información y las Comunicaciones de la
Universidade da Coruña, constituyendo su proyecto clásico de
ingeniería que presenta para optar al Grado de INGENIERO
TÉCNICO en Informática de la UDC en la convocatoria de
Septiembre del 2005.
A Coruña, 15 de Septiembre de 2005
Fdo. Prof. D. Antonino Santos del Riego
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 3 -
Agradecimientos A mi familia, sin la que nada de esto habría sido posible.
A Nino, por la atención y dedicación con la que ha dirigido el proyecto.
A mi pareja, Javier, y a todos los seres humanos que hacen de su vida una entrega
generosa al otro.
A todos, ¡gracias!.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 4 -
Resumen
El presente proyecto se centra en el ámbito del espeleosocorro. Su objetivo es el diseño e
implementación de un sistema gestor de espeleosocorro para rescates en entornos
subterráneos.
Dicho sistema gestor de rescates permitirá coordinar y documentar de un modo eficaz las
distintas intervenciones que se puedan llevar a cabo en el campo del espeleosocorro. Para
poder realizar todo esto, el sistema resultante permitirá gestionar una base de datos del
dominio a través de una arquitectura cliente/servidor sobre los protocolos TCP/IP.
Palabras Clave
Java, Web, J2EE, Servlets, JSP, JavaBeans, HTML, XML, Tomcat, MVC, UML,
MySQL, Hibernate
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 5 -
Índice 1. Introducción .................................................................................................................... 8 2. Dominio de la aplicación .............................................................................................. 11 3. Estado del Arte.............................................................................................................. 13 4. Tecnologías y herramientas seleccionadas ................................................................... 15
4.1 La plataforma Java.................................................................................................. 15 4.1.1 El lenguaje Java ............................................................................................... 15 4.1.2 El entorno de desarrollo Java........................................................................... 16 4.1.3 El compilador de Java...................................................................................... 17 4.1.4 La “Java Virtual Machine”.............................................................................. 17
4.2 Tecnología J2EE ..................................................................................................... 18 4.2.1 J2EE vs. NET................................................................................................... 18 4.2.2 Ventajas de J2EE ............................................................................................. 20 4.2.3 Arquitectura J2EE multicapa ........................................................................... 22 4.2.4 Servlets............................................................................................................. 23
4.2.4.1 Ventajas de los Servlets ............................................................................ 24 4.2.4.2 Arquitectura básica de los Servlets ........................................................... 26 4.2.4.3 El ciclo de vida de un Servlet ................................................................... 27
4.2.5 JavaServer Pages (JSP) ................................................................................... 29 4.2.5.1 JSPs vs. Servlets........................................................................................ 30 4.2.5.2 Arquitectura básica de las JSP .................................................................. 30
4.2.6 JavaBeans ........................................................................................................ 32 4.3 Lenguaje de marcado de hipertexto (HTML) ......................................................... 33 4.4 eXtensible Markup Language (XML) .................................................................... 34 4.5 Apache/Tomcat ....................................................................................................... 35 4.6 Hibernate................................................................................................................. 36 4.7 MySQL ................................................................................................................... 40 4.8 NetBeans IDE ......................................................................................................... 42
5 Modelo Vista Controlador (MVC)................................................................................. 44 5.1 Modelos de diseño: Modelo 1, Modelo 2 y Modelo 2X......................................... 46
6 Modelado ....................................................................................................................... 50 6.1 UML - Lenguaje Unificado de Modelado .............................................................. 50 6.2 Análisis de requisitos .............................................................................................. 51
6.2.1 Actores del sistema .......................................................................................... 51 6.2.2 Casos de uso..................................................................................................... 52
6.3 Diseño del sistema .................................................................................................. 55 6.3.1 Arquitectura general......................................................................................... 55 6.3.2 Diseño de la aplicación servidora .................................................................... 57
6.3.2.1 Seguimiento de las sesiones...................................................................... 57 6.3.2.2 Control de acceso a los recursos ............................................................... 58 6.3.2.3 Lectura de datos del cliente....................................................................... 59 6.3.2.4 Lógica funcional ....................................................................................... 60 6.3.2.5 El Gestor de Flujo ..................................................................................... 61 6.3.2.6 Procesamiento de peticiones en el servidor .............................................. 62
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 6 -
6.3.2.7 Arquitectura de paquetes del sistema........................................................ 64 6.3.3 Diseño de la base de datos ............................................................................... 69 6.3.6 Interfaz gráfica ................................................................................................. 80
7 Conclusiones y desarrollos futuros .............................................................................. 103 Bibliografía ..................................................................................................................... 105 Enlaces electrónicos........................................................................................................ 107
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 7 -
Índice de ilustraciones Figura 1. Procesamiento de una petición .......................................................................... 24 Figura 2. Ciclo de vida de un servlet ................................................................................ 29 Figura 3. Páginas JSP........................................................................................................ 30 Figura 4. Creación de una JSP .......................................................................................... 31 Figura 5. Ciclo de vida de una JSP ................................................................................... 32 Figura 6. Fichero de mapeado para Hibernate .................................................................. 39 Figura 7. Arquitectura del Modelo 1................................................................................. 47 Figura 8. Arquitectura de Modelo 2.................................................................................. 49 Figura 9. Actores del sistema............................................................................................ 51 Figura 10. Casos de uso para todos los usuarios............................................................... 53 Figura 11. Casos de uso para el administrador ................................................................. 54 Figura 12. Arquitectura del sistema .................................................................................. 56 Figura 13. Procesamiento de peticiones en el servidor..................................................... 63 Figura 14. Diagrama de paquetes...................................................................................... 65 Figura 15. Esquema E/R extendido .................................................................................. 71 Figura 16. Esquema relacional completo de la base de datos........................................... 79 Figura 17. Pantalla de autenticación ................................................................................. 80 Figura 18. Pantalla de inicio del administrador ................................................................ 81 Figura 19. Pantalla de inicio de los usuarios..................................................................... 82 Figura 20. Creación de un usuario .................................................................................... 83 Figura 21. Listado del personal......................................................................................... 84 Figura 22. Creación de un nuevo material ........................................................................ 85 Figura 23. Listado de los materiales ................................................................................. 86 Figura 24. Creación de un equipo ..................................................................................... 87 Figura 25. Listado de los equipos ..................................................................................... 88 Figura 26. Listado de los roles.......................................................................................... 89 Figura 27. Asociación de roles.......................................................................................... 90 Figura 28. Listado de los nidos ......................................................................................... 91 Figura 29. Listado de la bibliografía................................................................................. 92 Figura 30. Creación de una intervención .......................................................................... 93 Figura 31. Listado de las intervenciones........................................................................... 95 Figura 32. Asociación de bibliografía............................................................................... 96 Figura 33. Asociación de personal.................................................................................... 97 Figura 34. Asociación de materiales................................................................................. 99 Figura 35. Selección de una intervención para generar su informe................................ 100 Figura 36. Informe generado........................................................................................... 101 Figura 37. Cierre de una intervención............................................................................. 102
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 8 -
1. Introducción
Los importantes avances tecnológicos que han tenido lugar en los últimos años y las
mejoras en las comunicaciones globales han hecho de la sociedad de la información una
realidad que nos brinda nuevas facilidades de comunicación y gestión. Dichas facilidades
no deben ser ignoradas en aquellas actividades en las que una comunicación fluida y una
coordinación precisa pueden salvar vidas humanas.
Sin duda alguna el ámbito del espeleosocorro es uno de estos campos donde la
coordinación y organización entre los equipos participantes es de vital importancia.
Comunicaciones en tiempo real y una gestión distribuida de materiales reducirían los
tiempos de actuación incrementando significativamente las posibilidades de rescatar con
vida a los accidentados.
En la actualidad los grupos de espeleosocorro se encuentran con importantes carencias a
la hora de planificar un rescate. Destacando la inexistencia de un acceso a información
actualizada y unos métodos de trabajo poco flexibles que retrasan considerablemente la
organización de las operaciones.
La utilización de un sistema gestor potente y flexible agilizaría los rescates y disminuiría
la complejidad de planificar una operación, ya que haría innecesaria una recopilación de
datos permitiendo llevar a cabo una correcta localización del personal y materiales
disponibles. Además, la emisión automatizada e instantánea de informes es sin duda otra
de las importantes ventajas del sistema.
Para la realización de dicho sistema gestor se llevará a la práctica una solución basada en
el Web que permita aprovechar las posibilidades ofertadas por una red global de bajo
coste como es la red Internet. Dicha solución se desarrollará utilizando la arquitectura
Java 2 Enterprise Edition (J2EE) y el denominado Modelo-Vista-Controlador (MVC).
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 9 -
Es por tanto objetivo de este proyecto realizar un sistema gestor con el cual se puedan
coordinar y documentar las intervenciones de espeleosocorro de un modo eficiente,
rápido y automatizado.
El presente documento se encuentra organizado en nueve apartados. En el apartado
actual, Introducción, se presenta brevemente la actividad del espeleosocorro explicando
su situación social, limitaciones y carencias así como la necesidad de un sistema gestor
que palie las necesidades existentes.
El apartado dos, Dominio de la aplicación, describe el entorno de la aplicación.
En el apartado tres, Estado del Arte, se exponen las soluciones que existen en la
actualidad para el problema que tratamos de resolver.
En el apartado cuatro, Tecnologías y Herramientas Seleccionadas, se describen las
tecnologías y herramientas empleadas para el desarrollo del proyecto y se justifica su
elección.
El apartado cinco, Modelo Vista Controlador (MVC), se describe y justifica la
arquitectura software MVC que se utilizará en la implementación del presente proyecto.
En el apartado seis, Modelado, se proporciona un análisis de los requisitos en el cual se
muestran los casos de uso que permiten apreciar la utilidad de la aplicación. Además, se
detalla todo el diseño y la arquitectura del sistema describiendo los distintos componentes
y la forma en que se interrelacionan. Al final del apartado se muestra el proyecto en
funcionamiento mediante un “paseo” por la aplicación.
El apartado siete, Conclusiones, expone las conclusiones alcanzadas tras la realización
del proyecto y la evaluación del mismo.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 10 -
Finalmente, en los apartados ocho y nueve, Bibliografía y Enlaces electrónicos
respectivamente, se muestra toda la bibliografía y los enlaces electrónicos utilizados
durante la realización del presente proyecto.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 11 -
2. Dominio de la aplicación
El fin de la espeleología es la exploración de las cuevas y el estudio de las mismas. Como
actividad científica, atrae la atención de geólogos, biólogos, arqueólogos y muchos otros
que ven en las cavidades subterráneas un entorno adecuado para la investigación pero,
además, es una actividad considerada de alto riesgo que requiere de una cierta
preparación técnica que permita maximizar los niveles de seguridad.
Para garantizar los rescates en esta actividad existe una disciplina técnica que se conoce
como espeleosocorro [FEDE98], la cual tiene como objetivo propiciar los métodos y
medios necesarios para tal tipo de intervenciones. Una disciplina que puede reducir el
número de rescates es el autosocorro, siendo de gran interés la formación del espeleólogo
en dichas técnicas.
El autosocorro comprende las acciones que realiza un espeleólogo o grupo de
espeleólogos para resolver un problema que se presenta durante la exploración de una
cueva. Es el nivel básico del espeleosocorro y debe ser dominado por todo el que practica
la espeleología. Este nivel comprende conocimientos de primeros auxilios, soporte vital
básico, maniobras de desbloqueo y desobstrucción, supervivencia en condiciones de
campaña, etc. que preparan al espeleólogo para afrontar la situación y dar una respuesta
inicial limitada.
En cuanto al socorro espeleológico o espeleosocorro debemos decir que es una
especialidad que requiere de una mayor preparación y de todo un sistema organizativo
que va a garantizar una respuesta oportuna y eficiente en caso de producirse un accidente.
Para la realización del espeleosocorro es necesaria la participación de un equipo de
personas que se conocen como espeleosocorristas y que son los que se entrenan en
técnicas especiales de tratamiento, traslado y evacuación de un accidentado, para lo cual
se requiere de un gran equipamiento de salvamento y rescate propio de, y para la
espeleología.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 12 -
Los espeleólogos españoles se agrupan en la Federación Española de Espeleología que
engloba a 15 federaciones territoriales, entre ellas la gallega, que comprenden más de 250
grupos y unos 5.000 federados.
Estos grupos organizan cursos de varios niveles con la colaboración de las Escuelas de
Espeleología que dependen de las Federaciones y mantienen equipos de rescate para
casos de incidentes (retrasos, fatigas, pérdidas durante poco tiempo, lesiones leves, etc.) o
accidentes (pérdida total, caídas con fracturas, pérdidas de conocimiento, etc.).
Realizar rescates en un entorno subterráneo no es tarea fácil y el factor tiempo suele ser
de vital importancia en muchos casos. De esto podemos concretar que es fundamental
tener una buena base en cuanto a fundamentos de actuación, organización y planificación
de un rescate.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 13 -
3. Estado del Arte Durante la fase de documentación del presente proyecto pudimos comprobar las líneas de
desarrollo seguidas en los últimos años. En ellas se puede apreciar una intensa labor en la
digitalización de los informes y de la documentación relativa a operaciones de rescate
realizadas con anterioridad.
Sin embargo, los métodos utilizados en la actualidad para dichas labores de digitalización
carecen de un estándar, lo que a la hora de automatizar cualquier manipulación de la
información supone dificultades que no pueden ser obviadas.
Entre estas dificultades cabe destacar las siguientes:
• La inexistencia de una estructura, los datos habitualmente se encuentran
almacenados sin usar ningún tipo de criterio formal.
• La escasa variedad de datos, sólo una pequeña parte de los datos de interés de un
rescate llega a tratarse adecuadamente.
• Los sistemas de consulta son poco flexibles y proporcionan unas opciones de
consulta muy limitadas.
• La realización de actualizaciones no es una tarea fácil, esto se debe
principalmente a la ausencia de estructuras de datos.
• La disponibilidad de los datos es muy limitada, ya que la mayoría de los sistemas
utilizados en la actualidad requieren disponer de una copia para su utilización.
Creemos por tanto que el desarrollo de sistemas gestores y la innovación en los mismos
no sólo cubren la necesidad de almacenar la información en un soporte digital flexible y
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 14 -
automatizado sino que también añaden nuevas posibilidades de distribución y gestión que
facilitan y estandarizan la inclusión del nuevo material digitalizado.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 15 -
4. Tecnologías y herramientas seleccionadas
A lo largo de esta sección se expondrán las tecnologías y herramientas más importantes
que se han utilizado en el desarrollo de este proyecto. De cada una de ellas se expondrán
sus características, ventajas y desventajas, explicando las razones que nos han llevado a
elegir esas tecnologías, y no otras, para la realización del presente proyecto.
4.1 La plataforma Java
Java es una plataforma, desarrollada al comienzo de los años 90 con el objetivo concreto
de permitir ejecutar programas sin tener relativamente en cuenta el hardware final.
Consiste en tres grandes bloques, el lenguaje Java, una máquina virtual y un programa de
aplicación de interfaz o API (Application Programming Interfaz).
4.1.1 El lenguaje Java
A finales de 1995 se introdujo Java como lenguaje de programación para computadores.
La clave fue la incorporación de un intérprete Java en la versión 2.0 del programa
Netscape Navigator, produciendo una verdadera revolución en Internet.
La compañía Sun describe el lenguaje Java [ALLE00] como “simple, orientado a objetos,
distribuido, interpretado, robusto, seguro, de arquitectura neutra, portable, de altas
prestaciones, multitarea y dinámico”. Además de una serie de halagos por parte de Sun
hacia su propia criatura, el hecho es que todo ello describe bastante bien el lenguaje Java.
Para el desarrollo del presente proyecto se ha optado por el lenguaje de programación
Java así como por diversas tecnologías asociadas al mismo. Esta decisión se ha tomado
en base a las características anteriormente mencionadas del lenguaje Java y a que cuenta
con una amplísima colección de APIs a nuestra disposición. Al programar en Java no se
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 16 -
parte de cero. Cualquier aplicación que se desarrolle “cuelga” (o se apoya, según como se
quiera ver) de un gran número de clases preexistentes. Algunas de ellas las ha podido
hacer el propio usuario y otras pueden ser comerciales, pero siempre hay un número muy
importante de clases que forman parte del propio lenguaje.
Otro de los motivos clave para declinarse por este lenguaje es la amplísima plataforma de
desarrollo de aplicaciones que se encuentra detrás de Java. El equipo de desarrollo de
Java agrupó las características de Java en tres ediciones [JAVA04], cada una de las
cuales cuenta con un kit de desarrollo de software (Software Development Kit o SDK).
• J2SE (Java 2 Standard Edition): La Java2 edición estándar es la edición original
de Java y consiste de las interfaces de programación de aplicaciones, APIs,
necesarias para construir una aplicación o applet en Java.
• J2ME (Java 2 Mobile Edition): Es la edición móvil de Java 2. Contiene las API
que se utilizan para crear aplicaciones Java inalámbricas o para dispositivos
pequeños.
• J2EE (Java 2 Enterprise Edition): La Java 2 edición empresarial es una versión
mejorada de la J2SE. Contiene las API necesarias para construir aplicaciones para
arquitecturas multicapa.
4.1.2 El entorno de desarrollo Java
Existen distintos programas comerciales que permiten desarrollar código Java. La
compañía Sun, creadora de Java, distribuye gratuitamente el Java(tm) Development Kit
(JDK).
El JDK se trata de un conjunto de programas y librerías que permiten desarrollar,
compilar y ejecutar programas en Java. Incorpora además la posibilidad de ejecutar
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 17 -
parcialmente el programa, deteniendo la ejecución en el punto deseado y estudiando en
cada momento el valor de cada una de las variables (con el denominado Debugger).
4.1.3 El compilador de Java
Se trata de una de las herramientas incluidas en el JDK. Realiza un análisis de sintaxis del
código escrito en los ficheros fuente de Java (con extensión *.java). Si no encuentra
errores en el código genera los ficheros compilados (con extensión *.class). En otro caso
muestra la línea o líneas erróneas. En el JDK de Sun dicho compilador se llama
javac.exe.
4.1.4 La “Java Virtual Machine”
La existencia de distintos tipos de procesadores y ordenadores llevó a los ingenieros de
Sun a la conclusión de que era muy importante conseguir un software que no dependiera
del tipo de procesador utilizado.
Se planteó la necesidad de conseguir un código capaz de ejecutarse en cualquier tipo de
máquina. Una vez compilado no debería ser necesaria ninguna modificación por el hecho
de cambiar de procesador o de ejecutarlo en otra máquina.
La clave consistió en desarrollar un código “neutro” el cual estuviera preparado para ser
ejecutado sobre una “máquina hipotética o virtual”, denominada Java Virtual Machine o
JVM.
Es esta JVM quien interpreta este código neutro convirtiéndolo a código particular de la
CPU utilizada. La JVM ejecuta los “bytecodes” (ficheros compilados con extensión
*.class) creados por el compilador de Java (java.exe). De este modo se evita tener que
realizar un programa diferente para cada CPU o plataforma.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 18 -
4.2 Tecnología J2EE
A lo largo de los últimos años el desarrollo de aplicaciones Web ha sufrido un auge muy
importante, la Web ha ido pasando de ser un mero contenedor de “texto” estático en
forma de páginas HTML, a convertirse en un entorno dinámico, movido por diversas
tecnologías que permiten y facilitan la creación de HTML en base a contenidos
dinámicos provenientes de diversas fuentes como pueden ser las bases de datos.
Las aplicaciones Web en Internet se están convirtiendo en un importante motor de la
economía digital. Frente a esta nueva demanda surgen dos plataformas distintas para el
desarrollo de este tipo de aplicaciones: J2EE de Sun y .NET de Microsoft.
4.2.1 J2EE vs. NET J2EE y .NET son los dos titanes que se enfrentan en el ring de los servidores para
aplicaciones web. A lo largo de los últimos años se han vertido miles de líneas sobre la
estrategia .NET de Microsoft [MICR05] y su comparación con la plataforma J2EE
[REJ05].
Para poder comparar y luego valorar cual de estas tecnologías es conveniente usar en el
desarrollo del presente proyecto vamos a mostrar primero una panorámica general.
• J2EE: J2EE [KEOG02] se denomina plataforma porque proporciona
especificaciones técnicas que describen el lenguaje pero, además, provee las
herramientas para implementar aplicaciones. Veamos la definición que
proporciona Sun de J2EE:
“J2EE define un estándar para el desarrollo de aplicaciones empresariales
multicapa. J2EE simplifica las aplicaciones empresariales basándolos en
componentes modulares y estandarizados, proveyendo un completo conjunto de
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 19 -
servicios a estos componentes, y manejando muchas de las funciones de la
aplicación de forma automática, sin necesidad de una programación compleja”.
Esquemáticamente se resumiría en la siguiente ecuación J2EE = Java +
componentes adicionales orientados a empresas (JavaBeans, JSPs, etc.).
La plataforma J2EE ha sido creada con la participación de cientos de empresas de
diversa índole y es sin lugar a dudas una plataforma conjunta, no exclusiva de Sun
o de ninguna otra compañía.
• .NET: Nació a principios de este siglo, producto de una serie de herramientas de
software que Microsoft ya ofrecía a sus clientes, especialmente en lo que a
servidores se refiere. Más que una plataforma, es un concepto creado por
Microsoft para generar servicios a través de Internet, gracias a servidores de bases
de datos que contienen la información.
Según Steven B. Levy, redactor de Microsoft TechNet, ".NET es una plataforma
llena de servicios para construir aplicaciones basadas en web y desarrollar
experiencias interactivas para los usuarios y sus sistemas".
La parte más importante de la plataforma .NET es NET framework, una suite de
herramientas que incluye COM+ (Component Object Model), un entorno de
ejecución común, un compilador JIT (just-in-time) y un conjunto de librerías de
sistema.
Desde el punto de vista del programador, el entorno .NET ofrece un solo entorno
de desarrollo para todos los lenguajes que soporta (Visual Basic, C++, C#, Visual
J#, Fortran, Cobol, etc.).
Aunque entre J2EE y .NET existen diferencias, ventajas y desventajas también existen
similitudes. A continuación se muestran algunas características comunes.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 20 -
• El propósito tanto de J2EE como de la plataforma .NET es facilitar y simplificar
el desarrollo de aplicaciones empresariales o corporativas.
• Los servidores de aplicaciones J2EE y .NET proporcionan un modelo de acceso
de componentes a datos y de lógica del negocio, separados por una capa
intermedia de presentación implementada mediante ASP .NET (.NET) ó Servlets
(J2EE).
• Visual Basic .NET y C# son lenguajes orientados a objetos, al igual que Java, y en
su diseño ha tenido mucha importancia la existencia de Internet.
• Desde la perspectiva de los desarrolladores, J2EE y .NET proporcionan las
herramientas necesarias para crear sitios web.
4.2.2 Ventajas de J2EE
Para explicar los motivos que nos han llevado a utilizar J2EE en la realización de este
proyecto vamos a ver algunas de las ventajas que ofrece esta plataforma frente a .NET.
• Aunque Java fue creado originalmente por una compañía, Sun MicroSystems, lo
cierto es que J2EE es ahora el producto de la colaboración de un gran número de
empresas y organizaciones de todo tipo (públicas, privadas sin ánimo de lucro,
privadas con ánimo de lucro, y de normalización en ámbitos nacionales e
internacionales). Este hecho permite la existencia de una cierta competencia que
acarrea como resultado mejores productos. Esta competencia no existe en el caso
de Microsoft y su .NET. La plataforma .NET es, y será, el producto de una sola
compañía.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 21 -
• Debido al proceso evolutivo de los productos de Microsoft y, en muchos casos, a
motivos de compatibilidad, la seguridad frente a virus informáticos de los
productos de Microsoft es menor que los basados en Java, pues desde un
comienzo Java se fundamentó siempre en un estricto modelo de seguridad.
• Hasta el momento, la plataforma J2EE es la única plataforma que corre en
múltiples sistemas operativos y múltiples máquinas hardware y cuyos usuarios
pueden seleccionar la implementación que más le convenga. Además, no solo
corre en computadores domésticos o servidores o estaciones de trabajo, sino
también en multitud de dispositivos como teléfonos móviles, agendas,
componentes electrónicos industriales de automatización, etc. Java ya ha hecho
realidad el sueño de "escriba el código una vez, ejecútelo en cualquier parte".
Hasta la fecha, .NET corre solamente sobre sistemas operativos de Microsoft.
• La tecnología Java es una tecnología abierta (en el sentido de que el código de la
plataforma completa puede ser obtenido, revisado y estudiado por cualquiera que
esté interesado) y se basa en gran parte en estándares de organizaciones de
normalización y estándares empresariales "de facto". Esto posibilita que los
desarrolladores puedan conocer y entender completamente cómo hace las cosas
Java y aprovecharlo para sus aplicaciones y, por otro lado, al basarse en
estándares empresariales, simplifica la integración con productos de múltiples
compañías. En contraposición, sólo el código fuente del Nuevo lenguaje C# de la
plataforma .NET ha sido abierto al público general (aunque Microsoft permite a
determinadas compañías el acceso al código fuente de ciertas partes de .NET).
• La tecnología Java goza ya de una veteranía en el mercado y J2EE ha probado su
eficacia en muchos entornos y situaciones empresariales distintas. De hecho,
J2EE llegó al mercado tres años antes que .NET.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 22 -
4.2.3 Arquitectura J2EE multicapa
J2EE posee una estructura estándar basada en tres capas:
• Capa de usuario: Representa lo que el usuario ve. Por ejemplo, las páginas
HTML.
• Capa Intermedia. Es la que se utiliza en el negocio de una empresa y contiene la
gestión de la aplicación, como es el caso de objetos Java que acceden a datos.
• Capa de datos: Representa la base de datos.
Este tipo de estructuras permiten que exista cierta independencia entre la visualización, la
gestión y la base de datos. Además, permite acceder a la información que interesa vía
http. Por lo tanto, se envía la información a través de una página HTML (capa cliente), la
cual es interpretada por la capa intermedia, que a su vez accede a la base de datos. La
capa intermedia resuelve las peticiones del cliente mediante el servidor de aplicaciones
J2EE.
Como se dijo anteriormente, el único lenguaje que soporta J2EE es Java y por lo tanto es
el que se usará en el desarrollo de todos los componentes.
Existen sólo dos formas oficiales para acceder a la plataforma J2EE con otros lenguajes:
a través de JNI (Java Native Interface) o mediante la interoperabilidad que ofrece
CORBA.
Un elemento fundamental en las aplicaciones web soportadas bajo Java son los
denominados "patrones J2EE", que describen los típicos problemas encontrados por
desarrolladores de aplicaciones empresariales y proveen soluciones para éstos.
En esencia, estos patrones contienen las mejores soluciones para ayudar a los
desarrolladores a diseñar y construir aplicaciones para la plataforma J2EE.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 23 -
Las características y usos de estos patrones para su implementación se pueden encontrar
en la web de Sun.
El diseño de aplicaciones Web basadas en los Patrones J2EE se organiza alrededor de la
utilización de varios elementos: un controlador frontal, dispatchers (despachadores),
vistas compuestas, vistas JSP y los helpers (ayudantes) de las vistas (JavaBeans).
4.2.4 Servlets
Los servlets son programas o clases Java que se ejecutan en un servidor de aplicaciones
web, por ejemplo Tomcat, y hacen de capa intermedia entre una petición proveniente de
un navegador web u otro cliente HTTP, y las bases de datos o aplicaciones del servidor
http. Es decir, los servlets contienen la lógica de negocio para procesar una petición.
Por ejemplo, un servlet podría ser responsable de tomar los datos de un formulario en
HTML y aplicarle la lógica de negocio utilizada para actualizar la base de datos. En la
siguiente figura (véase Figura 1) se muestra el procesamiento de una petición.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 24 -
Figura 1. Procesamiento de una petición
4.2.4.1 Ventajas de los Servlets
En el caso del presente proyecto se utilizan servlets porque estos tienen numerosas
ventajas [HUNT98] sobre otras tecnologías como puede ser la Interfaz Común de
Pasarela (Common Gateway Interface o CGI). A continuación se muestran los principales
beneficios de utilizar servlets.
• Eficiencia: Con el CGI cada vez que se realiza una petición HTTP se inicia un
nuevo proceso. El coste de arrancar este nuevo proceso puede llegar a superar el
tiempo de ejecución del propio programa CGI y esto es inaceptable. Con los
servlets, la JVM permanece en ejecución y administra cada petición mediante un
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 25 -
ligero subproceso de Java. De forma similar, si hay n peticiones simultáneas al
mismo programa CGI, el código del programa se carga la misma cantidad de
veces en memoria. Sin embargo, con los servlets puede haber n procesos y sólo
una copia del servlet en memoria. Finalmente, cuando un programa CGI termina
de manejar la petición, el programa finaliza. Esto dificulta agilizar los procesos,
mantener abiertas conexiones a la base de datos y realizar otras optimizaciones
que se basan en datos persistentes. Por su parte, los servlets permanecen en
memoria aún después de que han dado una respuesta, por lo que es fácil
almacenar datos entre las peticiones.
• Adecuados: Los servlets cuentan con una extensa infraestructura para analizar y
decodificar automáticamente los datos de los formularios HTML, leer y establecer
encabezados HTTP, administrar cookies, rastrear sesiones y muchas otras
utilidades.
• Poderosos: Los servlets pueden comunicarse directamente con el servidor web,
mientras que los programas CGI no pueden hacerlo, para ello necesitan utilizar
cierta API específica de los servidores. Además el hecho de que los servlets
puedan mantener información de una petición a otra, simplifica el rastreo de
sesiones.
• Transportables: Los servlets están escritos en el lenguaje de programación Java
y siguen una API estándar. De este modo pueden utilizarse de manera directa en
cualquier servidor web. Además ahora son parte de J2EE.
• Seguros: Una de las principales fuentes de vulnerabilidad en los programas CGI
proviene del hecho de que por lo general son ejecutados por entornos de sistemas
operativos de propósito general. Por ello, el programador de CGI debe tener
cuidado de filtrar caracteres como las comillas y los puntos y coma porque tienen
un tratamiento especial por el entorno. Una segunda fuente de problemas es el
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 26 -
hecho de que ciertos programas CGI son procesados por lenguajes que no
verifican automáticamente los límites de las matrices o cadenas. Por ello, los
programadores que olvidan realizar esta verificación, abren sus propios sistemas a
posibles ataques de desbordamiento de buffer. Los servlets no tienen estos
problemas. Aun si un servlet ejecuta una llamada a un sistema distante para
ejecutar un programa en el sistema operativo local, no utiliza el entorno del
sistema operativo para lograrlo. Y por supuesto la verificación de los límites de
las matrices y otras características para la protección de la memoria son una parte
central de Java.
4.2.4.2 Arquitectura básica de los Servlets
Un servlet es una clase Java que recibe peticiones que envía un cliente y envía
información de vuelta al cliente como respuesta. Para que esta clase Java se convierta en
servlet es necesario que extienda a la clase HttpServlet y que sustituya a lo métodos
doGet o doPost de dicha clase, dependiendo de si los datos son enviados por GET o por
POST.
El método doGet se utiliza para interactuar con aquellas peticiones que se envían
utilizando METHOD=GET. Las peticiones GET son el tipo usual de peticiones del
navegador para las páginas Web. Un navegador Web genera una petición cuando el
usuario teclea un URL en la línea de Dirección, sigue un vínculo desde una página Web o
envía un formulario HTML que no especifica un METHOD.
Los servlets también pueden manejar con facilidad peticiones POST, que se generan
cuando alguien envía un formulario HTML que establece METHOD=POST. Ambos
métodos, doGet y doPost, toman un par de argumentos: un HttpServletRequest y
un HttpServletResponse.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 27 -
• HttpServletRequest: contiene métodos por los cuales puede encontrar
información entrante como los nombres de los parámetros pasados por el cliente,
encabezados de petición HTTP, y el nombre del host cliente que ha realizado la
petición.
• HttpServletResponse: le permite especificar la información de salida como
los códigos de estado de HTTP (200, 404, etc.), encabezados de respuesta
(Content-Type, Set-Cookie, etcétera) y, lo más importante, le permite obtener un
PrintWriter utilizado para enviar el contenido del documento de regreso al
cliente.
4.2.4.3 El ciclo de vida de un Servlet
Los servlets se ejecutan en el servidor HTTP como parte integrante del propio proceso
del servidor. Por este motivo el servidor HTTP es el responsable de la inicialización,
llamada y destrucción de cada objeto de un servlet, tal y como puede observarse en la
Figura 2.
El servidor web se comunica con el servlet mediante los métodos de la interface
javax.servlet.Servlet también esta interface está constituida por al menos cuatro
métodos que serán llamados durante el ciclo de vida del servlet. Estos cuatro métodos
son:
• init(): Es llamado por el servidor HTTP cuando un servlet se carga por primera
vez. Este método no será llamado nunca más mientras el servlet se esté
ejecutando. El método init() es utilizado para leer parámetros de inicialización
como pueden ser parámetros de la base de datos. Se puede sobrescribir y no
recibe parámetros.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 28 -
• service(): Es el núcleo fundamental del servlet. Cada petición por parte del
cliente se traduce en una llamada al método service() del servlet. El método
service() lee la petición y debe producir una respuesta en base a los dos
argumentos que recibe:
1. Un objeto de la interface ServletRequest con datos enviados por el
cliente. Estos incluyen parejas de parámetros clave valor.
2. Un objeto de la interface ServletResponse que encapsula la respuesta
del servlet al cliente.
• doGet(), doPost(): El método service() examina el tipo de petición HTTP
y llama al método adecuado, por ejemplo doGet() o doPost(). Estos métodos
contienen la verdadera esencia del servlet. El noventa por ciento del tiempo, sólo
se atenderá a peticiones GET y, en su caso, POST, por lo que sustituirá a doGet y,
en su caso, a doPost.
• destroy(): es el último método que se llama justo antes de destruir el servlet.
Una buena implementación de este método debe permitir que el servlet concluya
sus tareas de forma ordenada. De esta forma es posible liberar recursos (ficheros
abiertos, conexiones con bases de datos, etc.) de una forma limpia y segura.
Cuando esto no es necesario o importante, no hace falta redefinir el método
destroy().
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 29 -
Figura 2. Ciclo de vida de un servlet
4.2.5 JavaServer Pages (JSP)
Las JavaServer Pages (JSP) son programas del servidor cuyo diseño y funcionalidad es
muy similar al de los servlets. Una JSP procesa las peticiones mediante la lógica que
incluye o mediante llamadas a otros componentes construidos con tecnología de servlets
o con alguna otra tecnología.
La diferencia entre una JSP y un servlet radica en la forma en que se escribe la JSP. El
servlet se escribe en lenguaje Java mientras que la JSP se escribe en HTML, XML o en el
formato del cliente, entremezclado con elementos de código, directivas y acciones
escritas en lenguaje Java.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 30 -
4.2.5.1 JSPs vs. Servlets
JSPs y servlets tienen muchas características en común [HALL01] y ambos pueden servir
contenido dinámico. Sin embargo, los servlets se han de utilizar estrictamente como una
extensión del servidor. Esto puede incluir la implementación de un controlador
ofreciendo servicios de autenticación, validación de bases de datos, etc. Las JSP se usarán
para desarrollar aplicaciones basadas en contenido dinámico. En el apartado cinco, en el
cual se habla del MVC, se explica con más detalle el uso que haremos de los servlets y de
las JSPs para la realización del presente proyecto. En la siguiente figura (véase Figura 3)
se muestra el uso de las JSP.
Figura 3. Páginas JSP
4.2.5.2 Arquitectura básica de las JSP
Crear una JSP es más sencillo que crear un servlet debido a que, como se dijo
anteriormente, la JSP está escrita en HTML. Sin embargo, una JSP proporciona
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 31 -
fundamentalmente las mismas características que un servlet, ya que una JSP se convierte
en un servlet la primera vez que el cliente la solicita.
Es decir, las páginas JSP pasan por una fase de traducción que realiza el motor JSP por si
mismo cuando recibe una petición de la página JSP por primera vez. El resultado de esta
traducción es que el fichero .jsp se convierte en un fichero .class. Además, este fichero
.class extiende a HttpJspBase el cual a su vez implementa la interfaz Servlet. En la
siguiente figura (véase Figura 4) se muestra como una JSP se convierte en un servlet.
Figura 4. Creación de una JSP
Hay tres métodos que se llaman de forma automática al llamar a una JSP y cuando la JSP
termina en forma normal:
• jspInit(): Es idéntico al método init() de un servlet.
• jspDestroy(): Es idéntico al método destroy() de un servlet.
• jspService(): Una vez que el fichero .class es cargado en el contenedor
servlet, se llama de forma automática al método service(), que es el
responsable de responder a las peticiones de los clientes enviando el resultado de
la JSP mediante HTTP.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 32 -
En la Figura 5 se muestra como son llamados los métodos init(), destroy() y
service() a lo largo del ciclo de vida de las JSP.
Figura 5. Ciclo de vida de una JSP
4.2.6 JavaBeans
El modelo de componentes de la tecnología JSP está basado en la arquitectura de
componentes JavaBeans. Un componente JavaBean no es más que un objeto Java que ha
sido realizado siguiendo un patrón de nombres y diseño realizado previamente.
Un bean encapsula sus propiedades declarándolas como privadas y proporciona métodos
de acceso públicos (gets y sets) para permitir leer y modificar sus valores. La principal
función de los JavaBeans es la de proporcionar la lógica de negocio a la aplicación e
interactuar con otros componentes del servidor.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 33 -
4.3 Lenguaje de marcado de hipertexto (HTML)
Como indica su nombre, HTML es un lenguaje de marcado que se utiliza para definir la
forma en que el texto se debe mostrar en un navegador u otro software capaz de
interpretar HTML, como pueden ser algunos procesadores de texto. Para indicar la forma
de mostrar el texto se utilizan etiquetas. Una etiqueta se puede considerar como una
orden al navegador.
Es importante conocer HTML antes de crear componentes J2EE con JSP, ya que, como
se verá posteriormente, la mayor parte del contenido de las JSP se escribe con HTML. Un
usuario interactúa con una aplicación J2EE a través de una interfaz de usuario que se crea
utilizando HTML. La interfaz de usuario envía la petición del cliente a componentes
construidos con servlets y/o JSP.
Hay dos características que se encuentran frecuentemente al utilizar HTML en una JSP
para construir una página web en forma dinámica. Estas características son los
formularios y las tablas.
Los formularios HTML se utilizan frecuentemente en las JSP para generar una página
web que recolecta información de un usuario, la cual se envía entonces a una JSP o
servlet para su procesamiento.
Un ejemplo de formulario HTML puede ser un formulario que captura datos. Los datos
que recibe la JSP o servlet del formulario por lo general se envían a un componente
javabean, el cual conecta con un Sistema de Gestor de Bases de Datos (SGBD).
Una tabla HTML es una matriz similar a una hoja de cálculo que una JSP o servlet genera
en forma dinámica para mostrar datos recuperados del SGBD. El código HTML de la JSP
o servlet crea cada componente de la tabla y coloca etiquetas y datos dentro de sus celdas
antes de enviar la página HTML al navegador para su despliegue.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 34 -
4.4 eXtensible Markup Language (XML)
La familia XML es un conjunto de especificaciones que conforman el estándar que define
las características de un mecanismo independiente de plataformas desarrollado para
compartir datos. Se puede considerar a XML como un formato de transferencia de datos
multi-plataforma. Es un subconjunto de LMGS (Lenguaje de Marcado Generalizado
Standard) y uno de sus objetivos es permitir que LMGS genérico pueda ser servido,
recibido y procesado en la web de la misma manera que actualmente es posible con
HTML.
XML ha sido diseñado de tal manera que sea fácil de implementar. No ha nacido sólo
para su aplicación en Internet, sino que se propone como lenguaje de bajo nivel (a nivel
de aplicación, no de programación) para intercambio de información estructurada entre
diferentes plataformas.
XML [MCLA00] hace uso de etiquetas (únicamente para delimitar datos) y atributos, y
deja la interpretación de los datos a la aplicación que los utiliza. Por esta razón se van
formando lenguajes a partir del XML, y desde este punto de vista XML es un
metalenguaje.
El conjunto de reglas o convenciones que impone la especificación XML permite diseñar
formatos de texto para los datos estructurados, haciendo que se almacenen de manera no
ambigua, independiente de la plataforma y que en el momento de la recuperación se
pueda verificar si la estructura es la correcta.
Para comprobar que los documentos estén bien formados se utiliza un DTD (Definición
de Tipo de Documento). Se trata de una definición de los elementos que pueden incluirse
en el documento XML, la relación entre ellos, sus atributos, posibles valores, etc. Es una
definición de la gramática del documento [ERDP05], es decir, cuando se procesa
cualquier información formateada mediante XML, el primer paso es comprobar si está
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 35 -
bien formada, y luego, si incluye o referencia a un DTD, comprobar que sigue sus reglas
gramaticales.
En el caso del presente proyecto, XML se utiliza activamente en tareas de configuración,
como pueden ser los ficheros de configuración del descriptor de implementación Servlet
2.4 y los ficheros de mapeo de Hibernate.
4.5 Apache/Tomcat
En el desarrollo del presente proyecto necesitaremos un contenedor web. Los
contenedores web son la puerta de las aplicaciones Java a la World Wide Web. Son
servidores, escritos normalmente en Java, que son capaces de recibir peticiones HTTP y
ejecutar las clases de Java (que a su vez utilizarán recursos tales como páginas HTML e
imágenes) indicadas para darles respuesta, formando lo que se llama una aplicación web.
Además, aunque casi todos incluyen un pequeño servidor web que les permite funcionar
en solitario, normalmente pueden ser integrados con los servidores más conocidos como
Apache.
Las aplicaciones web realizadas en Java pueden tomar dos formas: servlets y páginas
JSP. Las especificaciones de estas tecnologías forman parte de J2EE y como se dijo
anteriormente, su principal cometido es el de crear páginas web dinámicas, es decir,
páginas web que se generan en el servidor en base a nuestra lógica de negocio.
Podemos elegir entre varios contenedores de servlet de código abierto y gratuitos. Los
más conocidos y ampliamente usados en la industria, tanto de forma independiente, como
en conjunto con servidores de aplicaciones, son Jetty [JETT05] y Apache Tomcat
[APAC05].
Jetty lleva en marcha desde 1995 y es la mayor competencia de Tomcat. Aunque el
menor tamaño de su comunidad y de la publicidad que recibe lo hacen pasar más
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 36 -
desapercibido, se trata de un contenedor web muy ligero y que está desarrollado para ser
integrado fácilmente en otras aplicaciones y así proporcionar a estas una interfaz HTTP.
Para la realización de este proyecto utilizaremos Apache Tomcat a pesar de que Jetty se
trate también de una buena solución. Las principales razones de esta decisión son lo
estandarizado que se encuentra Tomcat (es la implementación de referencia para las JSP
y los Servlet), su rendimiento más que aceptable y su contrastada estabilidad.
Apache Tomcat forma parte del proyecto Jakarta. Este proyecto, que se encuentra bajo la
dirección de la Apache Software Foundation (ASF, ampliamente conocida por su
servidor web Apache), desarrolla tecnología orientada a software de construcción de
sitios web. Jakarta está compuesto por varios subproyectos que dan soluciones potentes
basadas en el lenguaje Java a problemas en particular. Entre estos subproyectos se
encuentra Tomcat, que es sin lugar a dudas el proyecto de software libre escrito en Java
más famoso.
Tomcat implementa las especificaciones de los servlets y de las JSP de Sun
Microsystems [CHOP05] e incluye el compilador Jasper que compila las JSPs para
convertirlas en servlets.
Dado que Tomcat fue escrito en Java, funciona en cualquier sistema operativo que
disponga de la máquina virtual. La última versión de Tomcat, Tomcat 5.5, se trata de una
implementación de las especificaciones Servlet 2.4 y JSP 2.0 API.
4.6 Hibernate
Trabajar con software orientado a objetos y bases de datos relacionales puede hacernos
invertir mucho tiempo en los entornos actuales. Hibernate [HIBE05] es una herramienta
que realiza el mapping entre el mundo orientado a objetos de las aplicaciones y el mundo
entidad-relación de las bases de datos en entornos Java. El término utilizado es ORM
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 37 -
(Object/Relational Mapping) y consiste en la técnica de realizar la transición de una
representación de los datos de un modelo relacional a un modelo orientado a objetos y
viceversa.
Hibernate no solo realiza esta transformación sino que nos proporciona capacidades para
la obtención y almacenamiento de datos de la base de datos que nos reducen el tiempo de
desarrollo.
Este tipo de herramientas son necesarias debido a que el modelo de objetos sobre el que
hoy en día se desarrolla la mayor parte del software, no concuerda adecuadamente con el
modelo relacional que se utiliza de forma mayoritaria para el almacenamiento de
información.
La potencia que nos ofrecen los mapeadores objetos/relacionales es realmente
impresionante, y se aprecia en todo su esplendor cuando vemos que gracias a ellos no es
necesario escribir ni una sola línea de código SQL, ni siquiera para llevar a cabo tareas
complejas, como puede ser recuperar colecciones de objetos, o estructuras de herencia.
Hemos elegido Hibernate debido a que en los últimos años se ha convertido en un
estándar de facto en la industria, por encima de otras soluciones realmente estándares. Y
es que Hibernate nos proporciona un método de trabajo muy eficiente y funcional, el cual
se encuentra basado totalmente en torno a lo que se conoce como ficheros de “mapeado”
[RESP05].
Estos ficheros son prácticamente lo único que un programador tiene que desarrollar para
poder acceder a la base de datos, y consisten en unos ficheros con sintaxis XML en los
que se especifica, “mapea”, la relación entre los diversos atributos de nuestras clases y las
filas de las tablas SQL.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 38 -
Estas relaciones pueden ser muy sencillas, como sería el caso de atributos basados en
tipos de datos simples, como pueden ser enteros, cadenas de caracteres, etc. Algo a lo que
el modelo relacional se adapta muy bien, y resulta sencillo pasar a un modelo de objetos.
Sin embargo, los verdaderos problemas entre el modelo relacional y el modelo de objetos
aparecen cuando vemos que en un modelo de objetos resulta muy sencillo implementar
relaciones entre atributos complejos. Por ejemplo, no supone ningún problema que una
clase tenga un atributo que no es tipo de dato simple, sino otra clase, que a su vez puede
tener también otros atributos complejos asociados. O incluso podemos tener atributos que
son colecciones de objetos. Todo ello de una forma natural y sencilla, mientras que esto
no es posible en el mundo relacional.
Y en esta área es donde resultan realmente útiles los “mapeadores” objeto/relaciones.
Como ejemplo, si tenemos que recuperar desde una base de datos relacional un objeto
que pertenece a una clase que tiene como atributo una colección de objetos de otra clase
diferente, primero tendremos que recuperar el objeto que deseamos, y posteriormente a
partir de su clave primaria acceder a la tabla donde se almacenan los objetos de la
colección, recuperarlos y asociarlos al objeto inicial.
Esto da lugar a código bastante complejo y lioso, que hace muy difícil añadir nuevas
relaciones o entidades (clases). Sin embargo, con Hibernate simplemente especificamos
en los ficheros de “mapeado” que la clase tiene un atributo que es una colección, y que
además forma parte de una relación uno a muchos con otra entidad, y cuando
recuperemos un objeto de esa clase, el propio Hibernate, de forma totalmente
transparente, recupera el resto de objetos asociados a el. Esto hace que añadir nuevas
relaciones o clases sea muy sencillo, debido a que solo es necesario crear las nuevas
clases y tablas SQL que necesitemos, y por último definir las asociaciones en los ficheros
de “mapeado”.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 39 -
En la Figura 6 se puede ver un ejemplo de fichero de “mapeado” para Hibernate, que se
utiliza en el proyecto, en el que se describe cual es la clave primaria de la entidad, y a
continuación se describen las diversas propiedades de tipos de datos simples. Para
finalmente definir la relación uno a muchos existente entre la tabla personal y la tabla
equipos.
Figura 6. Fichero de mapeado para Hibernate
Como vemos, Hibernate nos facilita enormemente la tarea de la persistencia desde
aplicaciones orientadas a objetos, y todo ello de una forma muy sencilla, teniendo en la
especificación de los ficheros de “mapeo” la base de toda la herramienta.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 40 -
4.7 MySQL
En el presente proyecto se ha hecho uso de la herramienta MySQL [MYSQ05] para todas
las tareas de almacenamiento de la información. Para la elección del SGBD se ha partido
de que tenía que ser un producto de código abierto y además gratuito.
Otros de los motivos por los que se ha optado por utilizar MySQL es el ser un gestor de
bases de datos sencillo de usar e increíblemente rápido. También es uno de los motores
de bases de datos más usados en Internet y está avalado por empresas de renombre. La
principal razón de esto es el ser gratis para aplicaciones no comerciales.
Las características principales de MySQL [SUEH20] son:
• Es un gestor de base de datos. Una base de datos es un conjunto de datos y un
gestor de base de datos es una aplicación capaz de manejar este conjunto de datos
de manera eficiente y cómoda.
• Es una base de datos relacional. Una base de datos relacional es un conjunto de
datos que están almacenados en tablas entre las cuales se establecen unas
relaciones para manejar los datos de una forma eficiente y segura. Para usar y
gestionar una base de datos relacional se usa el lenguaje estándar de programación
SQL.
• Es Open Source. El código fuente de MySQL se puede descargar y está accesible
a cualquiera, por otra parte, usa la licencia GPL (General Public License) para
aplicaciones no comerciales.
• Es una base de datos muy rápida, segura y fácil de usar. Gracias a la
colaboración de muchos usuarios, la base de datos se ha ido mejorando
optimizándose en velocidad. Por eso es una de las bases de datos más usadas en
Internet.
• Existe una gran cantidad de software que la usa.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 41 -
Para ver la lista de opciones proporcionadas por mysql, lo invocamos con la opción --
help:
shell> mysql --help
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 42 -
4.8 NetBeans IDE
El entorno de desarrollo integrado (Integrated Development Environment, IDE)
NetBeans, es un entorno de programación desarrollado en Java que sirve para escribir,
compilar, probar y depurar aplicaciones. NetBeans es también una plataforma de
ejecución de aplicaciones.
Además de Java, NetBeans soporta gracias a sus módulos muchos otros lenguajes como
pueden ser C, C++, XML, HTML y varias tecnologías [BOUD02] como JSP, RMI,
CORBA, JINI, Servlet, etc.
NetBeans comenzó como un proyecto de estudiantes de la república checa en 1996. Su
nombre original era Xelfi y su objetivo era construir un entorno de desarrollo de
aplicaciones Java parecido a Delfi en Java. Este proyecto desembocó en una empresa
llamada NetBeans que en 1999 fue adquirida por Sun Microsystems.
NetBeans es una aplicación de fuente abierta, es decir, se proporciona el código fuente
del entorno para que se pueda modificar de acuerdo a ciertos parámetros de licencia. A
continuación se enumeran algunas de las características de esta aplicación.
NetBeans incluye herramientas de diseño visual para crear y manipular componentes
visuales, un editor de código con sistema de coloración de la sintaxis y de auto-
completado, anotaciones, macros, identificación automática del código, sistema de
control de versiones, soporte para servlets, etc. junto a una gran cantidad de asistentes y
utilidades de gestión y generación de código.
Para la realización de este proyecto se utilizará la versión NetBeans 4.1. En esta versión
se incluyen novedades que están orientadas hacia el desarrollo de aplicaciones web.
Algunas de estas novedades son los módulos que se añaden para crear y desplegar
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 43 -
JavaBeans, para invocar código de un JavaBean desde un servlet, para crear, registrar y
probar servicios web, así como un designer gráfico que permite configurar visualmente
los JavaBeans, los componentes web, etc.
Desde la página de NetBeans [NETB05] se puede descargar el entorno, y acceder a su
documentación, foros y otros recursos.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 44 -
5 Modelo Vista Controlador (MVC)
Modelo/Vista/Controlador o MVC es un patrón de diseño aportado de forma originaria
por el lenguaje SmallTalk a la Ingeniería del Software. Fue creado por el profesor Trygve
Reenskaug en 1978 cuando trabajaba para Xerox PARC y utilizado como núcleo de la
interfaz de usuario de la implementación del lenguaje SmallTalk-80. En aquellos tiempos
no se utilizaba todavía la palabra patrón, se utilizaba el término MVC.
Desde entonces se ha escrito mucho sobre este paradigma que ha ido evolucionando con
el tiempo. A continuación se van a mostrar las ideas actuales que están más presentes en
la literatura respecto a MVC.
El propósito del patrón MVC es desacoplar los datos, la información de su representación
visual. Para ello divide un componente o subsistema en tres partes: Modelo, Vista y
Controlador. Las responsabilidades de cada una de estas partes se detalla a continuación.
El Modelo:
• Representa las entidades de negocio o los datos y encapsula en ellos el estado de
la aplicación.
• Responde a preguntas sobre su estado.
• Notifica a la vista sus cambios.
La Vista:
• Visualiza el modelo, es su representación gráfica.
• Se encarga de la interacción con el usuario y envía dicha interacción del usuario
sobre ella al controlador.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 45 -
• Recibe notificación de las modificaciones del modelo, para que pueda
actualizarse.
• Permite al controlador seleccionar la vista, ya que puede haber varias.
El Controlador:
• Encaminan las peticiones del usuario.
• Define el comportamiento de la aplicación.
• Convierte las acciones del usuario en modificaciones del modelo.
• Selecciona la vista a devolver.
En el patrón MVC el procesamiento se lleva a cabo entre sus tres componentes. La
relación entre el controlador y el modelo es la siguiente: el controlador recibe una orden y
decide quién la lleva a cabo en el modelo. Una vez que el modelo (la lógica de negocio)
termina sus operaciones devuelve el flujo, que vuelve al controlador. Éste se encarga de
enviar el resultado a la capa de presentación. El controlador en cierta forma debe tener un
registro de la relación entre órdenes que le pueden llegar y la lógica de negocio que le
corresponde (es como una operadora de teléfono que une dos líneas).
En la relación entre el modelo y la vista se debe cumplir que, por un lado, el modelo no
debe conocer nada de la vista. La vista, por otro lado, es la representación visual del
modelo y depende de él.
A diferencia de la relación entre el modelo y la vista, la vista y el controlador tienen una
relación más estrecha. Normalmente, una vista se pasa como referencia al objeto
controlador.
Antes de existir el patrón MVC estas tres partes residían en una única clase, lo que hacía
a las aplicaciones no flexibles y difíciles de reutilizar. Si el cliente está en relación directa
con el modelo, cualquier cambio en el cliente afectará al modelo.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 46 -
La independencia de la presentación, lógica de negocio y acceso a datos se considera
fundamental para el desarrollo de arquitecturas consistentes, reutilizables [GANM95] y
más fácilmente mantenibles, lo que al final resulta en un ahorro de tiempo en el
desarrollo de posteriores proyectos. Además, permite, por ejemplo, aplicar multilenguaje
y distintos diseños de presentación sin alterar la lógica de negocio.
En resumen, MVC es una forma de construir aplicaciones que promueve la separación
completa entre la lógica de negocio y la presentación. No es específico de aplicaciones
web, Java o J2EE, ya que es bastante anterior a esto, pero se puede aplicar, y así lo
promueven estas tecnologías, a la construcción de aplicaciones web J2EE.
5.1 Modelos de diseño: Modelo 1, Modelo 2 y Modelo 2X
Como se dijo anteriormente, la plataforma J2EE sigue una estructura de tres (ó más)
capas. El escenario de aplicación de uso más extendido de la plataforma J2EE es el
siguiente: aplicación distribuida en tres capas y orientada a web.
Se define una capa cliente que proporciona la interfaz de usuario, una capa intermedia
que proporciona servicios a dicha capa cliente y que contiene la lógica de negocio
necesaria para realizar dichos servicios, y una capa final que contiene los sistemas de
información de la empresa.
MVC indica la forma en la que debe descomponerse el sistema y la responsabilidad de
cada uno de estos componentes. J2EE, como plataforma tecnológica, pone al alcance de
la mano la tecnología para conseguirlo.
Generalmente, para el desarrollo de aplicaciones web se utilizan dos modelos de diseño:
el Modelo 1 y el Modelo2.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 47 -
El Modelo 1 es de diseño (arquitectura) de aplicaciones web en la cual las aplicaciones se
componen de una serie de páginas JSP por las que el usuario va pasando. En las páginas
se une la parte visual y la lógica de negocio. Está recomendado para aplicaciones muy
sencillas ya que su problema es el ser difícil de mantener y la falta de flexibilidad.
Además, esta arquitectura no promueve la división entre las labores del diseñador de
páginas web y el desarrollador de aplicaciones web.
A continuación (véase Figura 7) se muestra la arquitectura del Modelo1.
Figura 7. Arquitectura del Modelo 1
La mayoría de las aplicaciones web necesitan el Modelo 2 y se recomienda para
aplicaciones web de mediano y gran tamaño o para aplicaciones que puedan crecer en
complejidad en un futuro. El Modelo 2 es una arquitectura concreta derivada de J2EE
para el desarrollo de aplicaciones web y promueve que se realicen aplicaciones web
siguiendo el patrón MVC. Cada componente de este patrón se implementa en este modelo
de la forma que se explica a continuación.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 48 -
La vista es el interfaz de usuario, las pantallas que pueden ver y con las que puede
interactuar el usuario final de la aplicación. En una aplicación web J2EE las vistas son
ficheros JSP. Estas páginas tienen código que se procesa en el servidor y en función del
resultado generar una página HTML personalizada.
Por ejemplo, para recoger la entrada del usuario se tendrá un JSP que generará una página
HTML que contenga uno o más formularios HTML. Para mostrar la salida (como
informes), se tendrá un JSP que genere una página HTML que probablemente contenga
una o más tablas HTML. Cada una de estas es una vista, un camino para que el usuario
final interactúe con el sistema, introduciendo y obteniendo datos.
Se tiene un servlet actuando como controlador. Como se dijo anteriormente, un servlet es
una clase Java que sabe manejar peticiones y respuestas HTTP. El controlador es el
encargado de coger los datos introducidos por el usuario (en el formulario HTML que
generó la página JSP) y pasarlo al modelo. El modelo es una o varias clases que
contienen la lógica de negocio.
El flujo de control empieza cuando el usuario interactúa con la interfaz de alguna manera
(por ej. presionando un botón o un enlace). Es entonces cuando el contenedor web recibe
una petición desde la aplicación cliente. Todas las peticiones se pasan al controlador, el
cual recibe la notificación de la acción solicitada por el usuario. El servlet controlador
accede al modelo y envía los datos del modelo a la vista delegando a los objetos de esta la
última la tarea de desplegar la interfaz de usuario. Finalmente la interfaz espera por
nuevas interacciones del usuario para iniciar nuevamente el ciclo. Éste es el modelo que
utilizaremos para el desarrollo del presente proyecto. A continuación se muestra la
arquitectura de Modelo2 (véase Figura 8).
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 49 -
Figura 8. Arquitectura de Modelo 2
Como variación tecnológica de este modelo existe otro que consiste en sustituir la parte
JSP por transformaciones de XML y XSL que generan HTML. Es conocido por el
nombre de Modelo 2X [M2X]. Promulga que su utilización proporciona mayor
independencia entre el modelo y la vista.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 50 -
6 Modelado
En esta sección veremos en detalle todo el proceso de análisis y diseño que se ha llevado
a cabo en el presente proyecto. La mayor parte de este trabajo se ha realizado con el
apoyo de una reconocida herramienta como es el lenguaje UML (Unified Modeling
Language). Por ello comenzaremos la sección haciendo una breve introducción a UML,
seguida de la fase de análisis, que está encabezada por el análisis de requisitos en el cual
se realiza un estudio de los Casos de Uso. Posteriormente expondremos brevemente la
arquitectura general del sistema para finalizar con en el proceso de diseño del mismo.
6.1 UML - Lenguaje Unificado de Modelado UML es desde hace bastante tiempo un estándar de facto en la industria para el diseño y
modelado de software. Nace como sucesor de la maraña de métodos de diseño orientado
a objetos que aparecieron a principios de los 90.
Se basa principalmente en una unión de los métodos de Grady Booch, Rumbaugh y
Jacobson, obteniendo de ellos un lenguaje muy potente y expresivo [LARM01], que
puede se utilizado para modelar desde pequeñas aplicaciones para dispositivos
embebidos, a grandes aplicaciones empresariales distribuidas.
Para ello pone a nuestra disposición una sintaxis muy rica, en la forma de diferentes
diagramas y expresiones, cada una con un objetivo concreto y con una semántica bien
definida [FOWL05], que permite que los “planos” del software modelados mediante
UML puedan ser entendidos por cualquier persona, sin caer en un sinfín de
ambigüedades.
Como último comentario acerca de UML, cabe destacar que, a diferencia de la mayoría
de sus antecesores, UML es sólo un lenguaje, no un método. Citando a Martin Fowler:
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 51 -
“La mayoría de los métodos consisten, al menos en principio, en un lenguaje de
modelado y un proceso. El lenguaje es la notación utilizada para expresar los diseños. El
proceso son los consejos de que pasos seguir para llevar a cabo el diseño”. UML
representa, por tanto, la parte del lenguaje de modelado, y deja a elección del
desarrollador el proceso utilizado para guiar las fases de diseño.
6.2 Análisis de requisitos
Comenzaremos la fase de modelado por los requisitos del sistema. Para ello estudiaremos
brevemente cuales serán los usuarios del sistema y algunas de sus características, y nos
centraremos en el estudio de los requisitos funcionales.
6.2.1 Actores del sistema
Dado que el sistema a desarrollar es un sistema gestor, podemos determinar que existirán
dos tipos de usuarios diferenciados por razones de seguridad. Habrá usuarios principales
o administradores que tendrán acceso total al sistema y usuarios normales que sólo
tendrán acceso al sistema para consultar información.
Figura 9. Actores del sistema
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 52 -
6.2.2 Casos de uso
El siguiente paso en nuestro desarrollo consiste en el estudio de los requisitos funcionales
de la aplicación. De este modo tendremos una visión general de cuales son las tareas que
nuestro sistema debe implementar y que debemos diseñar [ALON05]. Para determinar los
componentes que dotarán de funcionalidad a la aplicación debemos definir los casos de
uso. El sistema permitirá realizar las siguientes operaciones:
• Autenticación: El usuario podrá proporcionar al sistema un identificador de
usuario y una contraseña.
• Información: El usuario podrá obtener información de las diferentes entidades
que componen la base de datos del sistema. Es decir, podrá consultar información
de las intervenciones, del personal, de los equipos, de los roles, de los nidos o
almacenes de material, de los materiales de espeleosocorro y la bibliografía.
• Gestión: Engloba toda la funcionalidad relativa al tratamiento de las entidades,
como pueden ser la creación de personal, materiales, intervenciones y equipos, la
asociación o asignación tanto de personal como de materiales y bibliografía a las
intervenciones, la asociación de roles al personal, el cierre de intervenciones, la
generación de informes, etc.
• Generación de informes: el sistema permitirá emitir informes de forma
automatizada.
En la Figura 10 podemos ver un diagrama UML de los casos de uso en el que se modelan
las distintas funcionalidades que necesitan todos los usuarios del sistema.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 53 -
Figura 10. Casos de uso para todos los usuarios
Una vez que conocemos los casos de uso de todos los usuarios, es necesario analizar las
funciones que requerirán los actores que hemos llamado administradores. Los
administradores serán los encargados de administrar todos los recursos, por ello, sus
tareas pasarán por altas, modificaciones, creación de recursos, asignación o asociación de
los mismos, etc. Podemos ver el diagrama de los casos de uso de los administradores en
el diagrama UML de la Figura 11.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 54 -
Figura 11. Casos de uso para el administrador
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 55 -
6.3 Diseño del sistema
A lo largo de esta sección nos centraremos en llevar a cabo la fase de diseño del sistema,
comenzando por aquellas partes más generales como puede ser la arquitectura del
sistema, para ir poco a poco centrándonos en aspectos más detallados del mismo.
6.3.1 Arquitectura general
Es conveniente pararse a analizar la arquitectura general del sistema antes de avanzar más
en el diseño del mismo. Un análisis previo nos permitirá seleccionar adecuadamente las
tecnologías que se van a utilizar en su implementación y nos ayudará posteriormente a
dividir correctamente la funcionalidad entre las diferentes partes de nuestro sistema.
Como se dijo anteriormente en el resumen, el modelo que utilizaremos para el desarrollo
del proyecto será la arquitectura cliente/servidor. Entendiendo por cliente el proceso que
inicia el diálogo o solicita recursos y servidor el proceso que responde a las solicitudes.
En este modelo, las aplicaciones se dividen de forma que el servidor contiene la parte que
debe ser compartida por varios usuarios, y en el cliente permanece sólo lo particular de
cada usuario. Entre las principales características de la arquitectura cliente/servidor,
destacan las siguientes:
• El servidor presenta a todos sus clientes una interfaz única y bien definida.
• El cliente no necesita conocer la lógica del servidor, sólo su interfaz externa.
• El cliente no depende de la ubicación física del servidor, ni del tipo de equipo
físico en el que se encuentra, ni de su sistema operativo.
• Los cambios en el servidor implican pocos cambios en el cliente.
Con el objetivo de definir y delimitar nuestro modelo, debemos identificar los
componentes básicos que permitirán articular dicha arquitectura.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 56 -
Estos componentes son:
• Captación/presentación de información.
• Procesos (la aplicación).
• Manejo de datos.
En la Figura 12 se muestra un diagrama UML que representa como será la arquitectura de
nuestro sistema.
Figura 12. Arquitectura del sistema
En la anterior figura podemos observar los tres componentes básicos del sistema
claramente diferenciados. Por un lado tenemos el cliente, en el cual se maneja la interfaz
de usuario y se generan las consultas sobre la base de datos. A continuación se encuentra
el servidor, donde está toda la lógica de trabajo de la plataforma y que lleva integrado un
contenedor web J2EE (Tomcat). El último componente del sistema será un SGDB que se
utilizará para todas las tareas de persistencia de información necesarias, en nuestro caso
hemos elegido MySQL.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 57 -
6.3.2 Diseño de la aplicación servidora
En nuestro siguiente paso de diseño del sistema, nos centraremos en la arquitectura de la
aplicación servidora, para poder definir con mayor claridad que parte de la lógica se
ejecutará en cada componente del sistema, y después llevar a cabo el diseño detallado de
la implementación de la funcionalidad.
6.3.2.1 Seguimiento de las sesiones
Con los protocolos sin estado, como es el caso de HTTP, cada vez que el cliente obtiene
una página web se abre una conexión y no se guarda nada de las sesiones anteriores, de
este modo, el servidor web no conserva información contextual respecto al cliente. Para
los problemas que provoca esta carencia de contexto existen varias soluciones: las
cookies, la reescritura del URL, los campos ocultos de un formulario, etc.
En el presente proyecto el seguimiento de sesiones se ha implementado utilizando una
solución que consiste en el rastreo de sesiones en los servlets. Los servlets otorgan una
excepcional solución técnica para el rastreo: la API HttpSession. Dicha API utiliza el
objeto HttpSession asociado al HttpServletRequest.
El rastreo de sesiones en los servlets trae consigo el buscar el objeto HttpSession
asociado con la petición en curso, crear un nuevo objeto HttpSession cuando sea
necesario, buscar información asociada con la sesión y descartar las sesiones finalizadas
o abandonadas.
Cada vez que el cliente realiza una petición a un servlet es el contenedor de servlets quien
gestiona la creación o asociación de los objetos sesión que extenderán la funcionalidad
del protocolo HTTP.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 58 -
Para obtener el objeto HttpSession el servlet llama al método getSession(boolean)
del objeto HttpServletRequest. Si éste boolean es true, se crea una sesión nueva si
es necesario, mientras que si es false, el método devolverá la sesión actual en caso de que
exista o una referencia nula en el caso contrario.
Los objetos HttpSession residen en el contenedor y se asocian automáticamente con el
cliente. Estos objetos de sesión cuentan con una estructura de datos incorporada que le
permite almacenar una cantidad de claves y valores asociados sólo limitada por los
recursos disponibles o restricciones de configuración. Las claves actúan como
identificadores únicos en los atributos de la sesión. Para leer el valor de un atributo se
llama al método getAttribute() del objeto HttpSession mientras que para
modificar dicho valor se llama al método setAttribute().
6.3.2.2 Control de acceso a los recursos
En el presente proyecto, para determinar la pertenencia de un usuario a uno de los dos
perfiles que existen en el sistema, y de este modo, poder controlar el acceso a los recursos
de la aplicación, se implementa un atributo de sesión llamado Sid.
El atributo Sid es un identificador de seguridad que se introduce en la sesión y almacena
el nick del usuario, y un boolean que nos indica si la persona autenticada es un
administrador o un usuario normal.
A través del objeto Sid sabremos que permisos tiene el usuario, lectura (r) o
lectura/escritura (rw), y de este modo podremos determinar que operaciones le está
permitido realizar. Cuando el usuario realiza la operación Logoff, el identificador de
seguridad es eliminado de la sesión.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 59 -
6.3.2.3 Lectura de datos del cliente
Cada vez que el usuario selecciona el botón “Enviar” en un formulario o introduce una
URL en el navegador, se genera una cadena de petición. Dicha cadena se compone del
URL y de la cadena de consulta. El servlet controlador tiene que analizar la cadena de
consulta y extraer los campos que debe procesar.
Como se dijo en el apartado 4, cuando se explicó la arquitectura de los servlets, el cliente
utiliza el método GET o POST para enviar información al servlet y dependiendo del
método empleado por el cliente, en el contenedor se llama a doGet() o doPost().
Con los servlets la lectura de los datos del cliente se administra de forma automática en
la aplicación. Simplemente es necesario llamar al método getParameter() del
HttpServletRequest, y proporcionar el nombre del parámetro (con distinción de
mayúsculas y minúsculas) como argumento. El método getParameter() se utiliza
siempre de igual modo, se envíen los datos mediante GET o mediante POST. El servlet
sabrá cuál fue el método de petición utilizado y automáticamente realizará la tarea
adecuada entre bambalinas.
El valor de retorno del método getParameter() será un string con el valor del
parámetro si el cliente lo ha asignado. Si el parámetro existe pero no tiene ningún valor
asignado por el cliente, el valor de retorno será una cadena vacía y si no existe tal
parámetro se devolverá null.
Cuando el parámetro puede tener más de un valor se llama a getParameterValues().
El valor de retorno será una matriz de cadenas donde cada cadena contendrá uno de los
valores del conjunto de parámetros. El método getParameterValues() devuelve null
si no existe el parámetro indicado y solamente contendrá un elemento cuando el
parámetro tenga sólo un valor. Para recuperar los nombres de los campos se utiliza el
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 60 -
método getParameterNames(),el cual no recibe parámetros y nos devuelve una lista
en forma de enumeración.
6.3.2.4 Lógica funcional
La lógica funcional del presente proyecto está encapsulada como llamadas a métodos en
JavaBeans diseñados para este propósito. Los JavaBeans son componentes poderosos y
reutilizables que potencian las aplicaciones con una gran flexibilidad.
Antes de poder acceder a un bean mediante una página JSP, es necesario identificar el
bean y obtener una referencia. El tag <jsp:useBean> intenta obtener una referencia a
una instancia existente especificando un identificador y una visibilidad ya que el bean
puede haber sido creado previamente y colocado en el objeto de sesión por una página
JSP diferente. Si no existe una referencia al objeto con esa identidad dentro del objeto de
sesión, se crea una nueva instancia del bean utilizando el nombre de clase especificado en
el atributo de clase. Una vez que se haya declarado un componente JavaBean ya se tiene
acceso a sus propiedades.
En el presente proyecto para procesar los datos obtenidos de los formularios se seguirá un
patrón de diseño común en el que se asocian los nombres de las propiedades del bean con
los nombres de los campos INPUT del formulario.
Entre los Javabeans que hemos desarrollado tenemos los beans que soportan la lógica de
negocio y los beans de acceso a la base de datos, que siguen el patrón de diseño Data
Access Object (DAO). El objetivo de la lógica de negocio es realizar las actividades que
generan o determinan las respuestas a peticiones realizadas por el cliente. La lógica de
negocio es manejada por varios beans y por el objeto modelo que controlan las
transacciones y encapsulan los resultados.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 61 -
La lógica de acceso a la base de datos describe las transacciones con la base de datos,
implica el almacenamiento o recuperación del contenido recolectado o generado por la
lógica de negocio. Su objetivo es proporcionar un interfaz entre la aplicación y un
conjunto de datos. Los beans DAO abstraen y encapsulan todos los accesos a la fuente de
datos.
Como se ha mencionado anteriormente en el apartado de Tecnologías y Herramientas
empleadas, la aplicación hace uso de Hibernate. Podría creerse entonces que no es
necesario el uso del patrón, ya que Hibernate se encarga de extraer nuestros datos de
modo que no tengamos que trabajar con el modelo relacional. Sin embargo, un enfoque
que prescinda del patrón DAO, haría que una gran parte de nuestro sistema tenga una
dependencia total de Hibernate, que es una herramienta externa a nuestro proyecto y
sobre la cual no tenemos ningún tipo de control. Además no se trata de ningún estándar,
por lo que no resultaría raro que en un futuro se realizasen cambios en la forma de
trabajar del mismo, lo cual nos obligaría a modificar diversas partes del código, y nos
acarrearía importantes problemas de mantenimiento de la aplicación. Por ello, hemos
decidido utilizar extensivamente el patrón DAO, viéndolo más que nada como una
fachada que permite que la mayor parte de nuestro código sea independiente de Hibernate
y, por tanto, del modo en que accedemos a los datos, de forma que si en un futuro se
decide utilizar otra herramienta de “mapeado” objeto/relacional, o incluso otra tecnología
de acceso a datos, se pueda cambiar sin más que modificar el paquete
proyecto.rescate.db.beans.
6.3.2.5 El Gestor de Flujo
En contraste con las aplicaciones estáticas, en las que la sucesión de vistas no es más que
una serie de enlaces que nos llevan de una pantalla a otra, en las aplicaciones dinámicas
la siguiente vista a mostrar al usuario depende de varios factores.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 62 -
Normalmente, la siguiente vista depende de al menos uno de los siguientes factores:
• La vista actual.
• Las acciones realizadas por el usuario.
• La lógica de negocio implementada en el modelo.
• Alguna condición en el lado del servidor.
Por ejemplo, la siguiente página JSP que se mostrará al usuario después de la pantalla de
autenticación dependerá de:
• La vista actual.
• El nick y el password introducido por el usuario.
• El éxito o fracaso de la operación de autenticación.
• Otros factores. Por ejemplo, podría estar limitado el número máximo de usuarios
que pueden estar autenticados dentro del sistema al mismo tiempo.
En el presente proyecto la determinación de cual es la siguiente vista no se deja en
manos del controlador. Cuando el controlador necesita saber cual es la siguiente página
JSP que debe mostrar al usuario, llama al Gestor de Flujo y le pasa el control.
El Gestor de Flujo es una clase java cuya tarea consiste en seleccionar la siguiente vista.
Para ello el gestor utiliza un mapa hash en el cual almacena los pares clave/valor, donde
la clave que es de tipo string almacena el nombre de la operación, y el valor almacena la
vista o página JSP correspondiente a cada operación. Una vez que el Gestor de Flujo
realizó su tarea, le pasa el nombre de la JSP al controlador devolviéndole el control.
6.3.2.6 Procesamiento de peticiones en el servidor
Para diseñar el funcionamiento de la aplicación en el lado del servidor, utilizaremos de
nuevo UML, en concreto los diagramas de secuencia. Estos diagramas nos permitirán
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 63 -
modelar la forma en que trabaja todo el sistema en conjunto para llevar a cabo las tareas.
En la siguiente figura (véase Figura 13) se muestra como se procesa una petición en el
servidor. El proceso especificado en dicho diagrama se lleva a cabo para todas y cada una
de las peticiones que llegan al servidor.
Figura 13. Procesamiento de peticiones en el servidor
En el diagrama anterior se representa la siguiente secuencia de llamadas:
1. El controlador recibe un POST del cliente.
2. Llega la petición del usuario (operación y parámetros) al controlador y este decide
que acción se debe ejecutar dependiendo de la operación solicitada. Una acción es
una clase que contiene un método llamado perform. Este método se programa
para que realice la acción correspondiente.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 64 -
3. El controlador llama al método perform de la acción.
4. El método perform llama al modelo de negocio. El funcionamiento de la
aplicación reside en el módulo del modelo.
5. El controlador llama al Gestor de Flujo que es el encargado de seleccionar cual
será la siguiente vista que se mostrará al cliente.
6. El Gestor de Flujo determina cual es la siguiente vista.
7. El controlador recibe el nombre de la siguiente vista que le envía el Gestor de
Flujo.
8. El controlador retoma el control y es el encargado de montar y direccionar,
forward, la vista seleccionada por el gestor al cliente, finalizando así el
tratamiento del evento.
6.3.2.7 Arquitectura de paquetes del sistema Ya hemos visto como será la distribución física del sistema y el diseño de la parte del
servidor. Por ello ahora vamos a introducir un nuevo modelo que nos permite diseñar
cual será la forma de agrupar las diversas piezas del sistema, tratando así de hacerlas lo
más independientes posible y modelando también las diversas dependencias entre las
mismas.
El código que forma la aplicación contiene paquetes desarrollados para la realización del
proyecto, que son aquellos cuyo nombre empieza por proyecto.rescate, y paquetes
obtenidos de diversos proyectos de software libre. Un paquete es una unidad de software
que contiene clases (u otros componentes) que están relacionados entre sí de alguna
forma. El objetivo de esto es crear unidades lo más aisladas posibles, que puedan ser
mantenidas sin necesidad de tocar otras partes del sistema. Obviamente en un sistema real
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 65 -
esto es imposible, ya que siempre surgen algunas dependencias entre paquetes, por lo que
el objetivo final es minimizar al máximo estas dependencias.
En la Figura 14 se representan los paquetes del sistema mediante un diagrama UML.
Dicho diagrama nos permite ver las diversas piezas de software desarrolladas para el
proyecto, así como otras piezas de terceros sobre las que se apoya el sistema.
Figura 14. Diagrama de paquetes
A continuación haremos un breve repaso de los diversos paquetes implementados, y cual
es el objetivo de cada uno de ellos.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 66 -
1. Paquete proyecto.rescate.acciones: En este paquete está contenida la verdadera
lógica de procesamiento. En el están detalladas las acciones que se requiere que
realice el servidor y las clases formulario de la aplicación. Las acciones son
clases que extienden la clase Accion y que son llamadas para dar respuesta a las
peticiones HTTP del cliente. Para cada formulario de entrada necesario en
nuestra aplicación tendremos una clase FormAccion que se utilizará para que
las clases acción puedan obtener los datos que el usuario introduce. Las clases
que contiene este paquete son:
• Accion.java
• AsociaBibiblioAccion.java
• AsociaBiblioFormAccion.java
• AsociaMaterialesAccion.java
• AsociaMaterialesFormAccion.java
• AsociaPersonalAccion.java
• AsociaPersonalFormAccion.java
• AsociaRolesAccion.java
• AsociaRolesFormAccion.java
• CerrarIntervencionAccion.java
• CerrarIntervencionFormAccion.java
• CreaEquipoAccion.java
• CreaEquipoFormAccion.java
• CreaIntervencionesAccion.java
• CreaIntervencionesFormAccion.java
• CreaMaterialAccion.java
• CreaMaterialFormAccion.java
• CreaPersonaAccion.java
• CreaPersonaFormAccion.java
• GeneraInformeAccion.java
• GeneraInformeFormAccion.java
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 67 -
• HomeAccion.java
ListaBibliografiaAccion.java
• ListaEquiposAccion.java
• ListaIntervencionesAccion.java
• ListaMaterialesAccion.java
• ListaNidosAccion.java
• ListaPersonasAccion.java
• ListaRolesAccion.java
• LogoffAccion.java
• LogonAccion.java
• LogonFormAccion.java
2. Paquete proyecto.rescate.db.beans: En este paquete se encuentran las clases
JavaBeans que han sido creadas para soportar todos los requerimientos de
funcionalidad, tanto los beans de la lógica de negocio como los beans DAO.
Las clases que contiene este paquete son:
• Bibliogafia.java
• BibliografiaDao.java
• BibliografiaIntervencion.java
• BibliografiaIntervencionDao.java
• Equipo.java
• EquipoDao.java
• Informe.java
• Intervencion.java
• IntervencionDao.java
• Material.java
• MaterialDao.java
• MaterialIntervencion.java
• MaterialIntervencionDao.java
• Nido.java
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 68 -
• NidoDao.java
• Persona.java
• PersonaDao.java
• PersonalIntervencion.java
• PersonalIntervencionDao.java
• Rol.java
• RolDao.java
• RolPersonal.java
• RolPersonalDao.java
3. Paquete proyecto.rescate.errores: Este paquete sólo contiene una clase que
encapsula y abstrae el mensaje de error que visualizará la página JSP destinada a
esta función cuando ocurre un error o excepción en la aplicación. Las clases que
contiene este paquete son:
• Error.java
4. Paquete proyecto.rescate.modelos: En este paquete se encuentran todas las
funciones que albergan lo que se denomina “lógica de negocio”. Es decir, las
funciones más “pequeñas” con significado: crear una nueva entrada en la tabla
personal, obtener un listado de las intervenciones o rescates realizados, etc.
Básicamente contiene la funcionalidad de la aplicación y es utilizado para
manejar los datos y controlar todas sus transformaciones. Las clases que
contiene este paquete son:
• Modelo.java
5. Paquete proyecto.rescate.servlets: Este paquete contiene el controlador que
está diseñado en forma de servlet. Las clases que contiene este paquete son:
• Controlador.java
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 69 -
6. Paquete proyecto.rescate.utils: Este paquete contiene el Gestor de Flujo (un
mapa hash que nos permite saber cual es la siguiente vista), unas clases de
Hibernate personalizadas, y la clase Sid (identificador de seguridad). Las clases
que contiene este paquete son:
• GestorFlujo.java
• HibernateFilter.java
• HibernateSessionFactory.java
• HibernateUtil.java
• Sid.java
Además de estos paquetes, el código de la aplicación contiene una serie de páginas JSP
que forman la vista. Estas páginas se encuentran en los directorios
Espeleosocorrismo\WebPages\form y Espeleosocorrismo\WebPages\view.
6.3.3 Diseño de la base de datos
Para el diseño de la base de datos [DEMI01], en la que se almacenará toda la información
persistente que manejará nuestro sistema, se ha utilizado el esquema E/R extendido
(Entidad/Relación extendido). Realizar dicho diseño requiere examinar las tareas que se
encomendarán a nuestra aplicación con el objetivo de averiguar que información
tendremos que almacenar en la base de datos.
Haciendo un análisis de los requisitos de la aplicación podemos detectar las siguientes
entidades: roles, personal, equipos, intervenciones, bibliografía, materiales y nidos.
Además, junto con estas entidades se introducen en el esquema las siguientes tablas que
surgen de interrelaciones del tipo muchos a muchos (NaN): rol_personal,
personal_intervención, bibliografía_intervención y materiales_intervención.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 70 -
En la siguiente figura (véase Figura 15) se puede ver el esquema E/R extendido de la base
de datos del presente proyecto.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 71 -
Figura 15. Esquema E/R extendido
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 72 -
A continuación se muestra un diccionario de datos con el fin de explicar los diferentes
elementos del esquema.
Diccionario de datos
Tablas:
Tabla roles
En esta tabla se almacenan todos los roles de los miembros del Grupo de
Espeleosocorro.
Atributos
• id_rol: Numérico. Clave primaria, el identificador de cada rol.
• rol: Numérico. Es el nombre del rol.
Tabla personal
En esta tabla se almacenan los datos de todo el personal de espeleosocorro.
Atributos
• id_personal: Numérico. Clave primaria. Identifica a cada miembro
del grupo.
• id_equipo: Numérico. Clave foránea. Se utiliza para relacionar a un
miembro del grupo con el equipo de espeleosocorro al que pertenece.
• nick: Texto. Es el nombre que tiene el miembro del grupo de
espeleosocorro dentro del sistema.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 73 -
• password: Texto. Es la clave que tiene el miembro del grupo para
acceder al sistema.
• fecha_ingreso: Timestamp. Es la fecha en la que se ingresa en el
grupo de espeleosocorro.
• nombre: Texto. Es el nombre del miembro del grupo.
• nif: Texto. Es el NIF del miembro del grupo.
• telefono1: Texto. Es el primer teléfono de contacto con el miembro
del grupo.
• telefono2: Texto. Es el segundo teléfono de contacto con el
miembro del grupo.
• direccion: Texto. Es la direccion del miembro del grupo.
• disponible: Texto. Este atributo nos indica si el miembro se
encuentra disponible para realizar un rescate.
Tabla equipos
En esta tabla se almacenan todos los equipos que forman el espeleosocorro.
Atributos
• id_equipo: Numérico. Clave primaria. Identifica al equipo en el
sistema.
• nombre: Texto. Es el nombre del equipo.
• zona: Texto. Indica la zona geográfica en la que se encuentra el
grupo.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 74 -
Tabla intervenciones
En esta tabla se almacenarán todas las intervenciones realizadas con su
correspondiente historial.
Atributos
• id_intervención: Numérico. Clave primaria. Identifica a la
intervención.
• antecedentes: Texto. Describe los antecedentes de la intervención.
• cronología: Texto. Describe la cronología de la intervención.
• informe: Texto. Describe el informe de la intervención.
• conclusiones: Texto. Describe las conclusiones de la intervención.
• lugar: Texto. Describe el lugar de la intervención.
• accidentados: Texto. Describe datos personales de los
accidentados.
• tipo: Texto. Describe el tipo de intervención (real/práctica).
• fecha_inicio: Timestamp. Indica la fecha de inicio del rescate.
• fecha_fin: Timestamp. Indica la fecha de finalización del rescate.
Tabla bibliografía
En esta tabla se almacena toda la bibliografía relevante relacionada con el
espeleosocorro.
Atributos
• id_bibliografia: Numérico. Clave primaria. Es el identificador de
libro dentro del sistema.
• titulo: Texto. Es el título del libro
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 75 -
Tabla materiales En esta tabla se almacenan todo el material disponible.
Atributos
• id_material: Numérico. Es el identificador del material dentro del
sistema.
• id_nido: Numérico. Clave foránea. Se utiliza para relacionar un
material con el nido al que pertenece.
• descripción: Texto. Es la descripción del material.
• fecha_compra: Timestamp. Indica la fecha en la que se adquirió el
material.
• disponible: Texto. Indica si el material se encuentra disponible
para ser utilizado.
Tabla nidos En la tabla nidos se almacenan todos los nidos existentes. Un nido es un
almacén de materiales.
Atributos
• id_nido: Numérico. Clave principal. Es el identificador del nido
dentro del sistema.
• nombre: Texto. Es el nombre que recibe el nido.
• situacion: Texto. Indica la situación geográfica en la que se
encuentra el nido.
Tabla rol_personal Esta tabla surge de la relación que existe entre la tabla roles y la tabla personal por
tratarse de una relación muchos a muchos.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 76 -
Atributos
• id_rol_personal: Numérico. Clave principal.
• id_rol: Numérico.Clave foránea.
• id_personal: Numérico. Clave foránea.
Tabla personal_intervencion Esta tabla surge de la relación que existe entre la tabla personal y la tabla
intervenciones por tratarse de una relación muchos a muchos.
Atributos
• id_personal_intervencion: Numérico. Clave principal.
• id_personal: Numérico.Clave foránea.
• id_intervencion: Numérico. Clave foránea.
• estado: Texto. Nos indica el estado en que se encontraba durante la
intervención cada miembro del grupo. Los posibles estados son:
movilizado, en centro de coordinación, concentrado en prealerta, en
prealerta, localizado no disponible y no localizado.
Tabla bibliografia_intervencion Esta tabla surge de la relación que existe entre la tabla bibliografía y la tabla
intervenciones por tratarse de una relación muchos a muchos.
Atributos
• id_bibliografial_intervencion: Numérico. Clave principal.
• id_bibliografia: Numérico.Clave foránea.
• id_intervencion: Numérico. Clave foránea.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 77 -
Tabla materiales_intervencion Esta tabla surge de la relación que existe entre la tabla materiales y la tabla
intervenciones por tratarse de una relación muchos a muchos.
Atributos
• id_materiales_intervencion: Numérico. Clave principal.
• id_materiales: Numérico.Clave foránea.
• id_intervencion: Numérico. Clave foránea.
Interrelaciones
Interrelación rol_personal Una persona tiene obligatoriamente como mínimo un rol y un mismo rol lo
pueden tener de 1 a N personas.
Interrelación personal_equipos Una persona tiene que pertenecer obligatoriamente a un equipo y sólo a uno y un
equipo puede tener de 1 a N personas.
Interrelación personal_intervencion Una persona del grupo de espeleosocorro puede haber participado en 0 ó N
intervenciones, mientras que en una intervención pueden haber trabajado de 1 a
N personas.
Interrelación bibliografia_intervencion Un libro puede haber sido utilizado en 0 ó N intervenciones y en una misma
intervención se pueden haber usado de 0 a N libros.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 78 -
Interrelación materiales_intervencion Un mismo material puede haber sido utilizado en 0 ó N intervenciones y en
una intervención también se pueden haber utilizado de 0 a N materiales.
Interrelación materiales_nidos Un material en concreto ha de pertenecer a un nido y sólo a uno, mientras que un
nido puede tener de 0 a N materiales.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 79 -
Figura 16. Esquema relacional completo de la base de datos
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 80 -
6.3.6 Interfaz gráfica
A continuación veremos las diversas pantallas de la interfaz gráfica de usuario, así como
la funcionalidad desplegada en cada una de ellas.
Autenticación:
Figura 17. Pantalla de autenticación
En la Figura 17 se muestra la primera pantalla, es la que utiliza el usuario para
proporcionar al sistema su identificador y su password. En las siguientes figuras (véase
Figura 18 y Figura 19) se muestra la pantalla de entrada a la aplicación. Esta pantalla
varía dependiendo de si la persona autenticada se identificó como administrador del
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 81 -
sistema (en nuestro caso el administrador del sistema será el coordinador) o como
usuario (todos los miembros del grupo de espeleosocorro que no sean coordinadores o
coordinadores suplentes se identificarán como usuarios).
Entrada del administrador a la aplicación:
Figura 18. Pantalla de inicio del administrador
En todas las páginas de la aplicación se puede observar el identificador con el que está
autenticado el usuario además de los permisos que tiene el mismo. En la Figura 18 se
muestra la página de inicio del administrador. El administrador tendrá permisos (rw), esto
significa que podrá crear personal, crear materiales, crear intervenciones, crear equipos,
generar informes, asociar tanto personal como materiales y bibliografía a una
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 82 -
intervención y hacer listados de todos los datos almacenados en la Base de Datos
relacional como puede verse en el panel de gestión.
Entrada de cualquier usuario a la aplicación:
Figura 19. Pantalla de inicio de los usuarios
En la Figura 19 se muestra la pantalla de inicio de todos los usuarios que no sean
administradores. Estos usuarios tendrán permiso (r). Este permiso tan sólo les permitirá
consultar información. Podrán hacer listados completos de todas las intervenciones
realizadas, listar todo el personal de espeleosocorro, los roles, los equipos, los materiales
de los que dispone el grupo, los nidos en los que se encuentran dichos materiales y la
bibliografía existente.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 83 -
Crear un usuario:
Figura 20. Creación de un usuario
Para incorporar personal hay que seleccionar la opción “Crear personal” del Panel de
Gestión. Cuando se crea una nueva entrada en la tabla personal hay que cubrir datos
personales (véase Figura 20) como son el nombre, el nif, dos teléfonos de contacto y la
dirección. Además hay que introducir un identificador de usuario (nick) y un password
que serán los que utilice el nuevo miembro del grupo de espeleosocorro para acceder al
sistema. También hay que indicar la fecha de ingreso en el grupo y si se encuentra
disponible o no para prestar sus servicios ante una llamada de emergencia. Finalmente es
necesario marcar el equipo al que el nuevo miembro va a ser asignado.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 84 -
Listar personal:
Figura 21. Listado del personal
Para poder realizar listados del personal es necesario seleccionar la opción “Listar
personal” en el Panel de Gestión. En la Figura 21 se muestra un listado de todo el
personal del grupo de espeleosocorro.
Este listado puede ser utilizado entre otras cosas para obtener de forma inmediata una
relación de todo el personal disponible y de sus datos personales. El poder manejar toda
esta información de una forma rápida y sencilla es muy importante a la hora de planificar
un rescate, ya que nos permite conocer los teléfonos de contacto, saber que personal está
disponible y dentro del personal disponible determinar que miembros del grupo se
pueden encontrar más próximos al lugar del accidente.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 85 -
Crear un nuevo material:
Figura 22. Creación de un nuevo material
Para introducir un nuevo material en la base de datos es necesario seleccionar la opción
“Crear material” en el Panel de Gestión.
En la Figura 22 se muestra como introducir un nuevo material de espeleosocorro en la
base de datos. Cuando se crea una nueva entrada para un material es necesario indicar
una descripción del material, la fecha de compra y marcarlo como disponible. Además,
hay que marcar el nido al que va a ser asignado dicho material
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 86 -
Listar materiales:
Figura 23. Listado de los materiales
Para realizar un listado de materiales tan sólo hay que seleccionar la opción “Listar
materiales” del Panel de Gestión. En la Figura 23 se muestra un listado del material
disponible.
En el listado aparece una descripción del material, su fecha de compra, si está o no
disponible (si no está disponible es porque fue asociado a una intervención y se está
utilizando en un rescate o está pendiente la evaluación del estado de dicho material) y el
nido al que pertenece el material.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 87 -
Crear un equipo:
Figura 24. Creación de un equipo
En la Figura 24 se muestra como crear un nuevo equipo. Para crear un equipo tan solo
hay que seleccionar la opción “Crear equipo” en el Panel de Gestión e indicar la zona en
la que va a encontrarse y el nombre que va a recibir dicho equipo.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 88 -
Listar equipos:
Figura 25. Listado de los equipos
En la Figura 25 se muestra el resultado de seleccionar la opción “Listar equipos” en el
Panel de Gestión. Esta opción realiza un listado de todos los equipos en el que se puede
ver tanto la zona en la que se encuentran como el nombre de los mismos.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 89 -
Listar roles:
Figura 26. Listado de los roles
En la Figura 26 se muestra el resultado de seleccionar en el Panel de Gestión la opción
“Listar roles”. Esa opción lista todos los roles que hay en el espeleosocorro.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 90 -
Asociar roles:
Figura 27. Asociación de roles
En la Figura 27 se muestra la funcionalidad de la opción “Asociar roles” del Panel de
Gestión. Esta opción nos permite seleccionar a un miembro del espeleosocorro de entre
todos los existentes y asociarle uno o más roles.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 91 -
Listar nidos:
Figura 28. Listado de los nidos
En la Figura 28 se muestra el resultado de seleccionar en el Panel de Gestión la opción
“Listar nidos”. El listado resultante nos permite ver los nidos disponibles junto a su
situación y el nombre que reciben.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 92 -
Listar bibliografía:
Figura 29. Listado de la bibliografía
La Figura 29 nos muestra que ocurre si seleccionamos en el Panel de Gestión la opción
“Listar bibliografía”. Como se puede ver se crea un listado con toda la bibliografía
disponible relacionada con el dominio del espeleosocorro.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 93 -
Crear intervención:
[PANTALLAS DEL ENTORNO NO DISPONIBLES POR RAZONES DE
CONFIDENCIALIDAD]
Figura 30. Creación de una intervención
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 94 -
En la Figura 30 se muestra el proceso de alta de una intervención. Cuando seleccionamos
“Crear intervención” en el Panel de Gestión nos encontramos con un formulario para
cubrir los datos de la intervención.
Entre los datos que hay que cubrir están el tipo de intervención (real o práctica), el lugar
en el cual ocurrió el accidente, las fechas de inicio y de fin del rescate, los datos de los
accidentados, los antecedentes, la cronología, el informe realizado por los
espeleosocorristas que realizaron el rescate y las conclusiones.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 95 -
Listar intervenciones:
[PANTALLAS DEL ENTORNO NO DISPONIBLES POR RAZONES DE
CONFIDENCIALIDAD]
-
Figura 31. Listado de las intervenciones
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 96 -
En la Figura 31 se muestra la funcionalidad de la opción “Listar intervenciones” del
Panel de Gestión. Cuando se selecciona esta opción se realiza un listado de todas las
intervenciones realizadas.
Asociar bibliografía a una intervención:
Figura 32. Asociación de bibliografía
En la Figura 32 se muestra la funcionalidad de la opción “Asociar bibliografía” del Panel
de Gestión. Esta opción nos permite seleccionar una intervención y asociarle la
documentación utilizada para la realización del rescate de entre toda bibliografía
disponible. Destacar en este sentido lo relacionado con los trabajos de topografía de la
cueva involucrada en el rescate.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 97 -
Asociar personal a una intervención:
Figura 33. Asociación de personal
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 98 -
En la Figura 33 se muestra la funcionalidad de la opción “Asociar personal” del Panel de
Gestión. Esta opción nos permite asignar personal a una intervención. Para ello nos
muestra una pestaña en la que tenemos que seleccionar la intervención a la que queremos
asociar el personal y un listado del personal que se encuentra disponible.
Fijándonos en la parte inferior de la figura podemos observar como si queremos hacer
otra asociación de personal a una nueva intervención tan solo tenemos disponible el
personal que no se encuentra movilizado y asignado.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 99 -
Asociar materiales a una intervención:
Figura 34. Asociación de materiales
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 100 -
En la Figura 34 se muestra como asociar materiales a una intervención. La operación
“Asociar materiales” del Panel de Gestión es muy similar a la operación “Asociar
personal”. Nos permite seleccionar todos los materiales que queramos de entre los que se
encuentran disponibles y asignarlos a una intervención en concreto.
En la parte inferior de la figura se puede observar que, al igual que con “Asociar
personal”, a medida que vamos asociando material a las intervenciones nos va quedando
menos material disponible.
Generar informe:
Figura 35. Selección de una intervención para generar su informe
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 101 -
En la Figura 35 se muestra la opción “Generar informe” del Panel de Gestión. Para
generar el informe de una intervención tan sólo tenemos que seleccionar la intervención
de la cual queremos generar dicho informe.
Informe generado:
[PANTALLAS DEL ENTORNO NO DISPONIBLES POR RAZONES DE
CONFIDENCIALIDAD]
Figura 36. Informe generado
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 102 -
En la Figura 36 se puede observar el resultado de ejecutar la opción “Generar informe”
del Panel de Gestión. En la generación de un informe se ven implicadas todas las tablas
de la base de datos, esto es debido a que en dicho informe se incluyen datos de la
intervención (tipo, fecha de inicio, fecha de finalización, antecedentes, cronología,
informe, conclusiones y accidentados), datos del personal de espeleosocorro involucrado
en la misma (nombre, estado durante el rescate, roles y equipos), datos del material
utilizado (descripción y nido) y datos de la bibliografía utilizada.
Cerrar intervención:
Figura 37. Cierre de una intervención
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 103 -
En la Figura 37 se muestra la opción “Cerrar intervención” del Panel de Gestión. Esta
opción nos permite seleccionar una intervención de entre todas las que se encuentran
abiertas y cerrarla.
El hecho de cerrar una intervención tiene como consecuencia la liberación de todos los
recursos que se habían asignado a dicha intervención. De este modo, tanto el personal
como los materiales que estaban asociados a la intervención y que por tanto aparecían
marcados como no disponibles, pasan a estar disponibles.
7 Conclusiones y desarrollos futuros Tras el desarrollo y la posterior evaluación del presente proyecto se ha demostrado que
presenta las cualidades necesarias para cumplir los objetivos marcados, aunque tan sólo
se trate de una primera aproximación hacia la obtención de un sistema gestor realmente
completo.
Estas cualidades reducen la complejidad de la organización de los rescates y hacen
sencilla la documentación de las intervenciones y la generación de forma automática de
informes de las mismas.
Debido al desacoplamiento entre los distintos componentes de la aplicación, es fácil
ampliar la funcionalidad de la misma y modificarla, lo que quiere decir que se ha
conseguido una aplicación que sigue el modelo MVC. Además, cada uno de los
componentes de esta arquitectura (Modelo, Vista y Controlador) cumple con su
responsabilidad. El planteamiento propuesto por el Modelo 2 fue de gran ayuda, en
especial a la hora de diseñar el componente controlador.
Como hemos comentado anteriormente, el presente proyecto se puede considerar una
primera aproximación, y sin duda tiene áreas en las que todavía queda mucho por hacer
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 104 -
para conseguir una herramienta realmente potente, como por ejemplo en la tarea de
planificación de rescates, gestión de tiempos, etc.
Se puede concluir diciendo que la tecnología utilizada ha ayudado al diseño y desarrollo
de la aplicación.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 105 -
Bibliografía [FEDE98] Federación Francesa de Espeleología. “Manual del espeleosocorrista”.
Graphic 2000. 1998.
[ALLE00] Allen, M. “Estructuras de datos en Java”. Addison Wesley.2000.
[KEOG02] Keogh, J. “J2EE: The Complete Referente”. The McGraw-Hill Companies.
2002.
[HUNT98] Hunter, J., Crawford, W. “Java Servlet Programing”. O'Reilly & Associates.
1998.
[HALL01] Hall, M. “Servlets y JavaServer Pages. Guía Práctica”. Pearson Educación.
2001.
[MCLA00] McLaughlin, B. “JAVA and XML”. O'Reillyand & Associates. 2000.
[CHOP05] Chopra, V., Bakore, A., Eaves, J., Galbraith, B., Sing, L., Wiggers, C.
“Profesional Apache Tomcat 5”. Ediciones Anaya Multimedia (Grupo Anaya, S.A).
2005.
[SUEH02] Suehring, S. “MySQL Bible”. New York, USA. 2002.
[TURN02] Turner, J. “MySQL and JSP Web Applications: Data driving programing
using Tomcat and MySQL”. Sams Publishing. 2002.
[MATT03] Matthews, M., Cole, J., Gradecki, J.D. “MySQL and Java Developers
Guide”. Wiley Publishing. 2003.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 106 -
[JAME03] James R. Groff, P., Weinberg, N. “SQL: The Complete Referente”. The
McGraw-Hill Companies. 2003.
[BOUD02] Boudreau, T., Glick, J., Greene, S., Spurlin, V., Woehr, J.J “NetBeans: The
Definitive Guide”. O'Reilly & Associates. 2002.
[GANM95] Ganma, E., Helm, R., Johnson, R., Vlissides, J. “Desing Patterns: Elements
of Reusable Object-Oriented Software”. Addison-Wesley Professional. 1995.
[ALON05] Alonso, F., Martinez, L., Segovia, F. “Introducción a la Ingeniería del
Software. Modelos de desarrollo de programas”. Delta Publicaciones Universitarias.
2005.
[LARM01] Larman, C. “Applying UML and Patterns: An Introducction to Object-
Oriented Analysis an Desing and Unified Process (2nd Ed.)”. Prentice Hall PTR. 2001.
[FOWL99] Fowler, M., Scott, K. “UML Distilled”. Addison-Wesley. 1999.
[DEMI01] de Miguel, A., Martinez, P., Castro, E., Cavero, M., Cuadra, D., Iglesias, A.,
Nieto, C. “Diseño de Bases de Datos. Problemas resueltos”. RA-MA Editorial.2001.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 107 -
Enlaces electrónicos
[JAVA04] Web oficial de Java.
http://java.sun.com, 2004.
[COMU05] Comunidad JavaHispano.
http://www.javahispano.com, 2005.
[MICR05] Web oficial de Microsoft.
http://www.microsoft.com/net, 2005.
[RESJ04] Revista electrónica sobre J2EE.
http://www.theserverside.com, 2004.
[ERDP05] Revista electrónica sobre progamación.
http://www.elrincondelprogramador.com, 2005.
[JETT05] Web oficial de Jetty.
http://jetty.mortbay.org, 2005.
[APAC05] Web oficial de la Apache Software Foundation.
http://www.apache.org, 2005.
[MYSQ05] Web oficial de MySQL.
http://www.mysql.com,2005.
[NETB05] Web oficial de NetBeans.
http://www.netbeans.org, 2005.
Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos
- 108 -
[HIBE05] Web oficial de Hibernate.
http://www.hibernate.org, 2005.
[RESP05] Revista electrónica sobre programación.
http://www.programacion.com, 2005.