Universidad Rey Juan Carlos

98  Descargar (0)

Texto completo

(1)

Escuela Superior de Ingenier´ıa Inform´

atica

Ingenier´ıa Inform´

atica

Curso Acad´

emico 2009/2010

Proyecto de Fin de Carrera

Sede Electr´

onica

Autor: David Rufo Valero

Tutor: Jes´

us Mar´ıa Gonz´

alez Barahona

(2)
(3)

El proyecto surge a partir de la aprobaci´on de la Ley 11/2007 , de 22 de junio, en la cual menciona que los ciudadanos deben tener acceso electr´onico a los Servicios P´ublicos y que en muchas ocasiones se refiere como “Ley de Administraci´on Electr´onica” que consagra el concepto de Administraci´on Electr´onica en el marco jur´ıdico espa˜nol y la eleva a la categor´ıa de derecho de los ciudadanos. Es decir, los ciudadanos tienen el derecho de acceder electr´onicamente a los servicios de la Administraci´on P´ublica, y ´estos ya no son facultativos para ´esta, sino que la capacidad para proporcionarlos se convierte en una obligaci´on para ellas que deber´a hacerse una realidad universal a partir del 31 de diciembre del 2009.

Este proyecto fin de carrera adopta el t´ıtulo de Sede Electr´onica , que se define en el art´ıculo 10 de dicha Ley como “aquella direcci´on electr´onica disponible para los ciudadanos a trav´es de redes de telecomunicaciones cuya titularidad, gesti´on y administraci´on corres-ponde a una Administraci´on P´ublica, ´organo o entidad administrativa en el ejercicio de sus competencias”.

Debido a que la Sede Electr´onica de la Administraci´on P´ublica est´a en sus primeros inicios, el proyecto se ha construido mediante las diferentes tecnolog´ıas que la administraci´on ha propuesto para su desarrollo. Por lo tanto los prop´ositos del proyecto son dos:

El primero es la evaluaci´on de las tecnolog´ıas sugeridas por la administraci´on con el fin de obtener un proyecto f´acil de elaborar, de mantener y eficiente.

Y el segundo es la construcci´on de una parte de esta aplicaci´on mediante las diferentes tecnolog´ıas evaluadas.

En cuanto a la funcionalidad de la aplicaci´on, cabe destacar el m´odulo de acceso del ciudadano, que permitir´a realizar la presentaci´on por medios electr´onicos de las solicitudes de servicio correspondientes a algunos de los procedimientos administrativos de la Administraci´on.

(4)
(5)

1. Introducci´on 1

1.1. Introducci´on al proyecto Sede Electr´onica . . . 1

1.2. Arquitectura . . . 3

1.2.1. Arquitectura MVC (Modelo-Vista-Controlador) . . . 3

1.2.2. Arquitectura SOA (Service Oriented Architecture) . . . 6

1.2.3. Arquitectura del Proyecto . . . 8

1.3. Tecnolog´ıas . . . 9 1.3.1. Capa de Presentaci´on . . . 9 1.3.2. Capa de Negocio . . . 12 1.3.3. Capa de Persistencia . . . 14 1.3.4. Base de Datos . . . 15 1.3.5. Servicios Web . . . 16 1.3.6. Otras tecnolog´ıas . . . 17 2. Objetivos 21

(6)

2.1. Descripci´on General del Problema . . . 21

2.2. Objetivos del Proyecto . . . 22

3. Descripci´on Inform´atica 25 3.1. Metodolog´ıa . . . 25

3.2. Especificaci´on de Requisitos . . . 27

3.2.1. Requisitos Hardware y Sofware del Producto . . . 27

3.2.2. Caracter´ısticas del Usuario . . . 29

3.2.3. Requisitos Funcionales . . . 29

3.2.4. Requisitos No Funcionales . . . 30

3.2.5. Funcionalidad de la aplicaci´on . . . 31

3.3. Arquitectura . . . 33

3.3.1. Justificaci´on de la arquitectura elegida . . . 34

3.3.2. Beneficios de la arquitectura dise˜nada . . . 35

3.4. An´alisis . . . 36

3.4.1. Diagramas de Casos de Uso . . . 36

3.4.2. Definici´on de interfaces de Usuario . . . 39

3.5. Dise˜no . . . 43

3.5.1. Dise˜no de la Realizaci´on de los Casos de Uso . . . 45

3.5.2. Dise˜no de Clases . . . 50

3.5.3. Dise˜no del Modelo de Datos . . . 55

3.5.4. Dise˜no de la Interfaz de Usuario . . . 58

3.6. Implementaci´on y Pruebas . . . 60

3.6.1. Ficheros configuraci´on del sistema . . . 61

(7)

3.6.3. Herramientas . . . 66

3.7. Pruebas del sistema . . . 68

4. Conclusiones 69 4.1. Trabajos Futuros . . . 71

4.2. Otras conclusiones . . . 72

Bibliograf´ıa 73 A. Manual de Usuario 77 A.1. Realizaci´on de un tr´amite . . . 77

A.2. Cambiar Idioma . . . 80

A.3. Cambiar Tama˜no Texto . . . 80

B. Manual de Instalaci´on 81 B.1. Instalaci´on JDK 1.5 . . . 81

B.2. Instalaci´on Apache Ant . . . 82

B.3. Instalaci´on Tomcat . . . 83

B.4. Instalaci´on y Configuraci´on Oracle . . . 83

B.4.1. Instalaci´on . . . 83

B.4.2. Configuraci´on . . . 84

B.4.3. Crear Cuenta de usuario . . . 84

B.5. Instalaci´on Toad para Oracle . . . 85

B.6. Instalaci´on y Configuraci´on Eclipse . . . 85

B.6.1. Configuraci´on Tomcat 5.5 . . . 85

(8)
(9)

1.1. Introducci´on. Modelo - Vista - Controlador. . . 4

1.2. Introducci´on. Arquitectura MVC orientada a Servicios. . . 8

3.1. An´alisis. Diagrama de casos de usos general. . . 37

3.2. An´alisis. Caso de uso - Ver informaci´on. . . 38

3.3. An´alisis. Caso de uso - Realizar un tr´amite. . . 39

3.4. An´alisis. Interfaz de Usuario, prototipo. . . 40

3.5. Dise˜no. Diagrama de secuencia - Visualizaci´on de la Informaci´on. . . 45

3.6. Dise˜no. Diagrama de secuencia - Realizar un tr´amite. . . 47

3.7. Dise˜no. Diagrama de secuencia - Realizar un tr´amite y enviar por Internet. 49 3.8. Dise˜no. Diagrama de clases. . . 54

3.9. Dise˜no. Modelo de base de datos. . . 57

3.10. Dise˜no. P´agina web con men´u lateral derecho. . . 59

3.11. Dise˜no. P´agina web sin men´u lateral derecho. . . 60

(10)

A.2. Manual Usuario. P´agina Web con Formulario. . . 79

B.1. Manual de Instalaci´on. Versi´on J2EE. . . 82

B.2. Manual de Instalaci´on. Versi´on Apache Ant. . . 83

(11)

En este cap´ıtulo, se pretende explicar de forma breve y concisa una serie de conceptos necesarios a modo de introducci´on para la comprensi´on del trabajo realizado en este proyecto. Muchos de esos conceptos se ir´an desarrollando con m´as detalle a lo largo de la memoria.

1.1.

Introducci´

on al proyecto Sede Electr´

onica

Este proyecto fin de carrera forma parte de un proyecto para la elaboraci´on de una Sede Electr´onica de una Administraci´on P´ublica. Esta administraci´on, al inicio del proyecto, propuso algunas de las tecnolog´ıas que deber´ıan utilizarse para el desarrollo del mismo. En el supuesto de que alguna de ´estas no cumpliese con la funci´on deseada podr´ıa ser modificada por otra, avisando de tal cambio.

El trabajo realizado se basa en dos partes bien diferenciadas que guardan una relaci´on entre s´ı. En primer lugar ser´a realizada una evaluaci´on de las tecnolog´ıas sugeridas por la administraci´on para el desarrollo de la aplicaci´on, con el fin de comprobar que claramente cumplen con las necesidades expuestas. Y por otro lado se debe utilizar dicha tecnolog´ıa para la construcci´on de un sistema sencillo, f´acil de mantener y eficiente.

(12)

El proyecto ha surgido a partir de la Ley 11/2007, la cual obliga a estas administraciones a habilitar el acceso, por parte de los ciudadanos, a los servicios electr´onicos a trav´es de diferentes canales. En el ´ambito de la Administraci´on General del Estado deben ser habilitados, al menos, los siguientes canales:

Presencial: canal que deber´a permitir a los ciudadanos o usuarios que lo deseen la posibilidad de entregar los tr´amites, elaborados a trav´es de la web, a la oficina correspondiente de forma personal. Una de sus limitaciones es la dependencia del horario de apertura de la oficina correspondiente, y otra de ellas podr´ıa ser las colas de espera para la entrega de la documentaci´on. El usuario una vez haya realizado el tr´amite mediante la web, deber´a imprimir el informe para poder realizar su entrega, para lo cual se le mostrar´a una alternativa con el fin de que dicho usuario pueda descargar en su ordenador dicho informe con los datos que ingres´o. En dicho documento aparecer´a una nube de puntos con el fin de que la oficina, con un esc´aner apropiado, pueda leer dicho c´odigo y realizar el tr´amite sin tener que volver a introducir de nuevo los datos del informe.

Sede Electr´onica: canal mediante el cual los ciudadanos podr´an enviar sus tr´amites a trav´es de la web. Por lo tanto el ciudadano elabora y env´ıa la documentaci´on a trav´es de la Sede Electr´onica a la administraci´on. Para el env´ıo de dichos tr´amites se necesitar´a cierta autenticaci´on, por lo que el sistema le solicitar´a algunos datos personales. Si por cualquier motivo no tiene disponible de dicha informaci´on, siempre tendr´a la posibilidad de llevar a cabo alguna de las otras dos alternativas. Su gran ventaja es no tener que desplazarse hasta la oficina para entregar la documentaci´on, lo cual ahorra tiempo al ciudadano. Adem´as es muy ´util para la administraci´on ya que podr´a llevar a cabo un n´umero mayor de tr´amites en el mismo tiempo y con menos personal, lo cual provocar´a menores gastos.

Telef´onico: por ´ultimo, aquel ciudadano que lo desee podr´a realizar sus tr´amites a trav´es de la web y mediante una llamada telef´onica podr´a realizar la entrega de dicha documentaci´on. Esta alternativa tendr´a la limitaci´on del horario establecido por la

(13)

oficina para la presentaci´on de dicha informaci´on. El horario podr´a ser consultado mediante la web o a trav´es de una llamada telef´onica a la oficina de atenci´on al cliente de la administraci´on p´ublica en cuesti´on.

Otro punto importante del proyecto es el tema de la usabilidad y accesibilidad de las p´aginas web. Cabe destacarlo ya que la mayor parte de los usuarios finales del proyecto ser´an personas de avanzada edad, por lo que se llevar´a a cabo una serie de medidas y validaci´on a trav´es de la W3C [1] con el fin de que todas las personas, tanto las normales como las que padecen de alguna discapacidad, puedan elaborar las tareas sin ning´un problema. El certificado Doble-A es el que se pretende alcanzar.

1.2.

Arquitectura

Una arquitectura se utiliza para organizar las diferentes partes de una aplicaci´on. Por tanto el objetivo principal de la arquitectura es separar, de la forma m´as limpia posible, las distintas capas de desarrollo, otorgando una especial atenci´on a la claridad del modelo de dominio y a la facilidad de mantenimiento y evoluci´on de las aplicaciones. Por lo que ´

esta nos proporcionar´a:

Ayuda para decidir c´omo dividir la aplicaci´on web.

Una pauta para definir la forma en que todos los componentes trabajen juntos para llevar a cabo la funcionalidad que se pretende conseguir con la aplicaci´on.

En los dos siguientes apartados se hace una breve explicaci´on de la Arquitectura MVC y la Arquitectura SOA. Mientras que en ´ultimo apartado de esta secci´on se mencionar´a la arquitectura utilizada en este proyecto fin de carrera.

1.2.1.

Arquitectura MVC (Modelo-Vista-Controlador)

La Arquitectura MVC, dise˜nada por Trygve M. H. Reenskaug en 1979, tiene como objetivo separar en capas las tres funciones b´asicas de una aplicaci´on (web en este caso).

(14)

Figura 1.1: Introducci´on. Modelo - Vista - Controlador.

A continuaci´on se explica el significado y prop´osito de cada una de las capas:

Modelo: es el objeto que representa la l´ogica de negocio de una aplicaci´on. Maneja los datos de la aplicaci´on y controla todas sus transformaciones. El Modelo no tiene conocimiento espec´ıfico de los Controladores o de las Vistas, ni siquiera contiene referencias a ellos. Es el propio sistema, ´el que tiene encomendada la responsabilidad de mantener enlaces entre el Modelo y sus Vistas, y notificar a las Vistas cuando cambia el Modelo.

Vista: es el objeto que constituye la l´ogica de presentaci´on de una aplicaci´on, es decir, la capa que maneja la presentaci´on visual de los datos representados por el estado actual del Modelo. Genera una representaci´on visual del Modelo y muestra los datos al usuario. Interact´ua con el Modelo a trav´es de una referencia a ´el. La vista es la que presenta los eventos que el usuario puede activar en cada momento. Controlador: es el objeto que representa la l´ogica de control, es decir, la que proporciona la uni´on a toda la arquitectura. Cuando se realiza alg´un cambio, esta capa entra en acci´on, bien sea por cambios en la informaci´on del Modelo o por alteraciones de la Vista. Interact´ua con el Modelo a trav´es de una referencia al propio Modelo. Los servlets son los componentes que act´uan de controladores en

(15)

esta aplicaci´on web. Las tareas que deber´a gestionar el controlador son: • Seguridad: asegurar autentificaci´on y autorizaci´on.

• Identificaci´on de eventos.

• Preparar el modelo, asegurar la disponibilidad de los componentes de modelo requeridos.

• Procesamiento del evento, seleccionando el manejador m´as apropiado. • Gesti´on de errores, gestionar los errores generados por los manejadores. • Activar la generaci´on de la respuesta, pasando el control al generador

apropiado.

El flujo seguido por el controlador es el siguiente:

1. El usuario interact´ua con la vista (Interfaz de usuario).

2. El controlador recibe (por parte de los objetos de la vista) la notificaci´on de la acci´on solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a trav´es de un gestor de eventos.

3. El controlador accede al modelo para recoger la informaci´on solicitada por el usuario, actualizando o insertando en el modelo nueva informaci´on.

4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo. El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podr´ıa utilizar el patr´on Observador para proveer cierta indirecci´on entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun as´ı el modelo en s´ı mismo sigue sin saber nada de la vista. El controlador no pasa objetos del modelo a la vista aunque puede dar la orden a la misma para que se actualice.

(16)

Luego una de las grandes ventajas de utilizar esta arquitectura es que permite distribuir el trabajo de creaci´on de una aplicaci´on por niveles, de este modo, se podr´ıa crear un grupo de trabajo que estuviera totalmente abstra´ıdo del resto de niveles, simplemente ser´ıa necesario conocer la API (Interfaz de Aplicaci´on) que existe entre los diferentes niveles. La divisi´on en capas reduce la complejidad, facilita la reutilizaci´on y acelera el proceso de ensamblar o desensamblar alguna capa, o sustituirla por otra distinta en un futuro si fuera necesario.

1.2.2.

Arquitectura SOA (Service Oriented Architecture)

La Arquitectura Orientada a Servicios es un concepto de arquitectura de software que define la utilizaci´on de servicios para dar soporte a los requisitos del negocio. La funcionalidad deseada de esta arquitectura se descompone en servicios que pueden ser distribuidos en diferentes nodos conectados a trav´es de una red y que, asimismo, son combinados entre s´ı para alcanzar el resultado deseado. Estos servicios pueden proporcionar datos a otros o llevar a cabo actividades de coordinaci´on entre uno o varios servicios.

Las unidades b´asicas son los servicios, los cuales desarrollan su actividad de forma independiente. En lugar de que los servicios contengan en su c´odigo fuente llamadas a otros, se definen protocolos que describen c´omo pueden comunicarse entre s´ı.

La colaboraci´on entre servicios consiste en la determinaci´on de la secuencia de operaciones que debe acontecer en la interacci´on entre clientes y servidores. La secuencia debe respetar el orden establecido para que pueda ser v´alida, y con el objeto de que esto resulte viable, se define un protocolo de coordinaci´on que ser´a el encargado de describir el conjunto de secuencias v´alidas. Existen dos modelos de colaboraci´on entre servicios: orquestaci´on y coreograf´ıa.

La Arquitectura Orientada a Servicios depende completamente de los datos y servicios descritos a trav´es de los correspondientes metadatos, independientemente de cu´al sea el mecanismo para su obtenci´on. Debe reunir dos requisitos:

(17)

los metadatos, que tienen que entregarse de forma que puedan ser utilizados directamente por los propios sistemas.

Simult´aneamente, permitir que los dise˜nadores puedan entenderlo y usarlos de la manera adecuada.

La finalidad de la arquitectura SOA es conseguir combinar m´odulos funcionales para generar aplicaciones de car´acter espec´ıfico, proviniendo todos los servicios preexistentes. Cuanto mayor sea la funcionalidad proporcionada por estos m´odulos menor ser´a el n´umero de interfaces necesarias para alcanzar el objetivo deseado y cada interfaz conlleva un gasto de procesamiento adicional; sin embargo, cuando los m´odulos son excesivamente grandes resulta complicada su reutilizaci´on. Es necesario alcanzar el nivel de granulaci´on adecuado. Una de las claves de SOA es que no existen interacciones entre los m´odulos que se encuentren embebidas. La interacci´on entre los servicios, los cuales son independientes, es especificada por los usuarios. De ah´ı la necesidad de que los servicios presentan mayor funcionalidad que las tradicionales funciones o clases de los lenguajes de programaci´on evitando la desbordante complejidad que produce la existencia de miles de objetos granulares supondr´ıa para el dise˜nador. Los servicios en s´ı mismo se desarrollan mediante el uso de lenguajes de programaci´on (Java en este caso). Los servicios SOA presentan un acoplamiento bajo, en oposici´on a las funciones que componen un fichero ejecutable. Los servicios se ejecutan en el interior de un envoltorio (wrapper) como Java, que se encarga de la gesti´on de la memoria, las invocaciones de los servicios, y el uso de tipos de datos.

En un entorno SOA, los servicios pueden ser utilizados sin conocimiento alguno de las caracter´ısticas de la plataforma sobra la que se despliegan.

Los requisitos de que una arquitectura sea Orientada a Servicios son:

Los servicios deben ser reutilizables.

Los servicios deben proporcionar un contrato formal. Los servicios deben tener bajo acoplamiento.

(18)

Los servicios deben permitir la composici´on. Los servicios deben ser aut´onomos.

Los servicios no deben tener estado.

Los servicios deben poder ser descubiertos.

1.2.3.

Arquitectura del Proyecto

En este proyecto fin de carrera se ha utilizado una Arquitectura MVC (Modelo-Vista-Controlador) en tres capas Orientado a Servicios (SOA).

Se deseaba una arquitectura que permitiese trabajar en capas y de disponer de la flexibilidad necesaria para poder emplear un cliente ligero (navegador web). Por lo que se eligi´o el patr´on MVC que permite una separaci´on limpia entre las distintas capas de una aplicaci´on.

Figura 1.2: Introducci´on. Arquitectura MVC orientada a Servicios.

La figura 1.2 muestra gr´aficamente la arquitectura utilizada en este proyecto fin de carrera. Como se puede observar existen las tres capas de la arquitectura MVC: capa de

(19)

presentaci´on (Interfaz de Usuario), capa de negocio y capa de persistencia. Por otro lado se puede observar como la capa de negocio es la que interact´ua con los servicios web.

1.3.

Tecnolog´ıas

En esta secci´on se explica las diferentes tecnolog´ıas que podr´ıan ser aplicadas en cada una de las capas de la arquitectura de este proyecto fin de carrera. Despu´es, de conocer las diferentes alternativas, se comenta cu´al ha sido la seleccionada.

1.3.1.

Capa de Presentaci´

on

Algunas de las alternativas tecnol´ogicas para la capa de presentaci´on (Interfaz de Usuario) son las que se presentan a continuaci´on:

Apache Struts [13]: Es una herramienta de soporte para el desarrollo de aplicaciones web bajo el patr´on MVC. Struts permite reducir el tiempo de desarrollo. Su car´acter de software libre y su compatibilidad con todas las plataformas en las que Java Enterprise est´e disponible lo convierten en una herramienta altamente disponible.

Spring Web MVC [14]: Es uno de los m´odulos del framework de Spring, y como su propio nombre nos indica implementa una arquitectura Modelo - Vista - Controlador que puede ser utilizada como base para el desarrollo de una aplicaci´on web.

Apache Tapestry [15]: Es un framework de c´odigo abierto para la creaci´on de aplicaciones web de forma din´amica, robusta y altamente escalable en Java. Tapestry complementa y construye desde el est´andar Java Servlet API, funcionando tambi´en en cualquier servidor de aplicaciones.

JavaServer Faces (JSF) [7]: Es el est´andar presentado por Sun para la capa de presentaci´on web. Forma parte de la especificaci´on J2EE 5 -que deber´an cumplir todos los servidores de aplicaciones- y se erige como una evoluci´on natural

(20)

de los frameworks actuales hacia un sistema de componentes. Es un est´andar sencillo que aporta los componentes b´asicos de las p´aginas web adem´as de permitir crear componentes m´as complejos (men´us, pesta˜nas, ´arboles,...). Existen diferentes implementaciones de la especificaci´on, tanto comerciales como de c´odigo abierto, as´ı como librer´ıas de componentes adicionales que ampl´ıan la funcionalidad de esos componentes iniciales.

Finalmente, seg´un fue indicado por la administraci´on, se ha utilizado JavaServer Faces para el desarrollo de esta capa. JavaServer Faces dispone de diferentes proyectos que la implementan, y en este proyecto se ha optado por utilizar MyFaces ya que ofrece la funcionalidad necesaria para la aplicaci´on. Adem´as, por iniciativa propia y previo consentimiento de la administraci´on, se ha incluido el framework PrimeFaces que ofrece mayor funcionalidad a JSF. En la versi´on 2.0 de JSF se incluye la librer´ıa JavaServer Facelets, la cual permite crear plantillas para la construcci´on de las diferentes p´aginas web de la aplicaci´on.

1.3.1.1. MyFaces

MyFaces [9] es un proyecto de la fundaci´on Apache que ofrece una implementaci´on en c´odigo abierto de JavaServer Faces, as´ı como un amplio conjunto de componentes adicionales. A lo largo del tiempo se van incorporando componentes cada vez m´as potentes. En un principio la administraci´on pretendi´o utilizar Oracle ADF Faces Rich Client [10], pero dado que se obtuvieron bastantes problemas a la hora de comprobar la accesibilidad de las p´aginas se decidi´o no utilizar este framework y en su lugar usar MyFaces.

1.3.1.2. PrimeFaces

PrimeFaces [11] es una librer´ıa c´odigo abierto (licencia apache v2) para JavaServer Faces. Esta tecnolog´ıa ofrece un conjunto de componentes ricos para facilitar la creaci´on de aplicaciones web. PrimeFaces se divide principalmente en tres m´odulos (totalmente

(21)

independientes):

El primero es el conjunto de componentes para las interfaces de usuario.

El segundo m´odulo llamado Optimus utiliza Guice para poder crear managed beans utilizando anotaciones, simplificar la navegaci´on entre p´aginas e integrar PrimeFaces con JPA, transacciones y otras.

Y un tercer m´odulo llamado FacesTrace permite monitorizar aplicaciones JavaServer Faces.

1.3.1.3. JavaServer Facelets

JavaServer Facelets [12] es un framework para plantillas centrado en la tencolog´ıa JSF, por lo cual se integran de manera muy f´acil. Sus caracter´ısticas m´as importantes son:

Tiempo de desarrollo cero de los tags para UIComponents.

Facilidad en la creaci´on de plantillas para los componentes y p´aginas. Habilidad de separar los UIComponents en diferentes archivos.

Un buen sistema de reporte de errores.

Soporte completo a EL (Expression Language). Validaci´on de EL en tiempo de construcci´on.

No es necesaria configuraci´on XML. Trabaja con cualquier RenderKit.

El uso de plantillas en la aplicaci´on trae consigo las ventajas de tener un c´odigo ordenado (muy ´util para las aplicaciones grandes), f´acil de desarrollar y de reutilizar.

Existen otras tecnolog´ıas que podr´ıan haber sido utilizadas para la creaci´on de esas plantillas, pero debido a que este framework ya est´a integrado en JSF 2.0 no fue necesario buscar una mejor soluci´on ya que ´esta cumple con las necesidades del proyecto.

(22)

1.3.2.

Capa de Negocio

Algunas de las alternativas tecnol´ogicas para la capa de negocio son las que se presentan a continuaci´on:

Spring [4]: es un conjunto de librer´ıas “a la carta” entre las que podemos escoger aquellas que faciliten el desarrollo de nuestra aplicaci´on. Entre sus posibilidades m´as potentes est´a su contenedor de Inversi´on de Control (conocido como Inyecci´on de Dependencias, es una alternativa a las cl´asicas b´usquedas de recursos v´ıa JNDI. Permite configurar las clases en un archivo XML y definir en ´el las dependencias. De esta forma la aplicaci´on se vuelve muy modular y a la vez no adquiere dependencias con Spring), la introducci´on de aspectos, plantillas de utilidades para Hibernate, iBatis y JDBC as´ı como la integraci´on con JSF.

PicoContainer [5]: Es un framework altamente integrable, de servicio completo, con un contenedor de Inversi´on de Control (IoC) para los componentes del patr´on de inyecci´on de dependencias. PicoContainer soporta diferentes tipos de inyecci´on de dependencias (Constructor, Setter, Anotaciones) y ofrece m´ultiples ciclo de vida y estrategias de vigilancia. Es una herramienta de c´odigo abierto y ha sido originalmente implementada en Java, pero tambi´en est´a disponible para otras plataformas e idiomas.

Apache HiveMind [6]: Es un microkernel de servicios y configuraci´on. Sus caracter´ısticas son conocidas como contenedor de Inversi´on de Control (IoC) o contenedor ligero. Un problema muy importante en la actualidad, es la falta de documentaci´on sobre la versi´on 2.0 de este framework, ya que est´a en pleno desarrollo.

Finalmente, seg´un fue indicado por la administraci´on, se ha utilizado Spring para el desarrollo de esta capa. Spring es uno de los proyectos m´as sorprendentes en el panorama actual en Java en el grado en que ayuda a que los diferentes componentes que forman una aplicaci´on trabajen entre s´ı, pero no establece apenas dependencias consigo mismo.

(23)

Ser´ıa posible retirarlo sin cambiar muchas l´ıneas de c´odigo, lo ´unico que ser´ıa necesario es, l´ogicamente, a˜nadir la funcionalidad que provee, ya sea con las otras tecnolog´ıas mencionadas previamente o mediante la creaci´on de c´odigo propio. A nivel de soporte de la comunidad, Spring es uno de los proyectos con m´as actividad.

1.3.2.1. Spring OXM

Spring Object/XML Mapping [37] es un m´odulo que ofrece Spring con el prop´osito de convertir los objetos a XML y viceversa. El proceso de conversi´on es tambi´en conocido como XML Marshalling o Serializaci´on XML. Este framework opera a trav´es de dos interfaces globales:

Marshaller es el responsable de serializar un objeto (gr´afico) a XML. Unmarshaller es el responsable de deserializar el XML a un objeto gr´afico.

El XML generado puede adoptar la forma de un documento DOM, un input/output stream, o un manejador de SAX. Dentro de este m´odulo hay diferentes implementaciones para llevar a cabo la tarea, entre las cuales cabe destacar las siguientes:

Castor [34]: Es un framework de c´odigo abierto que permite transformar los datos contenidos en un modelo de objetos java en un fichero XML y viceversa.

XStream [35]: Es una simple librer´ıa con la que serializar los objetos a XML y viceversa. No necesita ning´un mapeo y genera ficheros XML de forma limpia. JAXB [36]: Es una tecnolog´ıa, que al igual que las anteriores, su objetivo es convertir los datos de un objeto java en un fichero XML o viceversa. Una novedad que incorpora es la posibilidad de indicar qu´e clases Java ser´an convertidas mediante anotaciones.

La administraci´on en un principio indic´o que se deber´ıa utilizar Castor para la elaboraci´on de la tarea. Sin embargo, despu´es de evaluar y realizar pruebas con JAXB, fue

(24)

propuesta como una mejor soluci´on. Por lo tanto se termin´o usando esta ´ultima debido a que evita tener ficheros XML extra para la configuraci´on de las clases Java que se desean pasar a XML o viceversa, ya que JAXB permite realizar esta configuraci´on mediante anotaciones.

1.3.3.

Capa de Persistencia

Algunas de las alternativas tecnol´ogicas para la capa de persistencia son las que se presentan a continuaci´on:

Hibernate [32]: Es un motor de persistencia de c´odigo abierto. Permite mapear un modelo de clases a un modelo relacional sin imponer ning´un tipo de restricci´on en ambos dise˜nos. Cuenta con una amplia documentaci´on, tanto a nivel de libros publicados como manuales disponibles en su p´agina web. A nivel comercial est´a respaldado por JBoss, que proporciona servicios de soporte, consultor´ıa y formaci´on en el mismo.

iBatis [18]: No es exactamente un mapeador objeto-relacional, hablando en el sentido expl´ıcito del t´ermino. Es un sistema para mapear objetos contra una base de datos relacional mediante DAO’s en donde todo el c´odigo en SQL debe ser escrito. Parece un proyecto muy interesante cuando hay que trabajar contra un modelo de base de datos ya existente, si el mismo es muy complejo o si tiene muchas peculiaridades o defectos de dise˜no.

Apache Torque [17]: Es un mapeador objeto-relacional para Java. Es decir, es una herramienta que permite acceder y manipular informaci´on de una base de datos relacional utilizando objetos Java. Con Torque se puede realizar una aplicaci´on independiente de una base de datos espec´ıfica.

Finalmente, seg´un fue propuesto por la administraci´on, se ha utilizado Hibernate para el desarrollo de esta capa. El motivo de uso, en gran medida, ha venido proporcionado por la anotaciones que permite incorporar esta tecnolog´ıa en las clases Java para realizar

(25)

el mapeo entre el modelo de clases y el modelo relacional, con lo que se evitar´ıa tener m´as ficheros XML de configuraci´on.

1.3.4.

Base de Datos

Algunas de las alternativas tecnol´ogicas para la creaci´on de una base de datos son las que se presentan a continuaci´on:

MySQL [31]: Es un sistema de gesti´on de base de datos relacional, multihilo y multiusuario. Su popularidad como aplicaci´on web est´a muy ligada a PHP. MySQL es una base de datos bastante r´apida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modificaci´on. En esta aplicaci´on web nos encontramos con una baja concurrencia en la modificaci´on de datos y nuestro entorno es intensivo en lectura de los mismos, con lo cual, se deduce de lo anteriormente explicado que MySQL es una buena opci´on para incluir en la aplicaci´on.

Oracle [30]: Es otro sistema de gesti´on de base de datos relacional, multihilo y multiusuario desarrollado por Oracle Corporation y es bastante completo en cuanto a la funcionalidad que ofrece esta herramienta. Este framework se basa en la tecnolog´ıa cliente/servidor. Dispone de una versi´on gratuita Oracle Express Edition, y utiliza PL/SQL, ´este es un lenguaje bastante potente para tratar y gestionar la base de datos.

Finalmente, por indicaci´on de la administraci´on, se ha utilizado Oracle para la elaboraci´on del modelo de datos de la aplicaci´on. El principal motivo por el cual no se ha utilizado MySQL est´a estrechamente ligado con la continuidad y el mantenimiento del proyecto, ya que las personas que m´as adelante terminar´an la aplicaci´on tienen un conocimiento muy extenso sobre Oracle.

(26)

1.3.5.

Servicios Web

Un servicio web es b´asicamente una funci´on o procedimiento que puede ser accedido v´ıa web por cualquier programa o aplicaci´on sin importar en que plataforma reside el servicio o en que lenguaje ha sido desarrollado. El t´ermino “web” implica que el acceso se hace mediante una conexi´on a Internet habitualmente v´ıa HTTP, aunque pueden ser utilizados otros protocolos de transporte. A trav´es del organismo WS-I se intenta mejorar la interoperabilidad entre distintas implementaciones de servicios Web. WS-I est´a encargado de desarrollar diversos perfiles para definir de manera m´as exhaustiva estos est´andares.

Algunas de las alternativas tecnol´ogicas para la creaci´on de servicios web son las que se presentan a continuaci´on:

Apache CXF [25]: Es un framework de servicios de software libre. CXF nos ayuda a construir y desarrollar servicios utilizando JAX-WS como API de programaci´on. Estos servicios pueden “hablar” una gran variedad de protocolos como SOAP, XML/HTTP, HTTP RESTful o CORBA, y pueden trabajar sobre transportes como HTTP, JMS o JBI. Sus caracter´ısticas principales son:

• Soporte para est´andares de Servicios Web: CXF soporta varios est´andares de servicios web incluyendo a SOAP, el Perfil B´asico, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging y WS-Security.

• Interfaces: CXF da soporte a varios modelos de programaci´on como “interfaz”. CXF implementa el API JAX-WS. Tambi´en incluye una interfaz simple que permite crear clientes y endpoints sin utilizar anotaciones. CXF soporta el desarrollo por contrato primero con WSDL, y el desarrollo por c´odigo primero comenzando desde Java.

• Facilidad de uso: CXF est´a dise˜nado para ser intuitivo y f´acil de usar. Hay APIs simples para construir servicios comenzando por el c´odigo, plug-ins de Maven para integrar esta herramienta, soporte para el API JAX-WS, soporte de XML de Spring 2.0 y posteriores, para facilitar la configuraci´on.

(27)

• Soporte para protocolos binarios y legacy: CXF fue dise˜nado para proveer una arquitectura extensible que no s´olo soporte XML sino tambi´en otros binding no-XML, como JSON y CORBA, en combinaci´on con cualquier tipo de transporte.

Apache Axis 2 [26]: Es un framework que implementa la especificaci´on JAX-WS del Java Comunity Process, WS-Messging y WS-Security. Esta versi´on ha mejorado bastante en la documentaci´on ofrecida y la estabilidad de las versiones iniciales. Existen implementaciones disponibles en Java y C.

Spring Web Services [27]: Es un producto de la comunidad de Spring centrado en la creaci´on de servicios web. Tiene como objetivo facilitar el desarrollo de estos servicios mediante el protocolo SOAP.

Finalmente, la administraci´on indic´o el uso de Apache CXF para el desarrollo de los servicios web que va a consumir y publicar la aplicaci´on. Despu´es de evaluar la alternativa de Spring Web Services fue propuesta para su uso, pero la administraci´on no lo permiti´o debido a que CXF dispone de cierta funcionalidad que ser´ıa utilizada m´as adelante por la aplicaci´on, y Spring, actualmente, no dispone de ella.

1.3.5.1. SOAP (Simple Object Access Protocol)

SOAP [28] es un protocolo est´andar que define c´omo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Este protocolo deriva del protocolo XML-RPC, ´este es un protocolo de llamada a procedimiento remoto que usa XML para codificar los datos y HTTP como protocolo de transmisi´on de mensajes. SOAP fue creado por Microsoft, IBM y otros. Actualmente est´a bajo el auspicio de la W3C.

1.3.6.

Otras tecnolog´ıas

En este apartado se comentan el resto de las tecnolog´ıas que utiliza el proyecto y que no se han mencionado en las secciones anteriores.

(28)

1.3.6.1. Apache Log4J

Log4J [19], librer´ıa de c´odigo abierto de Apache, es la opci´on de referencia para gestionar todos los aspectos de los logs de desarrollo. La inserci´on del log en nuestro c´odigo permite su depuraci´on ya que a veces es posible que no se disponga de un depurador. Con log4j es posible habilitar el log en tiempo de ejecuci´on sin necesidad de modificar la aplicaci´on. El comportamiento del log se controla mediante la edici´on de un archivo de configuraci´on.

1.3.6.2. J2EE (Java Enterprise Edition)

J2EE es una plataforma de programaci´on para desarrollar y ejecutar software de aplicaciones en el Lenguaje de programaci´on Java, bas´andose ampliamente en componentes de software modulares ejecut´andose sobre un servidor de aplicaciones.

Java es un lenguaje de programaci´on orientada a objetos desarrollado por Sun Microsystems en los a˜nos 90. Su sintaxis es similar a la de lenguajes como C/C++ pero abstrayendo al programador de herramientas de bajo nivel como pueden ser el acceso directo a la memoria (reserva y liberaci´on) y el manejo de punteros.

Una aplicaci´on Java se ejecuta sobre una M´aquina Virtual de Java (JVM), que se encarga de ejecutar el c´odigo generado por la compilaci´on previa de la aplicaci´on. Ese c´odigo generado, denominado bytecode es el obtenido utilizando el compilador de Java, de manera que cualquier m´aquina virtual sea capaz de ejecutarlo.

Los aspectos m´as importantes de Java son:

Es orientado a objetos. Se trata de un paradigma de programaci´on que abstrae las estructuras de datos utilizadas por los programadores en objetos, entidades que se componen de tres partes:

• Estado: Se compone de los atributos, que almacenan la informaci´on referente al objeto, que tendr´a unos valores concretos.

(29)

• Comportamiento: Est´a definido por los m´etodos, que representan las opera-ciones que se pueden realizar sobre los objetos.

• Identidad : Se trata de una propiedad que consigue que cada objeto sea diferente del resto.

Independencia de la plataforma. La filosof´ıa de Java dice que cualquier aplicaci´on escrita en Java puede ser ejecutada en cualquier tipo de plataforma, como dice su lema “write once, run everywhere”.

Recolector de basura. En Java no es posible liberar la memoria de los objetos reservados, de ello se encarga el Recolector de Basura (Garbage Collector - GC). Este recolector libera la memoria de los objetos cuando ya no quedan referencias a los mismos, se˜nal de que no van a ser utilizados en el resto del c´odigo.

1.3.6.3. JasperReport

JasperReports [20] es una herramienta, muy buena, de c´odigo libre para generar informes. Puede entregar ricas presentaciones o dise˜nos en la pantalla, para la impresora o para archivos en formato PDF, HTML, RTF, XLS, CSV y XML. Est´a completamente escrita en Java y se puede utilizar en una gran variedad de aplicaciones de Java, incluyendo J2EE o aplicaciones web, para generar contenido din´amico.

La administraci´on decidi´o el uso de esta tecnolog´ıa ya que facilita la elaboraci´on de los informes y la obtenci´on de ´estos en formato PDF, con lo que cumplir´ıa con una parte de la funcionalidad de la aplicaci´on

1.3.6.4. Apache Ant

Apache Ant [22] es una herramienta usada para la realizaci´on de tareas mec´anicas y repetitivas. Ant utiliza uno o m´as documentos XML que enumeran todo lo que hay que hacer. El fichero XML en el que se basa Ant debe ser llamado build.xml, ´este es denominado fichero de construcci´on. La ventaja de esta herramienta es que se puede

(30)

ejecutar en cualquier plataforma ya que est´a escrita con el lenguaje de programaci´on Java.

1.3.6.5. Apache Maven

Apache Maven [23] es una herramienta de gesti´on de proyectos de software y de comprensi´on. Basado en el concepto de un modelo de objetos de proyecto (POM), Maven puede administrar un proyecto de construcci´on, elaboraci´on de informes y la documentaci´on de una pieza central de la informaci´on.

Inicialmente la administraci´on propuso la utilizaci´on de Maven para la creaci´on del proyecto web, y mediante el fichero POM ir incluyendo al proyecto las librer´ıas necesarias para su desarrollo. Pero debido a su complejidad de uso para la inclusi´on de nuevas tecnolog´ıas en el proyecto, se propuso a la administraci´on la posibilidad dejar de utilizarla. Por lo tanto, las tecnolog´ıas son incluidas mediante sus correspondientes ficheros JAR en el directorio WEB-INF/lib del proyecto.

(31)

En este cap´ıtulo, primero se exponen los motivos que me han llevado a realizar el proyecto que se presenta en esta memoria y a continuaci´on, se describen los objetivos que se pretenden conseguir y que nos dar´an una soluci´on al problema planteado:

2.1.

Descripci´

on General del Problema

La administraci´on p´ublica, para la cual se est´a elaborando este proyecto, necesita disponer de una aplicaci´on estable y eficiente a partir de las tecnolog´ıas propuestas por ella para cada parte de la arquitectura del proyecto (ver secci´on 1.3).

Por lo tanto, primero ser´an evaluadas esas tecnolog´ıas con el prop´osito de comprobar que cumplen con la funcionalidad esperada y, despu´es, ser´an utilizadas para la construcci´on de una sencilla aplicaci´on inicial con alguno de los procedimientos administrativos que ofrece dicha administraci´on actualmente en su oficina.

En la actualidad ciertos usuarios necesitan entregar informaci´on a la administraci´on, por lo que deben ir en persona varias veces, una para ir a recoger los papeles y otra para realizar su entrega, con la correspondiente p´erdida de tiempo en la realizaci´on de dichas tareas.

(32)

La aplicaci´on web que se presenta en este proyecto fin de carrera pretende solucionar dicha situaci´on mediante el uso de las diferentes tecnolog´ıas expuestas en la secci´on 1.3, por lo que los usuarios se ahorran tiempo en ir a recoger los papeles ya que podr´an conseguirlos a trav´es de la web y rellenarlos. Despu´es, dependiendo de la elecci´on del usuario, dispondr´a de la opci´on de poder entregar los papeles a trav´es de la SEDE. Esto supondr´a al cliente un gran beneficio ya que desde su propio domicilio podr´a llevar a cabo este proceso sin necesidad de acudir a la administraci´on.

Desde el punto de vista de la administraci´on, ´esta obtendr´a grandes beneficios ya que podr´a procesar grandes cantidades de informaci´on con mayor rapidez y pudiendo disponer de menos personal. El hecho de eliminarlo completamente se plantea imposible ya que parte de los usuarios no dispondr´an de los medios adecuados para realizar la entrega de la documentaci´on a trav´es de la sede y su opci´on ser´a llevarla de forma personal o presentarla mediante una llamada telef´onica. Otro beneficio para los usuarios es el menor tiempo de respuesta en ser atendidos por parte de la administraci´on.

Como la mayor parte de estos usuarios son personas mayores o con alguna discapacidad, la web ser´a dise˜nada en funci´on a los problemas de estas personas, luego la aplicaci´on debe cumplir con el certificado Doble-A de accesibilidad web. Por otro lado, la administraci´on dispondr´a de un horario telef´onico en el que se atender´an a aquellos ciudadanos que encuentren dificultades para llevar a cabo una tarea determinada.

Las funcionalidades de la aplicaci´on se pueden desarrollar utilizando diversas t´ecnicas y siguiendo diferentes protocolos de actuaci´on.

Adem´as, todos los usuarios que lo deseen tendr´an la posibilidad de consultar informaci´on sobre la administraci´on por medio de esta Sede Electr´onica.

2.2.

Objetivos del Proyecto

Una vez descritas las tecnolog´ıas que se van a utilizar para el desarrollo de este proyecto, se pasa a detallar los objetivos que se deber´an cumplir:

(33)

Evaluaci´on de las tecnolog´ıas: Se pretende obtener un conocimiento profundo de las principales tecnolog´ıas que engloban a este proyecto, las cuales son: JavaServer Faces, Spring, Hibernate, JasperReport, Apache CXF y Oracle. Con esto no quiere decir que el resto deban ser desconocidas sino que la profundidad de aprendizaje sobre las dem´as ser´a algo menor. Para la evaluaci´on de estas tecnolog´ıas se han utilizado las diferentes p´aginas web que proporcionan, adem´as de libros, art´ıculos, manuales y tutoriales que podemos encontrar de forma gratuita en Internet o en bibliotecas. Adem´as es muy importante el uso de los foros de estos frameworks ya que pueden resultar muy ´utiles para la resoluci´on de algunos problemas que puedan darse durante el empleo de la tecnolog´ıa.

Una vez obtenido el conocimiento suficiente de las tecnolog´ıas utilizadas, ser´an evaluadas para comprobar que cumplen con las expectativas deseadas. En el caso de no obtener la funcionalidad requerida ser´ıan evaluadas sus alternativas. Tambi´en es posible que se eval´uen las opciones disponibles con el fin de utilizar la que mejor rendimiento y funcionalidad proporcione.

Tecnolog´ıas con versiones recientes: Otro objetivo importante, impuesto por la administraci´on para la creaci´on del proyecto, es la utilizaci´on de los frameworks, anteriormente nombrados, en sus versiones m´as recientes ya que proporcionar´an, como regla general, un mejor rendimiento y seguramente incluyan nuevas caracter´ısticas que ser´an beneficiosas para el desarrollo.

Creaci´on de la aplicaci´on: El ´ultimo objetivo ser´a construir la aplicaci´on web mediante la configuraci´on y el uso de las diferentes tecnolog´ıas mencionadas en la secci´on 1.3. Para ello ser´a necesario tener en cuenta los requisitos del proyecto y los diferentes aspectos de dise˜no, los cuales ser´an detallados en la secci´on 3.5. Es decir, con este objetivo se pretende iniciar el desarrollo de una Sede Electr´onica para la administraci´on con un funcionamiento estable y capaz de atender las peticiones de todos los clientes que accedan a ella, ya que el n´umero de ´estos puede ser elevado en ciertos momentos.

(34)

La funcionalidad que se pretende obtener para el inicio de esta aplicaci´on es la posibilidad de que los usuarios puedan solicitar dos tipos de tr´amites: Solicitud de Copia de Contenido y Solicitud de Notificaci´on Simplificada. Por lo tanto, ser´a necesario que la aplicaci´on tenga acceso a dos formularios web, uno para cada tr´amite, y mediante ´estos los usuarios mandar´an sus solicitudes a la administraci´on v´ıa Internet, de forma presencial o telef´onica. En cualquier caso el usuario deber´a descargar el informe en formato PDF.

La otra funcionalidad que se desea conseguir es la consulta de informaci´on sobre la administraci´on por medio de esta aplicaci´on. Debido a que dicha informaci´on ser´a rellenada por la administraci´on y a la confidencialidad de ´esta, se ha utilizado un simple texto de relleno conocido como Lorem ipsum [40].

El beneficio principal que se obtendr´a con la creaci´on de este proyecto ser´a que los clientes tendr´an la posibilidad de acceder electr´onicamente a los servicios ofrecidos por la administraci´on sin necesidad de acudir en persona a la oficina, con lo que se ahorrar´an perder el tiempo en largas colas de espera. Por otro lado, las ganancias que obtendr´a la administraci´on p´ublica est´an relacionadas con la menor contrataci´on de personal y desarrollar de manera m´as ´agil y f´acil los tr´amites pertinentes, con el prop´osito de proporcionar una respuesta m´as r´apida al cliente.

(35)

Una vez explicados los conceptos m´as importantes para la comprensi´on del proyecto y detallados los objetivos que se pretenden conseguir con su implementaci´on, se describe a lo largo de este cap´ıtulo el proceso de desarrollo del sistema creado en este trabajo final de carrera.

En primer lugar, se explica la metodolog´ıa empleada para el desarrollo de la aplicaci´on web y a continuaci´on, se van describiendo con mayor detalle cada una de las fases de esa metodolog´ıa, de forma que se obtengan diferentes vistas del proyecto implementado, desde un nivel m´as abstracto hasta un nivel m´as detallado, para finalmente exponer una demostraci´on de la funcionalidad del sistema creado.

3.1.

Metodolog´ıa

Las metodolog´ıas de desarrollo ayudan a crear un sistema software siguiendo unas pautas para introducir el software deseado. En este proyecto, se ha usado un modelo de proceso de desarrollo similar al Modelo Iterativo e Incremental, ya que este modelo combina elementos del modelo cl´asico secuencial, formado por las etapas b´asicas del ciclo de vida del software, con la filosof´ıa iterativa de la construcci´on de prototipos.

(36)

Su desarrollo consiste en la segmentaci´on del proyecto completo en peque˜nos periodos de tiempo denominados iteraciones, donde cada iteraci´on es una secuencia de las fases de an´alisis, dise˜no, implementaci´on y pruebas. Al final de cada iteraci´on se obtiene un prototipo del sistema a desarrollar, y si el prototipo necesita mejorarse o ampliarse, se planifica el siguiente incremento y se itera de nuevo hasta conseguir el producto final. Esta metodolog´ıa presenta la ventaja de ser din´amica y flexible a los cambios, consiguiendo una gran adaptabilidad en la introducci´on de nuevos requisitos y en la modificaci´on de los ya existentes.

En cada fase de an´alisis, se tuvieron diferentes reuniones, normalmente una vez a la semana o a lo sumo cada quince d´ıas, con el supervisor del proyecto para realizar la captura de requisitos del sistema y especificar, en el caso de ser necesario, la alternativa tecnol´ogica a utilizar en cada parte de la arquitectura. Ya en las fases de dise˜no se lleva un trabajo m´as exhaustivo de estas tecnolog´ıas para quedarnos con una de ellas. En algunos casos no fue necesario elegir framework de desarrollo ya que ven´ıa impuesta por la administraci´on y adem´as cumpl´ıa con los requisitos del sistema. Sin embargo, algunas de las tecnolog´ıas fueron sustituidas por otras ya que ofrec´ıan mejor rendimiento y facilidad de uso, y para ello fue necesario comunic´arselo a la administraci´on, ya que ´esta es la que se encargar´a en un futuro de terminar la implementaci´on de la aplicaci´on.

En cada fase de dise˜no, como se coment´o anteriormente, primero fueron evaluadas cada una de las tecnolog´ıas seleccionadas para el desarrollo del proyecto, con el fin de comprobar que mediante su uso se podr´ıa obtener el resultado deseado. Despu´es se llev´o a cabo un estudio de cada una de esas tecnolog´ıas con el fin de que conseguir una aplicaci´on eficiente. Para obtener un conocimiento s´olido de ´estas se han utilizado manuales, art´ıculos, tutoriales, libros y foros de Internet. Una vez conocidos los aspectos m´as importantes de las tecnolog´ıas, se procedi´o al dise˜no de la funcionalidad del sistema bas´andome en la etapa previa de an´alisis. En alguna ocasi´on ha sido necesario el reemplazamiento de alg´un framework por otro de caracter´ısticas similares, siempre y cuando se consiguieran los mismos resultados y con mejor eficiencia, con el objetivo de utilizar las tecnolog´ıas con mejor rendimiento y simplicidad en su uso.

(37)

En cada fase de implementaci´on y pruebas, se realiza la codificaci´on de la aplicaci´on y los test necesarios para probar que el sistema funciona correctamente seg´un los requisitos previos y con la tecnolog´ıa adecuada para cada parte de la arquitectura. Con los resultados de esas pruebas y con las nuevas funcionalidades solicitadas se ten´ıa la informaci´on suficiente para proceder a una nueva iteraci´on sobre el prototipo creado e ir mejorando la funcionalidad de la aplicaci´on, hasta llegar al sistema que se presenta en este proyecto fin de carrera.

3.2.

Especificaci´

on de Requisitos

Un requisito es una descripci´on de c´omo se debe comportar el sistema, indicando las propiedades que debe cumplir el sistema que se va a desarrollar. No forman parte de los requisitos los detalles de dise˜no, implementaci´on o pruebas que se vayan a realizar, como tampoco lo es la planificaci´on del proyecto y sus necesidades.

3.2.1.

Requisitos Hardware y Sofware del Producto

3.2.1.1. Interfaces Hardware

Toda computadora desde la cual se desee utilizar este producto software deber´a dispon-er bien de una tarjeta de red (RJ45), bien de una tarjeta de red inal´ambrica (WIFI) o bien de un m´odem. A trav´es de alguno de ellos debe tener la posibilidad de conectarse con el servidor en el que se encuentra localizada la Sede Electr´onica v´ıa web (Internet) y as´ı poder realizar sus gestiones.

El servidor de la aplicaci´on deber´a disponer de una tarjeta de red (RJ45) mediante la cual estar´a conectado a Internet para que los clientes puedan establecer conexi´on con ´el y as´ı utilizar la aplicaci´on.

(38)

3.2.1.2. Interfaces Software

Los requisitos m´ınimos Software de la computadora del cliente deber´ıan ser los siguientes:

Sistema Operativo: Windows XP o superiores, Linux, Macintosh,...

Navegadores Web: Mozilla Firefox, Internet Explorer, Google Chrome, Opera, Safari,...

Acrobat Reader 8 o superiores.

En cuanto a la parte del servidor, deber´a cumplir con los siguientes requisitos: Sistema Operativo Windows XP o superiores,

Servidor de Aplicaciones Tomcat 5.5 o superiores,

Oracle 10g Express Edition. Crear cuenta de usuario con login “david” y password “david”,

J2EE 1.5 o superiores.

La memoria principal y secundaria de estos servidores ser´an las convenientes como para un funcionamiento holgado de las diferentes herramientas mencionadas. El servidor en el cual se ha desarrollado el producto software dispone de una memoria de 1 GigaBytes con la cual ha sido m´as que suficiente para la implementaci´on y las pruebas del software. Se debe tener en cuenta, por parte del cliente, que la aplicaci´on ha sido creada para ser utilizada con una resoluci´on m´ınima de 1280x800.

3.2.1.3. Interfaces de Comunicaciones

Para realizar cualquier gesti´on se deber´a disponer de conexi´on a Internet ya que la Sede Electr´onica estar´a alojada en la web. Luego las comunicaciones entre la Sede y el Cliente ser´an a trav´es de TCP/IP.

(39)

3.2.2.

Caracter´ısticas del Usuario

La aplicaci´on va a ser desarrollada para todo tipo de usuarios (incluso aquellos que tengan alguna discapacidad) que apenas tengan conocimientos de la web. El principal conocimiento que es requerido por el producto es el sencillo manejo de un ordenador. Luego el cliente debe tener algo de experiencia con la navegaci´on en Internet, aunque no demasiada, ya que sino le podr´a resultar algo complejo el uso de esta aplicaci´on web.

Todos los usuarios tendr´an la posibilidad de acercarse a la oficina o de hacer una llamada telef´onica para resolver las dudas o problemas que le vayan surgiendo mientras utiliza la aplicaci´on.

Como conclusi´on, el usuario debe tener los conocimientos b´asicos para acceder a Internet mediante un navegador web. No es necesaria ninguna experiencia previa con otras aplicaciones similares ya que el sistema le guiar´a de manera sencilla e intuitiva. Es aconsejable tener conocimientos elementales del uso de alg´un sistema operativo (como Linux, Macintosh o Windows).

3.2.3.

Requisitos Funcionales

Estos requisitos son los que capturan el comportamiento del sistema.

Cumplimiento de la Ley 11/2007.

El sistema deber´a poseer el certificado de accesibilidad Doble-A, con el fin de facilitar el uso de la aplicaci´on a todos los usuarios.

Los usuarios que hayan rellenado de forma correcta el formulario deber´an obtener dicha informaci´on en formato PDF. Necesario para aquellos usuarios que no dispongan de los medios adecuados para enviar dicha informaci´on a trav´es de la Sede Electr´onica.

Los formularios dispondr´an, en cada uno de los campos, una peque˜na ayuda con el fin de saber que informaci´on debe ser insertada en ´el. Adem´as lo usuarios tambi´en

(40)

tendr´an la posibilidad de realizar una llamada a la Administraci´on P´ublica para resolver sus dudas.

El sistema debe estar disponible en diferentes idiomas.

Los campos de los formularios ser´an comprobados para evitar introducir datos err´oneos en ´estos y provocar un fallo en la aplicaci´on, y s´olo cuando la informaci´on sea la correcta para cada campo se podr´a obtener el documento en formato PDF. Mediante este documento el usuario podr´a entregarlo en la administraci´on de forma personal, con una llamada telef´onica o v´ıa Internet.

La aplicaci´on debe garantizar que el env´ıo de los datos personales de los usuarios debe ser realizado mediante un protocolo de conexiones seguras (por ejemplo HTTPS).

El sistema no debe permitir realizar navegaciones incorrectas. Es decir, los usuarios no pueden acceder a recursos no disponibles en la aplicaci´on.

3.2.4.

Requisitos No Funcionales

Los requisitos no funcionales son aquellos que no han sido especificados por el cliente, pero que se espera que el sistema los recoja.

Funcionamiento correcto de la aplicaci´on en los navegadores de mayor importancia en la actualidad, los cuales son: Internet Explorer, Mozilla Firefox, Google Chrome, Opera y Safari.

La realizaci´on de cualquiera de estos tr´amites o la consulta de informaci´on se podr´a llevar a cabo en cualquier momento. Exceptuando los momentos que la aplicaci´on sufra de alguna ca´ıda por parte del servidor o en aquellos casos que se est´en realizando labores de mantenimiento del sistema.

El proyecto deber´a trabajar con los frameworks mencionados en sus versiones m´as recientes. Adem´as deber´a ser un sistema ligero, f´acil de mantener y escalable. Para

(41)

ello en las clases Java se han insertado las anotaciones oportunas con el fin de evitar tener ficheros innecesarios de configuraci´on y sobre todo ofrece una gran ventaja para el mantenimiento y la escalabilidad del sistema.

La creaci´on del proyecto se divide en tres m´odulos claramente diferenciados, que son los que corresponden con la arquitectura utilizada (Modelo - Vista - Controlador). Cada uno de estos m´odulos deber´a ser lo m´as independientemente posible con el fin de evitar solapamientos innecesarios. Adem´as esto permitir´a que la sustituci´on de un m´odulo por otro de caracter´ısticas similares o diferentes no afecten al resto de m´odulos.

El tiempo de acceso al sistema deber´a ser en el peor de los casos de varios segundos. El lenguaje utilizado en las interfaces de usuario ser´a sencillo y de f´acil comprensi´on. Deber´a ser un sistema multiusuario, es decir, deber´a permitir la conexi´on de varios usuarios sin provocar retardos innecesarios.

La distribuci´on de los componentes visuales en la interfaz debe permitir una c´omoda visualizaci´on de la informaci´on que se quiere mostrar al usuario.

El sistema debe responder adecuadamente ante cualquier imprevisto durante su ejecuci´on.

El sistema actual dispondr´a de una interfaz com´un para todos los usuarios. M´as adelante se podr´a extender dicha interfaz para el caso de usuarios registrados, no registrados y administradores, lo cual ser´a llevado a cabo seg´un las nuevas necesidades de la administraci´on.

3.2.5.

Funcionalidad de la aplicaci´

on

Los usuarios podr´an acceder a los formularios desde la p´agina principal de la Sede Electr´onica o desde cualquier otra p´agina a trav´es del men´u izquierdo de la web. En este momento el usuario entrar´a en una conexi´on segura para que pueda realizar el tr´amite con

(42)

la certeza de que ninguna otra persona sin autorizaci´on pueda acceder a su informaci´on privada. Luego se le mostrar´a una peque˜na informaci´on sobre el formulario, es decir, las condiciones de uso y la privacidad de los datos insertados.

A continuaci´on deber´a seleccionar la forma de entrega de la documentaci´on. Dispondr´a de tres opciones: presencial, telef´onica o por Internet. En el caso de seleccionar la ´ultima deber´a introducir unos datos personales para su autenticaci´on. El usuario no necesita registrarse en el sistema para llevar a cabo esta gesti´on.

Una vez situados en dichos formularios el usuario deber´a rellenar todos los campos obligatorios como m´ınimo y los dem´as ser´an opcionales, pero es recomendable el insertar informaci´on en ellos. Si al usuario se le olvida introducir datos en algunos campos obligatorios o los inserta de forma err´onea el sistema le mostrar´a un mensaje de error en cada uno de esos campos.

Cuando el usuario ya haya introducido correctamente la informaci´on en el formulario se le mostrar´a una pantalla con los datos insertados y las opciones de descargar el informe en formato PDF (disponible para todas las formas de entrega) y de enviar dicho informe a la Administraci´on P´ublica (s´olo disponible para la entrega de los documentos a trav´es de la Sede). En el caso de no enviar el tr´amite deber´a imprimirlo y llevarlo a la oficina para realizar su entrega de forma presencial o tambi´en tendr´a la posibilidad de entregar dicha informaci´on de forma telef´onica, en el horario establecido por la Administraci´on.

El usuario en cualquier momento o p´agina en la que se encuentre tendr´a la posibilidad de cambiar el idioma de la aplicaci´on, con el fin de leer la informaci´on o realizar los tr´amites oportunos en el idioma que mejor se adapte a sus conocimientos. Las posibilidades que se ofrecen actualmente son “Castellano” o “Ingl´es”.

Como toda Sede Electr´onica dispone de informaci´on sobre la fecha y hora actual en la cabecera de la web, as´ı como una p´agina con dicha informaci´on.

Tambi´en se dispone de informaci´on sobre la accesibilidad de la aplicaci´on. Es decir, se muestran las teclas de acceso r´apido de la aplicaci´on y la combinaci´on de las teclas en dependencia del navegador que se est´e utilizando.

(43)

Por ´ultimo, el sistema ofrecer´a informaci´on sobre la administraci´on. Actualmente esa informaci´on no estar´a disponible ya que ser´a rellenada por ella misma, por lo que en su lugar se ha utilizando un texto simple de relleno.

3.3.

Arquitectura

En la secci´on 1.2.3 se explic´o la arquitectura a partir de la cual se desarrolla este proyecto. Por lo tanto, en este apartado se pretende explicar con mayor detalle cada una sus partes.

Mediante el patr´on MVC se separa los conceptos de dise˜no, y por lo tanto decrementa la duplicaci´on de c´odigo, la centralizaci´on del control y se consigue que la aplicaci´on sea m´as extensible. JavaServer Faces (JSF) encaja bien en la arquitectura de la capa de presentaci´on basada en MVC, por lo que ofrece una clara separaci´on entre el comportamiento y la presentaci´on, es decir, est´a totalmente desacoplado de la l´ogica de negocio de la aplicaci´on, la cual est´a completamente controlada por Spring.

Arquitectura en tres capas:

Capa de Presentaci´on: recoge la entrada del usuario, presenta los datos, controla la navegaci´on por las p´aginas y delega la entrada del usuario a la capa de la l´ogica de negocio. Se utiliza JavaServer Faces para las vistas, con los ManagedBean como clases de apoyo. Los ManagedBean realizan operaciones relacionadas con la capa de presentaci´on, cargan datos en las JSP (JavaServer Pages), recogen datos de las vistas y atienden a los eventos de los componentes visuales, los listener. Cuando quiere realizar operaciones se apoya en los servicios de negocio.

Capa de Negocio: los servicios de negocio interact´uan con otros objetos de negocio y proporcionan una l´ogica de negocio con un nivel de abstracci´on mayor. Se utiliza el marco de trabajo Spring, el cual est´a basado en el concepto de Inversi´on de Control (IoC). Tecnolog´ıa encargada de controlar la declaraci´on de servicios y la inyecci´on de unos en otros seg´un sus dependencias y necesidades.

(44)

Capa de Integraci´on o Acceso a Datos: se utiliza el marco de trabajo Hibernate, con el cual se evita la necesidad de utilizar el API JDBC. Su uso favorece el acceso a la informaci´on de la base de datos ya que ofrece facilidades para recuperaci´on y actualizaci´on de datos, control de transacciones, repositorios de conexiones a bases de datos, consultas program´aticas y declarativas, y un control de relaciones de entidades declarativas. El Hibernate Query Language, dise˜nado como una extensi´on m´ınima orientada a objetos de SQL, proporciona un puente elegante entre los mundos objeto y relacional. El patr´on DAO (Data Access Object) abstrae y encapsula todos los accesos a la base de datos. Las clases de implementaci´on de los DAO contiene l´ogica espec´ıfica de Hibernate para manejar los datos persistentes.

La Arquitectura SOA es un concepto de arquitectura software en la que dise˜namos la capa de negocio como un conjunto de servicios agrupados por su funcionalidad, los cuales hacen uso unos de otros seg´un la operativa del procedimiento. Se utiliza Spring como centro de la soluci´on.

3.3.1.

Justificaci´

on de la arquitectura elegida

Se eligi´o el uso del patr´on MVC ya que permite una separaci´on limpia entre las distintas capas de una aplicaci´on.

Para la capa de presentaci´on (la vista), la administraci´on buscaba un framework que nos proporcionase una mayor facilidad en la elaboraci´on de pantallas, mapeo entre los formularios y sus clases en el servidor, la validaci´on, conversi´on, gesti´on de errores, traducci´on a diferentes idiomas, y a ser posible, que facilitase tambi´en el incluir componentes complejos de una forma sencilla y f´acil de mantener. Por ello, la administraci´on decidi´o utilizar JavaServer Faces.

En la capa de negocio y persistencia, la administraci´on deseaba una soluci´on basada en servicios que trabajaban contra un modelo de dominio limpio. La persistencia de las clases se sustenta en DAO’s, manteniendo aislada la capa de persistencia de la capa de negocio. Tanto los servicios como los DAO’s, as´ı como el propio modelo, son realmente

(45)

POJOs (clases simples de Java), con la simplicidad que conllevan y sin dependencias reales con ning´un framework concreto. Por ello, la administraci´on decidi´o usar Spring para el desarrollo de esta capa.

Para la capa de persistencia, la administraci´on pensaba en el uso de alguna herramienta ya existente, que permitiese el mapeo objeto-relacional de una forma c´omoda pero potente, sin tener que implementarlo directamente mediante JDBC. Esto llevar´ıa un gran esfuerzo en el caso de producirse un cambio de base de datos. Luego la herramienta elegida para el desarrollo de esta capa es Hibernate.

En la parte de los servicios web, la administraci´on deseaba usar Apache CXF ya que es un framework muy f´acil de utilizar e incluir en el proyecto con el resto de las tecnolog´ıas. Adem´as dispone de mayor funcionalidad que algunas de sus alternativas.

Y por ´ultimo, la administraci´on decidi´o utilizar como sistema de gesti´on de base de datos Oracle ya que es de los software m´as completos que existen actualmente, adem´as de cumplir con las necesidades del proyecto.

3.3.2.

Beneficios de la arquitectura dise˜

nada

La primera ventaja se deriva de la modularidad del dise˜no, lo cual era un objetivo claro para la administraci´on. Cada una de las partes empleadas (JSF para la vista, Spring para la integraci´on, Hibernate para la persistencia) es intercambiable de forma sencilla y limpia por otras soluciones disponibles. Por ejemplo, para la vista se emplea JavaServer Faces, pero nada impide emplear tambi´en una aplicaci´on de escritorio mediante Swing o SWT sin tener que tocar ni una solo l´ınea de c´odigo de las restantes capas. Es m´as, nada impedir´ıa que se pudiera disponer de una aplicaci´on con una parte de la capa de presentaci´on en JSF y otra parte, para otro tipo de usuario, en Swing, ambas funcionando a la vez y compartiendo todo el resto del c´odigo (l´ogica de negocio, persistencia, integraci´on, seguridad, etc).

De la misma forma, si se desean cambiar elementos de la capa de persistencia empleando otro framework para el mapeo diferente de Hibernate -o sencillamente no

(46)

utilizar ninguno- tan s´olo ser´ıan necesarios cambios en dicha capa, sin que las dem´as se vean afectadas.

De igual manera se podr´ıan sustituir cualquiera de las otras capas ya que el dise˜no se ha hecho reduciendo al m´ınimo posible las dependencias entre ellas.

3.4.

An´

alisis

El objetivo de la fase de an´alisis es realizar una especificaci´on m´as precisa de los requisitos, aumentando el nivel de formalismo. Para ello, se utilizar´an una serie de diagramas que nos ofrece el lenguaje de modelado UML. Con el an´alisis, se facilita la comprensi´on, preparaci´on, modificaci´on y mantenimiento de los requerimientos expuestos en la secci´on 3.2, creando una primera aproximaci´on al modelo de dise˜no.

Antes de realizar el dise˜no de la aplicaci´on, deber´ıan ser evaluadas las tecnolog´ıas indicadas por la administraci´on para el desarrollo de cada una de las partes de la arquitectura de este proyecto. Con el prop´osito de utilizar la tecnolog´ıa adecuada y mejor adaptada al resto del proyecto.

Para realizar el an´alisis de estas tecnolog´ıas, fue necesario la lectura y comprensi´on de ´estas mediante libros, art´ıculos, manuales o tutoriales que se pueden encontrar tanto en sus respectivas p´aginas web como en bibliotecas. Y una vez obtenido el conocimiento adecuado se podr´ıa considerar cual cumple y cual no con las necesidades del proyecto. En el caso de que alguna no fuera ´util, ser´ıan evaluadas sus alternativas y elegida la mejor de ellas. Pero antes de ser implantada en el proyecto se avisar´ıa de tal modificaci´on a la administraci´on y seg´un su respuesta se actuar´ıa en consecuencia.

3.4.1.

Diagramas de Casos de Uso

Un caso de uso es una descripci´on de un conjunto de secuencias de acciones que ejecuta un sistema, produciendo un resultado de inter´es para un actor. Una vez capturados los requisitos, en esta secci´on identificamos los casos de uso del sistema junto con los actores

(47)

que participan en ´el.

Figura 3.1: An´alisis. Diagrama de casos de usos general.

La figura 3.1 muestra el diagrama de casos de uso general de la aplicaci´on que se ha desarrollado de forma general. El usuario podr´a interactuar con el sistema para la obtenci´on de informaci´on de la Administraci´on P´ublica o para la realizaci´on de alg´un tr´amite que desee presentar en ella.

A continuaci´on, se explica de forma m´as detallada cada caso de uso y su interacci´on con el usuario:

3.4.1.1. Caso de uso: visualizaci´on de informaci´on

Este caso de uso comenzar´a cuando el usuario entre en la aplicaci´on y desee visualizar cualquier informaci´on que est´e disponible en ella. En la figura 3.2 se puede observar que s´olo existe un tipo de actor, el cual ser´a uno o varios usuarios que a trav´es de Internet establecer´an conexi´on con la aplicaci´on y podr´an obtener la informaci´on que deseen de la administraci´on.

(48)

Figura 3.2: An´alisis. Caso de uso - Ver informaci´on.

Este proyecto tendr´a algunas partes de informaci´on referentes a la aplicaci´on pero no sobre la Administraci´on P´ublica que se est´a tratando. Lo que se ha insertado en su lugar es parte del Lorem Ipsum, el cual es simplemente un texto de relleno para aquellas p´aginas que en un futuro tendr´an la informaci´on que esta administraci´on considere oportuna.

3.4.1.2. Caso de uso: realizaci´on de un tr´amite

El comienzo del caso de uso surgir´a cuando alguno de los usuarios, que est´en navegando o accedan a la p´agina principal de la aplicaci´on, decidan realizar un tr´amite para enviar a la administraci´on.

Inicialmente el usuario acceder´a a una conexi´on segura y despu´es obtendr´a la informaci´on correspondiente del tr´amite que va a realizar y las modalidades de entrega de ´este. Tras leer las condiciones y estar de acuerdo con ellas, deber´a seleccionar la forma de entregar dicho documento que mejor se adapte a sus necesidades.

Existir´an tres maneras de entregar los informes: presencial, por tel´efono o por Internet. Al seleccionar una de ellas se le mostrar´a una gu´ıa de lo que debe hacer dependiendo de c´omo decida presentar la documentaci´on.

A continuaci´on el usuario rellenar´a el formulario con los datos correspondientes. Despu´es se le mostrar´a una p´agina con los datos insertados cuyo prop´osito es la comprobaci´on de esos datos por parte del usuario y as´ı obtener el documento en formato PDF, necesario para su presentaci´on en la administraci´on.

Figure

Actualización...

Referencias

Related subjects :
Outline : Otras conclusiones