TRABAJO FIN DE GRADO

Ttulo

Aplicacin web para el control de proyectos en la

empresa Sumainfo S.L.
Autor/es

Naziha Ayachi Majait

Director/es

Francisco Jos Garca Izquierdo

Facultad

Facultad de Ciencias, Estudios Agroalimentarios e Informtica

Titulacin

Grado en Ingeniera Informtica

Departamento

Curso Acadmico

2012-2013

Aplicacin web para el control de proyectos en la empresa Sumainfo S.L.,

trabajo fin de grado
de Naziha Ayachi Majait, dirigido por Francisco Jos Garca Izquierdo (publicado por la
Universidad de La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan ms all de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.

El autor
Universidad de La Rioja, Servicio de Publicaciones, 2013
publicaciones.unirioja.es
E-mail: publicaciones@unirioja.es

UNIVERSIDAD DE LA RIOJA

FACULTAD DE CIENCIAS, ESTUDIOS AGROALIMENTARIOS E INFORMTICA

GRADO EN INGENIERA INFORMTICA

Aplicacin web para el control

de proyectos en la empresa
Suma Info S.L.
TRABAJO FIN DE GRADO
Junio de 2013

Realizado por
Naziha Ayachi Majait
Dirigido por
Francisco Jos Garca Izquierdo

Resumen
El presente Trabajo Fin de Grado consiste en el desarrollo de una aplicacin web para la
gestin de los proyectos en la empresa de servicios informticos Suma Info S.L. Partiendo de
una aplicacin web que usa la tecnologa JavaServer Pages y una base de datos en Oracle, se
construir otra nueva usando JavaServer Faces, Facelets, Richfaces, Hibernate y Spring, que
se monta sobre un nuevo modelo de datos en MySQL.
La funcionalidad de la nueva aplicacin consiste en gestionar los proyectos de la empresa,
mantener los tiempos que registran los empleados para cada uno de los proyectos en los que
participan, as como los gastos y honorarios generados durante el proceso de ejecucin y su
asignacin a los proyectos. Adems del mantenimiento del personal de la empresa y los
clientes con los que interacta, debe gestionar todas las facturaciones realizadas para
contabilizar los gastos y honorarios producidos por los proyectos activos en la empresa.
Una de las mayores dificultades de este proyecto fue el manejo de las distintas tecnologas,
totalmente desconocidas para m hasta el inicio del trabajo, lo que supuso un largo proceso
de formacin. Uno de los principales problemas fue la integracin de las tecnologas
utilizando Spring Framework, sobre todo en el caso de Hibernate. La construccin del
proyecto con Maven y la gestin de las libreras fue otro punto problemtico durante el
desarrollo.
Otro aspecto clave fue comprender y aplicar todos los mecanismos que ofrece Spring Security
para garantizar la seguridad de la aplicacin.
Mi mayor reto fue hacer frente a todos los problemas surgidos, desde la fase de recogida de
requisitos, pasando por el diseo de la arquitectura hasta llegar a su completa
implementacin y en buscar las soluciones que ms se adapten a cada caso y aplicarlas para
ver que el problema se resuelve.
El resultado obtenido es una aplicacin web que ampla la funcionalidad de la antigua y que
ha sido desarrollada con una tecnologa ms actual que facilitar su mantenimiento y
evolucin.

Abstract
The present dissertation consists of the development of a web application for the
management of projects in the company of computer services Suma Info S.L. Starting with
the web application that employs the JavaServer Pages and an Oracle database, a new
database is constructed using JavaServer Faces, Facelets, Richfaces, Hibernate and Spring,
which is assembled on a new model of data in MySQL.
The usefulness of the new application is based on the management of the projects of the
company, maintaining the time that the employees record in each one of the projects that
they take part in, as well as the expenses and the fees generated throughout the process of
execution and assignation of the projects. In addition to the maintenance of the personnel
employees, and the clients with whom they interact; it must also arrange all the billing
realized for the accountancy of the expenses and the fees produced by the active projects of
the company.
One of the most difficult aspects of this project was the handling of the diverse technology,
totally unknown to me until the beginning of the project; and this supposed a long process of
instruction. One of the main problems was the integration of technology applying Spring
Framework, principally in the case of Hibernate. The formation of the project with Maven,
and the administration of the Java libraries was another problematic point in the
development of the project.
Another key aspect was the understanding and the application of all the mechanisms that
Spring Security offers to warranty the security of the application.
My greatest challenge was tackling all the problems that emerged, from the phase of
collection of requirements, going through the design of the architecture, until reaching its
complete implementation and search for the solutions that best adapts with each case, and
their application to notice that the problem is solved.
The result obtained is a web application that extends the functionality of the former one, and
that has been established with a more modern technology that facilitates its maintenance
and evolution.

Agradecimientos

Me gustara dar las gracias a:

Mi tutor Francisco Jos Garca Izquierdo por darme los nimos necesarios para seguir
adelante, por sus consejos valiosos cuando ms los necesitaba y por guiarme a lo largo del
proyecto.
Mis queridos padres y hermanos que me han apoyado en todo y por la confianza que han
depositado siempre en m.
Todos mis profesores por aportarme los conocimientos necesarios para afrontar las
dificultades surgidas durante el desarrollo del proyecto.
Los integrantes de la empresa Suma Info S.L. y en especial a Juan Adanero, Eduardo Fras y
Alejandro Ochoa por su ayuda y apoyo.
Mis amigos y compaeros que han estado siempre a mi lado y por compartir los malos y
buenos momentos dentro y fuera de la universidad.

NDICE
INTRODUCCIN ....................................................................................................................... 1

1.

1.

Visin general .......................................................................................................................................... 1

2.

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

ANLISIS ............................................................................................................................ 3
1.1. Especificacin de requisitos funcionales ...................................................................................... 3
1.1.1. Gestin de usuarios y personal de la empresa ................................................................. 3
1.1.2. Mantenimiento de proyectos ................................................................................................... 4
1.1.3. Mantenimiento de tiempos ....................................................................................................... 5
1.1.4. Gestin de gastos .......................................................................................................................... 6
1.1.5. Gestin de facturas ....................................................................................................................... 6
1.1.6. Mantenimiento de los clientes ................................................................................................ 7
1.2. Especificacin de los requisitos no funcionales......................................................................... 7
1.2.1. Requerimientos tecnolgicos .................................................................................................. 7
1.2.2. Seguridad ......................................................................................................................................... 7
1.3. Modelo del dominio ............................................................................................................................... 8
1.3.1. Clases identificadas ...................................................................................................................... 8
1.3.2. Diagrama de clases ....................................................................................................................... 9

2.

DISEO ............................................................................................................................ 10
2.1. Modelo de datos .................................................................................................................................... 10
2.1.1. Antiguo modelo de datos ......................................................................................................... 10
2.1.1.1. Diagrama .............................................................................................................................. 10
2.1.1.2. Entidades .............................................................................................................................. 11
2.1.1.3. Deficiencias .......................................................................................................................... 12
2.1.2. Modelo de datos actual ............................................................................................................. 13
2.1.2.1. Requisitos ............................................................................................................................. 13
2.1.2.2. Migracin de Oracle a MySQL ...................................................................................... 14
2.1.2.3. Diagrama .............................................................................................................................. 14
2.1.2.4. Diferencias respecto del antiguo modelo ................................................................ 16
2.2. Arquitectura software ........................................................................................................................ 17
2.2.1. Capa de presentacin ................................................................................................................ 17
2.2.2. Capa de lgica de negocio........................................................................................................ 17
2.2.3. Capa de persistencia .................................................................................................................. 18
2.2.4. Comunicacin entre las capas ............................................................................................... 19

2.3. Interfaces de usuario .......................................................................................................................... 20

2.3.1. Interfaz de login .......................................................................................................................... 20
2.3.2. Partes fijas de la interfaz ......................................................................................................... 21
2.3.3. Interfaz de pginas con listado ............................................................................................. 22
2.3.4. Interfaz de pginas con formulario ..................................................................................... 22

3.

IMPLEMENTACIN ...................................................................................................... 23
3.1. Tecnologas empleadas ...................................................................................................................... 23
3.1.1. Maven .............................................................................................................................................. 23
3.1.2. Hibernate ....................................................................................................................................... 24
3.1.3. Richfaces......................................................................................................................................... 25
3.1.4. Facelets ........................................................................................................................................... 25
3.1.5. Spring............................................................................................................................................... 26
3.1.6. Informes con Jasperreports .................................................................................................... 26
3.2. Validacin y conversin..................................................................................................................... 28
3.3. Seguridad ................................................................................................................................................. 30
3.3.1. Autenticacin................................................................................................................................ 30
3.3.2. Autorizacin.................................................................................................................................. 33
3.4. El proceso de trabajo .......................................................................................................................... 34
3.4.1. La vista JSF..................................................................................................................................... 34
3.4.2. El Controlador .............................................................................................................................. 35
3.4.3. El Servicio ...................................................................................................................................... 37
3.4.4. El DAO.............................................................................................................................................. 37
3.5. Pruebas ..................................................................................................................................................... 38

4.

GESTIN DEL PROYECTO .......................................................................................... 40

4.1. Planificacin inicial .............................................................................................................................. 40
4.2. Definicin de tareas ............................................................................................................................. 40
4.3. Diagrama de Gantt ............................................................................................................................... 40
4.4. Resultado final ....................................................................................................................................... 42
4.4.1. Comparacin entre el tiempo estimado y el real ........................................................... 42
4.4.2. Justificacin de los desfases ................................................................................................... 43
4.5. Problemas afrontados ........................................................................................................................ 44

CONCLUSIONES ..................................................................................................................... 45
Posibles mejoras............................................................................................................................................. 45

BIBLIOGRAFA ...................................................................................................................... 46

NDICE DE FIGURAS
Figura 1: Diagrama de clases del modelo ................................................................................................... 9
Figura 2: Diagrama del antiguo modelo de datos .................................................................................. 10
Figura 3: Diagrama del modelo de datos actual ..................................................................................... 15
Figura 4: Diagrama de algunas clases de persistencia ........................................................................ 18
Figura 5: Comunicacin entre DAOs ........................................................................................................... 19
Figura 6: Flujo de aadir nuevo proyecto ............................................................................................. 20
Figura 7: Prototipo de la interfaz de login ................................................................................................ 21
Figura 8: Prototipo del esqueleto general ................................................................................................ 21
Figura 9: Prototipo de pginas con listado............................................................................................... 22
Figura 10: Prototipo de pginas con formulario.................................................................................... 22
Figura 11: Dependencias del proyecto ...................................................................................................... 23
Figura 12: Plantilla jrxml de facturas...................................................................................................... 27
Figura 13: Ciclo de vida JSF............................................................................................................................. 28
Figura 14: Proceso de autenticacin en Spring Security .................................................................... 32
Figura 15: Proceso de trabajo en la aplicacin ....................................................................................... 34
Figura 16: Descomposicin de tareas ........................................................................................................ 40
Figura 17: Diagrama de Gantt ........................................................................................................................ 41
Figura 18: Grfico de comparacin de tiempos...................................................................................... 43

NDICE DE TABLAS
Tabla 1: Entidades del antiguo modelo ..................................................................................................... 12
Tabla 2: Leyenda de smbolos del diagrama ER..................................................................................... 14
Tabla 3: Comparacin entre tiempos ......................................................................................................... 42

INTRODUCCIN
1. Visin general
En el presente proyecto se parte de una aplicacin ya disponible y puesta en
funcionamiento para la gestin de proyectos en la empresa Suma Info S.L.
La antigua aplicacin se basa en la tecnologa JavaServer Pages y usa una base de datos
en Oracle. Uno de los problemas que presenta esta aplicacin es que su modelo de
datos no corresponde con lo que realmente se pretende modelar, ya que slo almacena
tablas aisladas sin ninguna interconexin. Esto puede suponer incongruencias en la
base de datos. Adems de todo lo anterior, la aplicacin web posee una interfaz de
usuario poco usable.
El objetivo principal de este proyecto es lograr la construccin de una nueva aplicacin
que se apoya sobre un nuevo modelo de datos, que suponga una mejora en el
rendimiento respecto de la aplicacin actual y que facilite su mantenimiento posterior.
El proyecto tiene su punto de partida en la redefinicin de los requisitos de la nueva
aplicacin y su modelo de datos. Esta fase empieza por una recoleccin de los
requerimientos mediante varias reuniones con el cliente.
Asentndose sobre una base slida de anlisis, en su segunda fase se disearon todos
los elementos necesarios para la construccin de un nuevo sistema completo que se
ajusta a las necesidades del cliente.
Despus de un largo proceso de formacin en todas las tecnologas que venan
impuestas por el cliente para ser usadas en la fase de desarrollo de la aplicacin, con el
fin de facilitar este proceso y el mantenimiento de la nueva aplicacin de gestin. La
fase de implementacin empieza con el uso del estndar JavaServer Faces (JSF) que
resuelve varios problemas que se planteaban al principio, el sistema simplificado de
presentacin Facelets que aporta mayor libertad al anterior en cuanto al diseo y la
librera de componentes Richfaces para dotar los componentes de capacidad Ajax sin la
necesidad de escribir ni una lnea de cdigo JavaScript y su completa integracin en el
ciclo de vida JSF.
Con el uso de Spring Framework el coste de integracin se ha reducido de forma
drstica. El soporte para las anotaciones que brinda esta tecnologa, las nuevas
posibilidades para vincular los objetos con los que se trabaja, gracias al nuevo concepto
de inyeccin de dependencias y su gestin transparente para el usuario.
Si profundizamos en la arquitectura de esta aplicacin, nos encontramos con el motor
de persistencia Hibernate utilizado en el mapeo Objeto Relacional. Totalmente
integrable con Spring mediante las plantillas que ofrece este ltimo, lo que hace que la
labor del desarrollador se reduzca notablemente debido a su gestin de las conexiones
y transacciones con la base de datos.

Con Spring Security nace el concepto de seguridad declarativa para mantener y

alcanzar un determinado nivel de seguridad, lo que hace que la aplicacin tenga una
arquitectura limpia y robusta.
Por ltimo y como resultado final se obtiene una aplicacin Web de gestin ajustada a
las necesidades del cliente, intuitiva y fcil de manejar.

Palabras clave: JavaServer Faces, Hibernate, Spring, Framework, Aplicacin Web,

Spring Security, DAO, Jasperreports, Facelets, Java, autenticacin, autorizacin, capas y
MVC.

2. Objetivos del proyecto

El proyecto consiste en el desarrollo de una aplicacin web para el control de proyectos
en la empresa SumaInfo S.L. utilizando las siguientes tecnologas que vienen impuestas
por la misma: JavaServer Faces, Facelets, Richfaces, Hibernate, Spring y una base de
datos en MySQL.
Las funciones bsicas de esta aplicacin web se pueden resumir en:

El control y mantenimiento de los proyectos activos en la empresa, la asignacin de

personal a dichos proyectos y el registro de los tiempos dedicados a cada proyecto
por el tcnico correspondiente.

La gestin de los gastos imputados a cada proyecto.

La gestin de las facturas correspondientes a cada proyecto.

El mantenimiento de los clientes y el personal de la empresa.

Ofrecer la posibilidad de exportacin de informes de las facturaciones en formato

PDF.

La aplicacin debe permitir el mantenimiento de la informacin de forma fcil y rpida,

as como tener una infraestructura de usuarios y roles para controlar el acceso y
garantizar un determinado nivel de seguridad.

1. ANLISIS
1.1. Especificacin de requisitos funcionales
A la vista de los resultados obtenidos de las reuniones mantenidas con el cliente, he
decidido especificar el funcionamiento de la aplicacin dividido en seis partes
agrupadas por reas:

Gestin de usuarios y personal de la empresa.

Mantenimiento de proyectos.
Mantenimiento de tiempos.
Gestin de facturas.
Gestin de gastos.
Mantenimiento de los clientes.

Antes de empezar a describir los tipos de usuarios de la aplicacin y las funciones de

cada uno, debo mencionar tres operaciones que son comunes para cualquier usuario,
independientemente de su rol:

Identificarse en la aplicacin mediante el usuario y la contrasea: todo usuario

debe ser identificado por la aplicacin antes de proceder a realizar cualquier
operacin. La identificacin de un usuario le permite adquirir los privilegios
con los que puede interactuar con la aplicacin web.

Salir de la aplicacin y cerrar la sesin iniciada por el usuario: para

garantizar la seguridad evitando de esta manera posibles incidentes, se
recomienda al usuario que cierre su sesin cada vez que desea salir de la
aplicacin. En caso de que no se lleve a cabo esta operacin, el sistema deber
garantizar la invalidacin de la sesin pasado un cierto perodo de tiempo.

Cambiar contrasea: una vez que se identifica el usuario, el sistema debe

permitirle cambiar su contrasea antigua por una nueva.

1.1.1. Gestin de usuarios y personal de la empresa

La aplicacin permitir una gestin de usuarios que abarcar las funcionalidades de
dar de alta a un nuevo usuario, darle de baja y consultar o modificar sus datos
personales.
Los usuarios de dicha aplicacin sern todos los empleados de la empresa,
distinguindose entre usuarios con privilegios (responsables) y el resto de usuarios
que sern los tcnicos. Estos ltimos podrn adquirir dicho rol siempre que hayan
sido dados de alta en el sistema por un usuario responsable.

Usuario tcnico: podr llevar una gestin de sus tiempos, que consiste en
registrar el tiempo que dedica a un proyecto y modificar o eliminar dichos
registros. Por otra parte consultar la ficha de los proyectos de la empresa y
mantener sus gastos.

Usuario responsable: este usuario gozar de los privilegios de

administrador del sistema y con los cuales podr acceder a las
funcionalidades del usuario tcnico y adems llevar a cabo la gestin de
usuarios, el mantenimiento de proyectos, as como la gestin de facturas.

Para dar de alta a un empleado se debe recoger, su nombre, apellidos, usuario y

contrasea para acceder a la aplicacin y asignarle un rol (tcnico o responsable).
Dado que no es imprescindible recoger el DNI o cualquier otro documento
identificativo del empleado, para ello, se le asigna un cdigo nico en el sistema.
Un usuario responsable podr modificar todos los datos de un empleado excepto su
cdigo identificativo, as como darle de baja introduciendo la fecha en la que tuvo
lugar dicha baja.
Una vez que se da de alta a un empleado en el sistema, se le debe asignar una
categora con la que puede operar dentro del perodo de un ao (gerente,
responsable, analista, programador, etc.). Esta ser elegida de una lista de categoras
predeterminadas. Debemos distinguir entre esta asignacin y la que se realiza dentro
del mbito de un proyecto. Los usuarios responsables sern los encargados de
gestionar estas asignaciones de categoras, pudiendo modificar o eliminar
asignaciones previas.
Las tarifas de un empleado dependen de la categora que tenga asignada, por lo que se
debe llevar un registro de la categora, el importe de la tarifa y el ao de la asignacin.
Los usuarios responsables podrn consultar los datos de cualquier empleado dado de
alta en la aplicacin, como el nombre, los apellidos y el usuario, as como consultar
las categoras y tarifas de cada empleado.

1.1.2. Mantenimiento de proyectos

La aplicacin les permitir a los usuarios responsables gestionar los proyectos de la
empresa, para activar un nuevo proyecto o modificar uno existente y consultar el
histrico de todos los proyectos.
Cada proyecto tiene un identificador nico que generar la aplicacin
automticamente antes de su almacenamiento. ste identificador estar compuesto
por el ao, cdigo del cliente y un nmero correlativo. No puede haber dos proyectos
con el mismo identificador en el sistema.
La denominacin, plataforma de desarrollo, cliente, fecha propuesta y tipo de
proyecto (interno, externo, facturable, etc.), son datos obligatorios para la activacin
de un nuevo proyecto. Adems de stos datos se pueden aadir otros como la fecha
de aprobacin del proyecto, la fecha prevista para la finalizacin y la fecha de inicio.
4

El nmero de personas se calcular en funcin de los tcnicos que se vayan asignando

al proyecto y el nmero de horas totales en funcin del tiempo que registran estos
ltimos.
La plataforma de desarrollo y el tipo de proyecto se eligen de una lista. Por ello, se
permitir a los usuarios responsables el mantenimiento de las distintas plataformas
de desarrollo utilizadas en la empresa y los tipos de proyecto, accediendo a su
creacin, modificacin y borrado. De cada plataforma o tipo de proyecto se almacena
su cdigo y denominacin.
Ser posible la modificacin de los datos de un proyecto activo en la empresa, aunque
no se permitir modificar su identificador.
Los usuarios con rol responsable podrn consultar los proyectos de la empresa.
Empezando por ver sus datos bsicos (fecha de propuesta, identificador del proyecto,
descripcin, el cliente, la plataforma utilizada y si est finalizado) hasta ver todos los
empleados que participan en su realizacin y los tiempos previamente registrados
por cada empleado.
Les permitir a los usuarios responsables la asignacin de nuevos tcnicos para la
realizacin de un proyecto. En este caso, debe indicar la categora con la que operar
dentro del marco de ese proyecto. Un tcnico puede operar con distintas categoras
dentro del mismo proyecto (Ej.: un empleado puede ser el responsable y analista de
un proyecto).
Los usuarios identificados como tcnicos por la aplicacin, slo tendrn permisos
para acceder a los datos bsicos de un proyecto, por lo tanto, no podrn ver los
empleados asignados ni los tiempos que hayan registrado.

1.1.3. Mantenimiento de tiempos

Ser posible llevar un control de los tiempos que dedican los empleados a cada
proyecto, registrando una pequea descripcin de la tarea realizada, el tiempo
invertido (en horas), adems de la fecha, el nmero de orden y el tipo de trabajo
realizado elegido de una lista. Excepto el tipo de trabajo, todos los datos son
obligatorios para aadir un nuevo registro de tiempo. Los usuarios responsables se
encargan de mantener los distintos tipos de trabajo almacenando su cdigo y
denominacin, que posteriormente podrn modificar o eliminar.
El nmero de orden ser generado automticamente por la aplicacin y depender
del nmero de registros del tcnico para un mismo proyecto.
Slo podrn registrar tiempos en proyectos activos. Estos registros se distinguen por
la fecha, el tcnico y el nmero de orden. Por norma de la empresa a cada tarea se le
debe dedicar como mnimo una media hora.
Cada usuario podr acceder a sus registros de tiempo y modificarlos o proceder a su
borrado si es necesario. No se permite modificar la fecha del registro ni el nmero de

orden. La aplicacin permitir a cualquier usuario registrado la consulta de la fecha, el

proyecto, la actividad realizada y el tiempo invertido (en horas) de todos sus tiempos.

1.1.4. Gestin de gastos

Cada usuario deber registrar sus gastos personales en los que se incurre durante el
ciclo de vida de un proyecto en el que participa.
Podr imputar sus gastos a algn proyecto concreto. De cada gasto se recoge la fecha,
el nmero de orden, el tipo de gasto del que se trata (gastos de hotel, transporte, etc.),
el proyecto y por ltimo el importe y una breve descripcin. No se pueden imputar
gastos a proyectos que se consideran finalizados.
El nmero de orden ser generado automticamente por la aplicacin y depender
del nmero de registro de gastos del tcnico para un mismo proyecto.
El tipo de gasto se elige de una lista que almacena distintos tipos de gastos externos al
proyecto considerados por la empresa. Los usuarios responsables sern los
encargados de mantener esta lista actualizada insertando nuevos registros, y
modificando o eliminando registros de la misma.
Cada usuario tiene total acceso a sus gastos para modificar o eliminar sus registros,
excepto la fecha de creacin de los mismos.
Los usuarios podrn visualizar todos los gastos y consultar su fecha de creacin,
proyecto al que pertenecen, la descripcin y su importe.

1.1.5. Gestin de facturas

Con el fin de llevar a cabo una contabilidad a nivel de aplicacin de algunos de los
gastos generados por los proyectos que se llevan a cabo en la empresa, la aplicacin
deber permitir a los usuarios responsables la facturacin de los gastos imputados a
un proyecto.
En este caso, podrn facturar gastos que hayan registrado e imputado a un proyecto
concreto (de transporte, viajes, etc.). Por otra parte, podrn incluir honorarios, es
decir, gastos generados por el desarrollo del proyecto (horas de programacin,
anlisis, etc.).
Adems del importe total de todos los gastos, cada factura debe incluir un nmero
nico, la fecha de su creacin, el proyecto y el impuesto sobre el valor aadido (IVA)
correspondiente a la operacin
El nmero de una factura ser generado automticamente por la aplicacin y
compuesto por un nmero correlativo dependiente de las facturaciones realizadas al
cliente y el ao en curso.

De los honorarios incluidos en una factura, se recoge la tarea realizada que se elige de
la lista de tipos de trabajo realizado. Se recoge tambin la fecha de registro, el nmero
de horas dedicadas, el tcnico que realiz la tarea, el importe que se calcula a partir de
las horas y la tarifa del tcnico, la factura con la que se relaciona el honorario y una
descripcin ms detallada del trabajo que se ha llevado a cabo. Un usuario
responsable podr acceder al borrado de los honorarios incluidos en una factura.
Se consideran datos obligatorios para la creacin de una factura, su fecha de creacin,
nmero y el proyecto que se est facturando.
Permitir a los usuarios responsables la modificacin y borrado de las facturas que
haya generado anteriormente. No se permite la modificacin del nmero de factura ni
la fecha de su creacin.
Un usuario responsable podr visualizar todas las facturaciones realizadas y ver sus
detalles, as como generar informes con los mismos en formato PDF Los datos que se
pueden consultar de cada factura son: la fecha, proyecto, gastos incluidos, honorarios
y el importe total.

1.1.6. Mantenimiento de los clientes

Permitir a los usuarios responsables mantener todos los clientes relacionados con la
empresa. Mediante esta funcionalidad podrn acceder a la consulta de sus datos,
aadir nuevos clientes en el sistema y modificar sus datos. De cada cliente se recoge
su nombre y direccin.

1.2. Especificacin de los requisitos no funcionales

1.2.1. Requerimientos tecnolgicos
Como tecnologas a utilizar se han sealado las siguientes:

JavaServer Faces, Richfaces y Facelets para la construccin de la interfaz

web.
Hibernate para el mapeo objeto-relacional.
Spring para la integracin de Hibernate y JSF.
MySQL como sistema gestor de bases de datos.

1.2.2. Seguridad
Ser necesario asegurar que las personas ajenas al sistema no puedan acceder a l. Y
para aquellos usuarios que tengan privilegios de acceso, comprobar que lo hacen en
aquellas partes de la aplicacin donde tienen vigencia sus permisos.

1.3. Modelo del dominio

Una vez analizados los requisitos especificados en los apartados anteriores, podemos
modelar una vista esttica del sistema con un diagrama de clases. Se pretende dar una
visin de los conceptos que se manejan en el sistema representados mediante clases
con atributos y las relaciones definidas entre ellas.

1.3.1. Clases identificadas

Proyecto: almacena la informacin referente a un proyecto que se identifica por su
id, denominacin, tipo, plataforma, nmero de personas, total de horas, etc. Cada
proyecto pertenece a un cliente y puede tener varios tcnicos que actan
conjuntamente para su ejecucin.
Factura: almacena todo lo relacionado con una factura que recoge los honorarios y
gastos producidos por un proyecto concreto y la definen su nmero, fecha, importe
total y el IVA.
Honorario: representa un gasto por el desarrollo de un proyecto. Como atributos
de esta clase, se almacena su importe, fecha, concepto, horas y descripcin.
Cliente: esta entidad lgica representa un cliente de la empresa. De cada cliente se
recoge su denominacin, direccin, identificador, cdigo postal, pas, provincia y
municipio.
Tcnico: almacena todo lo relacionado con un empleado de la empresa. Cada
tcnico se identifica unvocamente con su cdigo, nombre, apellidos, usuario,
contrasea, rol (tcnico o responsable) y la fecha de baja. Cada tcnico puede tener
varias categoras asignadas y estar trabajando en varios proyectos a la vez.
Gasto: almacena todo lo relacionado con un gasto, su cdigo, fecha, orden, tipo,
descripcin e importe. Los gastos son registrados por un tcnico e imputados a un
determinado proyecto.
Categora: esta entidad representa una categora con denominacin y cdigo.
TarifaCategoria: relaciona una categora concreta con el importe que se le asigna
durante el ao.
Tiempo: almacena informacin acerca de un registro de tiempo en la aplicacin.
Un tiempo se identifica por la fecha, nmero de orden, descripcin, nmero de
horas, y el tipo de trabajo realizado. Cada registro de tiempo es asignado a un
proyecto y propio de un tcnico.
TipoTrabajo: almacena los distintos tipos de trabajo que se pueden realizar en un
proyecto. Se identifica por su cdigo y denominacin.
TipoGasto: esta entidad representa los distintos tipos de gastos. Se identifica por
su cdigo y denominacin.
8

TipoProyecto: hace referencia a un tipo de proyecto y se almacena su identificador

y denominacin.
Plataforma: esta entidad representa una plataforma de desarrollo utilizada en la
empresa mediante su cdigo y denominacin.

1.3.2. Diagrama de clases

Figura 1: Diagrama de clases del modelo

2. DISEO
2.1. Modelo de datos
Como he comentado en el captulo anterior, parto de una base de datos ya construida,
sobre la cual se apoya la antigua aplicacin web. En este apartado, voy a empezar por
explicar cmo estaba esta base de datos al principio; detallar todos sus defectos as
como las medidas tomadas en el nuevo diseo para subsanarlos.

2.1.1.

Antiguo modelo de datos

El antiguo modelo de datos estaba compuesto por 18 tablas sin ninguna restriccin de
integridad referencial entre ellas, como se puede observar en el diagrama que se refleja
en la Figura 2. Incluso, de forma natural, se podran deducir relaciones N:N entre algunas
de las tablas, relaciones que no estaban definidas. El Gestor de Bases de Datos utilizado
era Oracle.

2.1.1.1. Diagrama

Figura 2: Diagrama del antiguo modelo de datos

10

2.1.1.2.

Entidades

En la siguiente tabla se detallan todas las entidades que forman el antiguo modelo de datos
de la empresa. De cada tabla se incluye el nombre, sus atributos y una breve descripcin
de su contenido.
Tabla
CSIPROCE

Atributos

Descripcin

CSIPLADE

-- Identificador
- Denominacin

-Contiene los datos de las plataformas utilizadas por la

empresa en el desarrollo de los proyectos.

CSITITRA

- Identificador
- Denominacin

Contiene los datos de los posibles tipos de trabajo que

realizan los empleados.

CSITECNI

- Identificador
- Nombre

En esta tabla se almacenan los datos de los empleados

de la empresa.

CSICATEG

- Cdigo
- Denominacin

Contiene los datos de las categoras que pueden

adquirir los empleados.

- Identificador
- Denominacin

En esta tabla se almacenan los tipos de proyecto

considerados por la empresa.

-- Cdigo del tcnico

- Ao
- Cdigo de la categora

-Contiene informacin de
categoras a los empleados.

- Cdigo de la categora
- Ao
- Importe.

Se almacena informacin referente a las categoras y

sus tarifas.

CSITEPRO

- Cdigo del tcnico

- Cdigo del proyecto
- Cdigo de la categora

Esta tabla relaciona un tcnico con un determinado

proyecto y una categora.

CSIEMPOR

--

--

CSITIPRO
CSIESTPR
CSICATEC
CSITARCA

CSIUSAUT

CSITIEMP

Identificador
Contrasea
Tipo
Cdigo del tcnico

Identificador
Fecha
Nmero
Cdigo del proyecto
Descripcin
Nmero de horas
Cdigo del tipo de
trabajo

las

asignaciones

de

Almacena la informacin de acceso de los usuarios de

la aplicacin.

Almacena las actividades que realizan y registran los

tcnicos.

11

CSIGASTO

CSICONTA

CSIORGAN

CSIFACTU

CSISEPRO

Cdigo del tcnico

Fecha
Nmero
Tipo de gasto
Cdigo de proyecto
Importe
Descripcin
--

Identificador
Denominacin
Direccin
Cdigo Postal
Municipio
Provincia
Pas

Identificador
Nmero
Cdigo proyecto
Nmero de horas
facturadas
Importe de honorarios
Importe de gastos
IVA
Identificador
Denominacin
Organismo (cliente)
Cdigo plataforma
Cdigo tipo proyecto
Nmero de empleados
Nmero de horas
Fecha de propuesta
Fecha de aprobacin
Fecha de inicio
Fecha fin prevista
Honorarios
Gastos
Responsable del
proyecto

Recoge toda la informacin relacionada con un gasto

generado durante la vida de un proyecto.

--

Esta tabla almacena la informacin de los clientes con

los que interacta la empresa.

Recoge la informacin de las facturas.

Almacena todo lo referente a los proyectos.

Tabla 1: Entidades del antiguo modelo

2.1.1.3.

Deficiencias

El primer defecto que presenta este modelo radica en la ausencia de relaciones entre las
distintas tablas que componen el mismo.
La presencia de algunas tablas que realmente no se utilizan por la aplicacin y tampoco
son necesarias para llevar a cabo otras funciones.
En la tabla de las facturas (CSIFACTU) se recoge un importe de gastos, lo que puede
suponer interpretaciones errneas sobre su origen. Lo mismo sucede con el importe de los
honorarios.
12

En la tabla de los proyectos (CSISEPRO) se recoge el nmero de tcnicos que participan en

el desarrollo del proyecto y el nmero total de horas dedicadas al mismo, atributos
innecesarios sabiendo que se pueden calcular mediante las relaciones que debe tener esta
tabla con CSITIEMP y CSITEPRO.
Siguiendo en la misma tabla y, ms concretamente, con el atributo responsable del
proyecto (SPRESP), el antiguo diseo obliga a que el responsable de un proyecto sea
siempre una misma persona, el ltimo empleado que se le asign como responsable.
Teniendo en cuenta que un empleado puede abandonar la empresa o ser despedido de su
cargo, el antiguo diseo dejara los datos del proyecto en una situacin que no
corresponde con la realidad.

2.1.2. Modelo de datos actual

Para el nuevo modelo de datos, se han tenido en consideracin todas las tablas del antiguo
modelo, exceptuando CSIPROCE, CSIESTPR, CSIEMPOR y por ltimo CSICONTA. Dado que la
informacin almacenada en dichas tablas no aporta ningn tipo de beneficio al nuevo
sistema que se desea desarrollar.

2.1.2.1.

Requisitos

En este apartado se recogen los requisitos que debe cumplir la nueva base de datos,
tomando como punto de partida la antigua de Oracle. Por ello, no se realiza un diseo
conceptual completo del dominio, sino que se asume el esquema lgico heredado,
amplindolo o modificndolo segn los nuevos requisitos.
Estos son los requisitos ms relevantes tomados en cuenta en el proceso de diseo del
nuevo modelo:

A la empresa le interesa recoger adems del nombre de sus empleados, sus

apellidos y la fecha en la que fueron dados de baja.

La empresa registra todos los tiempos dedicados por los empleados, aunque
posteriormente procede a facturarlos resumidos por tcnico y actividad. Para ello,
se desea llevar un control de los honorarios facturados en un proyecto por los
trabajos realizados en el mismo.

En las facturas pueden optar por incluir varios gastos que se hayan generado
durante la realizacin de un proyecto.

En la antigua aplicacin web, en los formularios se introducen a mano tanto el pas

como la provincia y la localidad del cliente. Para ahorrar este trabajo y reducir la
probabilidad de introducir errores optan por crear tres nuevas tablas que recogen
los pases, provincias y localidades.

13

2.1.2.2.

Migracin de Oracle a MySQL

Una vez realizados todos los cambios necesarios comentados en el apartado anterior y
establecidas las relaciones entre las distintas tablas que componen el nuevo modelo, se
migraron los datos de la antigua base de datos de Oracle a la nueva de MySQL. El proceso
de migracin consisti en adaptar los datos del antiguo modelo con la ayuda de un
programa disponible en la empresa, que genera los Script para la poblacin de la nueva
base de datos. De esta tarea se encarg Eduardo Fras Lara (mi tutor en la empresa).

2.1.2.3.

Diagrama

En este diagrama se muestran todas las relaciones introducidas en el nuevo modelo, as

como las nuevas tablas y los atributos que se han aadido o eliminado en su caso.
Las tablas que se han agregado al nuevo modelo de datos, que son: CSITIGAS, CSIGAFAC,
CSIHONOR, CSILOCAL, CSIPROV, CSIPAIS y estn resaltadas en color gris en la Figura 1.2 que
representa el diagrama Entidad Relacin del modelo actual con todas las modificaciones
que se han introducido, mientras que las tablas que estn en color azul son las que ya
existan, aunque con algunas modificaciones que se comentan en el apartado 1.2.4.

Leyenda de smbolos del diagrama:

Smbolo

Significado
Indica que el atributo forma parte de una clave primaria.
Indica que el atributo forma parte de una clave alternativa (Unique).
Indica que el atributo es una clave fornea que referencia otra tabla.
Indica que el atributo forma parte de un ndice de la base de datos.
Indica el sentido de una relacin entre dos tablas y el atributo que
referencia a la segunda tabla.
El atributo que tiene este smbolo significa que se referencia por otra(s)
tabla(s).
Este smbolo slo o combinados con otros, indica que el atributo no
puede ser NULL.
Indica que la tabla que est en este extremo participa con varios en la
relacin.
Indica que la tabla que se encuentra en este extremo participa con uno
en esta relacin.
Tabla 2: Leyenda de smbolos del diagrama ER

14

Figura 3: Diagrama del modelo de datos actual

15

2.1.2.4.

Diferencias respecto del antiguo modelo

Aadir la tabla CSITIGAS que almacena los distintos tipos de gasto en los que puede
incurrir la empresa durante el desarrollo de sus proyectos, y relacionarla con la tabla
CSIGASTO.

Dado que una factura puede tener ninguno o varios gastos asignados. He aadido la
tabla CSIGAFAC que relaciona y agrega un gasto (CSIGASTO) a una factura (CSIFACTU).

Aadir las nuevas tablas que recogen la informacin de localidad (CSILOCAL), provincia
(CSIPROV) y pas (CSIPAIS). Con el objetivo de facilitar el proceso de introduccin de
datos.

Aadir la tabla CSIHONOR con los atributos cdigo, tcnico, concepto, factura, fecha,
nmero de horas facturadas y una breve descripcin de la tarea llevada a cabo. Esta
tabla almacena los trabajos realizados por los empleados y facturados para un
proyecto en concreto.

Eliminar los atributos nmero de personas y nmero de horas en la tabla (CSISEPRO)

ya que son valores que pueden ser calculados a partir de otras tablas (CSITIEMP y
CSITEPRO).

Eliminar el atributo (SPRESP) que representa a la persona responsable del proyecto.

En el nuevo modelo el responsable del proyecto se asigna en la tabla (CSITEPRO) con la
nueva categora Responsable de proyecto.

Dado que los nicos usuarios de la aplicacin sern empleados de la empresa (tcnicos
o responsables) se elimina la tabla (CSIUSAUT), ya que la relacin que guarda con la de
tcnicos es uno a uno; y pasan sus atributos a formar parte de la tabla (CSITECNI). De
esta forma cualquier empleado dispondr de una clave y un nombre de usuario para
acceder a la aplicacin.

Almacenar las claves de los tcnicos encriptadas en la base de datos usando el

algoritmo SHA-1.

Para evitar eliminar los datos de los tcnicos y as perder informacin relacionada con
los mismos, y tambin mantener un control de los que estn activos o no, he aadido la
fecha de baja en la tabla (CSITECNI) que indica si un tcnico est dado de baja o no.

En la tabla (CSIFACTU) se eliminan los atributos honorarios y gastos,

reemplazndolos con relaciones con las tablas (CSIHONOR) y (CSIGAFAC). Por otro lado,
se aade un atributo Total que recoge el importe total de la factura.

Podemos observar que en todas las tablas se introdujo un identificador cdigo como
clave primaria, aunque en algunas no hace falta. Todo ello fue para adaptar el nuevo
modelo al uso que se har de l, ms concretamente en el Mapeo Objeto Relacional (ORM)
en el que se usar Hibernate.
Este ltimo gestiona las claves primarias compuestas como una clase aparte, algo que
puede dificultar nuestro problema an ms. Por ello, he tomado la decisin de crear
identificadores autoincrementales y gestionar las operaciones que se realizan sobre la
base de datos con la ayuda de las claves candidatas.
16

2.2. Arquitectura software

La aplicacin utiliza una arquitectura cliente/servidor de n-capas, lo que significa que se
modela como un servicio que es proporcionado por un servidor y un conjunto de clientes
que usan dicho servicio.
La arquitectura n-capas, en este caso de tres capas, significa que cada capa se construye
en trminos de los que tiene por debajo y proporciona una base de implementacin para
aquellas que tiene por encima.
Spring Framework proporciona una implementacin del patrn Modelo Vista
Controlador. Este patrn separa los datos de una aplicacin de la interfaz de usuario y de
la lgica de negocio, lo que reduce el impacto sobre el resto de componentes en caso de
introducir cambios.
En este caso, los componentes del patrn MVC sern:
-

Modelo: estar formado por los Java Beans de JSF.

Vista: las vistas JSF en formato XHTML para mostrar las interfaces de usuario.

Controlador: las clases Controller de Spring que se encargan de recoger los datos
introducidos por el usuario y pasarlos a la capa de lgica de negocio y
posteriormente redireccionar los resultados obtenidos hacia otras pginas JSF.

2.2.1. Capa de presentacin

Esta capa proporciona una interfaz visual con la que interactan los usuarios de la
aplicacin. Se encarga de mostrar los datos, recoger las entradas de usuario, validarlas y
delegar su procesamiento en la capa de lgica de negocio.
Esta capa est formada por las paginas JSF que se corresponden con la Vista del patrn
Modelo Vista Controlador (MVC) y las clases Controller de Spring, que como su nombre
indica, juegan el papel del Controlador en MVC.
Las tecnologas elegidas para esta capa son JavaServer Faces y Richfaces para los
componentes de la interfaz, Facelets para construir rboles de componentes y por ltimo
Spring Framework en los controladores.

2.2.2. Capa de lgica de negocio

Esta capa hace de puente entre la capa de persistencia y los controladores Spring. Sus
objetos no slo tienen datos, tambin la lgica asociada a esos objetos especficos.
La tecnologa utilizada, al igual que en la capa de presentacin, es Spring Framework para
denotar todas las clases de esta capa como servicios de aplicacin con la anotacin
@Service. Las clases de esta capa forman parte del componente Modelo del patrn MVC.

17

2.2.3. Capa de persistencia

La capa de acceso a datos se encarga de realizar las cuatro operaciones bsicas sobre una
base de datos: insercin, modificacin, consulta y borrado. Para ello, usar Spring
Framework basado en Hibernate. Las clases de esta capa junto con la anterior forman
parte del componente Modelo del patrn MVC.
En esta capa emplearemos el patrn DAO (Data Access Object) para abstraer y encapsular
los accesos a la base de datos y manejar la conexin con la fuente para obtener o
almacenar datos.
El DAO implementa el mecanismo de acceso requerido para trabajar con la base de datos,
aunque oculta los detalles de implementacin a sus clientes.

Figura 4: Diagrama de algunas clases de persistencia

Normalmente en esta capa se implementan las cuatro operaciones bsicas (CRUD) para
cada una de las clases, lo que hace que el cdigo escrito para una se repita tantas veces
como clases tenga esta capa. Para evitar que esto ocurra voy a trabajar con un DAO
genrico y abstracto, de manera que cada clase que extiende este DAO no tendr la
obligacin de volver a reescribir el cdigo de estas operaciones. Todas las clases de esta
capa se denotan por la anotacin @Repository de Spring.
De esta manera cada DAO accede a las operaciones bsicas definidas en el DAO genrico,
como se observa en la siguiente figura; pudiendo implementar otras especficas.

Los DAOs se declaran con Scope Singleton que asegura que slo exista una instancia de
este bean por el contenedor de Spring. Este ltimo crea una instancia nica de todos los
DAOs y cada vez que recibe una llamada para obtener ese bean, responde con la misma
instancia.
18

Figura 5: Comunicacin entre DAOs

2.2.4. Comunicacin entre las capas

Para ver cmo sera la comunicacin entre las distintas capas de la aplicacin, vamos a
ceirnos a una funcionalidad concreta, que en este caso sera aadir un nuevo proyecto.
En primer lugar se enva una solicitud para aadir un nuevo proyecto, una vez que se
validen todos los datos del proyecto introducidos por el usuario; el controlador
(Controlador de Proyectos) recibe dicha solicitud y acta en consecuencia usando los
servicios de la lgica de negocio (Servicio de Proyectos) que a su vez aade toda la lgica
necesaria al objeto, realiza las comprobaciones que proceden y delega el resto de la tarea
en la capa de persistencia (DAO de Proyectos) para que se encargue de su almacenamiento
en la base de datos.
El DAO de proyectos inserta el proyecto o lanza la excepcin oportuna a la capa
inmediatamente superior que a su vez comunica sus resultados al controlador. Este ltimo
realiza una consulta en el fichero de configuracin para redireccionar la solicitud a la vista
adecuada.

19

Figura 6: Flujo de aadir nuevo proyecto

2.3. Interfaces de usuario

Las interfaces de usuario son el elemento principal para la comunicacin entre los
usuarios y aplicacin. En el desarrollo de esta aplicacin, el diseo de la interfaz no fue
uno de los principales puntos de atencin ya que muchos de los componentes de la
interfaz vienen determinados por Richfaces.
En las siguientes figuras se mostrarn las decisiones tomadas para el diseo de las
interfaces de usuario.

2.3.1. Interfaz de login

En esta primera pantalla se recogen los datos necesarios de autenticacin;
usuario y contrasea del usuario.

20

Figura 7: Prototipo de la interfaz de login

2.3.2. Partes fijas de la interfaz

Exceptuando la primera pgina de login, todas las dems pginas a las que puede
acceder el usuario estarn compuestas por cuatro elementos fijos: men, cabecera,
cuerpo y pie de pgina como se puede observar en la Figura 1.6.

El men: en esta parte de la pgina se mostrarn las distintas opciones a las

que puede acceder el usuario. Si se trata de un usuario responsable; las
opciones el men sern ms diversas que en el caso de un tcnico.

Cabecera: compuesta por el ttulo de la pgina, el nombre del usuario en

sesin y otras opciones como cambiar su clave y salir de la aplicacin.

Imagen: con el logotipo de la empresa Suma Info S.L.

Pie de pgina.

Figura 8: Prototipo del esqueleto general

21

2.3.3. Interfaz de pginas con listado

En todas las opciones que puede elegir el usuario, la primera pgina que se
muestra es un listado de todos los elementos donde puede consultar la
informacin bsica, crear nuevo, editar o eliminar algn elemento del listado.

Figura 9: Prototipo de pginas con listado

2.3.4. Interfaz de pginas con formulario

En las pginas donde se espera recibir datos nuevos o modificarlos se muestra un
formulario con los componentes necesarios en cada caso para la recogida de los
datos introducidos por los usuarios.

Figura 10: Prototipo de pginas con formulario

22

3. IMPLEMENTACIN
3.1. Tecnologas empleadas
3.1.1. Maven
Utilizado para crear la estructura de directorios del proyecto. Tambin se encarga de
descargar las dependencias que se indican en el fichero pom.xml (libreras usadas en el
proyecto) as como las dependencias de estas ltimas.
Maven utiliza una matriz de repositorios remotos que le permite localizar y descargar todo
lo necesario para generar el proyecto. Adems de estos repositorios remotos tambin
existe uno local que utiliza Maven como cach evitando la descarga en las siguientes
generaciones del proyecto y as reducir el tiempo que supondra volver a descargarse
todas las libreras de Internet.
En la siguiente imagen se pueden intuir grficamente todas las dependencias del proyecto
csi_sumainfo, algunas son directas y otras indirectas.

Figura 11: Dependencias del proyecto

23

3.1.2. Hibernate
Es el Framework para el mapeo Objeto Relacional. Para llevar a cabo este proceso he
utilizado anotaciones en las entidades, con ello, voy a conseguir convertir los tipos de Java
a los definidos en la base de datos MySQL y viceversa, sin preocuparme de cmo lo
gestiona Hibernate internamente. Una de las ventajas que ofrece esta tecnologa es su
lenguaje de consultas HQL (Hibernate Query Lenguage) el cual es ms orientado a objetos.
Spring Framework nos provee de una clase plantilla llamada HibernateTemplate que nos
asegura que las sesiones sean abiertas y cerradas automticamente y hace que nuestras
llamadas participen en transacciones.
En mis DAOs voy a tener acceso directo a esta clase mediante el mtodo que heredan al
extender de la clase abstracta HibernateDaoSupport.
Para la integracin de Spring con Hibernate hay que definir el Session Factory de
Hibernate para el manejo de sesiones. En esta configuracin utilizaremos una clase que
contiene Spring en su mdulo ORM para la integracin con Hibernate:
<bean id="sessionFactory"
class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="configurationClass"
value="org.hibernate.cfg.AnnotationConfiguration" />
<property name="configLocation">
<value>classpath:${hibernate.cfg.file}</value>
</property>
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">${hibernate.dialect}</prop>
</props>
</property>
<property name="packagesToScan">
<list>
<value>com.sumainfo</value>
</list>
</property>
</bean>

HQL (Hibernate Query Lenguage):

Es un lenguaje propio de Hibernate, como su nombre indica. Es muy parecido a SQL, sin
embargo, HQL es completamente orientado a objetos y comprende nociones como
herencia, polimorfismo y asociacin. Es sensible a las maysculas y minsculas.
Ejemplo de consulta con HQL:
String consulta = "SELECT c FROM Factura c WHERE c.proyecto.organismo.codigo = ?";

Como podemos ver, la consulta se realiza sobre el objeto Factura y no se realiza sobre la
tabla CSIFACTU. Su manera peculiar de acceder a los atributos de la clase que no son
atributos de una tabla. Cabe mencionar tambin que HQL permite realizar consultas
parametrizadas.
En este proyecto, y aunque Hibernate ofrece la posibilidad de trabajar con SQL como
lengua de consultas, he optado por utilizar HQL debido a las mltiples ventajas que ofrece
frente al primero.

24

3.1.3. Richfaces
Utilizado en la construccin de las vistas junto con los componentes JSF. Richfaces permite
definir por medio de etiquetas de JSF diferentes partes de una pgina que se desea
actualizar con una solicitud AJAX y sincronizar automticamente con el rbol de
componentes JSF sin tener que recargar toda la pgina Web. Proporcionando as varias
opciones para enviar peticiones AJAX al servidor.
Re-Rendering:
Un atributo clave de Richfaces es reRender que permite indicar una zona en la pgina
que debera ser actualizada como respuesta a la interaccin AJAX. El valor de este atributo
debe ser un identificador de un componente JSF o una lista de identificadores.
En

el

ejemplo

siguiente

se
indica
que
los
componentes
JSF
nueva,tablaCategorias,nuevaTarifa son re-renderizables, incluyndose a continuacin,
como ejemplo, el componente tablaCategorias:
<a4j:commandButton value="Guardar" styleClass="boton"
action="#{controladorCategorias.insertarCategoria}"
reRender="nueva,tablaCategorias,nuevaTarifa" />

<rich:extendedDataTable selectionMode="single" id="tablaCategorias" >

Richfaces tambin permite organizar el flujo de una pgina dentro del componente
<a4j:include>. Gracias a este componente podemos sustituir el contenido de una pgina
por otro. El contenido se toma de la vista obtenida de la regla de navegacin definida en el
fichero de configuracin faces-config.xml.
En la pgina de clientes se incluye en primer lugar el listado de los clientes definido en la
vista listado.xhtml. Si el usuario accede a la opcin de crear o modificar un cliente, se
aade automticamente el cdigo de la vista que procede en cada caso, reemplazando de
esta manera el listado anterior.
<a4j:include viewId="/pages/clientes/listado.xhtml" ajaxRendered="true"/>

3.1.4. Facelets
Es un Framework para plantillas centrado en la tecnologa JSF, por lo que se integran de
manera muy fcil. Con el uso de Facelets podemos definir vistas para reutilizar varias
veces sin necesidad de volver a copiar el cdigo. Tambin permite el paso de parmetros
entre distintas vitas.
Mediante su componente <ui:composition> podemos envolver un conjunto de
componentes (JSF y Richfaces) para definir el contenido de una parte de la vista que
posteriormente se podr incluir en otras pginas en el componente <ui:include>, como
pueden ser el pie de la pgina, la cabecera y el men entre otros.

25

Por ejemplo, la definicin del pie de pgina utilizado en el desarrollo de las vistas JSF,
definido en el fichero footer.xhtml:
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:a4j="http://richfaces.org/a4j"
xmlns:rich="http://richfaces.org/rich">
<rich:spacer width="50%" />
<h:outputText value=" 2013 - Suma Info S.L." style="font-size:
12px;color: #620f0f"/>
</ui:composition>

Esto hace posible la reutilizacin de este fragmento de cdigo en varias pginas como
sigue:
<f:facet name="footer">
<ui:include src="/pages/includes/footer.xhtml" />
</f:facet>

3.1.5. Spring
Est basado en un conjunto de mdulos que proporcionan todo lo necesario para
desarrollar una aplicacin empresarial. Su componente principal consiste en un contendor
de Beans que permite, mediante Inversin de Control (IoC), gestionar las instancias as
como su creacin y destruccin. Los componentes slo se encargan de declarar las
dependencias que necesitan y el contenedor se encarga de inicializar los componentes
necesarios antes de inyectar su referencia a quien la necesite.
La directiva @Autowired utilizada en el proyecto, inyecta las dependencias en Spring
buscando dentro del contexto un bean cuya clase coincide con el tipo de la variable. Para el
mismo propsito tenemos tambin a @Inject y @Resource.
Ejemplo de uso de la anotacin @Resource en el controlador de acceso para cargar el
AuthenticationManager declarado en el fichero de spring-security.xml:
@Resource(name = "authenticationManager")
private AuthenticationManager authenticationManager;

Ventajas que aporta Spring:

-

Manejo de transacciones.
Integracin con Hibernate.
Seguridad declarativa mediante anotaciones.

3.1.6. Informes con Jasperreports

Es una tecnologa opensource que he utilizado en este proyecto para generar los
informes de facturas. Permite generar informes en mltiples formatos; CVS, XML, TXT,
HTML, XLS y otros ms.
26

En Jasperreports los informes se definen en un fichero XML, el cual ser compilado por las
libreras Jasperreports y generar un fichero con la extensin .jasper que se utiliza para
rellenar y mostrar los informes finales.
En este caso utilic Ireport para generar las plantillas de los informes y compilarlos antes
de ser usados por la aplicacin. En estas plantillas se definen los datos, dnde y cmo se
van a incluir. Estos datos se obtienen mediante una conexin a la base de datos.

Figura 12: Plantilla jrxml de facturas

En esta aplicacin, la clase InformesService es la que se encarga de generar los informes

con su mtodo generaInforme. El cdigo de este mtodo se puede resumir de la siguiente
manera:
1) Prepara el canal de salida:
En el siguiente cdigo obtengo el canal de salida para enviar la respuesta al
usuario, aadindole todas las cabeceras necesarias:
HttpServletResponse response = (HttpServletResponse)
faces.getExternalContext().getResponse();
out = response.getOutputStream();
response.setContentType("application/pdf");
String nombreFichero = "Informe_facturas";
response.setHeader("Content-Disposition", "attachment; filename=\"" +
nombreFichero + ".pdf\"");

2) Genera el informe:
En esta parte, genero el informe tomando como base el archivo (plantilla
compilada) reporte.jasper, los parmetros, que en este caso no hay ninguno y la
conexin JDBC para obtener los datos.
if (params == null) {
params = new HashMap<String, Object>();
}
reportStream = faces.getExternalContext().getResourceAsStream(DIRECTORIO_FACTURAS
+ "reporte.jasper");
JasperPrint print = JasperFillManager.fillReport(reportStream, params,
connection);

27

3) Exporta el informe al canal de salida:

Una vez generado el informe, lo exporto con la clase JRExporter de la librera
Jasperreports en formato PDF, en este caso. As mismo, le paso como parmetros el
nombre que le voy a dar al fichero, el canal de salida (out) y el informe generado
en el punto anterior (print).
JRExporter exporter = new JRPdfExporter();
exporter.setParameter(JRExporterParameter.OUTPUT_FILE_NAME,
nombreFichero+".pdf");
exporter.setParameter(JRExporterParameter.OUTPUT_STREAM, out);
exporter.setParameter(JRExporterParameter.JASPER_PRINT, print);
exporter.exportReport();

3.2. Validacin y conversin

El ciclo de vida de una peticin JavaServer Faces es similar al de una pgina JSP; el cliente
realiza una peticin de la pgina y el servidor responde con la pgina traducida a HTML.
Sin embargo, y debido a las caractersticas extras que ofrece la tecnologa JSF, este ciclo de
vida proporciona algunos servicios adicionales mediante la ejecucin de algunos pasos
extras.
Para entender mejor el ciclo de vida de una pgina JSF, quiz nos sirva de ayuda el
siguiente diagrama, donde se reflejan los pasos desde que se pide una pgina hasta que se
recibe una respuesta:

Figura 13: Ciclo de vida JSF

Uno de los puntos dbiles de la antigua aplicacin de control de proyectos de la empresa

se encontraba en la conversin y validacin de los datos introducidos por los usuarios. En
algunos casos, permita incluso la insercin de cadenas vacas cuando se requera un valor.
JSF nos proporciona dos mecanismos que nos ayudan a validar los valores que introduce
el usuario a la hora de enviar los formularios.
28

El primer mecanismo es el de conversin (segunda fase en el ciclo de vida JSF) y est

definido por el interfaz javax.faces.convert.Converter y sus implementaciones. Las
conversiones nos aseguran que el tipo de un dato introducido en un formulario JSF sea el
correcto o el esperado por la aplicacin. JSF invoca a los conversores (de por defecto o los
creados por el usuario) antes de efectuar las validaciones. En caso de que un tipo
introducido no se corresponda con el tipo Java apropiado, el conversor lanzar una
excepcin de conversin.
La librera Core de JSF incluye elementos bsicos para la generacin de una vista y
tambin incluye otros especiales conocidos como validadores y conversores que permiten
realizar validaciones y conversiones de datos.
Algunas de los conversores que se han utilizado en la implementacin de la capa de
presentacin son:
1) NumberConverter: en la conversin de nmeros, porcentajes y monedas.
Monedas: <f:convertNumber type="currency" locale="es_ES" />
Nmeros: <f:convertNumber />
2) DataTimeConverter: para convertir y mostrar las fechas en el formato deseado.
Ejemplo: <f:convertDateTime pattern="dd/MM/yyyy" />

El segundo mecanismo es el de validacin y se encuentra en la tercera fase del ciclo de

vida JSF. Est definida por el interfaz javax.faces.validor.Validator y sus implementaciones.
En esta fase, JSF examina los atributos del componente que especifican las reglas de
validacin y compara esas reglas con el valor local almacenado en el componente. Si el
valor no es vlido JSF aade un mensaje de error al FacesContext y avanza el ciclo de vida a
la fase de renderizar la respuesta para que la pgina sea dibujada de nuevo incluyendo los
mensajes de error.
En este proyecto, he realizado las validaciones usando los componentes de la librera Core
de JSF en combinacin con Hibernate y el componenete ajaxValidator de Richfaces, que
permite validar datos en el lado del cliente.
Ejemplo:
<h:inputTextarea id="descripcion" rows="7"
value="#{controladorTiempos.tiempo.descripcion}" required="true"
requiredMessage="La descripcin es requerida.">
<rich:ajaxValidator event="onblur" />
</h:inputTextarea>

29

3.3. Seguridad
Uno de los aspectos ms importantes que se han tenido en cuenta a la hora de desarrollar
esta aplicacin fue la seguridad. Entendiendo como tal la necesidad de saber que el
usuario es quien dice ser (autenticacin), y permitirle acceso slo a aquellos recursos
necesarios (autorizacin). Spring Security proporciona la funcionalidad necesaria para
adaptar los mecanismos de seguridad en aplicaciones Java utilizando caractersticas de
programacin orientada a aspectos.

3.3.1. Autenticacin
Consiste en determinar quin desea hacer uso del sistema y comprobar que es quien dice
ser. En Spring Security el AuthenticationManager es el encargado de validar la
combinacin nombre de usuario y contrasea, devolviendo los roles asociados a dicho
usuario.
La configuracin del AuthenticationManager se realiza en el fichero de configuracin de
spring-security.xml.
El elemento <authentication-manager> registra un gestor de autenticacin. En concreto
registra una instancia de ProviderManager, un gestor de autenticacin que delega su
responsabilidad en uno o ms proveedores de autenticacin.
Spring Security incluye la posibilidad de obtener los usuarios y permisos utilizando
ficheros XML, bases de datos JDBC, LDAP o simplemente declararlos en el fichero de
configuracin (spring-security.xml).
En esta aplicacin y para evitar que Spring acceda directamente al contenido de la base de
datos, he configurado un servicio mediante la implementacin del interfaz
UserDetailsService. Este interfaz describe un objeto que realiza el acceso a los datos con un
nico mtodo loadUserByUsername y devuelve un objeto de tipo UserDetails construido a
partir de los datos obtenidos, en caso contrario lanza una excepcin de tipo
UsernameNotFoundException. He aqu el cdigo del mtodo:
public UserDetails loadUserByUsername(String username) throws
UsernameNotFoundException, DataAccessException {
UserDetails user = null;
try {
Tecnico tecnico = tecnicoDAO.tecnicoByUser(username);
if (tecnico == null) {
throw new UsernameNotFoundException(username + " no encontrado");
}else{
// Se construye un nuevo usuario con los datos del tcnico obtenido
user = new User(tecnico.getUsuario(), tecnico.getClave(),
tecnico.isEnabled(),
tecnico.isAccountNonExpired(), tecnico.isCredentialsNonExpired(),
tecnico.isAccountNonLocked(), tecnico.getAuthorities()
);
}
} catch (PersistenciaException ex) {
Logger.getLogger(DetallesUsuarioService.class.getName()).log(Level.SEVERE,
null, ex);
}
return user; }

30

Y en el fichero de configuracin spring-security.xml:

Declaracin del servicio de autenticacin:
<beans:bean id="detallesUsuarioService"
class="com.sumainfo.servicios.DetallesUsuarioService" />

Declaracin del PasswordEncoder:

<beans:bean id="passwordEncoder"
class="org.springframework.security.authentication.encoding.MessageDigestPassw
ordEncoder">
<beans:constructor-arg value="SHA-1"/>
</beans:bean>

Declaracin del AutheticationManager:

<authentication-manager alias="authenticationManager">
<authentication-provider user-service-ref="detallesUsuarioService">
<password-encoder ref="passwordEncoder"/>
</authentication-provider>
</authentication-manager>

Al proveedor de autenticacin se le especifica un PasswordEncoder con el algoritmo de

encriptacin SHA-1, que utiliza para realizar la comprobacin de las contraseas, ya que
stas se guardan encriptadas en la base de datos.
El proceso de autenticacin en esta aplicacin se define como sigue:
El usuario introduce sus datos en el formulario de la pgina de login (entrada.xhtml) y
pulsa el botn acceder. Esta peticin la procesa el Controlador de acceso de la aplicacin,
que define un mtodo de login. En este mtodo se construye un
UsernamePasswordAuthenticationToken con las credenciales del usuario (clave y nombre
de usuario), que se le pasan al AuthenticationManager de la aplicacin para su
autenticacin.
El AuthenticationManager se declara como una dependencia del Controlador de acceso, es
decir, Spring buscar dentro del contexto una variable con el nombre
"authenticationManager y encontrar el declarado con el mismo alias en el fichero de
configuracin spring-security.xml.
@Resource(name = "authenticationManager")
private AuthenticationManager authenticationManager;

Las decisiones tomadas por el AuthenticationManager en esta aplicacin para permitir el

acceso al usuario, entre otras cosas, se basan en el campo de fecha de baja del usuario. De
tal modo que un usuario que haya sido dado de baja con anterioridad al proceso de
autenticacin, su acceso ser rechazado por la aplicacin.

31

Si el proceso de autenticacin es exitoso, se construye un objeto de tipo Authentication con

los datos del usuario y se pone en el contexto de Spring Security:
SecurityContextHolder.getContext().setAuthentication(authenticate);

En la pgina entrada.xhtml de login, interesa que la solicitud se haga bajo el protocolo http
seguro ya que en ese formulario viaja la contrasea del usuario. Para ello, forzamos el uso
de https en la configuracin de Spring Security:
<intercept-url
pattern="/pages/entrada.xhtml"
channel="https"/>

access="permitAll"

requires-

De esta forma, cada vez que se produce una solicitud con formato /pages/entrada.xhtml,
Spring Security va a detectar que se requiere el uso del canal https y va a redirigir la
solicitud de forma automtica a travs de https.

Figura 14: Proceso de autenticacin en Spring Security

32

3.3.2. Autorizacin
Una vez finalizado el proceso de autenticacin del usuario, entra en juego la parte del
sistema encargada de la autorizacin, con el fin de permitir que ste acceda slo a aquellos
recursos a los que tiene permiso. Para ello Spring Security intercepta todas las peticiones
http utilizando filtros y acta en consecuencia.
El acceso a un recurso no permitido puede acabar lanzando una excepcin de tipo
AccessDeniedException.
Para dejar el acceso a los recursos bien delimitado para cada rol de esta aplicacin, he
configurado en el fichero spring-security.xml los siguientes permisos:
1) PermitAll: para aquellos recursos a los que tienen acceso todos los usuarios
(autenticados o no), por ejemplo la pgina de login:
<intercept-url pattern="/pages/entrada.xhtml" access="permitAll" />

2) isAuthenticated(): para recursos a los que pueden acceder usuarios autenticados

por la aplicacin, por ejemplo la carpeta de los informes:
<intercept-url pattern="/WEB-INF/informes/**" access="isAuthenticated()"/>

3) hasRole(el_rol): para aquellos usuario con el rol definido por la cadena el_rol.
Ejemplo, el contenido de la carpeta de facturas:
<intercept-url pattern="/pages/facturas/**" access="hasRole('R')"/>

4) hasAnyRole(lista_de_roles): son recursos a los que pueden acceder todos los

usuarios con alguno de los roles contenidos en la lista lista_de_roles. Ejemplo, el
contenido de la carpeta de tiempos:
<intercept-url pattern="/pages/tiempos/**" access="hasAnyRole('R','T')"/>

En caso de que se produzca una excepcin AccessDeniedException el usuario ser

redireccionado a la pgina principal.
<http auto-config="true" use-expressions="true" access-denied-page="/pages/index.xhtml">

33

3.4. El proceso de trabajo

En la figura 15 vemos las fases por las que pasa una peticin para ser procesada por la
aplicacin, donde se encuentran las validaciones de los datos en primera lugar. Una vez
superadas estas ltimas, acta el controlador pertinente que pasa los datos a un servicio
de la capa de lgica de negocio para realizar las comprobaciones y aadir la lgica
necesaria a los objetos antes de llamar al DAO o conjunto de DAOs, para ejecutar las
sentencias contra la base de datos.

Figura 15: Proceso de trabajo en la aplicacin

Para ver ms en detalle este proceso de trabajo, y siguiendo con la funcionalidad de

aadir un nuevo proyecto explicada en el captulo de diseo, veamos los pasos seguidos
desde que empieza el proceso, cuando el usuario introduce los datos del proyecto, hasta
que finaliza almacenndolo en la base de datos.

3.4.1. La vista JSF

En la vista JSF con formato XHTML se encuentran todos los componentes necesarios para
la recogida de los datos del proyecto as como su validacin y conversin. Por una parte
estn los datos obligatorios y por otra los opcionales:
1) Datos obligatorios: la denominacin, plataforma de desarrollo, cliente, el tipo de
proyecto y la fecha de propuesta del mismo. Todos estos elementos se denotan por
el atributo required a true, para indicar que son obligatorios. Tambin, se
personaliza un mensaje de error con el atributo requiredMessage con el mensaje
pertinente a cada caso. Como ejemplo, tomamos el TextArea para introducir la
denominacin del proyecto.
El atributo required exige que ese campo sea distinto de NULL, pero no detecta
las cadenas vacas. Para ello, he empleado una de las restricciones de Hibernate
Validator NotBlank que realiza un trim a la cadena antes de su comprobacin.

34

<h:inputTextarea id="denominacion" rows="5"

value="#{controladorProyectos.proyecto.denominacion}" title="Denominacion"
required="true" requiredMessage="La Denominacion es requerida."
styleClass="inputText">
<rich:ajaxValidator event="onblur" />
</h:inputTextarea>

El componente <rich:ajaxValidator> se encarga de realizar las validaciones va

AJAX.
2) Datos opcionales: fecha de aprobacin, fecha de fin prevista y la fecha de inicio
del proyecto.
<a4j:outputPanel id="calendar1" layout="block">
<rich:calendar value="#{controladorProyectos.proyecto.faprobacion}"
id="faprobacion" inputStyle="height: 20px" inputClass="inputText"
datePattern="dd/MM/yyyy" cellWidth="24px" cellHeight="22px"
style="width:200px" inputSize="40">
<rich:ajaxValidator event="onchanged" />
</rich:calendar>
</a4j:outputPanel>

En esta vista se sita el componente <rich:messages> para mostrar los mensajes de error
que se producen durante el proceso de validacin de los datos o los que devuelve el
controlador en caso de que se produzca un error.
<rich:messages layout="table" tooltip="true" title="Mensaje de error"
showDetail="false" showSummary="true" style="color: red">
<f:facet name="errorMarker">
<h:graphicImage value="/img/error.png" width="15px" height="15px"/>
</f:facet>
</rich:messages>

Una vez completado el formulario con todos los datos necesarios del proyecto, se enva la
solicitud de insercin al Controlador de proyectos al pulsar el botn Guardar, como se
observa en el atributo action del componente <a4j:commandButton>.
<a4j:commandButton styleClass="boton" value="Guardar"
action="#{controladorProyectos.insertarProyecto}" />

3.4.2. El Controlador
Se encarga de realizar todas las operaciones sobre proyectos, comunicando las vistas JSF
con los servicios de la capa de lgica de negocio.
Todos los controladores de la aplicacin son denotados por la directiva @Controller, que le
indica a Spring que sta clase sirve para manejar las peticiones y respuestas recibidas y
enviadas a los usuarios.
En el Controlador de proyectos, en su mtodo insertarProyecto, se encuentra el siguiente
cdigo:

35

@Autowired
private ProyectoService proyectoService;

public String insertarProyecto() {

String accion = "";
try {
this.proyecto = aniadirDatosProyecto(proyecto);
proyecto.setFinalizado(false);
if (proyectoService.saveProyecto(proyecto)) {
proyecto = new Proyecto();
recuperaProyectos();
construyeListaProyectos();
construyelistaProyectosActivos();
accion = "proyectos";
} else {
FacesContext.getCurrentInstance().addMessage(null, new
FacesMessage("Este proyecto ya existe"));
}
} catch (PersistenciaException ex) {
Logger.getLogger(ControladorProyectos.class.getName()).log(Level.SEVERE, null,
ex);
FacesContext.getCurrentInstance().addMessage(null, new
FacesMessage("Error al intentar guardar el proyecto"));
}
return accion;
}

Peculiaridades del mtodo:

1) Devuelve un String que contiene el nombre de la siguiente vista a la cual se
redirige la respuesta una vez que termina bien el proceso de insercin. El nombre
de la vista se determina en el fichero faces-config.xml como sigue:
<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>proyectos</from-outcome>
<to-view-id>/pages/proyectos.xhtml</to-view-id>
<redirect/>
</navigation-case>


</navigation-rule>

El elemento <from-autocome> indica la cadena de accin, y <to-view-id> el path de

la vista asociada. <redirect/> indica que se realiza una redireccin a la pgina. En
caso de no indicar nada, el paso a la vista se hara con un forward.
2) Manejo de errores y envo de mensajes de informacin a la vista mediante
FacesContext.getCurrentInstance().addMessage() que se muestran en el componente
<rich:messages> de la vista JSF antes explicado.
3) Una vez guardado el proyecto, vuelve a actualizar las listas de proyectos para
refrescar el contenido de las tablas que las usan en la vista JSF.

36

4) No recibe ningn parmetro, ya que el objeto proyecto es propio de la clase y

obtiene los valores de sus atributos directamente de la vista JSF. Ya que en sta se
hace referencia a este objeto y sus atributos. Por ejemplo, el campo denominacin
del proyecto tiene el siguiente valor:
<h:inputTextarea id="denominacion" rows="5"
value="#{controladorProyectos.proyecto.denominacion}"

5) Tiene un atributo de tipo ProyectoService, inyectado con la anotacin

@Autowired de Spring, en el que delega la funcin de guardar el proyecto. En caso
de que se guarde el proyecto, la pgina ser redirigida al listado de proyectos y en
caso contrario, lanzar un error al usuario para informarle.

3.4.3. El Servicio
El servicio de proyectos y en su mtodo saveProyecto se encarga de:
1) Generar un nmero de proyecto para el atributo idProyecto con la informacin
necesaria.
2) Comprobar que el proyecto no existe en la base de datos mediante una llamada al
DAO especfico de proyectos con el mtodo find(). Este mtodo busca y encuentra
un proyecto por su clave candidata (denominacin y cliente). Y por ltimo llama al
DAO que se encarga del mapeo Objeto Relacional de los proyectos.

3.4.4. El DAO
Como se trata de una operacin bsica, el DAO genrico ser el encargado de realizarla:
public Integer save(T objecto) throws PersistenciaException {
Integer id = null;
try {
id = (Integer) getHibernateTemplate().save(objecto);
getHibernateTemplate().flush();
} catch (DataIntegrityViolationException ex) {
this.logger.error(ex);
throw new PersistenciaException(PersistenciaExceptionCode.INSERT_FAILED,
ex);
} catch (DataAccessException ex) {
this.logger.error(ex);
throw new PersistenciaException(PersistenciaExceptionCode.INSERT_FAILED,
ex);
} catch (Exception ex) {
this.logger.fatal(ex);
throw new PersistenciaException(PersistenciaExceptionCode.INSERT_FAILED,
ex);
}
return id;
}

37

Peculiaridades del mtodo:

1) Accede a la clase plantilla HibernateTemplate mediante su mtodo
getHibernateTemplate(). Una de las responsabilidades de esta plantilla es gestionar
las sesiones, lo que implica su apertura y cierre, as como garantizar que exista
slo una sesin por cada transaccin. Ofrece adems algunos mtodos como save,
find, update, delete, getSession y muchos ms.
2) Envuelve las excepciones (DataIntegrityViolationException, Exception y
DataAccessException) en una propia de la capa de persistencia
(PersistenciaException).
3) El mtodo hibernateTemplate.flush() que a su vez ejecuta una llamada a
Session.flush() para confirmar los cambios realizados.

3.5. Pruebas
Para realizar las pruebas unitarias he utilizado Spring TestContext Framework que
proporciona un soporte de integracin con JUnit4 a travs de un Runner a medida. En este
proyecto la integracin la realic a travs de SpringJUnit4ClassRunner, que posibilita la
realizacin de pruebas unitarias o de integracin, la carga del contenedor de Spring y la
inyeccin de dependencias en las clases de test.
He aqu la configuracin de la clase que realiza las pruebas sobre el DAO de clientes:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({"file:src/main/webapp/WEB-INF/spring-config.xml"})

La anotacin @RunWith sirve para que la ejecucin de la clase de prueba unitaria la

efecte la clase especificada como parmetro, en este caso SpringJUnit4ClassRunner y no
la clase Runner de JUnit. Esta clase se encarga de levantar el contexto de Spring y resolver
todas las dependencias requeridas por la clase de prueba.
Para obtener el contexto Spring utiliza la informacin especificada en
@ContextConfiguration, donde se encuentra la localizacin del fichero(s) de
configuracin de Spring.

Una de las pruebas ms significativas que dio lugar a la toma de nuevas decisiones en la
implementacin de la capa de persistencia, fue la siguiente:
Al principio el cdigo de los mtodos find() de la clase ClienteDAO no se beneficiaba de las
operaciones que ofrece la plantilla HibernateTemplate, sino que creaba una nueva Query a
partir de la sesin en curso de Hibernate como se observa en el siguiente cdigo:

38

public Cliente find(Cliente cliente) throws PersistenciaException {

Cliente clienteBD = null;
try {
String hql = "SELECT c FROM Cliente c WHERE c.denominacion = :denominacion
and c.direccion= :direccion";
Query query =
getHibernateTemplate().getSessionFactory().getCurrentSession().createQuery(hql
);
query.setParameter("denominacion", cliente.getDenominacion());
query.setParameter("direccion", cliente.getDireccion());
clienteBD = (Cliente) query.uniqueResult();

Al realizar la prueba de este mtodo me di cuenta de que no me devolva los resultados

esperados, todo ello por causa de la obtencin de la sesin a partir del mtodo
getHibernateTemplate().getSessionFactory().getCurrentSession. Debido a la gestin que realiza
Spring de las sesiones no encontraba ninguna sesin para utilizar.
Todo ello, me llev a pensar en una nueva solucin que fue aadir un nuevo mtodo en el
DAO genrico para que pueda ser utilizado por todos los DAOs que realicen consultas
personalizadas. Este mtodo es findByQuery que recibe una consulta HQL y una lista de
parmetros para llamar a HibernateTemplate, aprovechando de esta manera el mtodo
find que ofrece esta clase plantilla.
protected List<T> findByQuery(String queryString, Object[] values) throws
PersistenciaException {
List<T> lista = null;
try {
lista = getHibernateTemplate().find(queryString, values);

return lista;
}

Y as hacer uso de este mtodo en el resto de los DAOs como sigue:

public Cliente find(Cliente cliente) throws PersistenciaException {
Cliente clienteBD = null;
try {
String hql = "SELECT c FROM Cliente c WHERE c.denominacion = ? and
c.direccion= ?";
List<Cliente> lista = super.findByQuery(hql, new String[]
{cliente.getDenominacion(), cliente.getDireccion()});
if (!lista.isEmpty()){
clienteBD = lista.get(0);
}

39

4. GESTIN DEL PROYECTO

4.1. Planificacin inicial
La planificacin de este proyecto la realic a finales de enero de 2013 para ir revisando y
modificando su contenido a lo largo del proyecto. De sta manera poder comprobar que lo
planificado al principio se cumple a tiempo y que no haya ningn desfase significativo que
pueda afectar de manera negativa al desarrollo del proyecto.

4.2. Definicin de tareas

Una de las tareas principales de la planificacin de un proyecto es la definicin de las
tareas que lo componen. En la siguiente figura se describen de forma ms detallada todas
las tareas derivadas de este Trabajo Fin de Grado.

Trabajo Fin de Grado

Gestin del proyecto

Anlisis

Diseo

Construccin

Pruebas

Planificacin

Especificar
requisitos

Prototipos
web

Base de
datos

Diseo

Definir
objetivos

Analizar
requisitos

Base de
datos

Persistencia

Verificacin

Reuniones

Definir el
modelo del
dominio

Seguimiento
Memoria

Arquitectura
Software

Formacin

Lgica de
negocio
Controladores
Presentacin

Figura 16: Descomposicin de tareas

4.3. Diagrama de Gantt

En el siguiente diagrama Gantt se recogen todas las tareas realizadas en este proyecto as
como la duracin planificada de cada una y los hitos ms importantes que se han tenido en
cuenta.
40

Figura 17: Diagrama de Gantt

41

4.4. Resultado final

El tiempo de casi todas las tareas se corresponde con su planificacin inicial, dado que
durante el perodo de prcticas en la empresa ya haba empezado a ver y manejar algunas
de las tecnologas empleadas en este proyecto.
El tiempo restante planificado para la formacin, se ha invertido en el estudio de la
tecnologa Spring Framework y en profundizar en algunos aspectos de las dems
tecnologas.
Al ser mi primera experiencia en realizar un proyecto real, no fue una planificacin
ajustada al 100% como es en la mayor parte de los casos. Ha habido algunos pequeos
desfases entre la planificacin inicial y la final. Estos desfases son muy poco significativos,
y adems se compensaron con otros donde la planificacin fue muy pesimista.

4.4.1. Comparacin entre el tiempo estimado y el real

Tarea
Anlisis
- Especificacin de requisitos
- Analizar requisitos
- Definir el modelo del dominio
Diseo
- Base de datos
- Prototipos de la interfaz
- Arquitectura software
Construccin
- Base de datos
- Poblacin de la BD
- Capa de persistencia
- Lgica de negocio
- Capa de presentacin
- Construccin de la interfaz
Pruebas
- Diseo de casos de prueba
- Verificacin de pruebas
Gestin del proyecto
- Definir los objetivos
- Reuniones con el tutor
- Planificacin
- Entrevistas con el cliente
- Seguimiento
- Confeccin de la memoria
Formacin
Total horas

Tiempo
estimado
40
20
15
5
25
15
5
5
126
20
6
25
25
30
20
25
10
15
44
10
4
6
6
3
15
40
300

Tiempo
real
35
15
15
5
20
10
5
5
118
12
6
30
30
30
10
25
10
15
57
10
6
6
10
5
20
50
305

Desfase
-5
-5
0
0
-5
-5
0
0
-8
-8
0
5
5
0
-10
0
0
0
13
0
2
0
4
2
5
10
5

Tabla 3: Comparacin entre tiempos

42

140
120
100
80
60
40
20
0

126

40 35

118

44
25

20

Tiempo estimado

25 25

57
40

50

Tiempo real

Figura 18: Grfico de comparacin de tiempos

4.4.2. Justificacin de los desfases

Uno de los desfases de la planificacin se produjo en el apartado de gestin del proyecto
que fue un total de 13 horas. La estimacin de las horas de reunin tanto con el cliente
como el tutor, fue un poco optimista. Tambin se han visto afectadas las horas planificadas
para la confeccin de la memoria debido a mi poca experiencia en la confeccin de este
tipo de documentos.
Por otra parte, el aumenta de la duracin del proceso de formacin debido a los problemas
que han surgido durante el desarrollo y al desconocimiento de las tecnologas utilizadas.
La notable disminucin del tiempo planificado al inicio para la construccin de la interfaz
de usuario debido al uso de la tecnologa Richfaces para este cometido, que afect de
forma positiva a esta tarea.
El diseo y construccin de la base de datos que realmente no requera tanto tiempo
debido a la reutilizacin de muchas de las tablas que pertenecan al antiguo modelo de
datos.

43

4.5. Problemas afrontados

Una de las tareas ms significativas durante el desarrollo de este proyecto fue la
formacin, debido a la multitud de tecnologas usadas y que eran totalmente desconocidas
para m, como es el caso de Hibernate, JavaServer Faces, Facelets, Jasperrreports y el ms
destacable entre todos Spring Framework y su parte de seguridad.
Uno de los problemas que he tenido durante el desarrollo fue haciendo uso de Maven
como gestor de proyectos, concretamente en la gestin que realiza ste de los repositorios
(empresarial, central y local). Al principio empec utilizando el repositorio privado de la
empresa Suma Info S.L. Al ver que no poda acceder desde fuera, tuve que modificar este
ltimo por otros repositorios centrales de Maven para la gestin de las libreras.
Al emplear Jasperrreports para generar los informes necesitaba la versin 4.5.0, sin
embargo no se encontraba en los repositorios centrales de Maven. Causa por la cual tuve
que volver a cambiar los repositorios declarados en el fichero de configuracin de Maven.
En las relaciones de asociacin (ManyToOne) en Hibernate por defecto realiza una
recuperacin temprana. Para evitar la carga en memoria de todos los objetos implicados
en una relacin de este tipo, configur las clases entidad (del modelo) con el objetivo de
que la recuperacin sea tarda o perezosa. En algunas de las consultas HQL realizadas
acceda a atributos de objetos que pertenecan a este tipo de relacin. Todo ello, me llev a
tardar en detectar que estos objetos no estaban inicializados.
La solucin tomada en este caso, aunque puede que no sea la ms ptima, fue cambiar el
modo de recuperacin en aquellos casos donde se necesitaba y dejar el resto como estaba
al principio.

44

CONCLUSIONES
En cuanto a funcionalidad, se han alcanzado todas las metas puestas al principio del
proyecto. Como resultado final se ha obtenido una aplicacin web que ofrece al usuario
una interfaz intuitiva sin mucha complejidad y de fcil manejo en la que se ha logrado
cubrir las funcionalidades deseadas por el cliente, que le permiten realizar una gestin
completa de sus proyectos y tiempos as como de la mayora de gestiones que se
realizaban con la antigua aplicacin de la que dispona al principio.
Cabe mencionar el gran nmero de conocimientos que se han adquirido durante el
desarrollo de este Trabajo Fin de Grado debido al manejo de todas las tecnologas que se
han usado para la ejecucin del mismo y que fueron impuestas en su totalidad por el
cliente.
El enfrentamiento a los distintos problemas surgidos durante todo proceso de
construccin de la aplicacin, el tiempo invertido en la bsqueda de las soluciones que
mejor se adapten a cada caso y su implantacin, con todo ello aprend a tomar mis propias
decisiones y asumir la responsabilidad de sus consecuencias.
El proceso de formacin que fue muy largo sobre todo con Spring Framework y la
navegacin en un mundo extenso de nuevas tecnologas ha merecido la pena para adquirir
nuevas experiencias en el mundo laboral.
La realizacin de un proyecto real en un entorno empresarial ha sido un punto clave para
ampliar y poner a prueba mis conocimientos adquiridos durante toda la carrera.
En general se han logrado los objetivos a nivel de proyecto, se han cumplido mis
propsitos personales y a nivel educativo fue un proyecto muy enriquecedor.

Posibles mejoras
Los siguientes puntos son algunas mejoras que pueden ser aadidas a la aplicacin en el
futuro:
1) Ofrecer la posibilidad de generar informes parametrizados: debido a la falta de
tiempo, en el desarrollo del proyecto se han tenido en cuenta los informes de
facturas que era uno de los requisitos que se haban establecido al inicio. Cabe la
posibilidad de ampliar la funcionalidad de esta aplicacin y permitir la generacin
de informes en formato PDF atendiendo a ciertos parmetros que introduce el
usuario, por ejemplo: ver sus registros de tiempo para un determinado proyecto.
2) Mejorar la navegacin en todas las pginas: se pueden incluir migas de pan para
que el usuario sepa en cualquier momento dnde se encuentra y la relacin
jerrquica de la pgina donde se encuentra con el resto de la estructura de la
aplicacin. Para ello, se pueden usar elementos de la librera Primefaces que
facilitan esta tarea.

45

BIBLIOGRAFA

FRANCISCO JOS GARCA IZQUIERDO. Apuntes de la asignatura Programacin de

aplicaciones Web.

ARTURO JAIME ELIZONDO. Apuntes de la asignatura Diseo de bases de datos

ELMASRI RAMEZ y NAVATHE SHAMKANT. Fundamentos de Sistemas de Bases de

Datos. 3Ed.

GRAIG WALLS. Spring. 3Ed.

PAUL TEPPER FISHER and BRIAN D. MURPHY. Spring persistence with hibernate.

MAX KATZ y ILYA SHAIKOVSKY. Practical Richfaces. 2Ed.

TEODOR DANCIU and LUCIAN CHIRITA. The definitive guide to JasperReports.

Referencias Web:

Richfaces: http://www.jboss.org/richfaces
http://livedemo.exadel.com/richfaces-demo/richfaces/dataTableScroller.jsf?s=glassX

Hibernate: http://docs.jboss.org/hibernate/core/3.5/reference/es-ES/html/

Jasperreports: http://community.jaspersoft.com/project/jasperreports-library

Spring: http://www.springhispano.org/
http://www.springsource.org/spring-framework

46

UNIVERSIDAD DE LA RIOJA

FACULTAD DE CIENCIAS, ESTUDIOS AGROALIMENTARIOS E INFORMTICA

GRADO EN INGENIERA INFORMTICA

Aplicacin web para el control

de proyectos en la empresa
Suma Info S.L.
Manual de usuario
Junio de 2013

Realizado por
Naziha Ayachi Majait
Dirigido por
Francisco Jos Garca Izquierdo

NDICE
SOBRE LISTADOS .................................................................................................................... 1
1.

PROYECTOS....................................................................................................................... 2
1.1. Crear nuevo proyecto ............................................................................................................ 2
1.2. Asignar tcnicos a proyecto ................................................................................................ 2
1.3. Detalles del proyecto ............................................................................................................. 3

2.

REGISTRO DE TIEMPOS ................................................................................................ 3

2.1. Registrar tiempo ..................................................................................................................... 4

3.

GASTOS ............................................................................................................................... 4
3.1. Imputar gastos a proyecto .................................................................................................. 5

4.

TCNICOS ........................................................................................................................... 5
4.1. Dar de baja a un tcnico ....................................................................................................... 6
4.2. Categoras de un tcnico ...................................................................................................... 6

5.

CLIENTES ........................................................................................................................... 7

6.

FACTURAS ......................................................................................................................... 7
6.1. Crear nuevo factura ............................................................................................................... 7
6.2. Generar informe de facturaciones ................................................................................... 8
6.3. Editar una factura ................................................................................................................... 9

7.

Categoras.......................................................................................................................... 9
7.1. Editar categora .....................................................................................................................10
7.2. Tarifas de una categora .....................................................................................................10

SOBRE LISTADOS
En cualquier listado que aparece en las pginas de la aplicacin, puede acceder a distintas
funciones. Utilizando el men que aparece al pulsar sobre la cabecera de cada columna
puede:
1) Ordenar de forma ascendente o descendente, que puede llevar a cabo de otra
forma, simplemente pulsando sobre la cabecera de la columna deseada.
2) Agrupar o desagrupar por una columna.
3) Mostrar u ocultar columnas mediante la opcin Columns del mismo men.

4) Navegar por las distintas pginas del listado.

En el pie del cada listado se muestran los botones de navegacin que le permiten
moverse de forma rpida por los distintos elementos del listado.

1. PROYECTOS
En este apartado puede gestionar todo lo relacionado con los proyectos de la empresa. En
el listado de proyectos se muestran los siguientes campos: la denominacin del proyecto,
el cliente y el estado del proyecto (finalizado o no).

Desde el listado puede realizar diferentes acciones como:

1) Utilizar los filtros para realizar bsquedas por denominacin y cliente,
simplemente introduciendo la cadena deseada en el campo
destinado a este fin.
2) Modificar los datos bsicos de un proyecto pulsando sobre
3) Ver los detalles de un proyecto accediendo a travs de
4) Asignar tcnicos al proyecto con la opcin

1.1.

Crear nuevo proyecto

En la pgina donde se muestra el listado de proyectos, pulsando el botn

formulario para rellenar los datos de un nuevo proyecto.

se abrir el

Debe introducir los datos bsicos del proyecto; denominacin, plataforma, organismo, tipo
de proyecto y la fecha de propuesta. Una vez que termina este proceso debe pulsar el
botn Guardar y as insertar el proyecto en la base de datos y volver al listado para
comprobar que se ha introducido correctamente.

1.2.

Asignar tcnicos a proyecto

Pulsando el botn
al proyecto.

puede acceder a un nuevo formulario para asignar nuevos tcnicos

Para ello, debe seleccionar un tcnico del listado de la parte izquierda y una categora de
las disponibles a la derecha. Para finalizar la operacin debe pulsar sobre el botn
Asignar.
Posteriormente podr ver todos los tcnicos asignados al proyecto en el listado que se
encuentra en parte inferior de esta pgina y borrar alguna asignacin anterior pulsando el
botn
si as lo desea. Una vez pulsado este ltimo aparece una ventana para confirmar
la eliminacin como puede observar en la siguiente figura:

1.3.

Detalles del proyecto

Por otra parte, puede acceder a la opcin

para ver los detalles de un proyecto. Esta
opcin incluye los datos bsicos (identificador, denominacin, plataforma, tipo de
proyecto, cliente, fecha de propuesta, fecha de inicio y el estado del proyecto), los tiempos
registrados por todos los tcnicos que participan en el desarrollo del proyecto y los gastos
imputados al mismo.

En la pestaa Tiempos registrados puede ver los siguientes datos de cada registro: el
tcnico, la fecha, una descripcin de la actividad realizada y por ltimo, el nmero de
horas.
En la segunda pestaa, Gastos del proyecto puede ver todos los gastos que se han
imputado al proyecto y consultar los datos bsicos de cada uno. Los atributos que puede
consultar son: la fecha, la descripcin, el tipo de gasto y el importe del mismo.

2. REGISTRO DE TIEMPOS
Esta seccin le permite registrar nuevos tiempos y ver todos los que haya registrado
anteriormente o filtrar la bsqueda por una fecha concreta.
En el panel que se muestra en la primera pgina puede acceder a filtrar sus tiempos por
una fecha. Para ello, debe pulsar sobre el icono
o sobre el campo donde aparece la
fecha para seleccionar una nueva y posteriormente pulsar sobre el botn Buscar.

En caso de que quiera ver todos los tiempos que lleva registrados hasta el momento,
puede hacerlo a pulsando el botn Ver todos.
En cualquier caso aparecer un listado con todos sus registros que incluye los campos de
fecha, descripcin de la actividad realizada y la duracin en horas.
Las acciones que incluye este listado son:
1) Los filtros para realizar bsquedas por fecha, descripcin o por horas.
2) Editar un registro pulsando sobre el icono
3) Eliminar un registro mediante la opcin
confirmar o cancelar esta operacin.

2.1.

.
, que muestra un mensaje de para

Registrar tiempo

Para crear un nuevo registro de tiempo debe pulsar el botn

que aparece en la pgina
del listado de tiempos. Se abrir un formulario donde debe introducir todos los datos
necesarios y que son: la fecha, la descripcin de la tarea, nmero de horas, el proyecto y
por ltimo, elegir el tipo de trabajo realizado.
Para finalizar esta operacin debe pulsar sobre el botn Guardar para insertar el nuevo
registro y volver al listado inicial.

3. GASTOS
En esta seccin se muestra un listado con todos sus gastos registrados por los proyectos
en los que haya participado. De cada gasto se muestra su fecha de registro, una
descripcin, el tipo de gasto y el importe del mismo.

Las acciones disponibles en este listado son:

1) La opcin

permite editar un gasto existente.

2) La opcin

permite eliminar un gasto de los registrados.

3) Filtrar por fecha, descripcin, tipo de gasto o importe.

3.1.

Imputar gastos a proyecto

Pulsando sobre el icono

se muestra un formulario donde puede crear un nuevo gasto.
Para ello, debe rellenar los datos requeridos como la fecha, el importe, el tipo de gasto y
seleccionar un proyecto de los disponibles.

4. TCNICOS
Le permite gestionar y mantener la informacin de los empleados de la empresa. De cada
empleado se muestra su nombre, apellidos, nombre de usuario y la fecha de baja (si ha
sido dado de baja).

Desde el listado de tcnicos puede realizar distintas acciones como:

1) Filtrar por nombre, apellidos y usuario.
2) Modificar los datos de un tcnico existente pulsando sobre el icono
3) Ver los detalles de un tcnico pulsando sobre el icono

4.1.

Dar de baja a un tcnico

Para dar de baja a un tcnico activo en la empresa debe pulsar sobre el botn
para
acceder a modificar sus datos. Una vez que est en el formulario, debe seleccionar una
fecha a partir de la cual tendr efecto la baja efectuada. Para volver a activar un tcnico
que ya se haba dado de baja, debe pulsar sobre el icono
para abrir el calendario y
seleccionar la opcin Clean para borrar la fecha de baja. Por ltimo, pulsar el botn
Editar para guardar los cambios.

4.2.

Categoras de un tcnico

Mediante la opcin
del listado de tcnicos puede acceder a sus detalles y ver todas las
categoras que se le han asignado durante su instancia en la empresa, as como efectuar
una nueva asignacin.
Para asignar una categora, debe elegir una de las disponibles, introducir el ao y
finalmente pulsar el botn Asignar.
En el listado se muestra la categora y el ao. Puede modificar estas asignaciones eligiendo
una categora nueva y/o introduciendo otro ao distinto en sus respectivos campos del
listado, como se puede observar en la siguiente figura.
Para confirmar la modificacin y guardar los datos cambiados debe pulsar sobre
Tambin puede optar por borrar una asignacin ya existente mediante la opcin

.
.

5. CLIENTES
Permite gestionar toda la informacin referente a los clientes de la empresa; crear nuevos
y modificar los existentes. En el listado de clientes se muestran los siguientes campos: el
nombre, la direccin y el municipio.
Pulsando el icono
puede acceder al formulario para crear un nuevo cliente. Los datos
necesarios para crear un nuevo cliente son: denominacin, direccin, cdigo postal, pas,
provincia y municipio.
Para modificar los datos de un cliente deber acceder pulsando sobre el botn
disponible en el listado de los clientes.

, accin

6. FACTURAS
Le permite gestionar y mantener todas las facturaciones realizadas por los proyectos de la
empresa. En el listado de las facturas se muestra el nmero de factura, la fecha, el proyecto
y el importe total.
Las posibles acciones para cada factura del listado son editar

6.1.

y eliminar

Crear nuevo factura

Pulsando sobre el icono

puede acceder a crear una nueva factura. Como datos
necesarios debe seleccionar la fecha y el proyecto para facturar sus gastos.

Una vez seleccionado el proyecto aparecern dos listas; la primera corresponde a los
gastos del proyecto para elegir los que desea incluir en la factura y en la segunda
aparecern los gastos que vaya seleccionando.

Usando los botones que aparecen entre las dos listas puede:
-

Aadir todos los gastos pulsando el boton Aadir todos.

Seleccionar algunos gastos y aadirlos pulsando sobre la opcin Aadir.

De manera similar puede borrar todos los gastos incluidos en la segunda lista o
seleccionar alguno(s) concreto(s) y borrarlo(s) usando los botones Borrar y Borrar
todos.
Una vez seleccionados los gastos que desea incluir en la factura, puede optar por terminar
el proceso y volver al listado de facturas o avanzar a la siguiente pgina pulsando el botn
Aceptar para incluir los honorarios.
Para crear un nuevo honorario debe seleccionar la fecha, el tcnico, el concepto e
introducir una descripcin y el nmero de horas. Los honorarios que va introduciendo se
reflejarn en la tabla que se sita en la parte superior de la pgina.

Tambin puede eliminar algn honorario que no desea incluir en la factura pulsando sobre
.
Para finalizar el proceso de facturacin debe pulsar el botn Terminar para guardar la
factura y volver al listado principal.

6.2.

Generar informe de facturaciones

Para descargar un informe con todas las facturaciones realizadas en la aplicacin en

formato PDF, debe pulsar el botn situado en la cabecera de la lista de facturas que se
indica en la imagen que sigue.

Posteriormente se descargar un documento con nombre Informe_facturas.pdf que

contiene toda la informacin de las facturas. Este informe incluye de cada factura los
campos: fecha, nmero de factura, cdigo del proyecto, el IVA y el total.

6.3.

Editar una factura

Para editar una factura, tiene que acceder pulsando el botn

, que abre una primera
pgina con la informacin bsica de la factura (nmero, fecha y proyecto) y una lista con
todos los gastos incluidos en la factura en el momento de su creacin.
En esta parte, dispone de una lista desplegable con todos los gastos del proyecto para
incluir otros nuevos que no estn en la factura. Cada vez que selecciona un gasto debe
guardarlo pulsando el botn Aadir.

Por otra parte, podr eliminar cualquier gasto de los que haya aadido o alguno de los que
ya estaban asignados al principio al pulsar el botn
y aceptar la confirmacin de la
eliminacin.
Una vez terminado este proceso, debe comprobar los datos y pulsar el botn Ver lneas
para acceder a aadir nuevos honorarios a la factura.
Para crear un nuevo honorario debe seleccionar la fecha, el tcnico, el concepto e
introducir una descripcin y el nmero de horas. Los honorarios que va introduciendo se
reflejarn en la tabla sita en la parte superior de la pgina. A travs de esta tabla puede
eliminar honorarios pulsando el botn destinado a este fin .

7. Categoras
En esta pgina se muestran todas las categoras en un listado. Puede aadir una nueva
categora insertando el nombre en el formulario que se sita en la parte superior de la
pgina y pulsar el botn Guardar.
Desde el listado de categoras puede realizar distintas acciones como:
1) Filtrar por denominacin.
2) Modificar una categora existen pulsando sobre el icono
3) Ver las tarifas de una categora pulsando sobre

7.1.

Editar categora

Para modificar una de las categoras que aparecen en el listado, debe situarse dentro del
campo de la denominacin y modificar su contenido. Finalmente confirmar la modificacin
realizada pulsando sobre el icono .

7.2.

Tarifas de una categora

Para ver las tarifas que se le han asignado a una categora durante el paso del tiempo, debe
pulsar sobre el icono

Acto seguido, aparecern toda la informacin relacionada con las tarifas de la categora
seleccionada incluyendo el ao y el importe de las mismas. Las acciones que puede
ejecutar sobre estas tarifas son:
-

Eliminar la tarifa pulsando sobre el icono

Modificar su contenido en el propio campo y pulsar el icono

cambios.

para guardar los

Tambin puede asignar nuevas tarifas a una categora usando el formulario que se sita al
principio de la pgina.

Inicialmente debe seleccionar la categora a la que quiere asignar la tarifa e introducir el

ao y el importe deseado. Una vez que termina de rellenar estos campos debe insertar esta
asignacin en la base de datos pulsando sobre el botn Guardar.

10