Professional Documents
Culture Documents
EL TRIBUNAL
Presidente:
Vocal:
Secretario:
VOCAL
SECRETARIO
PRESIDENTE
Agradecimientos
A mis padres, a quienes debo su trabajo y dedicacin para darme una formacin
profesional.
A Mariano, Jose y Eduardo por sus consejos y motivaciones constantes.
A Paola, por su apoyo incondicional.
A mi tutor, Javier, por haberme guiado.
Gracias a todos!
Resumen
En los ltimos tiempos, las redes sociales han adquirido una importancia notable y
aplicaciones como Tuenti, Twitter o Facebook resultan familiares para cualquier usuario
de la red. Con la llegada de la Web 2.0, las redes sociales en Internet ocupan un lugar
relevante en el campo de las relaciones personales. Gracias a ellas, podemos
interactuar con facilidad con nuestros amigos o conocer gente nueva sin ningn
esfuerzo.
En nuestro pas, varias de estas redes sociales gozan de gran popularidad. Sin embargo,
la mayora de ellas se basan en la participacin colectiva a travs de colaborar y
compartir con otros usuarios ya conocidos.
En ciertas ocasiones, el usuario desea realizar una actividad y necesita encontrar otros
usuarios con sus mismas aficiones.
Existen algunas aplicaciones para llevar a cabo esta labor, pero desafortunadamente no
son muy populares en nuestro pas.
El proyecto que se detalla a continuacin pretende dar una solucin concreta a este
problema. Se trata de una aplicacin para crear y administrar eventos y buscar usuarios
a los que les pueda interesar dicho evento. Igualmente se pueden buscar eventos que
hayan sido creados con anterioridad. La aplicacin ha sido diseada para ser intuitiva y
fcil de usar por el usuario.
A lo largo de las siguientes pginas se dar un repaso a las tecnologas que se han usado
as como la evolucin histrica de las mismas. Tambin se har hincapi en el diseo e
implementacin de la aplicacin web.
Abstract
In recent years, social networks have gained significant importance and applications
such as Tuenti, Twitter or Facebook are familiar to any network user. With the advent of
Web 2.0, social networking sites occupy a prominent place in the field of personal
relationships.
Thanks to them, we can interact easily with our friends or meet new people without any
effort.
In our country, several of these social networks are popular. However, most of them are
based on collective participation through collaboration and sharing with others already
known.
Sometimes, the user wants to perform an activity and need to find other users with
similar interests.
There are some applications to perform this task, but unfortunately are not very
popular in our country.
The project described below is intended to give a concrete solution to this problem.
This is an application for creating and managing events and find users who may be
interested that event. Also you can search events that have been previously created.
The application has been designed to be intuitive and easy to use by the user.
Throughout the following pages will give an overview of the technologies that have
been used as well as the historical evolution of the same. It also will focus on the design
and implementation of the web application.
ndice general
CAPITULO 1. INTRODUCCIN Y OBJETIVOS . . . . . . . . . . . . . . . . . . . .
1.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.
1.3.
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.
Contenido
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.
Introduccin
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.
Web 2.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1.
2.3.
Redes sociales
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
10
2.3.1.
AJAX
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.2.
CSS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3.3.
. . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.
2.5.
Frameworks J2EE
2.6.
Spring 3
13
. . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.6.1.
Introduccin e historia
. . . . . . . . . . . . . . . . . . . . . . .
16
2.6.2.
Novedades de Spring 3
. . . . . . . . . . . . . . . . . . . . . . .
17
2.6.3.
Arquitectura de Spring
. . . . . . . . . . . . . . . . . . . . . . .
18
2.6.3.1.
Contenedor Central
. . . . . . . . . . . . . . . . . . . .
2.6.3.2.
Acceso a datos/Integracin
. . . . . . . . . . . . . . . .
19
23
2.7.
2.6.3.3.
Spring AOP
2.6.3.4.
Hibernate
. . . . . . . . . . . . . . . . . . . . . . . . .
25
. . . . . . . . . . . . . . . . . . . . .
27
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.7.1.
Caractersticas
. . . . . . . . . . . . . . . . . . . . . . . . . . .
31
2.7.2.
Ventajas
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
2.7.3.
Componentes bsicos
2.7.4.
Conclusiones
. . . . . . . . . . . . . . . . . . . . . .
33
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
2.8.1.
Persistencia
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
2.8.2.
Interfaces JPA
. . . . . . . . . . . . . . . . . . . . . . . . . . .
36
2.8.3.
Anotaciones
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
2.8.4.
2.8
JPA
CAPITULO 3. ANLISIS
. . . . . . . . . . . . . . . .
39
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.1.
Introduccin
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.
Requisitos de usuario
. . . . . . . . . . . . . . . . . . . . . . . . . . .
41
41
3.2.1.
Requisitos de capacidad
. . . . . . . . . . . . . . . . . . . . . .
42
3.2.2.
Requisitos de restriccin
. . . . . . . . . . . . . . . . . . . . . .
47
3.3.
. . . . . . . . . . . . . . . . . . . . . .
48
3.4.
Entorno operacional
. . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.5.
Casos de uso
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
3.6.
3.7.
3.8.
. . . . . . . . . . . . . . . . . . . . . . . .
63
. . . . . . . . . . . . . . . . . . . . . . . . .
67
Matrices de trazabilidad
. . . . . . . . . . . . . . . . . . . . . . . . .
74
CAPITULO 4. DISEO
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
4.1.
Introduccin
4.2.
4.3.
4.4.
Diseo de la interfaz
CAPITULO 5. IMPLEMENTACIN
CAPITULO 6. PRUEBAS
. . . . . . . . . . . . . . . . . . . . . . . .
78
. . . . . . . . . . . . . . . . . . . . . . .
82
. . . . . . . . . . . . . . . . . . . . . . . . . .
85
. . . . . . . . . . . . . . . . . . . . . . . . .
87
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
6.1.
Pruebas de funcionalidad
. . . . . . . . . . . . . . . . . . . . . . . .
97
6.2.
Pruebas de rendimiento
. . . . . . . . . . . . . . . . . . . . . . . .
104
6.3.
Matriz de trazabilidad
. . . . . . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . 107
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
111
114
121
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
126
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
130
. . . . . . . . . . . . . . . . . . . . . . . . . .
133
. . . . . . . . . . . . . . . . . . . . . . .
139
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
141
ndice de figuras
Figura 1. Aplicaciones Web 2.0
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
11
12
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
13
. . . . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
. . . . . . . . . . . . . . . . . . . . . . . . . . .
19
. . . . . . . . . . . . . . . . . . . . . . . . . .
20
. . . . . . . . . . . . . . . .
22
. . . . . . . . . . . . . . . . .
24
. . . . . . . . . . . . . . . . . . . . . . . .
25
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
. . . . . . . . . . . . . . . . . . . . . .
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
. . . . . . . . . . . . . . . . . . . . . .
33
. . . . . . . . . . . . . . . . . . . . . . . . . .
35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . .
63
64
. . . . . . . . . . . . . . .
. . .
66
. . . . . . . . . . . . . . . . . . . . . .
79
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
65
. . . . . . . . . . . . . . . . . . . . . . . . . . .
80
83
86
. . . . . . . . . . . . . . . . . .
89
. . . . . . . . . . . . . . . . .
90
92
. . . . . . . . . . . . . . . . . . . . . . . .
94
. . . . . . . . . . . . . . . . . . . . . . .
95
. . . . . . . . . . . . . . . . . . . . . . . . . .
117
. . . . . . . . . . . . . . . . . . . . . . .
.. . ..
122
. . . . . . . . . . . . . . . . . . . . . . .
129
. . . . . . . . . . . . . . . . . . . . . .
131
. . . . . . . . . . . . . . . . . . . . . . . . . . .
134
. . . . . . . . . . . . . . . . . . . . . . . . . . .
135
. . . . . . . . . . . . . . . . . . . . . . . . . .
135
. . . . . . . . . . . . . . . . . . . . . . . .
136
. . . . . . . . . . . . . . . . . . . . . . . . .
137
. . . . . . . . . . . . . . . . . . . . . . . .
138
ndice de tablas
Tabla 1. Entorno operacional del administrador
Tabla 2. Entorno operacional del usuario
. . . . . . . . . . . . . . . . . .
49
. . . . . . . . . . . . . . . . . . . . .
49
. . . . . . . . . . . . . . . . . . .
106
. . . . . . . . . . . . . . . . . . . . . . .
116
. . . . . . . . . . . . . . . . . . . . . . . . . . .
118
. . . . . . . . . . . . . . . . .
76
. . . . . . . . . . . . . . . . .
119
. . . . . . . . . . . . . . . . . . . . . . . . . . .
120
Captulo 1
Introduccin y objetivos
1.1. Introduccin
El propsito de este proyecto es la implementacin de una aplicacin de gestin de
eventos, para poder compartir actividades con otros usuarios.Tambin proporcionar
otros servicios como la gestin de grupos y usuarios.
Para llevar a cabo la aplicacin se usar Spring 3, uno de los frameworks J2EE ms
populares hoy en da. Tambin se utilizar otro framework muy popular como
Hibernate, para desarrollar la capa de persistencia.
La aplicacin web, tratar de acercarse al concepto Web 2.0 mediante el uso de
tecnologas especficas, como pueden ser AJAX y Google Maps API.
Empezaremos explicando los motivos y caractersticas que han gestado esta idea, para
en captulos posteriores explicar el anlisis, diseo e implementacin del mismo.
1.3. Objetivos
El objetivo del proyecto es realizar una aplicacin que permita a un usuario apuntarse a
eventos que son creados por otros usuarios. Del mismo modo, el usuario puede crear
eventos que sern mostrados a los dems usuarios.
Otro objetivo principal es desarrollar en la aplicacin la manera de gestionar esos
usuarios y los grupos que pueden formar entre ellos. Adems, la aplicacin debe ser
sencilla para el usuario y tener una interfaz atractiva e intuitiva.
Por lo tanto, los objetivos principales del proyecto son los siguientes:
Aparte de los objetivos principales, hay otros objetivos secundarios que se pretenden
alcanzar y que tienen que ver con las herramientas que se van a utilizar para el
desarrollo. Estos objetivos secundarios son los siguientes:
1.4. Contenido
El proyecto se ha estructurado en tres grandes partes bien diferenciadas: una destinada
a estudiar el funcionamiento del framework Spring y cmo se integra con las diferentes
tecnologas que se han utilizado para desarrollar el proyecto; la segunda trata de cmo
se ha diseado e implementado la aplicacin que usar todas estas tecnologas y por
ltimo las conclusiones a las cuales se ha llegado, adems de informacin extra
aportada mediante anexos.
La primera parte de la memoria comprende de los captulos 1 al 2. El primer captulo
(Introduccin) sirve como ayuda para poder comprobar la motivacin de este proyecto,
as como los objetivos que se desean alcanzar. En el segundo captulo (Estado del arte)
se trata de explicar el significado del Web 2.0, y as, entender mejor las caractersticas
que tendr nuestra aplicacin web. Se hablar sobre el uso de J2EE como tecnologa de
desarrollo. Por ltimo se analizar en detalle el funcionamiento del framework Spring
MVC 3, realizando comparativas con otros frameworks del mercado. Tambin
hablaremos sobre la integracin de otros frameworks a la aplicacin como es el caso de
Hibernate y la especificacin JPA.
La segunda parte de la memoria comprende de los captulos 3 al 6 y se centra en el
anlisis, diseo, implementacin y pruebas de la aplicacin web. En la parte del anlisis
se mostrarn tanto los requisitos de usuario como los requisitos software.En el captulo
de diseo, se mostrarn los diagramas del proyecto, adems de aportar informacin
sobre la arquitectura de la aplicacin o las clases del modelo.En el captulo de
implementacin se analizar qu pasos se han seguido a la hora de realizar la
aplicacin.Y por ltimo, en el captulo de pruebas se indicarn las pruebas realizadas
para comprobar el correcto funcionamiento de la aplicacin.
La parte final de la memoria est compuesta por las conclusiones y resultados que se
han obtenido en la realizacin del estudio e implementacin de la aplicacin web.
Tambin se reflejan las dificultades que han ido apareciendo a lo largo del proyecto y
las alternativas de mejora para una posible continuacin del proyecto en el futuro.
Tambin se incluyen las referencias bibliogrficas hechas a lo largo del proyecto junto
con los anexos para la correcta utilizacin y comprensin del sistema. En dichos anexos
se explica una lista detallada de los costes que supone implantar la aplicacin web,
adems de realizar una comparacin entre los frameworks ms usados del mercado y
explicar en qu consisten los patrones de diseo utilizados en el proyecto, como son el
caso del patrn MVC y el patrn DAO para el acceso a la capa de persistencia de datos.
Captulo 2
Estado del arte
2.1. Introduccin
En este captulo, trataremos de explicar las principales tecnologas que se han utilizado
dentro del proyecto. Empezaremos comentando la tendencia Web 2.0 y qu
tecnologas estn desarrolladas dentro de este concepto, haciendo especial hincapi en
las que se han utilizado en el proyecto como son las llamadas asncronas al servidor,
para aumentar la interaccin con el usuario.
Lo siguiente ser comentar la tecnologa J2EE para el desarrollo del proyecto,
remarcando algunas de sus caractersticas principales, que nos servir de introduccin
al mundo de los frameworks J2EE.
Una vez visto lo que es un framework y qu puede hacer por nosotros como
desarrolladores web, entrar en detalle en el estudio de Spring MVC 3, como principal
framework del proyecto, estudiando sus caractersticas ms importantes. Tambin
comentar la integracin de las otras tecnologas que se han utilizado en el proyecto
como pueden ser Hibernate y JPA.
Poco menos de diez aos despus, en la primera conferencia de OReilly Media, Tim
OReilly, su fundador, acuaba el termino Web 2.0 para referirse a la nueva revolucin
que estaba sufriendo Internet. Sin embargo, esta vez la revolucin no hace referencia
slo a la tecnologa (de hecho, la Web 2.0 no introduce ninguna especificacin nueva
sobre lo que es la Web, cosa que ha hecho que el creador original de la Web, Tim
Berners-Lee haya cuestionado lo apropiado del nombre), sino tambin a las personas.
Con la emergencia de Internet y sobre todo de la Web 2.0 mediante las llamadas redes
sociales, la limitacin espacial fsica/presencial para las interacciones sociales
desaparece y la temporal se hace mucho ms manejable por la posibilidad de la
asincrona en la comunicacin. Hoy en da, seis de los diez sitios ms visitados en la Web
son redes sociales.
Las redes sociales son espacios de Internet donde las personas publican y comparten
todo tipo de informacin, personal y profesional, con terceras personas. De este modo,
las redes sociales favorecen el trabajo colaborativo y la democratizacin de los
contenidos, siendo el lugar propicio para que los usuarios desarrollen la propia Red.
La tecnologa sobre la que se sustentan las redes sociales permite a sus usuarios
compartir todo tipo de datos e informacin en mltiples formatos (audio, texto y vdeo).
De esta manera los usuarios pueden crear nuevos contenidos, mezclar los contenidos
existentes, agregar comentarios, etiquetar diferentes contenidos, y finalmente
compartir los contenidos con usuarios de otras partes del mundo, entrando a un ciclo
permanente de retroalimentacin.
Han surgido hasta hoy un gran nmero de redes sociales en Internet, entre las cuales
podemos mencionar Facebook, LinkedIn, MySpace, Twitter, Slashdot, Reddit, Digg,
Delicious, StumbleUpon, FriendFeed, Last.fm, Friendster, LiveJournal, Hi5, Tagged, Ning,
Xanga, Classmates y Bebo.
No obstante es importante sealar que las redes sociales no solo aportan beneficios.
Las redes sociales pueden representar un serio problema en cuanto a la privacidad y/o
Dentro del proyecto utilizaremos tecnologas que siguen la tendencia Web 2.0 como lo
son AJAX, CSS y Google Maps API.
10
2.3.1. AJAX
AJAX es una tcnica de desarrollo web para crear aplicaciones interactivas. stas se
ejecutan en el lado del cliente, o mejor dicho en el navegador del usuario, y mantiene
una comunicacin asncrona con el servidor en segundo plano. Esto tiene la ventaja de
realizar cambios sobre la misma pgina sin necesidad de recargar todo el contenido de
la misma, como ocurre cuando pinchamos en un enlace o cuando pulsamos el botn
submit de un formulario. Esto puede traducirse como un aumento de la interactividad,
velocidad y usabilidad de la aplicacin web.
Esta tecnologa est basada en el objeto XMLHttpRequest, el cual es un objeto
suministrado por los navegadores webs, accesible mediante JavaScript, usado para
transferir datos asncronos entre el navegador y el servidor web [6].
11
2.3.2. CSS
CSS es un lenguaje de hojas de estilos creado para controlar el aspecto o presentacin
de los documentos electrnicos definidos con HTML y XHTML. CSS es la mejor forma de
separar los contenidos y su presentacin y es imprescindible para crear pginas web
complejas.
Separar la definicin de los contenidos y la definicin de su aspecto presenta
numerosas ventajas, ya que obliga a crear documentos HTML/XHTML bien definidos y
con significado completo. Adems, mejora la accesibilidad del documento, reduce la
complejidad de su mantenimiento y permite visualizar el mismo documento en
infinidad de dispositivos diferentes [8].
12
Una vez creados los contenidos, se utiliza el lenguaje CSS para definir el aspecto de cada
elemento: color, tamao y tipo de letra del texto, separacin horizontal y vertical entre
elementos, posicin de cada elemento dentro de la pgina, etc.
Google ofrece de forma gratuita una API con la que poder desarrollar aplicaciones a
medida basadas en los mapas de Google, integrar los mapas en otras aplicaciones e
incluso hacer "mash-up"o mezclas de Google Maps y otras aplicaciones web que
tambin disponen de una API pblica.
El API consiste de archivos JavaScript que contienen las clases, mtodos y propiedades
que se usan para el comportamiento de los mapas.
13
14
Spring, Jsf, entre otros, y que han nacido como idea de un pequeo grupo de expertos
y que han logrado llamar la atencin del mundo de la informtica.
15
2.6. Spring 3
En este apartado se dan a conocer todos los aspectos tcnicos de Spring, los conceptos
bsicos, sus caractersticas esenciales, las partes de su arquitectura,as como los
componentes que lo conforman.
Spring nos proporciona varios mdulos los cuales abarcan la mayor parte de las tareas
que debemos hacer en cualquiera de las capas de nuestras aplicaciones, desde plantillas
para trabajar con JDBC o invocacin de Web Services y JMS, pasando por sus propias
soluciones ORM o MVC (web), hasta integracin con otros frameworks, como Struts 2,
Hibernate, JSF, etc. Todo esto de una forma elegante y haciendo uso de muchos buenos
principios de programacin. Adems Spring maneja la infraestructura de la aplicacin,
por lo que nosotros slo deberemos preocuparnos de la lgica de la misma (y de la
configuracin de Spring).
Spring es, como lo definen sus autores, un framework ligero para construir aplicaciones
empresariales.La separacin en mdulos nos permite usar slo las partes que
necesitamos, sin tener la carga de los que no usemos.
Spring est diseado para no ser intrusivo, esto significa que no es necesario que
nuestra aplicacin extienda o implemente alguna clase o interface de Spring (si no lo
queremos), por lo que nuestro cdigo de lgica quedar libre y completamente
reutilizable para un proyecto sin Spring, o por si debemos quitarlo de una aplicacin que
16
ya lo est usando. Gracias a esto es posible usar un POJO o un objeto Java para hacer
cosas que antes solo podan hacerse con EJBs. Sin embargo la utilidad de Spring no es
slo para el desarrollo de aplicaciones web. Cualquier aplicacin Java puede
beneficiarse del uso de Spring.
Adems, si usamos Spring de la forma correcta nuestra aplicacin quedar dividida en
capas bien delimitadas, y con buenas prcticas de programacin.
Este framework est adquiriendo gran auge y una gran popularidad.Una de las
caractersticas que ayuda a este xito, es que es una aplicacin open source, lo cual
implica que no tienen ningn coste, ni se necesita una licencia para utilizarlo, por lo
tanto da libertad a muchas empresas y desarrolladores a incursionar en la utilizacin de
esta aplicacin. Adems de que est disponible todo el cdigo fuente de este
framework en el paquete de instalacin.
En general, estas son algunas de las caractersticas de Spring:
17
Soporte para Java EE6: ofrece soporte de caractersticas como JPA 2.0, JSF 2.0 y
JRS 303 (validaciones de Beans).
Soporte para bases de datos embebidas: un soporte conveniente para bases de
datos embebidas como HSQL, H2 y Derby.
Soporte para formateo de datos mediante anotaciones: ahora los campos de
fecha, divisas, etc., sern formateados automticamente y convertidos usando
anotaciones.
Nueva organizacin de los mdulos: los mdulos han sido revisados y separados
en diferentes paquetes, ms organizados, de acuerdo a su funcionalidad. [10]
18
19
BeanFactory
Representa las fbricas de beans y son el tipo de contenedor ms simple. Proporciona la
funcionalidad bsica. Como un BeanFactory conoce a los objetos que componen
nuestra aplicacin (los declarados en el archivo de configuracin), es capaz de crear las
asociaciones entre estos objetos en el momento de ser instanciados. Adems, como
el BeanFactory tiene el control del ciclo de vida del bean, puede hacer llamadas a
mtodos personalizados de inicializacin y destruccin (si estos mtodos estn
definidos).
En el momento en el que creamos nuestro BeanFactory, ste lee las definiciones de los
beans del archivo indicado, sin embargo los beans no son creados en ese momento. Los
beans se crean cuando que son necesitados.
Application Context
Un BeanFactory est bien para aplicaciones simples, pero no toma ventaja de todo el
poder que nos proporciona el framework de Spring. Para ello tenemos un contenedor
ms avanzado que representa el contexto de la aplicacin.
20
Inversin de Control
El ncleo de Spring est basado en un principio o patrn de diseo llamado Inversin de
Control (IoC por sus siglas en ingls). Las aplicaciones que usan el principio de IoC se
basan en su configuracin (que en este caso puede ser en archivos XML o con
anotaciones como en Hibernate) para describir las dependencias entre sus
componentes, esto es, los otros objetos con los que interacta.
La aplicacin no controla su estructura; permite que sea el framework de IoC (en este
caso Spring) quien lo haga.En este caso en vez de ser el mismo objeto quien se
encargue de instanciar, o localizar las dependencias con las que trabaja (usando
directamente su constructor o un localizador de servicios), es el contenedor el que
inyecta estas dependencias cuando crea al bean.
21
Inyeccin de dependencias
En Spring, los objetos no son responsables de encontrar o crear los otros objetos que
necesitan para hacer su trabajo. En vez de eso, el contenedor les da las referencias de
los objetos con los que colaborarn.
En el contexto de DI, Spring acta como un contenedor que proporciona las instancias
de las clases que nuestra aplicacin necesita, pero en una forma no intrusiva y
automtica. [11]
Todo lo que debemos hacer es crear un archivo de configuracin que describa las
dependencias, y Spring se har cargo del resto.O mediante la anotacin @autowired le
indicamos a Spring que se tiene que encargar de buscar un bean que cumpla los
requisitos para ser inyectado.En caso de que hubiese ms de un bean que cumpliese
esos requisitos tendramos que decirle a Spring cul es el correcto.
Sin inyeccin de dependencias, cada clase llama al objeto que necesita en tiempo de
ejecucin. Mientras que con inyeccin de dependencias, cada objeto es cargado en
cada clase que lo necesita en tiempo de inicializacin.
La implementacin de DI de Spring se enfoca en el acoplamiento dbil: los
componentes de nuestra aplicacin deben asumir lo menos posible acerca de otros
componentes. La forma ms fcil de lograr este bajo acoplamiento en Java es mediante
el uso de Interfaces. Cada componente de la aplicacin slo es consciente de la
interface de otros componentes, por lo que podemos cambiar la implementacin sin
afectar a los otros componentes.
22
Hace que las pruebas sean ms fciles: nuestras clases sern diseadas para que
sea fcil el reemplazo de dependencias. Podemos proporcionar dummies, que
regresen datos de prueba, de servicios o cualquier dependencia que necesite el
componente que estamos probando.
Como podemos ver, el uso de DI nos proporciona muchos beneficios, pero no sin sus
correspondientes desventajas. En particular, es difcil ver qu implementacin particular
de una dependencia est siendo usada para qu objeto, especialmente para alguien
que no est familiarizado con esta forma de trabajo.
23
El patrn DAO (Data Access Object) es uno de los patrones ms importantes y usados
en aplicaciones J2EE, y la arquitectura de acceso a los datos de Spring provee un buen
soporte para este patrn, proporcionando plantillas que nos ahorrarn muchas lneas
de cdigo.Las plantillas gestionan las partes fijas del acceso a datos, controlan las
excepciones, asignan los recursos y manejan las transacciones.
24
25
sistema, ya que necesariamente afecta a todas las partes del sistema que
generan un suceso.
Pointcut (Puntos de Corte) define los Consejos que se aplicarn a cada Punto
de Cruce. Se especifica mediante expresiones regulares o mediante patrones
de nombres (de clases, mtodos o campos), e incluso dinmicamente en tiempo
de ejecucin segn el valor de ciertos parmetros.
26
Provee una limpia separacin entre el modelo de dominio y los formularios web
y lo integra con todas las dems caractersticas de Spring Framework.
Spring puede ser fcilemnte integrado con otros frameworks MVC.
Spring brinda un MVC para web bastante flexible y altamente configurable, pero
esta flexibilidad no le quita sencillez, ya que se pueden desarrollar aplicaciones
sencillas sin tener que configurar muchas opciones.
Spring brinda soporte para JSP, Struts, Velocity, entre otros.
Para intentar comprender cada parte de la arquitectura del Web MVC de Spring
analizaremos el ciclo de vida de una peticin o request.[14]
27
DispatcherServlet
En Spring MVC el DispatcherServlet es un Servlet que recibe las peticiones HTTP y las
enva al controlador apropiado. En una aplicacin Spring MVC puede haber varios
DispatcherServlet para cumplir con varios propsitos (por ejemplo manejar las
solicitudes de las interfaces de usuarios, solicitudes de webServices, etc.) y cada
DispatcherServlet tiene su propia configuracin (WebApplicationContext), el cual define
las caractersticas del Servlet tales como los controladores que el Servlet soporta,
manejador de mapeo, etc.
28
HandlerMapping
Existen diversas maneras con las que el DispatcherServlet puede saber qu controlador
es el encargado de procesar una peticin, y a qu bean del Application Context se lo
puede asignar. Esta tarea la lleva cabo el Handler Mapping o el manejador de mapeo.
Existen 2 tipos principales que son los que ms se usan:
ViewResolver
Un View Resolver es el encargado de resolver el nombre lgico que retorna un
controlador en un objeto ModelAndView, a un nombre de archivo fsico que el
navegador podr desplegarle al usuario junto con los resultados procesados.
Spring MVC cuenta con cuatro View Resolvers diferentes, pero el ms utilizado es
InternalResourceViewResolver, el cual resuelve los nombres lgicos en un archivo tipo
View que es convertido utilizando una plantilla de archivos como JSP, JSTL o Velocity.
Controladores
Los controladores retornan por lo general un objeto tipo ModelAndView, que es un
objeto que contiene el modelo y la vista, ya que est compuesto de 2 o ms atributos.
El objeto ModelAndView contiene el nombre lgico de la vista,el cual el framework se
encarga (a travs del View Resolver) de convertir ese nombre lgico al nombre fsico,
que es el que buscar el servidor web.
Adems el modelo puede estar formado por un objeto o por un Map de objetos,los
cuales se identificarn en la vista con el mismo nombre que se haya mandado dentro
del modelo que se le dio al objeto ModelAndView.
29
2.7. Hibernate
Para la mayora de las aplicaciones, almacenar y recuperar informacin implica alguna
forma de interaccin con una fuente de datos. Esta fuente de datos normalmente es
una base de datos relacional la cual presenta un problema para la gran mayora de
programadores puesto que el modelo relacional dista mucho del orientado a objetos, y
no existe una estandarizacin para este manejo de datos.
30
2.7.1. Caractersticas
Entre las caractersticas ms importantes de Hibernate se destacan:
31
2.7.2. Ventajas
Las ventajas son las siguientes:
32
De todo el conjunto de APIs de Hibernate, existen varias clases que permiten el trabajo
bsico con el Framework. Entre las ms importantes se encuentran:
Session: corresponde con un objeto que representa una unidad de trabajo con la
base de datos (transaccin). Adems representa el gestor de persistencia, ya
que dispone de la API bsica para poder cargar y guardar objetos.
Transaction: La API de Hibernate contiene utilidades para demarcar la
transaccionalidad de operaciones de manera programtica.
Query: este interfaz permite crear consultas y enlazar argumentos a parmetros
de la consulta (binding). Permite definir consultas en HQL (Hibernate Query
Language) o en SQL.
SessionFactory: es una factora de sesiones. Proporciona objetos Session.
Adems, es thread-safe y permite concurrencia.
33
2.7.4. Conclusiones
El uso de aplicaciones de persistencia de objetos en bases de datos relacionales es cada
vez ms comn. En el mercado existen muchos frameworks dedicados a esta tarea que
hacen el trabajo de almacenamiento de objetos de una forma transparente para el
programador.
Hibernate es uno de los mejores frameworks de persistencia de la actualidad ya que
posee caractersticas mejoradas como: buen soporte, facilidad de adaptacin, categora
libre, soporte de java y .net , buena documentacin y un grupo de programadores
mundiales que soportan su crecimiento.
Con Hibernate podremos cubrir de manera sencilla y rpida el 80 - 90% de la
persistencia de nuestra aplicacin. Esto nos permite centrar nuestros esfuerzos en
optimizar las consultas que realmente lo merecen.
34
2.8. JPA
Java Persistence API (JPA) proporciona un modelo de persistencia basado en POJO's
para mapear bases de datos relacionales en Java.
JPA es una parte de la especificacin de EJB 3.0 (JSR 220). Por lo tanto no existe
realmente como framework, sino que es simplemente un documento. Un documento
en el cual se especifican los principios bsicos de gestin de la capa de persistencia en el
mundo de Java EE. [20]
El uso de JPA no se limita a los componentes software EJB. Se puede utilizar en
aplicaciones web y aplicaciones clientes. Para ello, combina ideas y conceptos de los
principales frameworks de persistencia, como Hibernate, Toplink y JDO. El mapeo
objeto-relacional (es decir, la relacin entre entidades Java y tablas de la base de datos,
queries con nombre, etc) se realiza mediante anotaciones en las propias clases de
entidad.
La relacin que existe entre JPA e Hibernate es que este ltimo implementa como parte
de su cdigo la especificacin de JPA. Es decir podemos usar Hibernate para construir
una capa de persistencia apoyndonos en las definiciones y reglas de la especificacin
de JPA, aunque no es obligatorio.
Eso s, esto no quiere decir que Hibernate simplemente implemente el standard de
JPA. Hibernate es mucho ms grande que la especificacin de JPA y aade ms
funcionalidad.
35
2.8.1. Persistencia
Pero para entender JPA, tendremos que tener claro el concepto "persistencia".
La persistencia o el almacenamiento permanente, es una de las necesidades bsicas de
cualquier sistema de informacin de cualquier tipo. En primer lugar, se propuso que los
programas trataran los datos haciendo consultas directas a la base de datos. Despus,
se propuso trabajar con objetos, pero las bases de datos tradicionales no admiten esta
opcin.
Debido a esta situacin, aparecieron los motores de persistencia, cuya funcin es
traducir entre los dos formatos de datos: de registros a objetos y de objetos a
registros. Persistir objetos Java en una base de datos relacional implica serializar un
rbol de objetos Java en una base de datos de estructura tabular y viceversa. Esencial es
la necesidad de mapear objetos Java para optimizar velocidad y eficiencia de la base de
datos.
Una entidad pasar a ser manejada por el contexto de persistencia de JPA cuando sta
sea persistida (mediante el mtodo persist del Entity Manager). En este caso, y mientras
la entidad sea manejada/asociada por el contexto de persistencia (tambin se las
conoce como attached entities), el estado (valores de la propiedades) de la entidad ser
automticamente sincronizado con la BD.
La unidad de persistencia define un conjunto de todas las entidades que son
gestionadas por la instancia del EntityManager en una aplicacin. Este conjunto de
clases de entidad representa los datos contenidos en una nica BBDD.
Las unidades de persistencia se definen en el fichero de configuracin persistence.xml.
36
37
2.8.3. Anotaciones
JPA trabaja fuertemente con anotaciones. Gracias a las anotaciones, JPA mapea
automticamente nuestras clases en la base de datos de manera transparente, y
utilizando un estndar, lo cual entre otras cosas nos permite poder migrar de motor
cuando queramos sin ningn problema. [21]
Para mapear un bean (una clase java) con una tabla de la base de datos, tendramos
que escribir lo que se llama un Entity.
Esto es tan sencillo como escribir nuestro bean, con sus atributos y mtodos get y set. Y
despus aadirle la anotacin @Entity a la par que seleccionamos uno de sus
atributos como clave primaria con @Id. Por ejemplo, el siguiente cdigo es el utilizado
para crear la entidad User.Mediante las anotaciones, JPA nos permitira almacenar,
recuperar, o actualizar campos sobre una tabla users:
@Entity
@Table(name="users")
public class User implements Serializable {
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
private Integer id;
@NotEmpty
@Column(nullable = false)
private String nameUser;
}
Mediante @Entity indicamos que es una entidad. Con la anotacin @Table forzamos a
que se mapee con una tabla llamada users.En caso de no usar la anotacin @Table, el
nombre de la tabla creada se llama exactamente igual al nombre de la clase java.
Con @Id vamos indicando qu columnas son clave y con @GeneratedValue podemos
indicar si queremos que los campos clave se creen de manera automtica, por ejemplo
mediante el uso de secuencias. En otro caso, somos nosotros los que debemos calcular
el valor de un nuevo id cuando vayamos a insertar, o podemos elegir IDENTITY y que se
genere una clave autoincremental. Otra anotacin es @Column, que nos permite
asociar un atributo a un nombre de columna en particular. Con @NotEmpty indicamos
que ese valor no puede estar vaco. [22]
Otra anotacin interesante es @NamedQueries , con la que vamos indicando las
diferentes sentencias SQL que queremos utilizar(en realidad sentencias JPQL).
38
Tambin son importantes las anotaciones para indicar las relaciones de la entidad, las
cuales veremos con ms detalle a continuacin.
Uno a uno: cada entidad se relaciona con una sola instancia de otra entidad. Las
relaciones uno a uno utilizan anotaciones de la persistencia de java "OneToOne".
Ej:@OneToOne(cascade={CascadeType.PERSIST, CascadeType.REMOVE})
Uno a muchos: una entidad puede estar relacionada con varias instancias de
otras entidades. Las relaciones uno a muchos utilizan anotaciones de la
persistencia de java "OneToMany" en los campos o propiedades persistentes.
Ej:@OneToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER,
mappedBy="group").
Muchos a uno: mltiples instancias de una entidad pueden estar relacionadas
con una sola instancia de otra entidad. Esta multiplicidad es lo contrario a la
relacin uno a muchos. Las relaciones muchos a uno utilizan anotaciones de la
persistencia de java "ManyToOne" en los campos o propiedades persistentes.
Ej:@ManyToOne
Muchos a muchos: en este caso varias instancias de una entidad pueden
relacionarse con mltiples instancias de otras entidades. Este tipo de relacin
utiliza anotaciones de la persistencia de java "ManyToMany" en los campos o
propiedades persistentes.
Ej:@ManyToMany
@JoinTable(name="groups_users",joinColumns=@JoinColumn(name="group_id
"),inverseJoinColumns=@JoinColumn(name="user_id"))
39
Captulo 3
Anlisis
40
3.1. Introduccin
Una vez estudiado las tecnologas pertinentes, es el momento de realizar la aplicacin
web que represente en cierta medida a estas tecnologas.
En primer lugar, se especifican los requisitos de usuario, que se dividen en dos
categoras:
A continuacin, se definirn los roles o tipos de usuario que pueden utilizar la aplicacin
y las necesidades tecnolgicas del sistema desde el punto de vista de los usuarios.
Por ltimo, se tratarn los requisitos desde el punto de vista del diseo. Estos requisitos
se han dividido en dos tipos:
Por lo tanto, en este captulo se analizarn los requisitos necesarios para cumplir los
objetivos planteados y se detallarn los roles que existirn dentro de la aplicacin web.
41
REGISTRO DE USUARIO
IDENTIFICADOR: RU_UC_01
DESCRIPCIN: Para poder utilizar los servicios de la aplicacin, el usuario debe estar
registrado.
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
42
AUTENTICACIN DE USUARIO
IDENTIFICADOR: RU_UC_04
DESCRIPCIN: Si un usuario ya est registrado, puede acceder a los servicios de la
aplicacin introduciendo su nombre de usuario y password.
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
CREAR GRUPO
IDENTIFICADOR: RU_UC_05
DESCRIPCIN: Cualquier usuario puede crear un grupo y aadir usuarios a ese grupo.
Cualquier evento que sea creado en dicho grupo, ser notificado a los usuarios que
pertenecen al grupo
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Inestable
VERIFICABILIDAD: Alta
MODIFICAR GRUPOS
IDENTIFICADOR: RU_UC_06
DESCRIPCIN: Se podrn modificar datos del grupo, aadir nuevos usuarios al grupo
o eliminar usuarios del grupo. En caso de eliminar el grupo, todos los eventos del
grupo sern borrados automticamente.
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
CREAR REGIONES
IDENTIFICADOR: RU_UC_07
DESCRIPCIN: Cuando se crea una regin, automticamente se crea un grupo
asociado a dicha regin. Los grupos asociados a las regiones son los grupos por
defecto que un usuario puede elegir como grupo inicial en el proceso de registrarse.
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
MODIFICAR REGIONES
IDENTIFICADOR: RU_UC_08
DESCRIPCIN: Al ser modificado algn nombre de los datos de la regin,
automticamente se modificar el nombre del grupo asociado .En caso de borrar una
regin, el grupo asociado a la regin automticamente ser borrado.
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
43
CREAR EVENTO
IDENTIFICADOR: RU_UC_09
DESCRIPCIN: Cualquier usuario puede crear un evento, indicando descripcin,
fecha, lugar y otros datos de inters del evento si son necesarios. El grupo al que
pertenece el evento se elegir entre los grupos a los que pertenece el usuario.
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
MODIFICAR EVENTO
IDENTIFICADOR: RU_UC_10
DESCRIPCIN: Se podr modificar algn dato del evento, como el lugar, la fecha, la
descripcin, etc. o borrar dicho evento.
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
BUSCAR USUARIOS
IDENTIFICADOR: RU_UC_11
DESCRIPCIN: Cualquier usuario podr acceder a una lista de todos los usuarios
registrados de la aplicacin y hacer bsquedas por nombre de usuario
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
BUSCAR GRUPOS
IDENTIFICADOR: RU_UC_12
DESCRIPCIN: Cualquier usuario podr acceder a una lista de todos los grupos
registrados de la aplicacin y hacer bsquedas por nombre de grupo.
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
BUSCAR EVENTOS
IDENTIFICADOR: RU_UC_13
DESCRIPCIN: Cualquier usuario podr acceder a una lista de todos los eventos
registrados de la aplicacin y hacer bsquedas por nombre de evento.
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
44
BUSCAR REGIONES
IDENTIFICADOR: RU_UC_14
DESCRIPCIN: El administrador podr acceder a una lista de todas las regiones
registradas en la aplicacin y hacer bsquedas por nombre de regin.
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Inestable
VERIFICABILIDAD: Alta
45
EVENTO YA REALIZADO
IDENTIFICADOR: RU_UC_22
DESCRIPCIN: Los eventos cuya fecha y hora de suceso son anteriores a la actual,
permanecern registrados en el sistema. El administrador de cada evento ser el
responsable de borrarlos del sistema si lo considera oportuno. Los eventos ya
realizados slo se mostrarn en el listado de mis eventos.
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
46
47
48
Se entiende que una misma persona puede poseer varios roles. No se tienen en cuenta
los usuarios indirectos de la aplicacin, que no acceden a ella, como son los gestores de
las bases de datos o los administradores de red que se encargan del buen
funcionamiento de la misma. Estas acciones recaen directamente en el usuario
administrador.
ADMINISTRADOR
Ordenador con acceso a redes. Requiere los elementos para poder desarrollar las
herramientas en el lenguaje deseado, as como poder aadir funcionalidades a la
aplicacin. Por lo tanto, se necesita un equipo con Eclipse o algn otro IDE similar y
con MySQL como sistema gestor de base de datos.
Tabla 1. Entorno operacional del administrador
USUARIO
Cualquier ordenador que contenga un acceso a la red y la mquina virtual Java.
Tabla 2. Entorno operacional del usuario
49
Identificador: cdigo nico que identifica a cada caso de uso. Se compone del
siguiente formato:
o CU: corresponde a Caso Uso.
o XX: nmero del caso de uso.
Nombre: nombre del caso de uso.Este nombre se usa en el diagrama de casos
de uso para identificarlo.
Actores: agentes externos que interactan con el sistema.
Precondiciones: condiciones necesarios para que el caso de uso se pueda
realizar.
Postcondiciones: hechos que suceden si el caso de uso se ha ejecutado
correctamente.
Descripcin: descripcin detallada del caso de uso correspondiente.
Escenario principal: descripcin detallada de los pasos que ha de realizar el actor
dentro del escenario para completar el caso de uso.
Escenario secundario: descripcin detallada de los pasos que ha de realizar el
actor dentro del escenario, en caso de que pueda darse una bifurcacin en la
ejecucin normal del sistema.
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Figura 23. Diagrama de casos de uso del Administrador Regiones, Grupos y Usuarios
66
MAPA DE GMAPS
IDENTIFICADOR: RS_RF_01
DESCRIPCIN: Para hacer ms atractiva la aplicacin, y mostrar de una manera ms
clara la localizacin de los eventos, se integrar GMaps en la aplicacin por medio de
JQuery.Slo se podr marcar una localizacin por evento.
ORIGEN: RU_UC_09, RU_UC_10
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
67
68
PRIORIDAD: Alta
VERIFICABILIDAD: Alta
69
70
BSQUEDA EN LISTADOS
IDENTIFICADOR: RS_RF_11
DESCRIPCIN: En los listados se habilitar un cuadro de texto para hacer bsquedas
especficas de algn registro cuyo nombre contenga el texto indicado.Se realizar
mediante el uso de AJAX.
ORIGEN: RU_UC_11, RU_UC_12, RU_UC_13, RU_UC_14, RU_UC_15, RU_UC_16,
RU_UC_20
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
GEOLOCALIZACIN
IDENTIFICADOR: RS_RF_12
DESCRIPCIN: En la creacin o modificacin de eventos se habilitar un cuadro de
texto para introducir alguna localizacin. Al pulsar el botn, el mapa de Google Maps
se posicionar en el lugar especificado, si es que existe.
ORIGEN: RU_UC_09, RU_UC_10
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
MOSTRAR NOVEDADES
IDENTIFICADOR: RS_NF_13
DESCRIPCIN: Cuando el usuario se autentifica en la aplicacin, y accede al men
principal, la interfaz le mostrar un mensaje indicando si se han creado nuevos
eventos o ha sido modificado alguno en el que participa. Dicho mensaje viene
acompaado con un enlace para mostrar el listado de dichos eventos.
ORIGEN: RU_UC_17
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
71
72
VISTA DE LOGIN
IDENTIFICADOR: RS_NF_20
DESCRIPCIN: En la interfaz de login, el usuario estar obligado a introducir los
campos de nombre de usuario y contrasea. En caso de que los datos introducidos no
existan en la base de datos, se le comunicar al usuario mediante un mensaje.
ORIGEN: RU_UC_04
NECESIDAD: Esencial
PRIORIDAD: Alta
ESTABILIDAD: Estable
VERIFICABILIDAD: Alta
73
74
RS_NF_20
RS_NF_19
RS_NF_18
RS_NF_17
RS_NF_16
RS_NF_15
RS_RF_14
RS_NF_13
RS_RF_12
RS_RF_11
RS_NF_10
RS_NF_09
RS_NF_08
RS_NF_07
RS_NF_06
RS_NF_05
RS_RF_04
RS_RF_03
RS_RF_02
RS_RF_01
RU_UC_01
RU_UC_02
RU_UC_03
RU_UC_04
RU_UC_05
RU_UC_06
RU_UC_07
RU_UC_08
RU_UC_09
RU_UC_10
RU_UC_11
RU_UC_12
RU_UC_13
RU_UC_14
RU_UC_15
RU_UC_16
RU_UC_17
RU_UC_18
RU_UC_19
RU_UC_20
RU_UC_21
RU_UC_22
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
75
RU_UR_01
RU_UR_02
RU_UR_03
RU_UR_04
RU_UR_05
RU_UR_06
RU_UR_07
X
X
X
X
X
X
X
76
RS_NF_20
RS_NF_19
RS_NF_18
RS_NF_17
RS_NF_16
RS_NF_15
RS_RF_14
RS_NF_13
RS_RF_12
RS_RF_11
RS_NF_10
RS_NF_09
RS_NF_08
RS_NF_07
RS_NF_06
RS_NF_05
RS_RF_04
RS_RF_03
RS_RF_02
RS_RF_01
Captulo 4
Diseo
77
4.1. Introduccin
En este captulo, nos centraremos en el diseo realizado para la aplicacin. Para ello,
describiremos la arquitectura de la aplicacin as como las diferentes capas que interactan
entre ellas. Tambin se analizarn las interfaces que se mostrarn al usuario y la estructura de
la base de datos que contiene la informacin general del sistema.
78
Por lo tanto, cuando el usuario desea crear grupos o eventos, o bien cuando quiere visualizar
un listado de los grupos o eventos ya registrados en el sistema, estar realizando una peticin
al servidor (para introducir informacin en la base de datos o para recuperar la informacin
ya existente) .El servidor ser el encargado de procesar las peticiones,de introducir los datos
en la base de datos o de realizar una consulta y devolver los resultados al cliente.
79
Capa presentacin
Es la capa con la que interacta el usuario de la aplicacin web, normalmente a travs de un
navegador. Una de sus tareas, es la de capturar los datos del usuario con los que opera la
capa de la aplicacin y envirselos a sta. Esta capa est formada por el conjunto de las
pginas que se pueden ver desde el navegador.
Cuando un usuario se autentica, se crea una sesin automticamente con los datos del
usuario, esto le permite al usuario acceder a diferentes partes de la aplicacin sin tener que
preocuparse de autenticarse otra vez.
Para el diseo de las vistas, se han utilizado pginas JSP. Se han utilizado hojas de estilo CSS
para formatear el contenido y as aprovechar las ventajas que este sistema nos ofrece, como
tener limpio el cdigo HTML y tener en varios ficheros de configuracin el aspecto que debe
tener la aplicacin, permitindonos realizar cambios en toda la aplicacin nicamente
modificando una lnea de cdigo en estos ficheros CSS, esto promueve la usabilidad y la
accesibilidad.
Se ha utilizado tambin el framework Tiles para el diseo de elementos comunes a las
pginas, como son la cabecera,el men lateral,etc.
80
Capa aplicacin
En esta capa, se encuentra la aplicacin en s. sta se encuentra en el servidor a la que
acceden los usuarios a travs de la red .las funciones de la capa Aplicacin consisten en
recoger los datos enviados desde la capa de presentacin, procesar la informacin,
implementar la lgica de la aplicacin, acceder a los datos y generar las respuestas para el
cliente.
Tambin se encarga de interaccionar con la capa de servicios para acceder a la capa de
persistencia.
Es en esta capa donde Spring y su patrn MVC entra en juego, adems de utilizar la
funcionalidad de la inyeccin de dependencias.
Capa Servicios
Esta capa acta como un puente entre las capas de aplicacin y persistencia usando la capa
de dominio como contenedor de informacin, tambin llamados DTO (Data Transfer
Protocol).
Estos servicios de negocio, usan el patrn DAO (Data Access Object) para acceder a la
informacin de la capa de persistencia mediante una interface, de esta forma conseguimos
que nuestra lgica de negocio (aplicacin) no sepa nada de Hibernate, y siempre que quiera
acceder a los datos lo har usando la interface DAO, con esto conseguimos reducir el
acoplamiento y as podemos intercambiar la implementacin fcilmente si algn da nos
cansamos de Hibernate/JPA sin que eso repercuta en el cdigo de la aplicacin. En los anexos,
se explicar con ms detalle cmo funciona el patrn DAO.
Capa Dominio
Esta capa, se comunica directamente con las capas de aplicacin, servicios y persistencia.
Hibernate usar estos objetos de dominio, que sern persistidos en en nuestra base de datos
relacional. Para ello Hibernate ha de conocer como relacionar el objeto con la base de datos,
para eso dispone de una serie de anotaciones que utilizar para definir el objeto a persistir.
81
Capa Persistencia
La funcin bsica de esta capa, es la persistencia de un modelo de dominio basado en objetos
dentro de una base de datos relacional (MySQL) mediante un ORM, que en este caso es
Hibernate/JPA.
Hibernate, ser el encargado de acceder, modificar o eliminar registros en la base de datos de
Mysql. La nica configuracin que requiere MySQL, es su instalacin y creacin de una base
de datos. La funcin de creacin de tablas y relaciones, est delegada a Hibernate.
82
El diagrama es el siguiente:
Vamos a explicar en qu consisten cada una de las clases del diagrama y sus atributos.
83
Region
Esta tabla almacena la informacin sobre la distintas regiones.Un usuario al registrarse slo
pertenecer a un grupo inicial, que sern los grupos asociados a las regiones que existen.Slo
el administrador tendr acceso a estos datos.
idRegin: clave que identifica la regin.
nameRegion: nombre de la regin.
country: nombre del pas al que pertenece la regin.
group: grupo asociado a la regin.
Group
Esta tabla almacena la informacin sobre los grupos registrados. Aparte de los grupos iniciales
(asociados de las regiones), los usuarios podrn crear nuevos grupos en los que se crearn
eventos y se aadirn usuarios a ellos.
idGroup: clave que identifica al grupo.
nameGroup: nombre del grupo.
managerGroup: el usuario que cre e grupo, y el nico que podr editarlo.
events: lista de eventos que han sido creados en el grupo.
users: lista de usuarios que pertenecen al grupo.El administrador al crear el grupo est
incluido en la lista por defecto.
User
Esta tabla almacena la informacin sobre los usuarios.Cada usuario registrado en el sistema
es guardado en esta tabla.
id: clave del usuario.
nameUser: nombre de usuario que lo identificar de manera nica en el sistema.
password: contrasea que junto con el nombre de usuario ayuda a identificar a un
usuario.
name: nombre del usuario.
surnames: apellidos del usuario.
birthdate: fecha de nacimiento del usuario.
email: correo electrnico del usuario.
city: ciudad en la que vive el usuario
mainGroup: grupo inicial a la que va a pertenecer el usuario.Lo tendr que seleccionar
entre una lista de los disponibles.
image: imagen que aparece en su perfil de usuario.
managedGroups: lista de grupos administrados por el usuario.
managedEvents: lista de eventos administrados por el usuario.
84
Event
Esta tabla almacena la informacin sobre los eventos. Un evento pertenece a un solo grupo y
los usuarios se apuntarn a los eventos que consideren interesantes.
id: clave del evento.
cityEvent: ciudad en la que suceder el evento.
dateEvent: fecha en la que suceder el evento.
timeEvent: hora en la que suceder el evento.
placeEvent: descripcin del lugar donde suceder el evento.
title: ttulo del evento.
description: informacin detallada del evento.
latitude: latitud marcada en el mapa de Google Maps
longitude: longitud marcada en el mapa de Google Maps.
group: grupo a que pertenece el evento.
managerEvent: administrador del evento. Ser el nico que podr editar el evento.
users: lista de usuarios apuntados al evento.
lastEdit: fecha de creacin o de ltima modificacin del evento.
85
CABECERA
MEN DE
BOTONES
CUERPO
86
Captulo 5
Implementacin
87
Debido a que el desarrollo de la aplicacin gira en torno al framework de Spring, va a ser este
framework quien nos va ayudar en la implementacin de la misma, aportndonos todas sus
funcionalidades y beneficios como la inyeccin de dependencias.
Adems, Spring nos permite mantener el cdigo desacoplado, limpio y reutilizable, ya que la
filosofa de Spring nos gua a programar orientado a interfaces.
El utilizar frameworks como Spring e Hibernate y hacer uso de las anotaciones nos va a
permitir reducir el tiempo de desarrollo con Java.
Por lo tanto, una de las tareas ms importantes consistir en la configuracin de Spring y el
permitir el uso de anotaciones.
A partir de Spring 2.5 la manera ms interesante de enlazar nuestros beans es a travs de las
anotaciones.
El uso de anotaciones nos permite eliminar el tener la definicin de nuestros beans en un
archivo XML, y esto es til cuando tenemos declarados muchos beans y nuestro archivo se
vuelve engorroso (aunque siempre se pueden combinar ambas formas de declaracin).
Para activar la configuracin de Spring para que detecte las anotaciones generales (como son
el caso de @Autowired o @Required) se usa el elemento <context:annotation-config/>. Para
indicar en qu paquetes se encuentran las clases que hemos anotado usamos el elemento
"component-scan".Mediante su elemento "base-package",indicamos el paquete raz en el
que se encuentran nuestros beans anotados.
La declaracin <mvc:annotation-driven> habilita el soporte de anotaciones para el mdulo
Spring MVC .Tambin habilitan soporte para las anotaciones utilizadas en la conversin,
formateo y validacin.
Para activar la configuracin de repositorios hay que indicar el paquete a partir del cul
Spring debe buscar clases que extiendan de Repository.
Por lo tanto, nuestro archivo de configuracin va a incluir las siguientes lneas de cdigo:
88
Spring proporciona una serie de anotaciones con las cuales podemos indicar exactamente
cmo queremos que se manejen los componentes. Para esto existen tres anotaciones
bsicas:
@Repository : indica que las clases marcadas con esta anotacin estn relacionada de
alguna forma con una capa de persistencia de datos.
@Service : indica que las clases marcadas con esta anotacin estn en una capa de
servicios o de lgica de negocios.
@Controller : indica que las clases marcadas con esta anotacin son el controlador de
una aplicacin web.
Las tres anotaciones anteriores extienden de "@Component", la cual indica que la clase es un
componente Spring, y por lo tanto son candidatas para ser auto-detectadas cuando usamos
una configuracin basada en anotaciones.
Por lo tanto, en la implementacin de la aplicacin vamos a usar anotaciones y tambin
vamos a apoyarnos en los patrones MVC y DAO.
Spring nos ayuda en este sentido, porque uno de sus mdulos ms importantes es Spring
MVC, el cual nos provee un exhaustivo soporte para el patrn MVC.
En las clases que forman parte del modelo, podemos agregar a nuestro cdigo anotaciones
para que puedan hacer uso de JPA, y con ello llevar a cabo una implementacin automtica
de las tablas de nuestra base de datos.
El siguiente es un ejemplo de una de las clases del modelo de la aplicacin usando
anotaciones:
89
90
@Entity para identificar el bean como una entidad a guardar en la base de datos
@Table indicamos el nombre que tendr la tabla en la base de datos.
@Id para identificar el campo de clave primaria.
@GeneratedValue para permitir a la base de datos asignar automticamente un valor
a la clave primaria cuando un registro es insertado.
@NotEmpty para indicar que la cadena no puede ser vaca.
@Column para indicar propiedades de la columna.En este caso indicamos que el valor
de la columna no puede ser nulo.
@DateTimeFormat para el formateo de fechas.
@Email para comprobar que el email introducido cumple el formato.
@Lob para el uso de imgenes.
@OneToMany y @ManyToMany indican el tipo de relacin que va a tener la entidad
con otras entidades.
@JoinTable y @JoinColumn para indicar el nombre que va a tener la tabla y las
columnas de las tablas intermedias.
91
En la parte del Controlador, tambin el uso de las anotaciones nos ayuda con el desarrollo de
las clases. El siguiente es un ejemplo de un extraxto de cdigo de uno de los controladores de
la aplicacin:
92
@Controller: esta anotacin la emplea Spring para escanear las clases y as detectar
cuales de estas clases forman los Controllers de nuestra aplicacin. Por lo tanto, el
contenedor de Spring detectar automticamente esta clase y sabr que la clase es un
controlador de Spring MVC capaz de manejar solicitudes web.
@Autowired nos sirve para llevar a cabo la inyeccin de dependencias. Nos sirve por
lo tanto para inyectar un Bean usando la autodeteccin de Spring. En este caso
inyectaremos un bean de tipo IUserService en el atributo userService.
Tambin podemos distinguir diferentes tipos de llamadas a una misma direccin, y tratarlas
segn nos convenga.
De este modo, si la llamada a la direccin se realiza por GET o POST la trataremos de diferente
forma. En este caso estamos recibiendo una peticin HTTP de tipo GET.Otro mtodo de esta
clase se encarga de recibir las peticiones HTTP de tipo POST.
Tambin nos podemos fijar que el mtodo devuelve un String. Este String hace referencia al
nombre del archivo JSP que ser llamado cuando acabe la ejecucin del mtodo.
En la vistas, se han utilizado las etiquetas que proporciona JSTL, que es una coleccin de
funciones de uso comn cuando se desarrollan pginas dinmicas. El uso de estas
funcionalidades permiten que las pginas sean ms fciles de leer y mantener. El siguiente
cdigo es un ejemplo de vista JSP utilizando etiquetas JSTL:
93
En este caso se utilizan las etiquetas c y form. La etiqueta c se utiliza para realizar iteracin
sobre datos y operaciones condicionales. La etiqueta form se utiliza para realizar operaciones
especficas del formulario como indicar qu objeto del modelo de datos vamos a enlazar con
el formulario, indicar qu atributos del objeto se enlazan con cada elemento del formulario o
mostrar errores.
Como se dijo anteriormente, en la aplicacin se usa el patrn de diseo DAO. Una buena
prctica es crear un DAO genrico que ser usado en todos los DAOs especficos debido a
que hay operaciones comunes en todos los DAOs. El DAO genrico implementar mtodos
como buscar, modificar, guardar o borrar.
94
95
Captulo 6
Pruebas
96
Las pruebas pueden determinar el xito o fracaso de un producto final, ya que deben
proporcionarnos garantas sobre el funcionamiento correcto de la aplicacin.
Para asegurar la estabilidad y robustez, se han realizado diversas pruebas,tanto funcionales
como para comprobar el tiempo de respuesta de la aplicacin.
97
MENS PRINCIPALES
IDENTIFICADOR: PF-02
DESCRIPCIN: Comprobar que se muestran correctamente los mens de grupos y
eventos.
ACCIONES:
1. Iniciar la aplicacin y autenticarse como usuario.
2. Pulsar el botn Grupos del men lateral y comprobar que se muestra el men de
grupos correctamente.
3. Pulsar el botn Eventos del menu lateral y comprobar que se muestra el men
de eventos correctamente.
RESULTADO: Correcto
NOTIFICACIN DE NOVEDADES
IDENTIFICADOR: PF-03
DESCRIPCIN: Comprobar que se muestra un mensaje con las novedades de eventos
al autenticarse en la aplicacin.
ACCIONES:
1. Iniciar la aplicacin y autenticarse como usuario.
2. Crear/modificar un evento.
3. Desconectarse de la aplicacin.
4. Iniciar sesin con otro usuario que pertenezca al grupo del evento creado o est
apuntado al evento modificado.
5. Comprobar que se muestra un mensaje en pantalla con las novedades en cuanto a
eventos.
6. Pulsar el enlace que acompaa al mensaje para comprobar el listado de los eventos
creados o modificados.
RESULTADO: Correcto
98
99
100
101
COMPROBAR GEOLOCALIZACIN
IDENTIFICADOR: PF-12
DESCRIPCIN: Comprobar que la funcionalidad de geolocalizacin funciona en los
mapas de GMaps.
ACCIONES:
1. Iniciar la aplicacin y autenticarse como usuario.
2. Pulsar el botn de eventos y acceder a la creacin de eventos.Introducir un lugar
(debe existir) en la caja de texto de la geolocalizacin y comprobar que el mapa de
GMaps se posiciona en dicho lugar.
RESULTADO: Correcto
102
LOGIN
IDENTIFICADOR: PF-15
DESCRIPCIN: Comprobar que no se permite acceder a la aplicacin a los usuarios no
registrados.
ACCIONES:
1. Iniciar la aplicacin y acceder a la pantalla de login.
2. Rellenar el nombre de usuario con un usuario vlido y el password incorrecto.
3. Comprobar que al pulsar el botn Login se muestra un mensaje indicando que los
datos no son correctos.
RESULTADO: Correcto
103
104
105
PF_15
PF_14
PF_13
PF_12
PF_11
PF_10
PF_09
PF_08
PF_07
PF_06
PF_05
PF_04
PF_03
PF_02
PF_01
RS_RF_01
RS_RF_02
RS_RF_03
RS_RF_04
RS_NF_05
RS_NF_06
RS_NF_07
RS_NF_08
RS_NF_09
RS_NF_10
RS_RF_11
RS_RF_12
RS_NF_13
RS_RF_14
RS_NF_15
RS_NF_16
RS_NF_17
RS_NF_18
RS_NF_19
RS_NF_20
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Tabla 4. Matriz de trazabilidad de funcionalidad
106
Captulo 7
Conclusiones y lneas futuras
107
108
109
Migrar la aplicacin para que pueda ser utilizada en los distintos dispositivos mviles.
Los usuarios podrn mandarse correos entre ellos. Para poder visualizarlos cada
usuario dispondr de un buzn personal.
Los usuarios podrn escribir mensajes en los eventos, y todos los usuarios apuntados
al evento podrn leerlos.
Se introducirn ms idiomas adems del espaol.
Introducir ms opciones para poder filtrar los registros en los listados.
Opcin de poder subir ms de una foto al perfil
Aadir un chat entre usuarios.
110
Glosario
AJAX
AOP
Aspect-Oriented Programming
API
BBDD
Base de Datos
CSS
CRUD
DAO
EJB
Enterprise JavaBeans
GWT
HQL
HTML
IDE
IoC
Inversion of Control
JDBC
JNDI
JPA
JPQL
J2EE
JSON
JSF
JavaServer Faces
JSP
JavaServer Pages
JSTL
MVC
ORM
Object-Relational Mapping
POJO
SGBD
SQL
UML
111
XML
112
113
Anexo A
Planificacin y presupuesto
114
Planificacin
Debido a lo complejo que resulta el desarrollo de este proyecto, es necesario establecer una
estimacin inicial y planificacin que defina cmo abordar las distintas fases que componen el
desarrollo del mismo.
Se empieza con la parte ms importante el anlisis y diseo, donde se realiza la recoleccin
de requisitos definidos en primera instancia por los usuarios, con su posterior tratamiento y
desarrollo.
En segundo lugar el diseo completo del sistema, a partir de dichos requisitos dar lugar a las
especificaciones necesarias para empezar el desarrollo del mismo.
A continuacin, se proceder a poner en prctica el diseo obtenido, siendo fieles a lo
anteriormente establecido. Esto comprender desde el desarrollo del cdigo necesario hasta
las posteriores remodelaciones.
Despus, con las primeras versiones del sistema, se proceder a realizar los test necesarios
que verifiquen el buen funcionamiento del mismo en diversas situaciones.
Debido a que en esta etapa puede surgir la necesidad de modificar el desarrollo del mismo, es
posible que se deba retroceder para poder solventar los problemas y errores que puedan
aparecer.
Adems, se realizarn mltiples revisiones sobre la documentacin creada durante todo el
proceso para establecer su versin final.
Por ltimo, se proceder a la implementacin de la versin final del proyecto.
La planificacin se ha establecido en horas (aproximadas) puesto que es una medida mucho
ms intuitiva a la hora de tomar conciencia del esfuerzo estimado.
Dicha planificacin inicial se muestra en la siguiente tabla y el calendario de las tareas se
representa en una diagrama Gantt.
115
DESCRIPCIN DE LA TAREA
Planteamiento inicial
Toma de requisitos funcionales
Toma de requisitos no funcionales
Reajustes de los requisitos
Anlisis de tecnologas candidatas
Casos de uso
Diagrama de casos de uso
Modelo de dominio
Diagrama de actividades
Diagrama de flujo
Diseo del sistema
Diseo de las pantallas
Instalacin y configuracin del software a utilizar
Aprendizaje de las tecnologas a usar
Capa dominio
Capa persistencia
Capa servicios
Capa aplicacin
Capa presentacin
Pruebas
Documentacin
Despliegue
ETAPA
Anlisis
Anlisis
Anlisis
Anlisis
Anlisis
Anlisis
Anlisis
Diseo
Diseo
Diseo
Diseo
Diseo
Implementacin
Implementacin
Implementacin
Implementacin
Implementacin
Implementacin
Implementacin
Pruebas
Documentacin
Integracin
TOTAL
HORAS ESTIMADAS
12
8
8
8
14
4
1
8
8
8
12
12
12
80
12
12
12
65
65
60
80
4
505
116
117
Presupuesto
El presupuesto hace referencia al precio total real que tendra este proyecto. Se ha supuesto
que se tuviese que adquirir todo lo necesario (hardware y software), aunque, claro est,
cualquier empresa ya dispondra de parte de estos recursos.
Costes de personal
ste es el coste de los recursos humanos que supondra a la empresa de desarrollo el pagar a
los empleados encargados de desarrollar el proyecto segn la planificacin que se incluy en
la tabla 5.
Tendremos en cuenta que el precio por hora medio estndar de un analista en una empresa
se paga a 36, mientras que la del programador est a 28. Si hacemos los clculos
pertinentes:
Recurso
Analista
Programador
Total
Nmero
1
1
2
Importe/hora
36
28
-
N Horas
103
402
505
Importe total
3708
11256
14964
118
Descripcin
Coste
% Uso
100%
100%
100%
100%
100%
Dedicacin
(meses)
7
8
8
7
7
Perodo de
depreciacin
60 meses
60 meses
-
Coste
imputable
452
257
0,00
0,00
0,00
Servidor
Ordenador
S.O. Windows 8
Base de datos MySql
Servidor de
aplicaciones Tomcat
Framework Hibernate
Framework Spring 3
MVC
Eclipse IDE
TOTAL
3000
1500
0,00
0,00
0,00
0,00
0,00
100%
100%
7
7
0,00
0,00
0,00
100%
0,00
709
Otros costes
No se ha contemplado ningn otro tipo de coste como pueden ser viajes o dietas.
119
Resumen de costes
Concepto
Presupuesto
Personal
Material para el desarrollo
Subcontratacin de tareas
Otros costes
TOTAL sin I.V.A
TOTAL con I.V.A
14964
709
0
0
15673
18964,33
Tabla 8: Resumen de costes
El presupuesto total del proyecto sin I.V.A asciende a la cantidad de 15673 EUROS y
aplicando el 21% del I.V.A correspondiente, el precio final del proyecto es de 18964,33
EUROS.
120
Anexo B
Comparativas de frameworks J2EE
121
Los Web frameworks son todos muy diferentes y se han creado normalmente por diferentes
razones y para lograr diferentes objetivos. Hay muchas caractersticas que pueden influir en la
decisin de elegir uno u otro y, por supuesto, depender del tipo de aplicacin que se est
construyendo.
En este anexo vamos a analizar las ventajas y desventajas de los frameworks Web ms
populares del mercado.
En primer lugar, vamos a mostrar la siguiente comparativa para ver qu cuota de mercado
tiene cada framework.
122
Spring MVC 3
Ventajas
Integracin con diferentes opciones para la vista como JSP/JSTL, Tiles, Velocity,
FreeMarker, Excel, PDF, o implementar tu propio lenguaje para integrarlo en la vista
de la aplicacin.
Los controladores de Spring MVC se configuran mediante IoC como los dems
objetos, lo cual los hace fcilmente testeables e integrables con otros objetos que
estn en el contexto de Spring, y por tanto sean manejables por ste.
Spring soporta un gran nmero de especificaciones, como JSR330, JMS, JSR250,
JPA, JSR303, etc
En cuanto a salida laboral, es muy conocido.
Al ser el framework ms utilizado, existe mucha documentacin y tutoriales
disponibles en Internet.
Constantemente actualizndose
Desventajas
El contenedor de Spring no es ligero (si se usan todos los mdulos disponibles),
no es recomendable su uso en aplicaciones de tiempo real o en aplicaciones para
mviles.
No se puede evaluar si un objeto ha sido bien inyectado ms que en tiempo de
ejecucin. Aunque hay herramientas como Spring IDE que s que ayudan.
Spring es bastante complejo y extenso, es necesario un tiempo previo para poder
explotar todas sus cualidades.
Struts 2
Ventajas
Arquitectura simple y fcil de extender.
Framework especializado en controlador.
Libreras de Tags fciles de personalizar.
AJAX integrado mediante Dojo Tookit.
Plugins para integrar GWT y resultados JSON.
OGNL ayuda en la conversin y validacin en la parte del cliente.
Facilidad en la testeabilidad.
Soporta la internacionalizacin y apuesta por la separacin de ficheros por cada
pgina y accin en la internacionalizacin.
Puede usar Tiles & SiteMesh para la decoracin de pginas.
Desventajas
Documentacin mal organizada.
Struts 1.x abarca la mayora de resultados en las bsquedas de internet .
123
Tapestry
Ventajas
Muy productivo una vez se aprende como funciona.
Muchas actualizaciones e innovaciones entre versiones.
Integra AJAX mediante Dojo Toolkit
Buen sistema de validacin.
Soporta la internacionalizacin y apuesta por la separacin de ficheros por cada
pgina y accin en la internacionalizacin.
Puede usar Tiles & SiteMesh para la decoracin de pginas.
Desventajas
Mala documentacin.
124
125
Anexo C
Patrn DAO
126
En una aplicacin J2EE necesitamos acceder a datos, ya sea por persistencia (hibernate, jdo,
iBatis), jdbc, ficheros de texto, LDAP, etc. Esto puede suponer un problema, pues la forma
de acceder a los datos depende del fabricante y del tipo de almacenamiento que estamos
accediendo.
Los componentes de nuestra aplicacin deben ser transparentes en la medida de lo posible al
actual sistema de persistencia o fuente de datos para permitir migraciones entre distintos
fabricantes, distintos tipos de almacenamiento y diferentes fuentes de datos. Supongamos
que en un momento dado queremos cambiar el motor de persistencia. Siguiendo este
mdelo ser mucho ms fcil.
Debemos tener muy claro que el acceso a los datos vara mucho dependiendo de la fuente de
los datos. El acceso al almacenamiento persistente, como una base de datos, vara mucho en
funcin del tipo de almacenamiento (bases de datos relacionales, bases de datos orientadas a
objetos, archivos planos, etc) y la implementacin de cada uno de los proveedores que tiene
la empresa.
El patrn DAO viene a resolver este problema usando un Objeto de Acceso a Datos para
abstraer y encapsular el acceso a los datos. Un DAO maneja la conexin con la fuente de
datos para obtener y guardar los datos. De esta forma conseguimos que nuestra lgica de
negocio no sepa nada del motor de persistencia, y siempre que quiera acceder a los datos lo
har usando la interface DAO, con esto conseguimos reducir el acoplamiento. [24]
Un DAO siempre realiza operaciones atmicas contra la base de datos, nunca son necesarias
las transacciones. Claros ejemplos de esto seran busquedas por una clave, creacin,
actualizacin y borrado de un registro, obtener todos los registros y cualquier otra operacin
que vayamos a realizar muy a menudo.
Normalmente se crea un DAO por cada Objeto que usemos en nuestra aplicacin, como por
ejemplo un Entity de Hibernate.
Los componentes de negocio que se basan en DAO utilizan la interfaz ms simple expuesta
por DAO para sus clientes. DAO oculta completamente los detalles del origen de datos de la
aplicacin hacia sus clientes. Debido a que la interfaz expuesta por el DAO a los clientes no
cambia cuando los datos subyacentes cambian su implementacin de cdigo, este modelo
permite al DAO adaptarse a los sitemas de almacenamiento sin que ello afecte a sus clientes o
componentes de negocio.
127
BusinessObject
El BusinessObject es la clase que va a obtener y almacenar los datos que obtendremos con el
patrn DAO, por lo tanto requiere el acceso a la fuente de datos .
DataAccessObject
Es el objeto principal de este patrn. El DataAccessObject abstrae la implementacin del
acceso a los datos subyacentes para el BusinessObject para permitir el acceso transparente a
la fuente de datos. El BusinessObject tambin delega la carga de datos y operaciones de
almacenamiento al DataAccessObject.
El DAO provee una interface permitiendo operaciones especficas sin exponer los detalles de
cmo se accede a la base de datos. Una buena prctica,es que estas interfaces incorporen la
funcionalidad CRUD.
DataSource
Contiene la implementacin especfica para cada fuente de datos.
128
Ventajas
Los DAO son un patrn de diseo J2EE y es considerada como buena prctica.
Los objetos de negocio no conocen como se va a manipular la informacin, ellos slo
tienen acceso a unos servicios para almacenar o obtener informacin de la base de
datos.
Separacin entre la capa de persistencia y la aplicacin.
Los cambios realizados en la capa de persistencia no afectan a los clientes que usan
DAO.
Desventajas
129
Anexo D
Patrn MVC
130
El patrn MVC fue originalmente formulado a finales de los 70s por Trygve Reenskaug en
Xeros SPARC como parte del sistema Smalltalk. [25]
Este patrn est indicado especialmente para el diseo de arquitecturas de aplicaciones que
requieran de una gran interactividad con los usuarios, como es el caso de aplicaciones Web.
De hecho, la gran mayora de Frameworks web J2EE estn basados en el patrn MVC.
Es un patrn o modelo de abstraccin de desarrollo de software que separa los datos de una
aplicacin, la interfaz de usuario, y la lgica de negocio en tres componentes distintos.
El principio fundamental del patrn MVC es definir una arquitectura con claras
responsabilidades para diferenciar componentes.
Por un lado tenemos el Modelo, el cual representa los datos de la aplicacin y sus reglas de
negocio; por otro la Vista, compuesta de vistas que representan los formularios de entrada y
salida de datos; y finalmente, el Controlador, encargado de procesar las peticiones entrantes
del usuario y controlar el flujo de ejecucin del sistema.
El patrn MVC en la programacin web J2EE se le conoce como arquitectura de modelo 2.
Esta arquitectura consiste en la utilizacin de Servlets para procesar las peticiones, que
estaran contenidos en el Controlador del patrn, y pginas JSP para mostrar la interfaz del
usuario que representara la Vista, y finalmente los famosos JavaBeans ubicados en el
modelo.
Controlador
Todas las peticiones a la capa intermedia que se realicen desde el cliente pasarn por
el Controlador, ste determinar las acciones a realizar e invocar al resto de los
componentes de la aplicacin como pueden ser el modelo o la vista.
131
Vista
La vista es la encargada de generar las respuestas que deben ser enviadas al cliente.
Esta respuesta normalmente incluir datos generados por el controlador, entonces el
contenido de la pgina no ser esttico sino que ser generado de forma dinmica, y
ah es donde entrarn los JSP.
Modelo
Encapsula la lgica de negocio de la aplicacin, acceso a los datos y su manipulacin.
Debido al auge que tienen las aplicaciones web basadas en Ajax, la aplicacin del patrn MVC
ha sido mejorada para proveer mejores experiencias a los usuarios usando JavaScript, Ajax y
el uso de formatos especiales de informacin como son JSON o XML.
132
Anexo E
Gua de usuario
133
Este anexo sirve como tutorial para guiar al usuario a travs de la aplicacin Woodie.
Debido a que la aplicacin gestiona usuarios, regiones, eventos y grupos se dividir la gua en
4 secciones.
134
En el caso de acceder a la pantalla de registro de usuario, ste tendr que introducir sus datos
personales. Campos obligatorios sern el nombre de usuario y el password. Tambin el
usuario podr asociar una imagen al perfil.
Una vez que el usuario accede a la aplicacin, sta mostrar siempre un men lateral con las
distintas secciones y una cabecera con el nombre del usuario y el botn para salir de la
aplicacin.
135
En cuanto a los distintos tipos de listados, el usuario podr realizar bsquedas por nombre de
evento. Los eventos se muestran ordenados por fecha de evento.
Al lado de cada registro, se muestran varios posibles enlaces como pueden ser ver la
informacin del evento, modificar el evento, borrar el evento, apuntarse al evento y
abandonar el evento.
136
137
138
Anexo F
Material entregado
139
Todos los programas necesarios para poder arrancar la aplicacin se entregan con el material
adjunto a la memoria del proyecto.
Los ficheros incluidos para instalar y establecer las condiciones iniciales son entregados en
una jerarqua de directorios. Los directorios son los siguientes:
Finalmente, slo tenemos que copiar el fichero woodie.war dentro de nuestro Contenedor de
Servlets Tomcat en la carpeta webapps:
C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps
Iniciamos Apache Tomcat y desde el browser escribimos: http://localhost:8080/woodie
140
Bibliografa
[1] Walls, Craig. Spring in Action 3 .2011
[2] Acera Garca, Migue Angel. CSS 3.2012
[3] Pugh, Eric. Professional Hibernate. 2004
[4] La Web 2.0. Una revolucin social y creativa. 2009
Disponible:
http://telos.fundaciontelefonica.com/telos/articulodocumento.asp@idarticulo=3&rev=74.ht
m
[5] Anlisis de los servicios de la tecnologa Web 2.0 aplicados a la educacin. 2010
Disponible:
http://www.nosolousabilidad.com/articulos/tecnologia_educacion.htm#sthash.S2qffYht.dpu
f
[6] Qu es AJAX. 2012
Disponible:
http://www.digitallearning.es/blog/que-es-ajax/
[7] JSON. 2011
Disponible:
http://librosweb.es/symfony/capitulo_11/json.html
[8] Qu es CSS. 2012
Disponible:
http://librosweb.es/css/capitulo_1.html
[9] Wikipedia. Google Maps. 2014
Disponible: http://es.wikipedia.org/wiki/Google_Maps
141
142
143
144