pedro colomina medina aplicaciÓn web para …deim.urv.cat/~pfc/docs/pfc1407/d1403182838.pdf ·...

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

3

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.

Índice

4

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

Índice

5

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

Índice

6

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

Capítulo 1: Introducción

7

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.


8

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.


9

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.

Capítulo 2: Objetivos del proyecto

10

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.


11

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.


12

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.


13

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.

Capítulo 3: Especificaciones del proyecto

14

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.


15

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


16

Capítulo 4: Diseño

17

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


18

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.


19

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


20

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.


21

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.


22

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.


23

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.


24

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.


25

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.


26

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.


27

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.


28

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.


29

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.

Capítulo 5: Desarrollo

30

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.


31

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


32

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");

}


33

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


34

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?


35

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.


36

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.


37

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


38

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.


39

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


40

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.


41

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");


42

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.


43

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.


44

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"


45

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


46

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"/>


47

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:


48

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


49

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.


50

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


51

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.


52

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.


53

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.


54

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.


55

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


56

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

Capítulo 6: Evaluación

57

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


58

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.


59

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


60

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


61

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.


62

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

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

Capítulo 7: Conclusiones

63

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.

Capítulo 7: Conclusiones

64

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.

Capítulo 8: Recursos utilizados

65

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

Capítulo 8: Recursos utilizados

66

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

Capítulo 9: Anexos

67

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.

Capítulo 9: Anexos

68

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.

Capítulo 9: Anexos

69

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

Capítulo 9: Anexos

70

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.

Capítulo 9: Anexos

71

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.

Capítulo 9: Anexos

72

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.

Capítulo 9: Anexos

73

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

Capítulo 9: Anexos

74

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.

Capítulo 9: Anexos

75

pedro colomina medina aplicaciÓn web para …deim.urv.cat/~pfc/docs/pfc1407/d1403182838.pdf ·...

Documents