Está en la página 1de 75

Pedro Colomina Medina

APLICACIÓN WEB PARA AGENTES COMERCIALES BASADA EN EL


PATRÓN MVC

TRABAJO DE FIN DE GRADO

dirigido por el Dr. Marc Sánchez Artigas

Grado en Ingeniería Informática

Tarragona
2014
Resumen

2
Resumen

Resumen
Hoy en día, muchos agentes comerciales o distribuidores de productos de marcas
siguen estancados en los métodos tradicionales para realizar sus tareas. Uno de estos
métodos es la recogida de pedidos mediante el teléfono móvil o directamente en persona;
otro método sería realizar la típica factura a mano o incluso con programas de hojas de
cálculo. Con esta aplicación se modernizará el ámbito de trabajo de estos agentes.
Por una parte, los clientes podrán encargar productos mediante cualquier dispositivo,
simplemente a través de su navegador web. Además, esto significa que tendrán toda la
información de los productos, facturas, datos, etc., en cualquier momento a su disposición.
Por otra parte, el agente comercial tendrá un control total de sus usuarios, productos o
facturas, gestionando así todo de una manera más fácil y rápida. No solo la gestión es
importante, ya que si podemos ahorrar tiempo a estos trabajadores generando las facturas
automáticamente, a partir de un pedido, aumentaría su producción y se reducirían los
costes de tiempo o de dinero, en el caso de que tenga a alguien encargado de la gestión.

Resum
Avui en dia, molts agents comercials o distribuidors de productes de marques
segueixen estancats en els mètodes tradicionals per realitzar les seves tasques. Un d'aquests
mètodes es la recollida de comandes mitjançant el telèfon mòvil o directament en persona;
un altre mètode seria realitzar la factura típica a mà o inclòs amb programes de fulls de
càlcul. Amb aquesta aplicació es modernitzarà l'àmbit de treball d'aquests agents.
D'una banda, els clients podran encarregar productes mitjançant qualsevol dispositiu,
simplement a traves del seu navegador. A més, això significa que tindran tota l'informació
dels productes, factures, dades, etc., en qualsevol moment a la seva disposició. D'altra
banda, l'agent comercial tindrà control total dels seus usuaris, productes o factures,
gestionant així tot d'una manera més fàcil i ràpida. No només la gestió es important, ja que
si podem estalviar temps a aquests treballadors generant factures automaticament, a partir
d'una comanda, augmentaria la seva producció i es reduirían costos de temps o de diners,
en el cas que tingui a algú encarregat de la gestió.

Abstract
Nowadays, many commercial agents or distributors of designer products remain
being blocked in traditional methods to do their jobs. One of these methods is the order
collection by mobile phone or directly in person; another method is to generate the typical
receipt by hand or even with spreadsheet programs. With this application the work setting
of these agents will be modernized.
On the one hand, costumers will be able to order products by any device, simply
through their web browser. Furthermore, this means that they will have all the information
about the products, receipts, data, etc., at any time at their disposal. On the other hand, the
commercial agent will have a total control of his users, products or receipts, managing
everything in the easiest and fastest way. Not only it is the management important, since if
we can save time to these workers by generating the receipts automatically, the production
will be increased and time and money-cost will be reduced , in the event that someone is in
charge of the management.

3
Índice

Contenido

1 Introducción ....................................................................................................... 7
1.1 Las aplicaciones web ................................................................................... 7
1.1.1 Ventajas .................................................................................................... 7
1.2 El patrón MVC............................................................................................. 8
1.3 La evolución del framework Struts .............................................................. 8

2 Objetivos del proyecto .................................................................................... 10


2.1 Introducción ............................................................................................... 10
2.2 Objetivos concretos .................................................................................... 10
2.2.1 Objetivos principales.............................................................................. 11
2.2.2 Objetivos secundarios ............................................................................ 12
2.2.3 Objetivos complementarios .................................................................... 12
2.3 Objetivos de aprendizaje ............................................................................ 13

3 Especificaciones del proyecto ......................................................................... 14


3.1 Especificaciones del servidor..................................................................... 14
3.1.1 Especificaciones del software ................................................................ 14
3.1.2 Especificaciones del hardware............................................................... 15
3.2 Especificaciones del cliente ....................................................................... 15
3.3 Especificaciones del programa .................................................................. 15

4 Diseño ............................................................................................................... 17
4.1 Estructura de la aplicación ......................................................................... 17
4.1.1 MVC, la base del proyecto ..................................................................... 17
4.1.2 Framework Struts 2 ................................................................................ 18
4.2 Herramientas para el desarrollo del entorno web ...................................... 18
4.2.2 Entorno de programación ...................................................................... 19
4.3 Elección del servidor ................................................................................. 19
4.4 Base de datos ............................................................................................. 20
4.4.1 Definición de los datos ........................................................................... 20
4.4.2 Esquema de la base de datos ................................................................. 20
4.5 Interfaz gráfica ........................................................................................... 21

4
Índice

4.5.1 Nombre, logotipo y productos de la aplicación ..................................... 22


4.5.2 Usabilidad y interfaz .............................................................................. 22
4.5.3 Dispositivos destino de la aplicación ..................................................... 23
4.5.4 Formato de las facturas ......................................................................... 24
4.6 Internacionalización ................................................................................... 25
4.7 Tipo de usuarios en el ámbito web ............................................................ 26
4.8 Seguridad ................................................................................................... 26
4.9 Formato del directorio de carpetas ............................................................. 27
4.9.1 Base del proyecto o servidor .................................................................. 27
4.9.2 Los reportes generados de facturas ....................................................... 28
4.9.3 Imágenes de los productos ..................................................................... 28

5 Desarrollo ......................................................................................................... 30
5.1 Implementación del modelo....................................................................... 30
5.1.1 Persistencia ............................................................................................ 30
5.1.2 JDBC ...................................................................................................... 30
5.1.3 JavaBeans (DTO) ................................................................................... 33
5.1.4 DAO........................................................................................................ 34
5.1.5 DAO Factory .......................................................................................... 35
5.1.6 Tuplas ..................................................................................................... 36
5.2 Implementación del controlador ................................................................ 38
5.2.1 FilterDispatcher y configuración web ................................................... 38
5.2.2 Struts.xml y resultados ........................................................................... 38
5.2.3 Variables de sesión y de la vista ............................................................ 39
5.2.4 Interceptores, seguridad básica ............................................................. 40
5.2.5 Validaciones en campos de entrada de texto ......................................... 42
5.2.6 Mensaje de acciones............................................................................... 43
5.3 Implementación de la vista ........................................................................ 44
5.3.1 Páginas JSP............................................................................................ 44
5.3.2 Struts 2 Tags ........................................................................................... 44
5.3.3 JQuery Tags de Struts 2 ......................................................................... 46
5.3.4 Tiles ........................................................................................................ 47
5.3.5 Interfaz general ...................................................................................... 48
5.3.6 Scripts ..................................................................................................... 50
5.4 I18n ............................................................................................................ 51
5.4.1 Acceder a las variables desde el JSP ..................................................... 51

5
Índice

5.5 Gestionando las facturas ............................................................................ 52


5.5.1 JasperReports ......................................................................................... 52
5.5.2 iReport .................................................................................................... 52
5.5.3 Carga de las facturas en la base de datos ............................................. 52
5.5.4 Envío de las facturas por email.............................................................. 54
5.6 Habilitar el acceso a la aplicación desde internet ...................................... 56

6 Evaluación ........................................................................................................ 57
6.1 Funcionamiento del modelo....................................................................... 57
6.2 Funcionamiento del controlador ................................................................ 58
6.3 Funcionamiento de la vista ........................................................................ 59
6.4 Fase de pruebas con diferentes usuarios .................................................... 60
6.4.1 Resultado final........................................................................................ 60

7 Conclusiones .................................................................................................... 63
7.1 Cumplimiento de los objetivos .................................................................. 63
7.1.1 Objetivos principales.............................................................................. 63
7.1.2 Objetivos de aprendizaje ........................................................................ 63

8 Recursos utilizados .......................................................................................... 65


8.1 Bibliografía ................................................................................................ 65
8.2 Software empleado .................................................................................... 65
8.3 Hardware para el desarrollo ....................................................................... 66
8.4 Programas de edición de textos ................................................................. 66

9 Anexos .............................................................................................................. 67
9.1 Manual de instalación y configuración ...................................................... 67
9.2 Manual de usuario ...................................................................................... 69
9.2.1 Administrador......................................................................................... 69
9.2.2 Cliente .................................................................................................... 72

6
Capítulo 1: Introducción

1 Introducción
En esta primera parte se explicará la tecnología y los conceptos claves que se han
utilizado para realizar esta aplicación web. Primero se hará una pequeña introducción del
concepto de aplicación web, y como ésta se puede estructurar con el patrón MVC.
También se hará un repaso a toda la evolución del framewok Struts, una pieza clave
para este proyecto.

1.1 Las aplicaciones web


Una aplicación web engloba todas aquellas herramientas utilizadas por los usuarios
mediante un navegador para acceder a un servidor web con ayuda de Internet. Estas
aplicaciones están programadas en lenguajes de programación como son PHP, Java (Java
Servlets y JavaServer Pages), Perl, Javascript, etc,. los cuales están soportados por los
navegadores web.
Una de las características de estas aplicaciones es que pueden contener elementos
que permiten una comunicación interactiva entre el usuario y la información; un claro
ejemplo son los formularios, los cuales son rellenados y enviados al servidor, donde queda
almacenada la información.
La mayoría de estas aplicaciones suelen ofrecer menos funcionalidades que las
aplicaciones de escritorio, ya que un sistema operativo engloba muchas más
funcionalidades y acciones que un navegador web. Esta carencia puede ser solucionada
mediante otras Aplicaciones de Internet Ricas, las cuales permiten instalar en el sistema
operativo para complementar más funciones en el navegador. De cualquier modo, para este
proyecto no ha sido necesario utilizar ninguna instalación extra.

1.1.1 Ventajas

 Portables, multiplataforma y sin problemas de compatibilidad, ya que se


podrán usar en cualquier navegador de cualquier plataforma; lo único necesario es
una conexión a Internet.
 Todo el contenido de la aplicación está localizado en un servidor con lo cual no
ocupará espacio en el disco duro.
 Se tendrán actualizaciones al momento en el caso de que el desarrollador de la
página decida actualizar la versión de la misma.
 Los posibles malware o virus que tengan los clientes que se conecten al entorno
Web no dañarán los datos del mismo ya que están almacenados en un servidor
externo.
 Gracias a que la aplicación se ejecuta en el navegador y ésta se encuentra en un
ordenador externo al nuestro, el consumo de recursos será realmente bajo.

7
Capítulo 1: Introducción

1.2 El patrón MVC


El modelo-vista-controlador es un patrón de arquitectura de software que separa los
datos, la lógica de negocio y la interfaz gráfica de usuario, además del módulo encargado
de gestionar los eventos. Para llevar a cabo esto, la aplicación Web se divide en tres
bloques explicados a continuación con la finalidad de poder facilitar la tarea de desarrollo
y su posterior mantenimiento y evolución.
El Modelo: Es el bloque que representa toda la información de datos y gestiona
todos los datos a ésta. Gestionar en esta parte significa tanto poder hacer consulta a los
datos como poder manipularlos a la necesidad que convenga. Todas las acciones que son
enviadas al modelo pasarán primero por el controlador y una vez realizada la operación
con los datos, se enviará a la vista (a través otra vez del controlador) aquella parte de la
información que en cada momento se solicita para poder mostrarla.
El Controlador: Es el bloque que responde a las acciones o peticiones que los
usuarios demandan desde la vista. Se puede decir entonces que este controlador actúa
como intermediario entre la vista y el modelo.
La Vista: Es la interfaz gráfica de la aplicación web, la cual recibe información del
modelo y la muestra al usuario en un formato adecuado para interactuar.

Figura 1. Esquema del patrón MVC

1.3 La evolución del framework Struts

El patrón MVC también tiene una serie de inconvenientes como son:


 La dificultad de comprensión del bloque de modelo y el nivel de
conocimientos que requiere.
 Al dividir la arquitectura en tres partes el número de archivos puede ser
mucho mayor.
A partir de los inconvenientes anteriores se buscó la solución para poder reducir
esos inconvenientes y aumentar la productividad.

8
Capítulo 1: Introducción

Esta solución fue creada alrededor del año 2000 en forma de framework por Craig R.
MCclanahan's para agilizar los desarrollos Java EE. Meses más tarde fue donada a la
fundación Apache, la cual fue lanzada un año más tarde con el nombre de Struts 1.0.
Al mismo tiempo que este primer framework, otro equipo de desarrolladores crearon
otro con el nombre de WebWork. Éste nunca llegaría a tener tanta popularidad como Struts
1.0 pero incorporaba nuevas características que llamaban mucho la atención como son la
validación de formularios o la ejecución sin necesidad de utilizar ningún navegador.
A finales de 2005, WebWork y Struts 1.0 se fusionaron para formar un único
framework, llamado a priori Struts TI (Titanium) y que poco después pasó a llamarse
Struts 2.0 (el cual es utilizado en este proyecto). Esta fusión pretendía agrupar las ventajas
de los dos frameworks. Sin embargo Struts 2.0 no está basado en Struts 1.0, ya que el
primero tiene un diseño completamente nuevo mayormente basado en WebWork 2.2.
Con lo cual aquellos desarrolladores que sabían todos los comandos y
funcionalidades de la primera versión de Struts tendrán que aprender desde cero todos los
nuevos métodos de Struts 2.0.

9
Capítulo 2: Objetivos del proyecto

2 Objetivos del proyecto


2.1 Introducción
Este proyecto pretende desarrollar un entorno web utilizando nuevas tecnologías
como es el caso de CSS 3 para poder adaptar la estructura de la aplicación al formato del
terminal que se utilizará en aquel momento. Todo esto para modernizar el ámbito de
trabajo de un agente comercial.
Toda esta idea surgió por un familiar que se dedica a distribuir productos de una
famosa empresa de nutrición deportiva llamada Nutrisport. Muchos días que iba a verlo
veía que recibía llamadas de encargos a cualquier hora por teléfono móvil, lo cual puede
llegar a ser un poco incómodo y estresante para el día a día. Más allá vi que, cada tarde que
llegaba de repartir, tenía apuntados en una libreta todos los productos que había repartido y
a quien los había repartido.
Con esta libreta de datos y pedidos, cada tarde, creaba la factura a mano con un
programa de hojas de cálculo (Microsoft Excel), y a continuación las enviaba una a una a
cada cliente por correo electrónico. Con lo cual el trabajo no acababa a la tarde, ya que
después de acabar de generar todas las facturas eran altas horas de la noche.
Por lo tanto, realizando este proyecto se facilitará los métodos diarios de un
distribuidor y se mejorará su calidad de vida; a la vez, se mejorará su producción, ya que
los clientes cada vez están más modernizados y coger un ordenador, un teléfono móvil o
una tableta para realizar un pedido les resultará mucho más funcional que una llamada de
teléfono o un envío de correo electrónico.
El proyecto, como toda aplicación web, se dividirá en dos caras: el servidor y el
cliente. Para la parte del servidor se decidió utilizar J2EE en su versión 7, con la versión
3.2 d’Enterprise Java Beans y la versión 2.3 de JavaServer Pages.
Por la parte del cliente se desarrollará con páginas JSP, las cuales además de poder
utilizar etiquetas de Struts, se basarán mayormente en HTML (4 y 5), CSS (2 y 3) y
Javascript. El navegador que se utilizará para el chequeo del desarrollo será Mozilla
Firefox.
El requerimiento que tiene que tener el navegador es poder interpretar los nuevos
lenguajes HTML 5 y CSS 3 ya que se han incorporado algunas pequeñas mejoras en la
aplicación con estos dos lenguajes.

2.2 Objetivos concretos


A continuación se comentarán los diferentes objetivos del proyecto comenzando por
los objetivos principales donde se explicará todas las intenciones que se tenían para
realizar esta aplicación web. Seguidamente se comentarán los objetivos secundarios y
complementarios, los cuales corresponden a objetivos que se tenían al principio de la
aplicación y que, por motivos de tiempo y de recursos no se han podido llevar a cabo en
este proyecto, pero que podrían llevarse a cabo en futuras versiones de él.

10
Capítulo 2: Objetivos del proyecto

2.2.1 Objetivos principales


A continuación se explicarán las funcionalidades básicas que se intentarán
implementar en esta aplicación web.
Como la Web se dividirá en dos tipo de usuarios, dividiremos también los objetivos
en éstos dos y lo que intentaremos crear para cada uno.
Cliente:
 Registro abierto para cualquier usuario
 Consultar las diferentes categorías y productos de la página
 Estar habilitada la opción de editar su perfil
 Poder realizar un pedido de productos y:
 Finalizar el pedido para que solo quede pagarlo.
 Dejarlo en la cesta de pendientes para comprar en otro
momento.
 Seguir comprando al añadir productos a la cesta.
 Consultar las cestas pendientes y las cestas finalizadas con su correspondiente
factura.
 Habrá una página de contacto, donde los usuarios podrán localizar donde está
situada la empresa y un formulario por si desean contactar con el
administrador.
 Se habilitarán tres idiomas (castellano, catalán e inglés) para que el usuario
escoja el que necesite y así adaptar la Web a su idioma.

Administrador:
 Añadir, editar o eliminar el perfil de cualquier usuario.
 Añadir, editar o eliminar los productos distribuidos.
 Añadir, editar o eliminar las categorías de los diferentes productos.
 Revisar todas las cestas que tiene registrado el sistema, tanto pendientes,
como finalizadas sin pagar, como pagadas.
 Se podrá validar el pago de aquella cesta finalizada una vez recibido (la
factura del cual se generará, se enviará por correo electrónico al usuario y se
podrá consultar, tanto en el perfil del usuario como en el del administrador).
 Para la edición, tanto de productos como de categorías se adaptará una
herramienta externa ya realizada como es CKeditor.

Una vez explicada la funcionalidad que se pretende aplicar a este proyecto, se pasará
a explicar la interfaz gráfica del usuario:
 Tiene que ser sencilla y llamativa para que atraiga a los usuarios y prefieran
utilizar esta aplicación a un papel y un bolígrafo.
 Tiene que ser clara y concisa, donde los usuarios puedan realizar sus compras
rápidamente sin ningún tipo de líos.
 Tiene que estar preparada para cualquier tipo de tamaño de pantalla, ya que
los usuarios podrán ejecutarla desde cualquier navegador en cualquier
dispositivo.

11
Capítulo 2: Objetivos del proyecto

Por último se marcan unos objetivos claros de seguridad para el control de la sesión,
el control de los ficheros que el administrador pueda subir al servidor (imágenes de
productos) y control de la entrada de texto (principalmente en formularios). Éste último se
implementa mayormente para la parte de cliente (intentando así poder evitar ataques como
el Cross-site scripting).

2.2.2 Objetivos secundarios


A continuación se explicará una gran extensión que se tuvo en mente cuando surgió
la idea de hacer una aplicación para agentes comerciales, pero que por falta de tiempo y
dada su complejidad no se ha podido llevar a cabo.
Esta idea consistía en poder hacer una aplicación web general para cualquier tipo de
agente comercial y que este pudiera diseñar su página a medida, manteniendo las funciones
base intactas para todos, pero con apariencias personalizadas para cada uno de ellos. Esto,
en realidad, hubiese sido una aplicación para el gestión de contenidos (un ejemplo es
WordPress).
Dada su dificultad, ya que para cada uno de los distribuidores no solo se tendría que
poder personalizar su apariencia física de la Web, sino que se tendría que haber podido
personalizar todas sus facturas. Además, no todos los comerciales tienen unos métodos de
trabajo iguales e investigar todos estos métodos y funciones de cada uno de los agentes
habría sido un trabajo complejo.
Por lo tanto, en lugar de intentar diseñar un gestor de contenidos, la aplicación se
centró en un método de trabajo, en unas funciones y en una interfaz gráfica ya conocida
(basada en todo momento por mi familiar). Las cuales se han utilizado como base para
crear los objetivos principales.

2.2.3 Objetivos complementarios


En esta parte se comentarán algunas funcionalidades que durante el proyecto se
consideraron realizar, pero que al final se encontraron otras vías mucho mejores.
Una de estas funcionalidades era poder crear la aplicación especializada en cada
plataforma (Android, Windows, etc.,), ya que existen muchos frameworks que son capaces
de transformar una aplicación web en una aplicación para cualquier plataforma en
segundos.
Esta opción quedó descartada ya que con un navegador Web se podían utilizar las
mismas características y funcionalidades de la aplicación que desde una aplicación
instalada en un sistema. La única diferencia es la visualización de contenido offline, lo cual
no merece la pena ya que para poder realizar pedidos hace falta una conexión a Internet.
La siguiente funcionalidad que se pudo integrar fue la característica de HTML 5 Web
Storage, que nos proporciona una base de datos en el navegador sin la necesidad de tener
que consultar todo el tiempo los datos del servidor. Era una opción novedosa pero no con
mucha utilidad ya que los productos o datos en generales a guardar no eran de gran
tamaño.

12
Capítulo 2: Objetivos del proyecto

2.3 Objetivos de aprendizaje


Con este proyecto el redactor pretende mejorar sus conocimientos en arquitectura del
software con el patrón MVC y el framework Struts 2.0 e iniciar sus conocimientos en
lenguajes de programación como son HTML (4 y 5), CSS (2 y 3), Javascript, Java, J2EE y
EJB versión 3.2 y JSP versión 2.3. Además de conocimientos, el redactor pretende conocer
si esta ramificación de la informática puede ser un camino a seguir en futuros estudios.

13
Capítulo 3: Especificaciones del proyecto

3 Especificaciones del proyecto


Tal como se ha explicado en el apartado anterior, esta aplicación requiere por una
parte el servidor de la aplicación y por otra parte un cliente que pueda visualizar el
contenido.
A continuación se describirán las especificaciones del servidor y del cliente, tanto de
software como de hardware. También se explicarán las especificaciones del programa. La
explicación a algunas de estas especificaciones, como son las del servidor están explicadas
más adelante, en el capítulo de diseño.

3.1 Especificaciones del servidor

3.1.1 Especificaciones del software


El servidor elegido para desarrollar la aplicación es Apache, en su versión 2.0.65.
Las razones de elección de Apache están explicadas en la parte de diseño como comenté
anteriormente.
Para la base de datos se ha utilizado MySQL en su versión 5.5. Cabe decir que se ha
utilizado una distribución de Apache que contiene MySQL entre otros componentes como
PHP y Perl, no utilizados en este proyecto. Esta herramienta se llama Xampp (fig 2) y
permite una fácil instalación así como una gestión centralizada e intuitiva.

Fig 2. Panel inicial de la aplicación XAMPP

Esta distribución que incorpora los dos componentes esenciales del proyecto como es
Apache y MySQL se ha probado en Windows 7. No se ha probado el funcionamiento en
otras plataformas como Linux o Mac OS, pero es compatible con ellos, así que se intuye
que no habría ningún tipo de problema en instalar Xampp en estas plataformas.

14
Capítulo 3: Especificaciones del proyecto

Además XAMPP también incorpora una herramienta muy útil llamada


phpMyAdmin, la cual está escrita en PHP con la intención de poder gestionar y administrar
una base de datos MySQL a través de una interfaz gráfica, es decir, a través de una página
web utilizando Internet. En la figura 3 se puede apreciar las diferentes funciones que nos
permite utilizar en el panel principal de la herramienta.

Fig 3. Página principal de administración de la herramienta phpMyAdmin

3.1.2 Especificaciones del hardware


No se han determinado las necesidades mínimas de hardware, pero el servidor
funciona correctamente con un sistema Windows 7 (64 bits) con 3GB de ram y un
procesador de 2 núcleos a 1,6GHz. Cabe decir que el servidor funciona muy fluidamente
con lo cual unas características mucho más bajas que las nombradas podrían hacer que el
servidor trabajase sin ningún tipo de problema.

3.2 Especificaciones del cliente


El sistema se ha probado en un navegador Mozilla Firefox, en su versión 28.0.1. El
funcionamiento "moderno" que incluye esta aplicación son las funciones utilizadas por
HTML 5 y CSS 3, con lo cual el cliente podrá utilizar este entorno Web con navegadores
que hayan incorporado las funcionalidades de estos dos últimos lenguajes.

3.3 Especificaciones del programa


El programa se ha desarrollado utilizando las siguientes tecnologías:
 HTML (4 y 5), CSS (2 y 3) y JavaScript
 SQL estándar utilizando JDBC para hacer las llamadas a la base de datos.
 J2EE, versión 3.2 de EJB (la cual incluye Serlvets, Beans, JSP, etc.,)

15
Capítulo 3: Especificaciones del proyecto

16
Capítulo 4: Diseño

4 Diseño
En este apartado se detallarán las decisiones previas que se han tomado a la hora de
diseñar la aplicación. Se explicarán las diferentes partes, es decir, los diferentes módulos
del entorno Web como son el modelo, el controlador y la capa de presentación o vista,
junto con las tecnologías que se han utilizado y el motivo.
También se comentará la internalización de la aplicación para ampliar su expansión a
nivel internacional.

4.1 Estructura de la aplicación


A continuación se explicarán las decisiones de diseño que se han llevado a cabo para
escoger una arquitectura Web como es el patrón MVC y un framework que cumple con las
necesidades del proyecto y que encaja perfectamente con este tipo de patrón.

4.1.1 MVC, la base del proyecto


Se ha elegido este tipo de arquitectura respecto a la arquitectura estándar de página
Web, donde todo el código, tanto la lógica de la aplicación como la presentación están
mezcladas, por muchas ventajas. Además de las ventajas que tiene, otro factor que se ha
tenido en cuenta por el redactor es la popularidad de este patrón a nivel empresarial, donde
cada vez más empresas buscan desarrolladores para trabajar en esta tecnología.
A continuación se nombran una serie de ventajas que se han tenido en cuenta a la
hora de escoger este tipo de patrón para la aplicación Web:

 La principal ventaja de separar la aplicación en tres capas es la escalabilidad. Por


ejemplo, la creación de una nueva vista si se quiere hacer una versión para el
navegador de un teléfono móvil.
 Gracias a lo anterior, la implementación se realiza de forma modular.
 Sus vistas muestran información actualizada siempre. El programador no debe
preocuparse de solicitar que las vistas se actualicen, ya que este proceso es
realizado automáticamente por el modelo de la aplicación.
 Cualquier modificación a adición de datos a la aplicación, afectará únicamente a
aquellos métodos que hayamos decidido cambiar, así como las vistas que estén
relacionadas con estas acciones.
 Las modificaciones a las vistas no afectan al modelo de dominio, simplemente se
modifica la representación de la información, no su tratamiento.
 Esta separación de capas es fundamental para el desarrollo de aplicaciones
consistentes, reutilizables y con un mantenimiento mucho más fácil, llevando
como consecuencia un ahorro de tiempo considerable.
 Otra gran ventaja es la simplicidad con la que se puede gestionar y mantener el
sistema así como la posibilidad de trabajar en paralelo. Puedes tener a diseñadores
trabajando en las vistas mientras que los desarrolladores se pueden centrar en el
Controlador y el Modelo.
¿Se quiere cambiar el diseño de la interfaz Web? Tan solo edita el documento de la
vista (HTML, JSP,...) y la aplicación seguirá funcionando.
 Al tener la lógica separada de la interfaz es mucho más sencillo crear las pruebas
unitarias y desarrollar mediante TDD (Test Driven Development).

17
Capítulo 4: Diseño

 No hay ViewState, ni HTML autogenerado por controles, ni mantenimiento de


estado en el código. Lo que interpreta el navegador es exactamente lo que hemos
escrito. Eso hace que la página sea más ligera y cargue en menos tiempo.
 Este tipo de arquitectura ayuda a controlar los recursos del servidor, evitando bugs
que puedan repercutir en el rendimiento, por ejemplo, muchas veces olvidamos
cerrar conexiones a la base de datos, sobrecargando el servidor.

4.1.2 Framework Struts 2


Como se dijo en capítulos anteriores, todo diseño de arquitecto tiene que tener una
serie de herramientas que lo hagan posible y le den forma, es aquí donde Struts juega un
papel importante en esta aplicación. Los argumentos de la elección se basan mayormente
en sus características, pero que sea uno de los frameworks más popular y utilizado entre
desarrolladores de aplicaciones Web fue el principal factor a tener en cuenta a la hora de
escogerlo.
A continuación se explicarán las características más relevantes de esta herramienta:
 Es un framework de código abierto para desarrollar aplicaciones Web J2EE.
 El controlador ya se encuentra implementado, sin embargo es posible
extenderlo o modificarlo si es necesario.
 El flujo de la aplicación se controla desde un único archivo en formato XML
(struts-confir.xml).
 Facilita y soporta la construcción de la interfaz gráfica de la aplicación
mediante un conjunto de tags predefinidos.
 Usa y extiende la API Servlet de Java para motivar a desarrolladores a
adoptar la arquitectura MVC.
 La validación de datos está integrada, con lo cual solo hace falta añadir el
archivo con las variables que se quieren comprobar.
 Incluye muchas librerías adicionales como es el caso de Jquery, el cual nos
permite programar con Javascript de una manera muy fácil y rápida desde los
diferentes tags.

4.2 Herramientas para el desarrollo del entorno web


4.2.1 Lenguajes de programación
Antes de plantearse la utilización de Struts, se pudieron haber planteado otro tipo de
frameworks, con lo cual los lenguajes de programación podrían haber sido PHP, Pyton,
JEE, etc. Una vez elegido Struts 2.0 conlleva un requerimiento, el cual es, que se tenga que
utilizar Java como lenguaje de programación (Tanto en el modelo como en el controlador
de la aplicación). Este lenguaje para el redactor era una gran ventaja, ya que tenía
conocimientos previos e incluso podría aumentarlos gracias a este proyecto con la finalidad
de facilitar en mayor grado la vida profesional futura.
La versión utilizada de JEE (Java Enterprise Edition) será la version 7ª, la cual
corresponde a la versión 3.2 de EJB.

18
Capítulo 4: Diseño

4.2.2 Entorno de programación


Otro aspecto a tener en cuenta y el cual nos acompañará durante todo el proyecto
será el entorno donde vayamos a programar toda la aplicación.
Se conocían dos tipos de entorno bastante populares y conocidos por el redactor;
Eclipse for Java EE y Netbeans 7.0. El primero fue utilizado por el redactor durante los
primeros años de carrera, pero una vez conocido Netbeans hizo que dejara de utilizar el
primero para siempre. Uno de esos motivos era el sistema de depuración que Netbeans
presentaba, acompañado de un gran entorno y un buen sistema de asistencia que facilitaba
mucho la programación.
Una vez realizado el proyecto hace falta herramientas para su construcción y
empaquetamiento. Netbeans implementa una herramienta que funciona por defecto (Ant) y
se ajustaba perfectamente a los requerimientos.

4.3 Elección del servidor


A la hora de elegir el servidor de aplicaciones nos encontramos con dos opciones;
por una parte NetBeans venía acompañado por un servidor preinstalado, GlassFish. Este
tipo de servidor se suele utilizar para grandes aplicaciones gracias a sus múltiples opciones
para aplicaciones Java EE.
Por otro lado estaba la opción de utilizar un servidor para aplicaciones más sencillo y
que no requiera una compleja configuración. Un servidor que sea rápido, claro y sencillo
de configurar, cumplía con nuestros requisitos; el elegido fue Apache Tomcat en su versión
7.0. Se buscaron comparativas de tiempos, como es el tiempo de inicio y reinicio del
servidor, en los cuales Glassfish sale peor parado dado que puede llevarse de 5 a 10
segundos; por otra parte en este aspecto, Apache conseguía hacerlo en tan solo 3 segundos.
En cambio, Glassfish es extremadamente rápido a la hora del despliegue de la aplicación,
haciéndolo en milisegundos, mientras Apache puede tardar hasta 3 segundos.
Para asegurarnos de la elección se buscó alguna gráfica comparativa con proyectos
del mismo grado de complejidad que éste donde se mostrara la utilización de diferentes
servidores (Fig. 4).

Figura 4. % de utilización de los diferentes servidores en aplicaciones sencillas

19
Capítulo 4: Diseño

En este tipo de aplicaciones, donde mayormente se quiere tener soporte para JSP /
Servlet, la elección del servidor no es tan decisiva e importante como otras. Además, Java
EE es un estándar y por lo tanto una aplicación EE desarrollada con un servidor de
aplicaciones podría migrarse a otro servidor sin excesivas complicaciones.

4.4 Base de datos


Para el tema de la persistencia de datos de una aplicación se decidió utilizar una base
de datos MySQL, versión 5.5 para la plataforma de Windows. Se optó por esta base de
datos al ser sencilla de instalar, ya que como se comentó anteriormente viene instalada en
la herramienta XAMPP (la cual también incluye el servidor Apache Tomcat). Otro factor a
tener en cuenta a la hora de utilizarla fue el conocimiento por parte del autor.
De todas maneras, como se verá más adelante en el desarrollo del modelo, se aplica
una capa de abstracción a la aplicación dotándola para que pueda ser capaz de añadir
cualquier base de datos de una forma sencilla y modificando mínimamente el código. Lo
cual permite la migración sencilla entre BD de diferentes empresas.
Esto se implementó en el caso de que MySQL no fuera suficiente y se tuviera que
utilizar otra marca diferente de BD. Es otra de las ventajas que tiene el patrón MVC.

4.4.1 Definición de los datos


Para la definición de los datos primero se tuvo que estudiar los diferentes objetos
(entity beans, explicados en el capítulo de desarrollo) que contendrían nuestro entorno
Web. Una vez realizado esto se procedió a la generación automática del esquema de la
base de datos.
Por lo tanto, la definición de los diferentes objetos que contendrían nuestro proyecto
era primordial a la hora de realizar una estructura bien definida de los datos. Las diferentes
entidades implementadas son: empresa, usuario, cesta de pedidos, los pedidos o encargos
de cada cesta, y finalmente los productos y sus categorías correspondientes.
Como característica principal de cada una de las tablas de los diferentes objetos es la
declaración del campo "id" (identificador) en cada una de ellas, definido por defecto, y que
se utilizará como referencia para saber si un elemento existe o no. Además también se ha
utilizado como identificador único del elemento.

4.4.2 Esquema de la base de datos


A continuación, en la figura 5, se muestra el diagrama UML de la base de datos,
construido a partir de los diferentes objetos (Beans) que estarán presentes en esta
aplicación. Este esquema ha sido diseñado por la herramienta MySQL Workbench 6.1.

20
Capítulo 4: Diseño

Figura 5. Estructura general de la base de datos MySQL.

4.5 Interfaz gráfica


En este apartado se definirán las características principales de la vista, donde se
comentará el contenido Web que se ha utilizado para dar un ejemplo real a la aplicación.
Todo el entorno está basado en una empresa muy popular de nutrición deportiva llamada
Nutrisport.
Esta empresa, ya tiene implementada una página web donde clientes pueden
comprarles productos a ellos directamente. Pero lo que se quiere con esta aplicación que se
está desarrollando es realizar una aplicación para los distribuidores de Nutrisport. No
obstante, se utilizarán algunos elementos comunes de la página original como se explicarán
a continuación.

21
Capítulo 4: Diseño

4.5.1 Nombre, logotipo y productos de la aplicación


El nombre elegido para cualquier aplicación siempre es un factor muy importante, ya
que se pretende describir e identificar el producto en un breve título.
Por otro lado, este tipo de aplicación no requiere de un nombre para identificarla (ya
que es una aplicación de ayuda para una empresa), más bien, en el futuro podría ser algo
conocido entre los agentes comerciales de esta empresa y ellos mismos podrían
personalizarla y llamarla como más les gustara. Hasta el momento no se ha identificado
con ningún nombre, simplemente se ha identificado con el nombre de la empresa y en el
futuro podría llamarse aplicación de distribución de Nutrisport.
El logotipo que representará la marca de la aplicación también ha sido escogido de la
misma marca de productos. Más bien no se ha aplicado al entorno web, sino al entorno de
cada factura. En la vista de la aplicación no se ha querido incluir ninguna personalización
de un logotipo, se ha pasado a realizar un título sencillo con el emblema de la empresa
como es "nutrición deportiva" o "for all sports" (para todos los deportes).
Como se ha dicho anteriormente las facturas sí que llevarán una personalización
propia de la empresa, ya que se quiere demostrar que se pueden hacer diseños diferentes a
la hora de generar las facturas automáticamente. En la figura 6 se puede apreciar el
logotipo principal que se ha utilizado en los recibos de empresa.

Figura 6. Logotipo extraído de la página Web de Nutrisport y utilizado en las facturas

Por último, los productos (por parte de las imágenes y sus descripciones) también se
han seleccionado de la página original de esta empresa. Al igual que sus categorías.
Toda esta metodología que se ha explicado hasta ahora se ha realizado de esta
manera, no para ahorrarse trabajo a la hora de diseñar ya que el agente comercial es
distribuidor de productos de esta empresa y se pretende ofrecer esta aplicación a Nutrisport
para ayudar a sus agentes a mejorar en su metodología de trabajo del día a día.

4.5.2 Usabilidad y interfaz


La interfaz y la usabilidad, a primera vista parece que no guarden ningún tipo de
relación, pero como se explicará a continuación tienen una relación muy directa.
Para este entorno web se ha decidido utilizar una estructura sencilla y clara, donde se
pretende llamar la atención del usuario por un bonito aspecto gráfico y a la vez que sea una
apariencia clara y directa; de esta manera, el cliente sabrá en todo momento todas las
funciones y características que tiene la aplicación.

22
Capítulo 4: Diseño

Otro factor a tener en cuenta a la hora de diseñar el entorno es el objetivo de esta


aplicación. Todo cliente que entre a esta aplicación sabrá de antelación todos los productos
y cualquier tipo de información de la empresa, por lo tanto su fin es entrar al sitio web,
realizar una compra rápida para que le llegue lo más rápido posible al distribuidor y éste
pueda entregarle los productos.

Figura 7. Página principal de la aplicación web visualizada en una plataforma PC

Una vez dicho esto, se quiere conseguir un entorno rápido, no sobrecargado con
información o elementos que no puedan interesar al usuario; es decir, el objetivo es un
equilibrio entre simplicidad y calidad de diseño para que el usuario se encuentre cómodo y
se acostumbre de manera más rápida al funcionamiento de la aplicación.

4.5.3 Dispositivos destino de la aplicación


Actualmente el mundo de la tecnología ha avanzado hasta un punto donde la
búsqueda de información o cualquier utilidad que antes podíamos hacer con un ordenador,
ahora se haga mediante un teléfono móvil (smartphone) o una tableta.
Por lo tanto se ha procedido a realizar un diseño gráfico enfocado también para otro
tipo de plataformas que no sea la de PC. La mayoría de clientes utilizarán tabletas o
Smartphones para realizar los pedidos, con lo cual el diseño estará adaptado y a la altura de
estos dispositivos.

23
Capítulo 4: Diseño

Figura 8. Dispositivos a los cuales se adaptará el entorno web.

En la figura 7 se puede apreciar el diseño de la página principal del proyecto en una


plataforma PC. Por otro lado, si la ejecutáramos desde un Smartphone la vista de la
aplicación cambiaría y toda la estructura y sus elementos se ajustarían a los márgenes
especificados por la pantalla. En la figura 9 se puede apreciar el diseño en este tipo de
plataformas, en este caso sobre una pantalla de 5".

Figura 9. Página principal de la aplicación visualizada en un Smartphone

4.5.4 Formato de las facturas


A la hora de diseñar las facturas, al igual que se hizo con el entorno web, se ha
utilizado un entorno minimalista, sin añadir demasiados detalles, aportando la información
necesaria pero a la vez demostrando que elementos y características se pueden añadir con
el programa de diseño (explicado en el capítulo de desarrollo).
La factura está organizada de la siguiente manera: los datos del cliente se encuentran
en la parte izquierda enmarcados, los datos de la empresa en la derecha junto con el
logotipo referencia. Un poco más abajo se ha añadido la fecha de creación del recibo y a
continuación se ha añadido una tabla con la información de pedidos (cantidad, nombre del
producto, su precio por unidad y el precio total). En el fondo del documento se ha añadido
una marca de agua del logotipo de la empresa. La figura 10 nos muestra un ejemplo de
factura de un cliente aleatorio.

24
Capítulo 4: Diseño

Figura 10. Ejemplo de un modelo de factura generada

4.6 Internacionalización
El mercado informático es global y para competir es preciso hacer programas para
usuarios de todo el mundo (o en su defecto, para el abasto de la aplicación); por lo tanto la
internacionalización es una necesidad, no una opción.
La internacionalización, por definición, es el diseño y desarrollo de un producto, una
aplicación o el contenido de un documento de tal manera que permita una fácil
comprensión a audiencias de diferentes culturas, regiones o idiomas.

25
Capítulo 4: Diseño

Como la palabra "internacionalización" es demasiado larga, los programadores


normalmente se refieren a ella como i18n (18 es el número de letras que existen entre la
letra "i" y la letra "n" de la palabra "internacionalización"). Algunas personas utilizan otros
términos para referirse al mismo concepto, por ejemplo, "globalización".
Esta globalización está mayormente basada en prácticas de diseño y desarrollo de
métodos típicos de aquella zona donde se quiera utilizar la aplicación (localización). A
continuación se explican una serie de ejemplos:
 Utilizar Unicode o asegurar, allí donde corresponda, un correcto tratamiento
de las codificaciones de caracteres anticuadas; controlar la concatenación de
cadenas; o evitar que la programación dependa de valores de cadenas
pertenecientes a la interfaz de usuario.
 Habilitar el texto bidireccional o la identificación de idiomas. Incluso se
podría hacer el archivo CSS compatible con texto vertical u otras
características tipográficas ajenas al alfabeto latino.
 Preparar el código para hacer frente a las preferencias locales, regionales,
lingüísticas o culturales. Algunos ejemplos son: formatos de fecha y hora,
calendarios locales, formatos y sistemas de números, etc.

El i18n por otra parte, no incluye necesariamente la localización de la aplicación


hacia otro idioma, aunque es un factor muy importante a tener en cuenta. En este proyecto
se le ha dado mucha importancia y ha sido el método desarrollado para internacionalizar la
aplicación.
En este proyecto el idioma podrá determinarse en la página principal. Se han
determinado tres idiomas base: catalán, castellano e inglés; por defecto se ha utilizado el
castellano. En un futuro dependiendo del requerimiento que se tenga se podría añadir
cualquier idioma más.

4.7 Tipo de usuarios en el ámbito web


Toda página de venta de productos debe tener dos roles de usuarios en su
implementación. Por una parte se ha realizado la zona de administración para que el agente
comercial pueda cambiar cualquier configuración que esté a su disposición. El diseño está
realizado de tal manera que el número de administradores que pueda haber sea ilimitado
aunque lo más lógico es que solamente haya uno.
La creación de un perfil de administrador la realizará el propio desarrollador de la
aplicación ya que no se ha dado ninguna opción en la página de registro para crear nuevos
perfiles de este tipo. Era lo más lógico y lo más seguro.
Por otra parte tenemos el rol de cliente; no hay ninguna restricción a la hora de
registrarse como tal, por lo tanto cualquier usuario, tanto empresa como usuario, puede
hacer pedidos al distribuidor.

4.8 Seguridad
La seguridad, en aplicaciones de este tipo es esencial, ya que se manejan muchos
datos de usuarios y empresa que requieren confidencialidad.

26
Capítulo 4: Diseño

Por lo tanto se tomarán las medidas preventivas necesarias para intentar eliminar
cualquier tipo de intrusión en el sistema. A continuación se explicarán las tres medidas que
se han tomado para dotar de seguridad este entorno web.
 Control de archivos: Este tipo de prevención tiene como objetivo controlar
los ficheros que se vayan a cargar al servidor, es decir, a la base de datos. Se
tendrán que controlar el formato de archivos que se vayan a cargar, su
tamaño, entre otras. En el contexto de la aplicación, donde el administrador
podrá subir imágenes de los productos, se controlará que el formato de tales
sea ".jpg" y que su tamaño no sobrepase los 3 MB.

 Control de acceso / sesión: La suplantación de identidad es lo que trataremos


de intentar evitar en este apartado. La sesión de cualquier tipo de cliente irá
controlada en cada movimiento sobre la aplicación, con lo cual ningún
extraño podrá intervenir en ella sin estar registrado. Por otro lado se
controlará la sesión de administrador de manera que ningún cliente pueda
realizar operaciones que no le pertenecen. Finalmente, si el usuario no está
activo pasados 20 minutos se desconectará automáticamente de su sesión.

 Control de la entrada de datos: Existen muchos tipo de ataques mediante


scripts como por ejemplo XSS (cross-site scripting) que se tendrán que
controlar. Estos ataques suelen realizarse mediante la inserción de un script
en un campo de texto, mayormente en formularios. Se controlará mediante
validaciones que el formato en los campos donde el usuario tiene que
introducir información sea exactamente la que se requiere.

(Los métodos prácticos que se han utilizado para realizar lo explicado anteriormente
se encuentra en el capítulo de desarrollo).

4.9 Formato del directorio de carpetas


Las decisiones sobre la gestión y localización de los diferentes ficheros que
contienen la aplicación se encuentran en este apartado. Se hará referencia a los tres tipos de
ficheros que forman la aplicación y por lo tanto las tres decisiones de diseño para cada uno
de ellos.

4.9.1 Base del proyecto o servidor


El proyecto de Struts 2 realizado con Netbeans contiene las carpetas distribuidas de
forma que en cada una de ellas se procederá a poner una capa de la aplicación (MVC). En
la carpeta llamada "Web Pages" tendremos todos los archivos correspondientes a la vista,
en la carpeta "Modelo" y la carpeta "action", las dos capas restantes de este patrón.
Además se ha añadido una carpeta donde se gestionarán los interceptores o
elementos de seguridad de la aplicación. En la carpeta por defecto del proyecto se sitúa el
archivo de configuración de Struts y los archivos de propiedades de los diferentes idiomas
implementados. En la figura 11 se puede apreciar esta distribución del contenido.

27
Capítulo 4: Diseño

Figura 11. Formato del archivo WAR (Proyecto de Struts 2)

4.9.2 Los reportes generados de facturas


Para gestionar estos reportes se tenía dos opciones: por un lado guardar los archivos
en un almacenamiento ajeno a la aplicación en un servidor seguro, y por otro lado,
guardarlos en formato .blob dentro de la base de datos.
Se optó por almacenarlos dentro de la base de datos ya que el tamaño de estos
reportes no era excesivo. Una de las ventajas que nos proporcionara este método era
seguridad, ya que los archivos estarían en un formato ilegible por parte de cualquier
usuario, en cambio si se hubiesen guardados y el sistema hubiera tenido algún problema de
intrusión las facturas estarían en formato .pdf listas para ser leídas.
Cuando cualquier usuario quiera adquirir una factura de su perfil, ésta tiene que ser
convertida del formato .blob de la base de datos a pdf. Para realizar esto, se utiliza un
archivo temporal de reportes situado en el mismo contexto de la aplicación, donde se
guarda el archivo que se quiere consultar, y una vez consultado se borra automáticamente
para evitar sobrecargas del sistema, a la vez que se intenta aumentar la seguridad tratando
de dejar los mínimos datos de usuarios posibles fuera de la BD.

4.9.3 Imágenes de los productos


Los siguientes archivos que se añadirán una vez lanzado el proyecto serán las
imágenes de los productos de la empresa. También hubo las opciones que se comentaron
en el apartado anterior, ya que podíamos guardarlas en la base de datos o en una carpeta.
Para este caso se decidió realizar una mezcla de las dos opciones, es decir, los
objetos se guardarán en una carpeta del proyecto (en la carpeta de vista de Struts, para
tenerlo todo bien organizado) y en la base de datos se añadirá la ruta relativa a estos
archivos para que puedan ser accedidos por los usuarios.

28
Capítulo 4: Diseño

Se realizó de esta manera por conveniencia del desarrollador ya que guardar las
imágenes directamente en la base de datos y intentar posteriormente acceder a ellas desde
la vista resultaba un tanto complicado.
Finalmente aclarar el concepto de path relativo (o ruta relativa) utilizado en esta
aplicación en cualquier método donde se haya necesitado introducir rutas de archivos; y es
que en cualquier aplicación web es obligatorio y no opcional utilizar este tipo de rutas, ya
que la absoluta puede llevar a crear grandes problemas de seguridad.

En la ruta relativa se llama a un archivo pero desde el lugar donde se está ejecutando el
servidor, es decir, solo funciona dentro de nuestro dominio. Por ejemplo: si se quiere
acceder a una factura temporal de este proyecto, solo se tendrá que determinar la ruta
relativa; en este caso /reports/temp/factura1.pdf.

La ruta relativa al caso anterior equivaldría a /Nutrisport/web/reports/temp/factura1.pdf, la


cual no habrá necesidad de utilizar ya que este método de acceder a una factura se realizará
dentro del contexto del servidor.

29
Capítulo 5: Desarrollo

5 Desarrollo
En este capítulo se pasará a explicar la parte práctica del proyecto, junto con las
características, lenguajes de programación, aplicaciones y métodos que se han
implementado para construir este entorno.
La implementación se ha dividido en dos partes, por una parte se dividen los tres
módulos que forman el patrón MVC y se explican las características utilizadas y por otra
parte se explican otros detalles que complementan la aplicación.

5.1 Implementación del modelo


A continuación se explicarán las tecnologías implementadas en la capa de datos.

5.1.1 Persistencia
El primer objetivo que se plantea es poder guardar los datos de los objetos, es decir
sus atributos, de forma persistente; mayormente en una base de datos relacional (BDR).
Los objetos que se utilizarán para acceder a estos datos guardados están explicados
posteriormente en la sección DAO.
Existen diferentes tipos de tecnologías para gestionar la persistencia en Java:
 Serialización
 Con un middleware como es JDBC (Java DataBase Connectivity)
 Utilizando EJB (Enterprise Java Beans), una plataforma compleja y
estandarizada en la tecnología J2EE.
 Con un framework de persistencia

5.1.2 JDBC
Para la gestión de persistencia de este proyecto se utilizó JDBC, el cual es un
middleware que permite a la aplicación Java conectar y acceder de una forma estándar
(independientemente del sistema operativo donde se ejecute, o de la base de datos a la cual
se accede siempre y cuando contenga el driver JDBC) a cualquier base de datos relacional.
Por lo tanto, el código de este intermediario entre la base de datos y la aplicación es
independiente al gestor utilizado; por lo tanto nos ofrece dos características
imprescindibles como son la portabilidad y la escalabilidad.
Este intermediario se encuentra en los paquetes de Java SDK: java.sql y javax.sql.

5.1.2.1 Drivers y tipos de datos


JDBC está dividido en dos partes (figura 12):
 API JDBC, una API puramente Java, la cual necesita los drivers para cada
tipo de base de datos.
 JDBC Driver Manager, que se comunica con los drivers específicos del
fabricante que se encargan de la comunicación específica de la BDR. Esta
traducción al formato específico del fabricante se realiza en la parte del
cliente.

30
Capítulo 5: Desarrollo

Figura 12. Middleware JDBC conectando una aplicación a diferentes proveedores de BD

Lo primero que se tiene que realizar es la elección de la clase que implementa la


interfaz del paquete java.sql en el controlador JDBC que se va a utilizar. Por ejemplo, en el
controlador proporcionado por MySQL la clase es "com.mysql.jdbc.Driver".
En esta segunda parte de este apartado se muestran los tipos de datos soportados por
este middleware. La figura 13 resume las correlaciones de tipos de datos Java con tipos de
datos de base de datos para los diferentes métodos existentes en programas JDBC.

Figura 13. Tipo de datos SQL 3 soportados en JDBC 2.0

31
Capítulo 5: Desarrollo

5.1.2.2 Detalles del proceso


Los pasos a realizar para utilizar JDBC en una aplicación Java serán explicados a
continuación:
Cargar el driver: Una vez identificado el controlador debe ser registrado para poder
ser utilizado por la aplicación Java. Esto se realiza en el código de la aplicación mediante
la sentencia "Class.forName("com.mysql.jdbc.Driver")". Tal y como se comentó
anteriormente al inicio de la aplicación deberá importarse la biblioteca de clases "java.sql".
Determinar la URL de la conexión: El código siguiente muestra como realizarlo.
String host = "localhost";
String dbName = "pfg";
int port = 8080;
String mysqlURL = "jdbc:mysql://"+host+":"+port+"/"+dbName;

Establecer la conexión: Para implementar esto se necesita el usuario y contraseña


que permitan entrar a la base de datos junto con la URL de aquel tipo de BD a la que se
desea conectar, en este caso sería MySQL. A continuación se ejecutará la siguiente
sentencia:
Connection con = DriverManager.getConnection(mysqlURL,user, pw);

Opcionalmente en este apartado se pueden utilizar metadatos para obtener


información relacionada con la BD como sería su proveedor, versión, etc.
Crear sentencias SQL: Una vez se ha establecido la conexión a la base de datos se
emplea el objeto "Connection" para enviar sentenciar SQL al gestor. Las diferentes
sentencias están explicadas en el siguiente apartado junto a las transacciones.
Ejecutar una consulta: Se crea una "query" típica en formato SQL, la cual se incluye
en la sentencia SQL. A continuación se muestra un ejemplo.
String query = "SELECT col1, col2, col3 FROM sometable";
statement.executeQuery(query);

En el anterior ejemplo se hace una llamada a la base de datos para recoger cierta
información, pero si ésta se quiere modificar hace faltar utilizar el método
"executeUpdate", junto un String que use las sentencias SQL (update, insert o delete).

Procesar el resultado: Para conseguir el resultado de la llamada a la BD hace falta la


variable "resultSet" la cual contiene todos los datos. A partir de los métodos "get" de esta
variable se puede obtener el valor de una columna indicando su nombre o mediante su
índice (la primera columna tiene índice 1 y no 0), como se muestra en el siguiente ejemplo.
while(resultSet.next()) {
resultSet.getInt("id");
resultSet.getString(1);
resultSet.getBlob("factura");
}

32
Capítulo 5: Desarrollo

Cerrar la conexión: Por último se cerrará la conexión con la base de datos; esta
función es bastante costosa por lo tanto se recomienda utilizar únicamente cuando se
esperen operaciones adicionales en la BD. Mediante el siguiente método se ejecutará esta
acción: connection.close();

5.1.2.3 Sentencias SQL y transacciones


Una vez que se ha establecido la conexión a la base de datos se emplea el objeto
"Connection" para enviar sentencias SQL al gestor. Estas sentencias se pueden enviar al
gestor de dos modos diferentes:
 Statement: Se trata de consultas de estructura estática, por lo tanto solo se utilizarán
cuando se sepan todos los parámetros de la consulta. A continuación un ejemplo de
este tipo de sentencias.
Statement stm = con.createStatement();
ResultSet rs = stm.executeQuery("SELECT * FROM personas");

 PreparedStatement: Se trata de consultas de estructura dinámica, las cuales se


prepararán especificando la estructura y colocando comodines (Signos de
interrogación) en aquellos puntos donde irán los futuros valores. Una vez se
conozcan dichos valores, se asignarán con los métodos set correspondientes
numerándolos de izquierda a derecha. En el siguiente ejemplo se aclara lo
explicado:
PreparedStatement pstm = con.prepareStatement("SELECT*FROM Personas
WHERE Nombre = ?");
pstm.setString(1, “Manuel”);
ResultSet rs = stm.executeQuery();

Por otro lado, a la hora de realizar transacciones, las conexiones se crean


automáticamente en modo "autocommit", lo que conlleva que todas las sentencias SQL se
ejecuten completamente y aisladas. Este ha sido el modo utilizado en el proyecto.
Si se quisiera bloquear la base de datos a los otros procesos y que solo tuviera acceso
un método en ese instante se tendría que hacer lo siguiente:
con.setAutocommit(false);
//Código que se ejecutará en esta transacción.
con.commit();
con.setAutocommit(true);

5.1.3 JavaBeans (DTO)


Son un modelo de componentes que se utilizan para encapsular varios objetos en
uno único y utilizar un objeto más complejo en lugar de varios más simples. También
pueden ser llamados objetos de transferencia de datos como se verá en el siguiente
capítulo.

En esta aplicación, se asignaron todos los beans al principio del desarrollo, ya que estos
nos servirían de guía para la creación de la base de datos y los objetos de acceso a los datos
que se implementarán a partir de ellos (explicados en el siguiente apartado).

33
Capítulo 5: Desarrollo

Tienen una serie de requerimientos sobre nomenclatura de métodos, construcción y


comportamiento. Las convenciones más esenciales son:
 Debe tener un constructor sin argumentos
 Sus propiedades deben ser gestionadas mediante métodos get y set, los cuales
siguen una nomenclatura estándar
 Debe ser serializable.
Los beans utilizados para este proyecto han sido los siguientes: Cesta, pedido,
producto, categoría, usuario y compañía.

5.1.4 DAO
Una aplicación J2EE necesita acceder a un almacén de datos desde uno de sus
componentes (EJB, JSP/Servlet). Para tratar de implementar lo anterior se han
implementado DAO's (Data Access Object). Sus principales ventajas son:
 Abstracción y encapsulamiento todos los accesos a la BD.
 Gestión de la conexión con el almacén y las operaciones de selección y
modificación de datos.

Se creará una clase abstracta DAO general que contendrá todos los métodos para
establecer una conexión con la base de datos. A continuación se creará un DAO por Bean
(los cuales serán heredados de la general) y su correspondiente interfaz.

Figura 14. Diagrama de las diferentes relaciones con el patrón DAO

En otras palabras, si se tiene un DAO para las cestas, como por ejemplo CestaDAO, en el
cual estará definido un método getPrice() para que retorne el precio total de aquella cesta,
desde el controlador no se sabrá cómo está implementado, ni que base de datos utiliza.

Todo esto se parecería a tener una clase llamada Cesta rellenada con métodos static a los
cuales se llamaría cuando fuera necesario. Con esto se intenta centralizar todo el acceso a
la tabla Cesta, pero DAO va más allá de la centralización. ¿Cómo se resolvería el problema
de devolver un listado de cestas a través de su clase con métodos static?

34
Capítulo 5: Desarrollo

Ya que, por ejemplo el método GetCestas() devuelve un dataset rellenado con los coches, o
un datareader/recordset, o una lista separada por comas, o una estructura xml, o un array…

public interface BasketDAO {


public int add_basket(Basket basket);
public Basket get_basket(int id_basket);
public Vector<Basket> get_all_baskets();
public Vector<Basket> get_basketpendientes();
public Vector<Basket> get_basketfinalizadas();
public Vector<Basket> get_basketpagadas();
public void set_basket(Basket basket);
public Vector<Basket> get_all_basket(int id_user);
public void set_payment(int id_basket);
public void delete_basket(int id_basket);
}
Código 1. DAO de cestas

Los DAO incluyen otro concepto que son los DTO (Objetos de transferencia o Java Beans,
explicados anteriormente) que sirven únicamente para transportar datos. En este mismo
caso, este objeto sería CestaBean. Entonces, DAO, lo que devuelve es una lista genérica de
CestaBean o solamente una si se está buscando información de una sola cesta.

Por lo tanto, este bean contiene información de las propiedades de una cesta como son la
identificación del usuario, los diferentes productos, el precio total, etc. El patrón DAO, tras
una petición del controlador, rellena un DTO (Java Bean) o un conjunto de ellos y los
vuelve a devolver al controlador.

Todo esto explicado anteriormente tiene un objetivo claro y sencillo: conseguir 100% de
separación entre el Controlador y el Modelo. Ante cualquier cambio que se diera en la
forma de acceder a los datos, como por ejemplo que a partir de ahora en lugar de sacar las
cestas de una tabla cestas se hace desde un servicio web que retorna cestas, el modelo no
será consciente de este cambio, ya que lo que le va a seguir llegando va a ser siempre
CestaBean.

5.1.5 DAO Factory


En el caso de que en un futuro la aplicación quiera ser migrada a otro almacén de
datos hay que estar preparado. Para ello se utiliza un Factory que implemente los diferentes
DAO's en función del tipo de base de datos utilizada. Dotará de flexibilidad la aplicación
ante posibles cambios que puedan pasar. Gracias a esto se obtienen una serie de ventajas
como son:
 Acceso transparente a la base de datos. Los objetos de negocio no necesitan
conocer nada sobre la fuente de datos a la cual conectan.
 Se facilita la migración entre diferentes mecanismos de persistencia.
 La complejidad en el código del objeto de negocio se reduce
considerablemente.

35
Capítulo 5: Desarrollo

public abstract class DAOFactory {


public static final int SQL = 1;
public abstract UserDAO getUserDAO();
public abstract BasketDAO getBasketDAO();
public abstract OrderDAO getOrderDAO();
public abstract ProductDAO getProductDAO();
public abstract Product_categoryDAO getProduct_categoryDAO();
public abstract CompanyDAO getCompanyDAO();
public abstract void tancarCon();
public static DAOFactory getDAOFactory(int whichFactory) throws
ClassNotFoundException {
switch (whichFactory) {
case SQL: return new SQLDAOFactory();
default : return null;
}
}
}
Código 2. DAO Factory de la aplicación

En el caso de este proyecto, se ha implementado para utilizar la base de datos


mySQL, pero como se puede ver en el código 2, cabrá la posibilidad en un futuro de poder
añadir otros tipo de proveedores.
Finalmente en el código 3 se aprecia la clase SQLDAOFactory.java donde se carga el
driver del proveedor MySQL, a continuación se inicia la conexión y se implementan los
diferentes métodos para retornar los DAO específicos de la aplicación para este proveedor.
Finalmente también está implementado el método para cerrar la conexión con la base de
datos.

5.1.6 Tuplas
Algunos objetos contenían información de otros objetos como podría ser su
identificador. En estos casos cuando se quería devolver información del objeto que
contenía el primero faltaban muchos datos, ya que solo se tenía un simple identificador.
Para esto se han creado tuplas de objetos, las cuales unen diferentes beans en uno solo y
ayudan a acceder a todas sus características en una única llamada.
Para ejemplificarlo, el objeto cesta, a su vez contiene el identificador del usuario al
que pertenece. La llamada a la función que devuelve una cesta aleatoria se necesita
también todos los datos del usuario y no solamente su identificador, con las tuplas se podrá
resolver este inconveniente. Ya que a la hora de devolver el objeto cesta, también enviará
el objeto usuario.

36
Capítulo 5: Desarrollo

public class SQLDAOFactory extends DAOFactory {


private Connection con;
public SQLDAOFactory() throws ClassNotFoundException {
try {
Class.forName("com.mysql.jdbc.Driver");
con = DriverManager.getConnection(
"jdbc:mysql://localhost/pfc", "pedrito", "logitech" );
catch( ClassNotFoundException e ) {
e.printStackTrace();
}
catch ( SQLException e) {
e.printStackTrace();
}
}
public UserDAO getUserDAO() {
return new SQLuserDAO(con);
}
public void tancarCon() {
try {
con.close();
}
catch (SQLException e) {
}
}
Código 3. DAO Factory específico para MySQL

37
Capítulo 5: Desarrollo

5.2 Implementación del controlador


Una vez visto el desarrollo del modelo se pasará a explicar la implementación del
intermediario o controlador del sistema, una parte fundamental de esta arquitectura
software web.

5.2.1 FilterDispatcher y configuración web


Struts 2 tiene una arquitectura en la cual están involucrados filtros e interceptores.
Estos despacho de filtros es responsable de recibir las peticiones entrantes y enviarlas a las
clases de acciones apropiadas. Las peticiones antes de alcanzar las clases de acciones son
enviadas a través de una serie de interceptores, los cuales modifican la petición según la
necesidad o el objetivo programado. En la figura 15 se puede apreciar un diagrama del
flujo de trabajo en el framework Struts 2.

Figura 15. Flujo de trabajo en Struts 2

En el archivo de configuración web (con formato XML) se declararán varias


propiedades de la aplicación, una de ellas es la declaración del filtro a utilizar en la
aplicación, Filter Dispatcher como el más común y utilizado.
Entre otras propiedades que incluye este archivo son:
 Los diferentes "listener" que contendrá la aplicación
 La definición del archivo de plantilla utilizado (explicado en el apartado
vista)
 El tiempo de espera máximo sin utilizar una sesión (30 segundos)
 El archivo inicial de arranque de la aplicación, típicamente nombrado como
índex.
 El filtro para la búsqueda de archivos a la hora de cargar las vistas, por
defecto se utiliza "/*".

5.2.2 Struts.xml y resultados


Las declaraciones de las diferentes acciones se gestionarán desde el fichero
Struts.xml; a continuación se detallará que contiene este fichero.

38
Capítulo 5: Desarrollo

En cada declaración de acciones se encontrará el nombre de la acción que la


ejecutará, la clase que la gestionará (en el caso de un método específico de la clase,
también podrá ser indicado) y la especificación de una serie de valores retornados que
puede devolver nuestra clase acción. En esta última parte, para cada valor de retorno
especificado se indicará la vista correspondiente a la cual redirigir el entorno web.
También existe la posibilidad de gestionar una declaración global, donde serán gestionadas
las acciones que no tengan ningún nombre predefinido.

<action name="perfil" class="com.myapp.controller.action.Profile">


<interceptor-ref name="authStack"></interceptor-ref>
<result name="success" type="tiles" >profilesuccess_user</result>
<result name="success_admin" type="tiles" >Aprofile_company</result>
</action>
Código 4. Fragmento de una declaración de acción en Struts.xml

Este valor retornado siempre será un String, de esta manera nos ayudará a identificar
mucho mejor las acciones; en el caso de no encontrar relación entre una acción y un valor
retornado se procederá a declarar un valor "input", el cual reenviará la aplicación a la vista
indicada.
En estas definiciones de las diferentes acciones también se pueden añadir los
interceptores, los cuales serán declarados al principio del fichero. Otra posibilidad es la
definición de las características que tendrán los diferentes parámetros en la acción. Por
ejemplo, a la hora de ejecutar la acción de "descargar factura" se definirá que el fichero
factura sea de tipo PDF, entre otras características.
En Struts.xml no solo se gestionan los direccionamientos sino que también se
declararán las variables globales de la aplicación como por ejemplo la variable del idioma
predeterminado o como se comentó en el párrafo anterior, los interceptores. También podrá
declararse un archivo de gestión de plantillas; en este caso se ha declarado "Tiles" como
sistema de plantillas, explicado en el apartado de la vista.

5.2.3 Variables de sesión y de la vista


Para recuperar los valores de las variables provenientes de la vista, Struts 2 se
encarga automáticamente de enviar aquellas variables definidas en los formularios de la
página JSP hacia el controlador, el único paso que se tendrá que realizar es la declaración
de estas variables en la clase acción con el mismo nombre que tenían en la vista.
Es decir, si tenemos una línea de código de un formulario como la siguiente:
<s:textfield name="price" key="text.price"></s:textfield>
Para coger el valor de esa variable con nombre "price" se tendrá que crear en la clase
acción una variable privada, con sus métodos GET y SET, con el nombre de "price".

Por otro lado se han utilizado variables de sesión, las cuales se les asigna un valor y se
introducen en el contexto de la sesión del usuario mientras ésta esté activa. La
implementación de esta gestión de la sesión se ha llevado a cabo con "ActionContext".

39
Capítulo 5: Desarrollo

session.setAttribute("basket", id_basket);
HttpServletRequest request=ServletActionContext.getRequest();
HttpSession session=request.getSession();
Código 5. Almacenamiento de la variable cesta en el contexto de la aplicación

Cada contexto es básicamente un contenedor de objetos que una acción necesita para
ejecutarse como son la sesión del usuario, parámetros, la variable "locale" de aquella
sesión...). Por cada contexto que se crea, también se crea un thread, lo que significa que
cualquier valor almacenado en él es único.

En esta aplicación se han almacenado variables en el contexto de la aplicación para:


 Mantener la sesión del usuario.
 Conocer el tipo de usuario conectado.
 Conocer que cesta se está visitando / gestionando.

SessionMap<String,String> sessionmap;
sessionmap.put("tipo","user");
sessionmap.put("user",aux.getEmail());
Código 6. Almacén de variables al inicio de sesión utilizando otro método llamado SessionAware

5.2.4 Interceptores, seguridad básica


Para desarrollar una aplicación web, es necesario dotar a esta de funcionalidades de
que proporcionen seguridad. Estos elementos utilizados son los interceptores, los cuáles no
únicamente tienen la función de proteger a la aplicación.
Los interceptores en Struts 2 son procedimientos (clases) que se ejecutan antes o
después de que se invoque una acción, existen algunos definidos que se pueden utilizar
directamente o implementarlos desde cero. También pueden evitar que un Action se ejecute
(por ejemplo si estamos haciendo alguna validación que no se ha cumplido). Se utilizan
para ejecutar algún proceso particular que se quiere aplicar a un conjunto de Actions.
Cada interceptor proporciona una característica distinta a la acción. Para sacar la
mayor ventaja posible de los interceptores, se permite aplicar más de un interceptor a la
vez a la misma acción.
Para poder implementar esto, Struts 2 permite crear pilas de interceptores y aplicarlas
a las diferentes acciones en función del orden que aparecen en el stack. Se pueden formar
pilas de interceptores a partir de otras; una de ellas es aplicada por defecto a todos los
Actions de la aplicación, del mismo modo que se puede aplicar una pila particular a una
acción.
Si alguna funcionalidad que se necesita no se encuentra en los interceptores por
defecto de Struts 2, se podrá crear un propio interceptor y agregarlo a la pila que se ejecuta
por defecto.

40
Capítulo 5: Desarrollo

Esta pila puede modificarse como se desee; por ejemplo, modificar el orden de
ejecución de los interceptores. Las funcionalidades que se han añadido gracias a los
interceptores son explicadas en los siguientes apartados.

5.2.4.1 Interceptor de ficheros


Este primer interceptor se implementó para controlar la carga de ficheros al servidor
en la acción donde el administrador añadirá o modificará las imágenes de los diferentes
productos. En él se definen dos características que el fichero deberá cumplir como son el
tamaño máximo y los formatos de imagen permitidos. En el caso de que la imagen no
cumpla estos requisitos, la acción no podrá llevarse a cabo y se reenviará al usuario a la
misma vista.
<interceptor-ref name="fileUpload">

<param name="maximumSize">2097152</param>

<param name="allowedTypes">image/png,image/gif,image/jpeg</param>

</interceptor-ref>
Código 5. Interceptor utilizado para la carga de imágenes al servidor

5.2.4.2 Interceptor de sesión cliente y de administrador


En este segundo caso se tratará el control de las sesiones generales de usuario y más
específicamente las del administrador.
Para controlar si un usuario está en una sesión y se le permite la navegación por
dentro de la aplicación web se comprobará que existe una variable de usuario en el
contexto de la sesión (ActionContext). En el caso que esta variable no exista se mantendrá
al usuario en la misma vista avisándole con un mensaje de los requisitos que se tienen que
cumplir. Este interceptor se declarará en todas aquellas acciones donde el registro de un
cliente normal sea obligatorio, como por ejemplo la visualización de los productos de la
empresa.
Por otro lado si se quiere prevenir la entrada de usuarios normales a funciones de
administrador se comprobará que la variable "tipo" está declarada en el contexto de la
aplicación y contiene el String "admin"; si no se cumple este requisito el usuario no podrá
navegar por aquellas acciones donde el interceptor de admin esté declarado. En el código 6
se puede ver como se ha implementado este interceptor, además de controlar la
verificación de administrador, primero se comprueba que dentro de la sesión se encuentra
un usuario registrado en el sistema.

public String intercept(ActionInvocation actionInvocation) throws


Exception {
Map<String,Object>sessionAttributes =
actionInvocation.getInvocationContext().getSession();
String email = (String) sessionAttributes.get("user");

41
Capítulo 5: Desarrollo

String tipo = (String) sessionAttributes.get("tipo");


if(email == null){
return "loginFirst";
}
if(!tipo.equals("admin")){
return "OnlyAdmin";
}
else{
return actionInvocation.invoke();
}
}
Código 6. Interceptor para controlar las sesiones de administrador

5.2.5 Validaciones en campos de entrada de texto


Struts 2 se basa en un tipo de validación proporcionada por XWork que permite la
aplicación de una serie de reglas de validación aplicada antes de la ejecución de las
acciones; esto permite separar la lógica de validación del código JSP.
Esta funcionalidad de XWork viene con un conjunto de rutinas útiles para manejar la
validación de formularios de forma automáticamente. Mediante la interface "Validator" se
podrá gestionar esta funcionalidad utilizando archivos de configuración XML para
determinar el comportamiento de la validación. "Validator" puede ser configurado para
enviar el código JavaScript en el explorador de manera que la validación se pueda realizar
tanto en el lado del cliente, como en el lado del servidor.
El tipo de validación que se implementará en este proyecto será la asociada a campos
aunque también existen otras posibilidades (no utilizadas en esta aplicación) como son la
validaciones de expresiones de contexto.

5.2.5.1 Formato y ejemplo de uso


Para crear estos ficheros de validación se tiene que seguir unos requisitos para su
nombre y localización. En Struts 2 estos ficheros se tienen que crear en el mismo directorio
que los archivos de acciones y los nombres que deberán tener será el nombre del fichero de
acción seguido de "-validation".
Como se ha dicho anteriormente la validación que se tratará en este proyecto será
sobre los campos que se enviarán a través de un formulario. En su definición se
especificará el nombre del campo, el tipo de validación y un mensaje de usuario en el caso
que no se cumpla aquella validación.
Como se puede apreciar en el código 7 existen diferentes tipos de validaciones; en él
se han implementado las siguientes restricciones:
 Requiredstring: Es obligatorio y de tipo String el campo "name".
 Double: El valor esperado será de tipo double y se incluyen dos propiedades
que indican el mínimo y máximo que tiene que tener ese campo.

42
Capítulo 5: Desarrollo

 Regex: En este campo se requerirán caracteres únicamente numéricos y se ha


implementado mediante una expresión regular, a menudo llamada regex.

<validators>
<field name="name">
<field-validator type="requiredstring">
<message key="req.name" />
</field-validator>
</field>
<field name="price">
<field-validator type="required">
<message key="req.price" />
</field-validator>
<field-validator type="double">
<param name="minInclusive">1.0</param>
<param name="maxInclusive">10000.0</param>
<message key="req.price" />
</field-validator>
<field-validator type="regex">
<param name="expression"><![CDATA[^[1-
9]\d*(\.\d+)?$]]></param>
<message key="req.numeric"/>
</field-validator>
</field>
</validators>

Código 7. Validación de campos de la acción "editar un producto"

5.2.6 Mensaje de acciones


Struts 2 tiene implementado un sistema muy sencillo para el envío de mensajes una
acción hasta la página JSP, es decir, desde el controlador a la vista. Esta utilidad forma
parte del sistema de validación de Struts y es accesible desde las clases que lo implementan
(ValidationAware y ActionSupport).
Los tipos de mensajes que se pueden enviar a la vista se dividen en dos grupos:
ActionMessage para mostrar información genérica y ActionError para mostrar mensajes de
error. Estos mensajes se gestionarán y enviarán desde la acción mediante los métodos
addActionMessage y addActionError respectivamente.
Los mensajes se añadirán dependiendo del orden en el que quieran ser mostrados,
por ejemplo, si en un formulario de registro, el email introducido ya existe y el nombre
contiene números, se dará preferencia al primer error introduciendo una acción de error
para el primer problema y más adelante en el código otra, para el segundo.

43
Capítulo 5: Desarrollo

5.3 Implementación de la vista


La última capa del patrón MVC que falta por explicar su desarrollo es la vista, es
decir el resultado visual que tendrá el usuario sobre la página y que, inconscientemente, se
le da una importancia mayor.

5.3.1 Páginas JSP


Las páginas HTML muestran únicamente información estática, por lo tanto
subministrar páginas creadas al momento con información adquirida de una base de datos
resulta imposible. De esta manera, para crear una página que muestre información
dinámicamente es necesario utilizar otro tipo de formato. Dentro de estos se encuentran
muchos tipos como son PHP, JSP, ASP...
Se eligió JSP para basar la vista del patrón MVC ya que permite un mayor
encapsulamiento mediante clases y uso de JavaBeans. Además permitía una mayor
escalabilidad y un uso de tags para acceder a variables modificadas dinámicamente.
El funcionamiento de estas páginas JSP es el siguiente: el cliente demanda una
acción al servidor, el controlador realiza todas las operaciones que se necesitan y devuelve
una página HTML con toda la información rellenada por los tags de JSP y el cliente
visualiza la página el texto HTML como si realmente hubiera estado almacenado en el
servidor. Es decir, la base de esto es como siempre una página HTML rellenada con
información proporcionada por el lenguaje Java Server Page.

5.3.2 Struts 2 Tags


Las librerías de tags que Struts nos proporciona para visualizar información dinámica
en una aplicación web es esencial. La mayoría de estos tags son muy parecidos a los tags
utilizados en HTML.
Para poder utilizar estas etiquetas en la página que proporciona la vista se debe
incluir la localización de la librería. Típicamente, esta directiva es:
<%@ taglib prefix="s" uri="/struts-tags" %>
De esta forma el prefijo para poder utilizar las diferentes etiquetas será "s". A
continuación se explicará uno de los tags más utilizados en esta aplicación y posiblemente
en cualquier aplicación web como son los formularios.
Para utilizar un formulario se utilizará la etiqueta "form" la cual incluye una acción
donde se gestionarán los datos enviados por él. En el código 8 se puede ver como la acción
a realizar es la edición del nombre de un producto y donde el parámetro que se enviará una
vez presionado el botón "Enviar" será una variable llamada "nombre_producto" que
contendrá el nuevo nombre del producto.

<s:form action="editarProducto">
<s:textfield label="nombre" name="nombre_producto" />
<s:submit value="Enviar" />
</s:form>

Código 8. Editar el nombre de un producto mediante el tag "form"

44
Capítulo 5: Desarrollo

En el ejemplo anterior se ilustraba una etiqueta para enviar información al servidor,


pero también existen etiquetas para mostrar la información proveniente del servidor. La
etiqueta utilizada en este caso es "property" donde se le indica el nombre de la variable o
bean que se quiera mostrar al usuario. Por ejemplo, si tenemos una variable que contiene el
precio total de una cesta y queremos mostrarlo en la página JSP se hará de la siguiente
manera:
<td><s:property value="total"/>

En la figura 16 se muestran todos los tipos de tags existentes que nos proporciona el
framework Struts 2. En los casos anteriores se utilizaron, en el caso del formulario un tipo
de etiqueta para formularios y en el segundo caso un tipo de etiqueta para datos.

Figura 16. Todos los tipos de etiquetas que nos proporciona Struts 2

45
Capítulo 5: Desarrollo

5.3.3 JQuery Tags de Struts 2


Struts 2 permite la utilización de diversos plugins para adaptar la vista de la página
mediante diferentes tipos de tecnologías de representación; de este modo es posible
incorporar la tecnología jQuery UI (soporte para AJAX y UI widgets) dentro de las páginas
JSP que se generan como vista de la aplicación. Esta tecnología está basada en el
framework jQuery de Javascript.
Al igual que en el apartado anterior este plugin también nos proporciona una serie de
etiquetas para poder utilizar sus diferentes componentes. De este modo mediante estos tags
se puede producir código jQuery UI en páginas JSP de manera muy veliz y productiva,
incluso si no se tienen conocimientos del lenguaje JavaScript.
Para poder utilizar estas etiquetas en la página que proporciona la vista se debe
incluir, como ya pasó en los tags de Struts 2, la localización de la librería. Típicamente,
esta directiva es:
<%@ taglib prefix="sj" uri="/struts-jquery-tags"%>

Una de las etiquetas más utilizadas en esta aplicación es "accordion"; una utilidad
muy interesante para poder crear paneles de contenido plegables y desplegables para
presentar información en una cantidad limitada de espacio. Otra ventaja de utilizar esta
librería es que cargará el contenido que se encuentre dentro a la vez que carga el contenido
de la página general. Es decir, mantendrá al usuario en la misma página en lugar de cargar
otra página para que visite el contenido que se encuentra dentro del panel desplegable. El
ejemplo que se encontrará en el entorno inicial de la aplicación (Figura 17) será un
"accordion" que cargará la página de inicio de sesión y la página de registro en dos paneles
plegables.

Figura 17. Página de inicio y de registro en un panel desplegable dentro de la página general

Otra funcionalidad que proporciona estas etiquetas jQuery UI es la aplicación de una


serie de temas en sus elementos. De esta manera se podrá cambiar el diseño de estos
elementos por una serie de predefinidos o se podrán construir desde cero. Estos diseños se
podrán incluir en la definición de localización del plugin, como se muestra a continuación:

<sj:head jqueryui="true" jquerytheme="smoothness"/>

46
Capítulo 5: Desarrollo

5.3.4 Tiles
Cuando se construye un entorno web dividido en diferentes partes (cabeceras, pies,
menús, cuerpo,...) se tiene que considerar el uso de una o más plantillas para reutilizar el
código estático y cambiar únicamente aquellas partes que suelen modificarse
mayoritariamente como suele ser el cuerpo de la página, es decir la porción central.
Las plantillas se basan en la estructura que tendrá la página web y contendrá los
elementos necesarios como acostumbran a ser: cabeceras, pies de página, menús, etc. Esto
nos ofrece muchas ventajas ya que si se quiere cambiar el contenido de estas partes de la
aplicación solamente se modificará de un fichero y el cambio se extenderá a todo el
sistema.
Para implementar este tipo de plantillas Struts tiene un complemento llamado Tiles,
el cual es utilizado en este proyecto. Primero de todo se tendrá que definir este
complemento en el archivo de configuración de la aplicación (web.xml) y a continuación
se definirá la plantilla (Código 9) en base a la construcción de tres elementos:
 La plantilla que define elementos estáticos y áreas donde insertar otros
contenidos.
 La página real que utiliza la plantilla insertando textos y otras porciones
dinámicamente..
 Las porciones particulares reutilizables, en este caso serán otros JSPs.

<definition name="baseLayout" template="/baseLayout_main.jsp">


<put-attribute name="title" value="Tiles"/>
<put-attribute name="header" value="/header.jsp"/>
<put-attribute name="menu1" value="/menu_index.jsp"/>
<put-attribute name="menu2" value="/tiles/menu.jsp"/>
<put-attribute name="body" value="/body.jsp"/>
<put-attribute name="footer" value="/footer.jsp"/>
</definition>
Código 9. Definición de una plantilla con el sistema Tiles.

Como se puede apreciar en el código anterior, la plantilla se dividirá en una serie de


partes (title, header, menu1, menu2...), los cuales a su vez estarán compuestos por
diferentes tipos de páginas incrustadas a su vez en una misma.
Una vez hecho el diseño se tiene que proceder a definir que plantilla y componentes
utilizarán las diferentes páginas o módulos de la aplicación. La mayoría de estas páginas
son las formadas por el cuerpo de la aplicación, constantemente cambiando.
En el código 10 se diseña la página que contendrá al módulo de historial de cestas, el
cual estará basado en: la plantilla "baseLayout_main" (definida en el código 9), contendrá
dos tipos de menús diferentes, un título específico para el entorno web y el cuerpo de la
aplicación, basado en el JSP que gestiona el historial de cestas:

47
Capítulo 5: Desarrollo

<definition name="basket_history" extends="baseLayout_main">


<put-attribute name="title" value="Lista de cestas" />
<put-attribute name="menu1" value=" /menu_index.jsp" />
<put-attribute name="menu2" value=" /menu_user.jsp" />
<put-attribute name="body" value="/basket_history.jsp" />
</definition>
Código 10. Definición del módulo "historial de cestas" en Tiles

5.3.5 Interfaz general


En este apartado se pretende explicar algunas funcionalidades extra que han dotado a
la aplicación con nuevas tecnologías que hasta hace pocos años no podían implementarse o
se podían, pero utilizando otras herramientas a día de hoy no recomendadas.

5.3.5.1 Novedades realizadas con HTML5


Hoy en día se utiliza abusivamente del elemento div, que permite estructurar el
entorno web en diferentes bloques. En HTML 5 existen diferentes elementos que se
utilizan para estructurar mejor una página, definiendo que es cada sección (reemplazando
en muchas ocasiones el elemento div.

Figura 18. Comparación de los etiquetas entre HTML y HTML5

Con estos nuevos elementos será mucho más coherente y fácil de entender la
estructura por otras personas y lo más importante es que las máquinas también entenderán
su significado, dándole más importancia a unas secciones, entre otras funcionalidades.
Concretamente, facilitará la tarea de un buscador, pero cualquier aplicación que interprete
el código se beneficiará. Los elementos utilizados en este proyecto son:
 Header: representa la cabecera de una sección, y se le dará más importancia
que al resto, sobre todo si la sección es un artículo.

48
Capítulo 5: Desarrollo

 Footer: representa el pie de una sección, con información acerca de la


página/sección que poco tiene que ver con el contenido de la página, como el
autor, el copyright o el año.
 Nav: representa una sección dedicada a la navegación entre el sitio, como el
típico menú de la aplicación.

Por otro lado está la capacidad multimedia de HTML 5, uno de los grandes avances
en esta última versión del popular lenguaje de programación. En este proyecto se ha
implementado la etiqueta de vídeo, que nos evita la necesidad de recurrir a plugins de otras
aplicaciones como Flash. Esta etiqueta ya está incluida como un elemento natural más de
HTML y cuenta con unos atributos que hacen mucho más flexible la utilización de un
vídeo.
Para poder utilizar esta funcionalidad hace falta que todos los navegadores estén
preparados para reproducir el vídeo que viene integrado en el código HTML5; el único
interrogante que falta por resolver es el formato estándar que todos los navegadores
tendrían que implementar. La presentación de vídeos se puede realizar mediante la etiqueta
<video>, dotada de diferentes atributos para su configuración.

Uno de ellos es la especificación del formato del vídeo a reproducir ya que, como se dijo
antes, no existe un acuerdo para implementar un formato de vídeo estándar. Los atributos
más importantes son:

 Autoplay: Este atributo indica al navegador que debe iniciar la reproducción


del video en cuanto se cargue la página.
 Controls: Se utiliza para incrustar un elemento gráfico, con los botones play,
pause y stop, para que el usuario controle la reproducción.
 Height y Width: A través de estos atributos se indica el alto y ancho del
cuadro donde se ubicará el vídeo. Si no se indica, las dimensiones serán
asumidas por el navegador.
 Poster: Se utilizará para implementar la carátula que tendrá el vídeo,
mediante una imagen. Si se omite el atributo, la imagen que se utiliza es el
primer cuadro de la película.
 Src: Especifica, directamente en la etiqueta video, la ubicación o URL del
archivo que contiene la película a reproducir.

Este elemento se ha implementado en la aplicación para realizar un vídeo introductorio de


la empresa, donde se pretende resumir brevemente en qué consta. Esta situado en el
apartado "Acerca de".

5.3.5.2 CSS 3 y media queries


Para la visualización de la página web en diferentes dispositivos hay que tener en
cuenta la resolución de ellos, ya que en la pantalla de un PC se puede tener una resolución
de 1280x1024, en cambio en una tableta o teléfono móvil esta resolución bajará
notablemente.
El proyecto se creó en principio sobre una pantalla PC y una vez finalizada se adaptó
a diferentes resoluciones de pantalla, estructurando y colocando los elementos en
posiciones que no ocuparán más espacio del que se tenía.

49
Capítulo 5: Desarrollo

Aquí es donde entra en acción la técnica de los “media queries”. Gracias a ella se
puede modificar el modo en que se visualiza la estructura del entorno web en distintos
dispositivos. La regla @media (implantada en esta última versión de CSS) permite añadir
media queries directamente en nuestras hojas de estilo. De esta manera se mejorará el
rendimiento de la página al no tener que cargar archivos CSS adicionales para los
diferentes dispositivos.

@media only screen and (min-width: 768px) and (max-width: 991px) {


//Código CSS a modificar para tabletas
}
@media only screen and (max-width: 767px) {
//Código CSS a modificar para móviles
}
Código 11. Media queries utilizadas en el proyecto para dispositivos como tabletas y móviles

5.3.6 Scripts
A la hora de implementar la aplicación web se han utilizado algunos scripts
(Javascript) de código abierto para la visualización de contenido y otros, también de código
abierto, para mejorar su funcionalidad como es el caso del elemento explicado en el
siguiente capítulo.

5.3.6.1 CKeditor
A la hora de editar ciertas partes de la web como son los productos o categorías se
requería un editor que incorporara algunas funcionalidades para facilitar la administración
de estas partes al usuario; ya que utilizando un elemento textarea se podrían escribir
descripciones o textos con un contenido y un formato no muy adecuado.
Es aquí donde se ha decidido implementar CKeditor: un editor de textos HTML de
código abierto que provee al usuario una edición de contenidos a la altura de aplicaciones
de escritorio (Microsoft Word) sin la necesidad de instalar ningún componente en la
máquina del cliente.

Figura 19. CKeditor, implementado en la parte de administración de la aplicación

50
Capítulo 5: Desarrollo

5.4 I18n
Lo habitual en Struts es utilizar ficheros de texto plano como son los ".properties",
gestionados mediante ResourceBundle) para definir cadenas de textos que tienen que ser
internacionalizadas junto a una clave única para poder recuperar dicha variable o cadena.
Por lo tanto se utilizará un fichero de propiedades para cada uno de los idiomas que
se implantarán en el sistema. En los nombres de los archivos se debe especificar el idioma
indicando el prefijo de ese fichero en el struts.xml; es muy habitual usar “global”. Junto a
este prefijo se adjuntará el sufijo del idioma a utilizar mediante su código correspondiente.
Para el fichero de idioma catalán se especificará el siguiente nombre: global_ca.properties.
Estos ficheros deberán localizarse en la carpeta general o por defecto que crea el
proyecto Struts 2. Un ejemplo del contenido de uno de estos ficheros ".properties" donde
se especifica un clave para una variable y un valor es el siguiente:
 Global_ca: field.add_category = Afegir categoria
 Global_es: field.add_category = Añadir categoría
 Global_en: field.add_category = Add category

Para poder seleccionar el fichero de propiedades que se utilizará habrá un


mecanismo, ya sea de forma automática (por ejemplo, utilizando el idioma predeterminado
del navegador del cliente) o dejando al cliente que indique su preferencia. Para este
proyecto se ha utilizado esta última técnica, en la cual se cambia la variable llamada
"locale" (la cual accede a un fichero de propiedades o otro según la opción.
Esta variable se cambia directamente desde la página JSP (código 12) donde
mediante una URL se envía un parámetro con el nombre de la variable locale
("request_locale") y su valor (el idioma seleccionado).

<s:url id="localeEN" action="localidad" >


<s:param name="request_locale" >en</s:param>
</s:url>
Código 12. Modificación de la variable locale en la página JSP mediante etiquetas de Struts.

5.4.1 Acceder a las variables desde el JSP


Para recuperar los textos que se internacionalizan en la página JSP, Struts 2
proporciona la etiqueta s:text a la cual se indicará la clave del texto que se quiere mostrar.
Del mismo modo se puede acceder utilizando OGNL (Object-Graph Navigation Language)
implementando una de las versiones getText que están disponibles en los ficheros del
controlador si se hereda de ActionSupport. En el código 13 se muestra un ejemplo
implementando las dos técnicas explicadas anteriormente.

<s:text name="field.add_product"/>
<s:submit value="%{getText('field.edit')}"/>
Código 13. Métodos para acceder desde el JSP a las variables del fichero propiedas de idiomas.

51
Capítulo 5: Desarrollo

5.5 Gestionando las facturas


En este capítulo de desarrollo se explicarán las herramientas utilizadas para crear y
gestionar las facturas que los agentes comerciales generarán por cada pedido.

5.5.1 JasperReports
Para poder implementar las facturas en un entorno de programación J2EE se ha
utilizado la herramienta JasperReports; una librería escrita completamente en Java que
permite la creación de informes y exportarlos directamente a diferentes formatos (PDF,
HTML, XML...).
La plantilla de un informe contiene toda la información (determinar la posición del
contenido de los textos, elementos gráficos, etc.) relacionada con la estructura y el aspecto
de los documentos que se generarán posteriormente. Además, toda la forma en la que se
gestionan y manipulan los datos para acceder a almacenes externos de datos también estará
definida en la plantilla.
Este template está programado en el lenguaje XML, el cuál es nombrado como
JRXML en la librería Jasper. Una vez creado, JasperReports procede a validar su
contenido (estructura y sintaxis) mediante un archivo DTD (Document Type Definition) y
generar automáticamente la versión compilada del informe.

5.5.2 iReport
JasperReports acostumbra a usarse con iReport, una herramienta que ayuda a la
edición de los informes mediante un editor gráfico, permitiendo la inclusión de cualquier
elemento (gráficos, imágenes...). Está desarrollado en Java y también es de libre
distribución. Las principales características por las que se ha decidido utilizar iReport son
las siguientes:
 Implementa el 90% de las etiquetas de JasperReports.
 Permite diseñar con sus propias herramientas una gran variedad de elementos
gráficos.
 Soport JDBC.
 Soporta Javabeans como origen de datos.

En definitiva, permite crear cualquier tipo de informe de una manera sencilla y


rápida a través de una interfaz gráfica intuitiva, diseñada en su mayoría para usuarios que
desconocen el lenguaje XML de JasperReports. También es utilizada por usuarios expertos
que ya conocían este lenguaje para ahorrar tiempo en el desarrollo de informes complejos o
muy elaborados permite

5.5.3 Carga de las facturas en la base de datos


Los informes, al no tener un tamaño excesivo son almacenadas en la base de datos.
Para implementar esta gestión en la aplicación web se han utilizado las diferentes librerías
que nos proporciona JasperReports.

52
Capítulo 5: Desarrollo

Figura 20. Pantalla principal de iReport con la plantilla realizada de Nutrisport.

La creación y posteriormente el almacenado de este informe se puede observar en el


código 14 el cual consta de diversas partes explicadas a continuación (y separadas en el
código por un espacio para diferenciarlas):
 Carga del fichero maestro del informe, es decir, la plantilla en formato
JRXML
 Mediante una estructura Map se cargan los Beans o variables de la base de
datos
 Se crea el informe con la librería JasperPrint incluyendo la plantilla, las
variables de la estructura Map y la conexión con la base de datos.
 Se exporta la factura generada a un contexto temporal de la aplicación
 El informe creado y guardado se introduce dentro de un "InputStream" y una
vez aquí es almacenado en la base de datos en formato BLOB.
 El borrado de este archivo temporal del sistema lo controlará Java, con lo
cual, lo eliminará cuando sea necesario.

53
Capítulo 5: Desarrollo

JasperReport masterReport =
JasperReport)JRLoader.loadObjectFromFile(contextReport);

Map pars = new HashMap();


pars.put("userName", user);
pars.put("id_cesta", id_basket);

JasperPrint Print =
JasperFillManager.fillReport(masterReport,pars,conexion);

JRExporter export = new JRPdfExporter();


export.setParameter(JRExporterParameter.JASPER_PRINT,jasperPrint);
export.setParameter(JRExporterParameter.OUTPUT_FILE,new
java.io.File(contextTemporal));
export.exportReport();

file = new File(contextTemporal);


FileInputStream in = new FileInputStream(file);
PreparedStatement update;
String insert = "UPDATE basket SET factura=? WHERE id = ?";
update = con.prepareStatement( insert ) ;
update.setBinaryStream(1, in);
update.setInt(2, id_basket);
con.setAutoCommit(false);
update.executeUpdate();
con.commit();
in.close();
Código 14. Creación y almacenaje en la base de datos del informe

5.5.4 Envío de las facturas por email


Para el envío de las facturas inmediatamente después de ser generadas a los clientes
se ha implementado mediante la API de Java Email. Los pasos que se han seguido (código
15 y los diferentes pasos claramente diferenciados) han sido los siguientes:
 Creación de un fichero de propiedades donde se incluye los parámetros
necesarios de configuración del correo electrónico (usuario, contraseña, host,
puerto...). Al mismo tiempo se crea un autenticado para mejorar la seguridad
respecto al nombre de usuario y la contraseña.
 Inicialización de una nueva sesión donde se incluyen los dos objetos
anteriores.
 Creación del mensaje del email y su cuerpo en el cual se incluye: la sesión, el
email de origen y de destino y un título.

54
Capítulo 5: Desarrollo

 Se crea un objeto MimeBodyPart donde se adjuntará el fichero de la factura y


finalmente se añadirá al cuerpo del correo electrónico.
 Finalmente, una vez que toda la información ha sido rellenada se procede al
envío del email.

//creates a new session with an authenticator


Authenticator auth = new Authenticator() {
public PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(getEmail(), getPassword());
}
};
Session session = Session.getInstance(properties, auth);

// creates a new e-mail message


Message msg = new MimeMessage(session);
msg.setFrom(new InternetAddress(email));
InternetAddress[] toAddresses = { new InternetAddress(emailFrom) };
msg.setRecipients(Message.RecipientType.TO, toAddresses);
msg.setSubject(subject);
msg.setSentDate(new Date());

// creates message part


MimeBodyPart messageBodyPart = new MimeBodyPart();
messageBodyPart.setContent(content, "text/html");

// creates multi-part
Multipart multipart = new MimeMultipart();
multipart.addBodyPart(messageBodyPart);
MimeBodyPart attachPart = new MimeBodyPart();
attachPart.attachFile(file);
multipart.addBodyPart(attachPart);
}

// sets the multi-part as e-mail's content


msg.setContent(multipart);
// sends the e-mail
Transport.send(msg);

Código 15. Código Java para el envío de la factura por email al cliente

55
Capítulo 5: Desarrollo

5.6 Habilitar el acceso a la aplicación desde internet


El último paso una vez creada la aplicación fue dotarla de acceso externo a la
intranet. Tomcat ya viene preparado para ser utilizado desde Internet así que no se requiere
ninguna configuración extra.
El único problema que no permitía acceso desde el exterior a la máquina de la
aplicación era el router y su negación de conexiones al puerto del servidor Apache. Se
solucionó abriendo y habilitando las conexiones a través del puerto 8080
Una vez realizado el paso anterior, solamente se requería la dirección IP del servidor
para acceder a la aplicación web, un número difícil de recordar a la vez que podría cambiar
constantemente si la dirección de la máquina es dinámica. Por lo tanto se decidió utilizar
un programa que a partir de una IP dinámica devolviera siempre un nombre de dominio; de
esta manera se solucionaban los dos inconvenientes a la vez.
El programa escogido fue DUC (Dynamic DNS Update Client), también llamado
más comúnmente como No-IP. Se registró un nombre de dominio gratuito para el servidor
de la aplicación llamado "pfg2014.zapto.org" y se instaló en la máquina. Cuando se
realizaron los pasos anteriores, la aplicación ya era accesible desde cualquier dispositivo
conectado a Internet mediante la URL: http://pfg2014.zapto.org:8080

56
Capítulo 6: Evaluación

6 Evaluación
A continuación se procederá a comprobar el funcionamiento de la aplicación. Se
realizará de igual manera a su desarrollo, es decir, capa por capa del patrón MVC y su
seguridad. En este proyecto no se realizarán pruebas unitarias, se realizará una evaluación
centrada en comprobar el correcto funcionamiento de las diferentes partes y las diferentes
funcionalidades que ésta ofrece.
Por último, para asegurarse al máximo su funcionamiento se ha pedido a diferentes
usuarios utilizarla y realizar todo tipo de funciones dentro de ella para poder recoger
opiniones y posibles fallos y proceder a su solución; este apartado se explicará en la última
parte de este capítulo.

6.1 Funcionamiento del modelo


Este apartado se centrará en el funcionamiento de la aplicación con la base de datos y
las diferentes operaciones que se realizan sobre ella. Las pruebas se realizaron de forma
manual y han sido las siguientes:
 Conexión a MySQL mediante un usuario y contraseña predeterminados
 Manipulación de los elementos (beans) que forman las diferentes columnas
de la base de datos. En esta parte se incluyen las operaciones añadir, editar y
eliminar todo tipo de objetos.
 El formato implementado en cada uno de los campos de la base de datos no
contiene ningún problema de longitud ni de compatibilidad con los elementos
que se introducen en los campos de entrada de texto o objetos.
 Añadir dos elementos con la misma clave primaria y que en el último añadido
no permita la finalización de la operación. En este caso entrarían:
 Usuarios con el mismo correo electrónico
 Categorías o productos con exactamente el mismo nombre
 Cierre de conexión con la base de datos una vez finalizada la operación.

Figura 21. Mensaje de error al intentar registrar un email ya existente en la base de datos

57
Capítulo 6: Evaluación

Las pruebas anteriores también permiten ver que el modelo de datos utilizado (DAO)
realiza su función correctamente junto con los objetos de transferencia de datos (beans)
implementados. Todas estas pruebas se realizaron con una interfaz gráfica muy sencilla, es
decir, sin haber desarrollado la capa de la vista totalmente.

Figura 22. Validación de los campos de Email y contraseña en la acción de iniciar sesión.

6.2 Funcionamiento del controlador


La evaluación de las diferentes acciones que se implementan en esta aplicación eran
vitales para su funcionamiento. En esta parte se han realizado las siguientes
comprobaciones:
 Las llamadas al modelo de datos, es decir, a los diferentes DAO
implementados mediante la clase principal DAO Factory.
 Modificación de las diferentes variables que se recibían de la base de datos y
tenían que ser visualizadas en la vista.
 Verificación de la creación de la factura correctamente:
 Creación de la factura mediante la plantilla JRXML y rellenada con los datos
provenientes de los diferentes objetos de transferencia de datos.
 Envío de la factura por correo electrónico a la dirección del propietario de la
cesta correspondiente.
 Comprobación del funcionamiento correcto de las diferentes variables que se
incrustan en la sesión del usuario (mediante el cual se podrá acceder a estas
variables en cualquier momento de la sesión).
 Los archivos XML para la validación de entrada de textos no permite la
ejecución de una función si los requerimientos no se cumplen.
 La implementación de los diferentes interceptores:
 Comprobación de la sesión de cliente y de administrador mediante las
variables implementadas con ActionContext en la sesión de usuario.
 Comprobación de la entrada de imágenes con diferentes formatos al
predeterminado (PDF) y con un tamaño superior especificado (3MB).
 Los mensajes de acciones y de errores son añadidos correctamente a la vista
después de realizar alguna función en la cual se muestran.
 La sesión del usuario se desconectará automáticamente pasados 30 minutos
desde la no utilización de la aplicación.

58
Capítulo 6: Evaluación

Figura 23. Factura enviada a través de correo electrónico

6.3 Funcionamiento de la vista


La interfaz gráfica del usuario fue la última en desarrollar completamente ya que en
un inicio se realizó una interfaz sencilla para la comprobación de los otros elementos de la
aplicación. En una primera parte se construyó una interfaz sin CSS ni elementos extra
como Javascript, en esta parte se comprobó el correcto funcionamiento de los tags de
Struts 2.
Más adelante, una vez que el controlador estaba casi terminado se procedió a
implementar y evaluar el sistema de plantilla Tiles. Finalmente se construyó toda la vista
con el diseño actual del entorno web; es aquí donde ya se comprobaron las partes restantes
como son:
 Etiquetas que forman los elementos jQuery y su funcionamiento a la hora de
interactuar con el usuario.
 El funcionamiento correcto de la página de contacto y la página de "Acerca de"
donde se reproduce un vídeo (funcionalidad HTML 5) sobre Nutrisport.
 CKeditor y el paso de datos al controlador.
 Ejecución de la aplicación en diferentes navegadores web, los cuales son:
 Firefox (v23)
 Google Chrome (v29)
 Internet Explorer (v10)
 Ejecución de la aplicación en diferentes terminales para comprobar el correcto
funcionamiento de las media queries del archivo CSS que las contenía. Estos
terminales han sido:
 PC (19")
 Tableta (7"-8"-10")
 Teléfono móvil (5")

59
Capítulo 6: Evaluación

6.4 Fase de pruebas con diferentes usuarios


En este apartado se eligió un administrador real, como es el caso del familiar del
desarrollador de la aplicación para comprobar si:
 La interfaz es sencilla e intuitiva, en la cual, hace falta muy pocos conceptos
básicos.
 El funcionamiento es el correcto en todas las acciones de la aplicación.
A continuación se eligieron diferentes personas para simular ser clientes de la
aplicación y poder exprimir y comprobar todo su funcionamiento. De aquí se quiso
comprobar los mismos casos anteriores.
Finalmente se concluyó con un resultado muy positivo, ya que todas las funciones y
comprobaciones de la página web eran correctas y gracias a estos usuarios se recolectaron
algunas opiniones para mejorar el diseño o metodología de la página; una de ellas
correspondía a la muestra de los diferentes productos y categorías, la cual ya ha sido
modificada en esta entrega final.

6.4.1 Resultado final

Figura 24. Panel de administrador de los diferentes productos de la aplicación

60
Capítulo 6: Evaluación

Figura 25. Panel de administrador de los diferentes usuarios registrados en el sistema.

Figura 26. Página de contacto de la aplicación con Google Maps y un formulario de contacto.

61
Capítulo 6: Evaluación

Figura 27. Panel de administrador: Editando un producto con CKeditor.

Figura 28. Panel de usuario: las diferentes cestas realizadas ordenadas por fecha.

62
Capítulo 7: Conclusiones

7 Conclusiones
Una vez finalizado el proyecto y su evaluación se han sacado una serie de
conclusiones, las dividiremos según los objetivos fijados al principio y se acabará
explicando las valoraciones personales que el desarrollador de la aplicación ha conseguido
extraer de todos los meses de trabajo realizado.

7.1 Cumplimiento de los objetivos

7.1.1 Objetivos principales


Todos los objetivos principales que se marcaron al principio de este proyecto han
sido resueltos. Gracias al patrón MVC se pudieron realizar las diferentes partes de la web
independientemente de las otras; se empezó perfeccionando el modelo, después el
controlador y finalmente diseñando una bonita interfaz. Este patrón ayuda mucho a la
aplicación una vez esta ya está implementada por los beneficios comentados al principio
del proyecto, pero su inconveniente es la complejidad de programarlo.
Si este proyecto se tuviera que volver a desarrollar seguramente se cambiarían
algunas cosas como el acceso a los datos. En esta parte se ha visto que es mucho más
cómodo para el programador implementar un framework muy popular llamado Hibernate
para acceder a la información de la base de datos; en lugar de utilizar la tecnología JDBC.
No se hubiese tratado de cambiar Struts por otro framework pero si hubiese sido lo
ideal su comparación con otros tipos ya que en las búsquedas de información se encontraba
mucha información de otro framework llamado Spring MVC que, en principio, parecía
más popular y tenía una comunidad mucho más activa que Struts.
Por último, el tema de la seguridad ha sido implementado y comprobado por usuarios
normales y no informáticos que puedan atacar el sitio web. Si este proyecto sigue en
marcha y llega a gustar a usuarios reales (agentes comerciales) se tendría que comprobar y
revisar este tema nuevamente.

7.1.2 Objetivos de aprendizaje


Antes de programar una arquitectura de software con el patrón MVC el desarrollador
ya había programado un entorno web con lenguaje PHP y con una única capa. Con esta
comparación, implementar este tipo de modelo de aplicación ha resultado ser muy útil a la
hora de solucionar ciertos tipos de errores, ya que una vez localizados se sabía qué parte
del proyecto se tenía que modificar.
Otros tipos de herramientas que han resultado muy útiles son los interceptores o
filtros de la aplicación Java, que permite definir una serie de acciones antes de que se
ejecute la acción principal. Por otra parte, la implementación de los DAO como modelo de
acceso a los datos ha resultado muy útil ya que se elimina el diseño de la base de datos y
permite centrarse en la estructura de objetos; además, permite pensar en el futuro ya que
con el "DAO Factory" se puede cambiar de almacén de datos muy fácilmente.
Las plantillas utilizadas (tiles) han reducido considerablemente la redundancia de
código en las páginas JSP y era algo ya conocido en PHP por el desarrollador pero no en
entornos de aplicación J2EE.

63
Capítulo 7: Conclusiones

Por lo que hace la adaptación de la aplicación en diferentes dispositivos, el lenguaje


CSS en su última versión resultó muy útil ya que en un solo archivo se pueden crear todas
las configuraciones; de esta manera, no se sobrecarga mucho el servidor al no tener que
descargar todos los ficheros de visualización.
Finalmente, como valoración personal por parte del redactor decir que se ha
mejorado y aprendido mucho con tecnologías correspondientes a la parte "back-end" de la
aplicación (Modelo y Controlador). En la parte correspondiente al "front-end", es decir, la
vista del entorno web como son los lenguajes HTML, CSS o JavaScript no se ha
profundizado todo lo que el desarrollador quería ya que para una aplicación de este tamaño
no requería una interfaz gráfica muy compleja.

64
Capítulo 8: Recursos utilizados

8 Recursos utilizados
8.1 Bibliografía
[1] Web en línea <> http://www.javatpoint.com [Consulta: Octubre 2013]
[2] Web en línea <> http://www.java4s.com [Consulta: Octubre 2013]
[3] Web en línea <> http://www.epidataconsulting.com [Consulta: Octubre 2013]
[4] PDF en línea <> http://es.scribd.com/doc/52029539/TEMA-8-2-Struts2
[Consulta: Diciembre 2013 ]
[5] Foro de usuarios en línea <> http://stackoverflow.com [Consulta: Enero 2014]
[6] Web en línea <> http://www.mkyong.com/struts2 [Consulta: Octubre 2013]
[7] Web en línea <> http://www.tutorialspoint.com/struts2 [Consulta: Octubre 2013]
[8] Web en línea <> http://www.javatutoriales.com [Consulta: Agosto 2013]
[9] Web en línea <> http://www.tutorials4u.net [Consulta: Septiembre 2013]
[10] Web en línea <> http://mrbool.com [Consulta: Febrero 2014]
[11] Web en línea <> http://viralpatel.net/blogs/struts-2-tiles-plugin-tutorial
[Consulta: Febrero 2014]
[12] Web en línea <> http://struts.jgeppert.com/struts2-jquery-showcase/
[Consulta: Abril 2014]
[13] Web en línea <> https://developer.mozilla.org/es/docs/CSS/Media_queries
[Consulta: Abril 2014]
[14] Web en línea <> http://community.jaspersoft.com/project/ireport-designer
[Consulta: Agosto 2013]
[15] Web en línea <> http://struts.apache.org/release/2.3.x/docs/home.html
[Consulta: Agosto 2013]
[16] Web en línea <> http://www.w3schools.com [Consulta Marzo 2014]

8.2 Software empleado


 Netbeans 7.3.1 como IDE.
 MySQL Workbench 6.1 CE.
 XAMPP.
 Tomcat como servidor de aplicaciones.
 Apache y phpMyAdmin como herramientas de interacción con la base de
datos.
 MySQL (5.5).
 Mozilla Firefox 28.0.1
 Sistema operativo Windows 7 (32 y 64 bits).

65
Capítulo 8: Recursos utilizados

8.3 Hardware para el desarrollo


 Intel Core 2 Duo a 2,67 GHz con 6GB de RAM
 Intel Core i3 a 2,27 GHz con 4GB de RAM

8.4 Programas de edición de textos


 Microsoft Word 2007
 Photoshop CS 6

66
Capítulo 9: Anexos

9 Anexos
9.1 Manual de instalación y configuración
En primer lugar se instalará el servidor de aplicaciones, la base de datos y la
herramienta para interactuar con la base de datos de manera gráfica en lugar de utilizar
comandos. Para instalar todo lo anterior solamente se tendrá que instalar la herramienta
XAMPP, que incluye las herramientas anteriores, desde la siguiente dirección:
https://www.apachefriends.org/es/index.html

No es necesaria una configuración adicional para este programa; simplemente se


instala y se activan los componentes que se quieren utilizar para el proyecto. Es un
programa válido para cualquier sistema operativo, aunque en este proyecto se ha probado
con Windows 7.
A la hora de instalar el servidor Tomcat deberemos verificar que existe la variable
JAVA_HOME en el path del sistema, por lo tanto el siguiente paso será instalar la máquina
virtual de Java junto al programa para desarrollar la aplicación, en este caso Netbeans. Este
programa se puede descargar junto a la máquina virtual desde el siguiente enlace:
https://netbeans.org/downloads/index.html

Tomcat permite varios métodos de identificación de usuario; en este proyecto se ha


realizado esto mediante la modificación directa del fichero tomcat-users.xml. Este archivo
está contenido dentro de la carpeta configuración de Tomcat y inicialmente tendrá este
contenido:
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
</tomcat-users>

Para añadir un nuevo usuario para la administración del servidor de aplicación se


añadirá la siguiente línea:
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<user name="user" password="pw" roles="standard,manager" />
</tomcat-users>

Donde "user" será el nombre de usuario y "pw" será contraseña para este usuario. Se
han añadido los roles "standard" y "manager", es decir, los permisos suficientes para
administrar el servidor. Tras añadir esta línea se tendrá que detener e iniciar el servicio de
Tomcat. La contraseña se guarda no encriptada, por lo que hay que tener cuidado y saber
que usuarios pueden acceder a este archivo de configuración.

67
Capítulo 9: Anexos

En netbeans se tendrá que crear una aplicación J2EE donde se indicará el framework
MVC a utilizar (Struts 2) y el servidor que se utilizará, ya que por defecto si no se indica
uno utilizará GlassFish. En este caso se indicará Tomcat. Las librerías que se incorporarán
al proyecto son las siguientes:
 commons-beanutils-1.8.0.jar
 commons-digester-1.8.jar
 commons-collections-2.1.1.jar
 commons-javaflow-20060411.jar
 commons-lang-2.6.jar
 freemarker-2.3.15.jar
 javax.mail.jar
 junit-3.8.2.jar
 struts2-jquery-plugin-3.6.1.jar
 struts2-tiles-plugin-2.1.8.jar
 tiles-core-2.0.6.jar
 xwork-core-2.1.6.jar
 jasperreports-5.5.0.jar
 jasperreports-applet-5.5.0.jar
 jasperreports-fonts-5.5.0.jar
 jasperreports-javaflow-5.5.0.jar
 swing-worker-1.1.jar
 groovy-all-2.0.0.jar
 iText-2.1.0.jar

A la hora de crear la base de datos MySQL y las diferentes tablas que la forman se
realizará mediante la herramienta phpMyAdmin. En el caso que no se sepan los comandos
correctos "sql" este programa solventará este problema. Para acceder a esta herramienta se
hará mediante el navegador en la dirección:
http://localhost/phpmyadmin

Desde esa dirección se creará como mínimo un usuario administrador ya que el


registro de éstos desde la aplicación web no está habilitado. La conexión entre la
aplicación y la base de datos mediante el driver JDBC no será explicado en esta parte ya
que se comentó brevemente su uso y configuración en el desarrollo del proyecto.
Finalmente, una vez que el servidor esté activo y la aplicación web compilada se
podrá visitar mediante la URL http://localhost:8080.

68
Capítulo 9: Anexos

9.2 Manual de usuario

9.2.1 Administrador
El usuario administrador solo podrá conectarse al entorno web con los datos
proporcionados por el desarrollador, es decir, con el correo electrónico y una contraseña
proporcionada, que posteriormente podrá cambiar en su perfil. En el caso de no introducir
los datos correctos o no tener permisos de administrador, el usuario permanecerá en la
misma página inicial de la aplicación.

Figura 29. Página de inicio para iniciar sesión, tanto de administradores como de clientes

En la página principal de administración podrá realizar las siguientes funciones:


 Perfil de empresa: Modificar los datos de la empresa a la que está dando
servicios de distribución o en el caso que en las facturas quiera que aparezcan
sus datos de autónomo en lugar de los de empresa tendrá que cambiar este
contenido.

Figura 30. Página para editar los datos de empresa de la aplicación

69
Capítulo 9: Anexos

 Perfil de usuario: Modificará sus datos personales, donde podrá cambiar el


correo electrónico de contacto, el teléfono, contraseña, etc.
 Usuarios registrados: Podrá añadir o eliminar usuarios al sistema. También se
da la posibilidad de editar los usuarios ya registrados, en casos como pérdida
de la contraseña o entrada de datos personales incorrectos.

Figura 31. Página para editar los usuarios registrados (clientes) en el sistema.

 Productos: Podrá añadir o eliminar productos del sistema. También se podrán


editar estos mismos. Los datos tendrán que estar bien introducidos, en el caso
del precio se aceptarán números decimales y en el caso de las imágenes de los
productos se aceptarán únicamente archivos JPG. No se aceptarán dos
productos con el mismo nombre

Figura 32. Página para añadir, editar o eliminar los productos de empresa introducidos en el sistema.

 Categoría: Se podrán realizar las mismas acciones que en los productos con la
misma restricción de no permitir dos categorías con el mismo nombre.

70
Capítulo 9: Anexos

 Historial de compras: Habrán tres tipos de cestas:

 Cestas sin confirmar: Son las cestas que los usuarios aun tienen pendientes
de finalizar ya que por algún motivo no pudieron confirmarlas. Estas cestas
no son de gran importancia para el agente comercial ya que no tendrá que
realizar ninguna acción.

 Cestas confirmadas: Son las cestas que los usuarios ya acabaron por lo tanto
el agente comercial tendrá que preparar los pedidos correspondientes de
productos y una vez pagadas se procederá a realizar el método "Validar pago"
donde automáticamente se generará una factura que será enviada al cliente
por correo electrónico y podrá ser accedida por él desde su panel de usuario.

Figura 33. Cestas confirmadas y pendientes de pago.

 Cestas pagadas: Son aquellas cestas que ya han sido confirmadas y pagadas.
Se podrá consular la factura de todas ellas.

Figura 34. Cestas confirmadas y pagadas donde se podrá descargar el informe correspondiente.

71
Capítulo 9: Anexos

Desde el panel de administración no se podrá realizar ninguna modificación de estas


cestas; únicamente se podrán ver sus detalles, es decir, los diferentes pedidos que
contienen. Las cestas estarán indexadas por el correo electrónico del usuario que las habrá
creado.

9.2.2 Cliente
Al igual que con el caso del administrador, el usuario cliente tendrá que entrar al
sistema mediante un correo electrónico y una contraseña proporcionada en este caso por el
administrador y no el desarrollador de la aplicación. Si no se introducen los datos correctos
el cliente permanecerá en la pantalla de inicio sin poder utilizar las funciones de la
aplicación.
En la página principal del cliente se podrá realizar las siguientes funciones:
 Perfil de usuario: Modificará sus datos personales, donde podrá cambiar el
correo electrónico de contacto, el teléfono, contraseña, etc.
 Productos: Podrá visualizar todos los productos que contiene el sistema. Para
ver la descripción, categoría a la que pertenecen y su precio deberán dar clic
encima de la imagen del producto y se abrirá una ventana con tal
información.

Figura 35. Descripción de un producto seleccionado.

 Categorías: Se mostrarán todas las categorías de productos junto con los


productos correspondientes a ellas; al igual que en el caso anterior para
visualizar más información acerca de esta categoría se hará clic encima del
nombre.

72
Capítulo 9: Anexos

 Historial de compras: Se mostrarán todas las cestas confirmadas y/o pagadas


por el usuario ordenadas por la fecha de creación. En este apartado se podrá
consultar las facturas de las cestas pagadas.

Figura 36. Lista de cestas confirmadas por fecha. Se muestra una cesta pagada con el correspondiente
enlace para descargar la factura

 Cestas sin confirmar: Se mostrarán todas aquellas cestas que el usuario dejará
pendientes de confirmar. Estas cestas podrán editarse para finalizarlas en el
momento que el usuario desee.

Figura 37. Categorías y productos mostrados al iniciar una nueva compra

73
Capítulo 9: Anexos

 Nueva compra: En este apartado se procederá a crear una nueva cesta;


primero se dará a elegir entre seleccionar los productos directamente o
mediante sus categorías. Una vez seleccionado el producto se tendrá que
clicar encima de él para introducir la cantidad correspondiente que se desea.
Una vez introducida esta cantidad se dará la opción de finalizar la cesta,
seguir comprando o seguir comprando en otro momento (Si se clica en la
última opción la cesta pasará a la clasificación de cestas pendientes).

Figura 38. Selección de la cantidad de unidades que se quieren de un producto.

74
Capítulo 9: Anexos

75

También podría gustarte