copia de memoria - tic.udc.esnino/fotos/proyectos/proyecto-espeleo... · diseño e implementación...

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!.


- 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


- 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


- 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


- 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


- 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).


- 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.


- 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.


- 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.


- 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.


- 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


- 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.


- 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


- 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


- 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.


- 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


- 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.


- 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.


- 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.


- 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.


- 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.


- 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


- 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


- 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.


- 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.


- 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().


- 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.


- 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


- 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.


- 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.


- 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.


- 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á


- 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


- 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


- 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.


- 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”.


- 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.


- 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.


- 41 -

Para ver la lista de opciones proporcionadas por mysql, lo invocamos con la opción --

help:

shell> mysql --help


- 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


- 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.


- 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.


- 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.


- 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.


- 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.


- 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).


- 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.


- 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:


- 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


- 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.


- 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.


- 54 -

Figura 11. Casos de uso para el administrador


- 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.


- 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.


- 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.


- 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.


- 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


- 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.


- 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.


- 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


- 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.


- 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


- 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.


- 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


- 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


- 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


- 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.


- 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.


- 71 -

Figura 15. Esquema E/R extendido


- 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.


- 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.


- 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


- 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.


- 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


Atributos

• id_bibliografial_intervencion: Numérico. Clave principal.

• id_bibliografia: Numérico.Clave foránea.



- 77 -

Tabla materiales_intervencion Esta tabla surge de la relación que existe entre la tabla materiales y la tabla


Atributos

• id_materiales_intervencion: Numérico. Clave principal.

• id_materiales: 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.


- 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.


- 79 -

Figura 16. Esquema relacional completo de la base de datos


- 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


- 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


- 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.


- 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.


- 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.


- 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


- 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.


- 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.


- 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.


- 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.


- 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.


- 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.


- 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.


- 93 -

Crear intervención:

[PANTALLAS DEL ENTORNO NO DISPONIBLES POR RAZONES DE

CONFIDENCIALIDAD]

Figura 30. Creación de una intervención


- 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.


- 95 -

Listar intervenciones:


CONFIDENCIALIDAD]

-

Figura 31. Listado de las intervenciones


- 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.


- 97 -

Asociar personal a una intervención:

Figura 33. Asociación de personal


- 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.


- 99 -

Asociar materiales a una intervención:

Figura 34. Asociación de materiales


- 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


- 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:


CONFIDENCIALIDAD]

Figura 36. Informe generado


- 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


- 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


- 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.


- 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.


- 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.


- 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.


- 108 -

[HIBE05] Web oficial de Hibernate.

http://www.hibernate.org, 2005.

[RESP05] Revista electrónica sobre programación.

http://www.programacion.com, 2005.

copia de memoria - tic.udc.esnino/fotos/proyectos/proyecto-espeleo... · diseño e implementación...

Documents