Repositorio Institucional de Documentos

Proyecto Fin de Carrera Ingeniería en Informática Curso 2010/2011 Sistema para la petición de cita de tutoría usando tecnología de Portlets Marcos Mainar Lalmolda Director: Pedro Javier Álvarez Pérez-Aradros Departamento de Informática e Ingeniería de Sistemas Centro Politécnico Superior Universidad de Zaragoza Zaragoza, febrero de 2011 i Sistema para la petición de cita de tutoría usando tecnología de Portlets RESUMEN Este proyecto fin de carrera comprende el análisis, diseño e implementación de un sistema accesible vía Web que facilite a profesores y alumnos la gestión de la asistencia a las tutorías. Desde un punto de vista funcional, el sistema permite a los profesores configurar las asignaturas para las cuales quieren utilizar el sistema y establecer sus horarios de tutorías. Por otro lado, los alumnos podrán consultar disponibilidad horaria para asistir a estas tutorías y solicitarlas en base a esta disponibilidad. El sistema notificará al alumno vía correo electrónico la aceptación de su solicitud. Antes de cada tutoría, el profesor recibirá un informe por correo electrónico con el listado de las solicitudes existentes. Con cada solicitud, un alumno podrá también exponer el objeto de la tutoría, facilitando al profesor una posible preparación previa si fuese necesario. Además de la funcionalidad básica expuesta en el párrafo anterior, el sistema también ofrece otras posibilidades a profesores y alumnos. Los profesores pueden visualizar, aplicando diferentes criterios, las tutorías pendientes de ser atendidas, consultar su histórico de solicitudes de tutorías o anotar qué alumnos acuden a las tutorías que solicitaron. También podrán configurar la frecuencia de los informes de solicitudes de tutorías (por cada nueva solicitud, diarios, semanales, etc.) y la forma en que se lleva a cabo la asignación de turnos de tutorías a los alumnos: permitiéndoles elegir hora entre las disponibles o asignándoles una hora concreta de forma consecutiva. Por otro lado, un alumno podrá consultar todas las tutorías asignadas, modificarlas o cancelarlas. Adicionalmente, el sistema detectará posibles alumnos que repetidamente no asisten a las tutorías solicitadas, realizará automáticamente copias de seguridad de su información, almacenará ficheros de log con todas las acciones que ocurran en el sistema para su posterior análisis e implementará un acceso seguro basado en claves privadas. El sistema desarrollado consta de dos aplicaciones: •Una aplicación Web de configuración de asignaturas y sus horarios de tutorías utilizada por los profesores. •Una aplicación Portlet utilizada por los alumnos para la solicitud de cita de tutoría. La tecnología de Portlets utilizada permite crear aplicaciones Web fácilmente integrables en un portal Web. Gracias a ella, los profesores pueden, de forma muy sencilla, poner el sistema a disposición de sus alumnos en su página Web. Por último, el sistema desarrollado se ha instalado en el servidor Alkaid del Centro Politécnico Superior para ponerlo a disposición de profesores y alumnos. ii Agradecimientos En primer lugar, quería agradecer al director de este proyecto, Pedro Álvarez, por darme la oportunidad de realizarlo y por su ayuda a lo largo del mismo. A mis padres por haberme apoyado y aconsejado acertadamente a lo largo de toda mi vida. A los amigos que me preguntaban y se interesaban constantemente durante todo este tiempo. También agradezco los consejos y experiencias de los que habían realizado PFC antes así como las fuentes de LaTeX facilitadas. A Ismael Saad por las numerosas horas que hemos compartido como compañeros de prácticas y estudio a lo largo de toda la carrera. También por proporcionarme las fuentes de LaTeX y realizar pruebas sobre el sistema. Por último, también me gustaría nombrar a los desarrolladores que, de forma voluntaria, dedican su tiempo a programar algunas de las herramientas utilizadas, sin las cuales este proyecto habría sido mucho más costoso. iii Índice general Índice general iv Índice de figuras viii 1 Introducción 1 1.1 Contextodelproyecto .......................... 1 1.2 Motivación ................................ 1 1.3 Tecnologías y herramientas utilizadas . . . . . . . . . . . . . . . . . . 2 1.4 Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Análisis del problema 5 2.1 Objetivosgenerales............................ 5 2.2 Especificación de requisitos . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2 Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . 9 2.3 Análisis de tecnologías . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1 Requisitos tecnológicos . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2 Tecnologías elegidas . . . . . . . . . . . . . . . . . . . . . . . 10 3 Diseño de la solución 13 3.1 Entorno de aplicación del sistema . . . . . . . . . . . . . . . . . . . . 13 3.2 Arquitectura general del sistema . . . . . . . . . . . . . . . . . . . . 13 3.2.1 Interacción entre las capas del sistema . . . . . . . . . . . . . 16 3.3 Capa de acceso a datos . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.1 Modelo de datos del sistema . . . . . . . . . . . . . . . . . . . 18 3.3.2 Diseño de un DAO . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4 Capadedominio............................. 23 3.4.1 Modelo de dominio . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5 Capa de lógica de negocio . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5.1 Componentes de alto nivel del sistema . . . . . . . . . . . . . 25 3.5.2 Diseño de un componente . . . . . . . . . . . . . . . . . . . . 27 3.6 Capa de presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.6.1 Modelado de la interfaz de usuario . . . . . . . . . . . . . . . 30 iv ÍNDICE GENERAL v 3.6.2 Implementación de la capa de presentación . . . . . . . . . . 34 4 Gestión del proyecto 35 4.1 Metodología................................ 35 4.2 Planificación ............................... 36 4.3 Esfuerzo real dedicado . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5 Conclusiones 41 5.1 Resultados................................. 41 5.2 Opiniónpersonal............................. 42 5.3 Trabajofuturo .............................. 43 5.3.1 Comparativas de tecnologías . . . . . . . . . . . . . . . . . . 43 5.3.2 Ampliaciones del sistema actual . . . . . . . . . . . . . . . . . 43 A Análisis de la tecnología de Portlets 45 A.1 Introducción................................ 45 A.1.1 PortalWeb ............................ 46 A.1.2 Servidor de portales Web . . . . . . . . . . . . . . . . . . . . 48 A.1.3 Contenedor de Portlets . . . . . . . . . . . . . . . . . . . . . 49 A.2 Estándares de Portlets . . . . . . . . . . . . . . . . . . . . . . . . . . 50 A.2.1 Java Portlet Specification (JPS) . . . . . . . . . . . . . . . . 51 A.2.2 Web Services for Remote Portlets (WSRP) . . . . . . . . . . 53 A.3 Desarrollo de Portlets . . . . . . . . . . . . . . . . . . . . . . . . . . 54 A.3.1 NetBeans Portal Pack . . . . . . . . . . . . . . . . . . . . . . 55 A.3.2 Eclipse Portal Pack . . . . . . . . . . . . . . . . . . . . . . . . 56 A.3.3 Eclipse Portlet Tools . . . . . . . . . . . . . . . . . . . . . . . 56 A.3.4 Spring Portlet MVC . . . . . . . . . . . . . . . . . . . . . . . 56 A.3.5 Tapestry Portlet Support . . . . . . . . . . . . . . . . . . . . 57 A.4 Conclusiones ............................... 57 B Análisis de tecnologías 59 B.1 Requisitos tecnológicos . . . . . . . . . . . . . . . . . . . . . . . . . . 59 B.2 Listado de tecnologías y herramientas utilizadas . . . . . . . . . . . . 60 B.3 Tecnologías principales . . . . . . . . . . . . . . . . . . . . . . . . . . 62 B.3.1 Java................................ 62 B.3.2 MySQL .............................. 62 B.3.3 Hibernate............................. 63 B.3.4 Spring............................... 63 B.3.5 Tapestry.............................. 64 B.3.6 Tomcat .............................. 65 B.3.7 OpenPortal Portlet Container . . . . . . . . . . . . . . . . . . 65 C Diseño del sistema 67 C.1 Estructura de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . 67 vi ÍNDICE GENERAL C.2 Componentes del sistema . . . . . . . . . . . . . . . . . . . . . . . . 70 C.2.1 Desglose de los componentes . . . . . . . . . . . . . . . . . . 70 C.2.2 Interfaces de los componentes . . . . . . . . . . . . . . . . . . 72 C.3 Diagrama de clases del dominio . . . . . . . . . . . . . . . . . . . . . 72 C.4 Patronesdediseño............................ 72 C.4.1 Model View Controller (MVC) . . . . . . . . . . . . . . . . . 72 C.4.2 Patrones objeto-relacional (The ORM Patterns) . . . . . . . 76 C.4.2.1 Identity Field . . . . . . . . . . . . . . . . . . . . . . 76 C.4.2.2 Foreign Key Mapping . . . . . . . . . . . . . . . . . 77 C.4.2.3 Association Table Mapping . . . . . . . . . . . . . . 77 C.4.2.4 LazyLoad ....................... 78 C.4.3 Open Session In View . . . . . . . . . . . . . . . . . . . . . . 79 C.4.4 Page by Page Iterator . . . . . . . . . . . . . . . . . . . . . . 80 D Manual de Usuario 81 D.1 Requisitos generales para utilizar el sistema . . . . . . . . . . . . . . 81 D.2 ManualdelProfesor ........................... 82 D.2.1 Primerospasos.......................... 82 D.2.2 Configuración de asignaturas . . . . . . . . . . . . . . . . . . 85 D.2.3 Configuración de horarios de tutorías . . . . . . . . . . . . . . 86 D.2.4 Configuración de las preferencias . . . . . . . . . . . . . . . . 88 D.2.5 Gestión de la asistencia a las tutorías . . . . . . . . . . . . . 89 D.2.6 Consulta de ausencias de alumnos . . . . . . . . . . . . . . . 89 D.2.7 Ver informes de tutorías . . . . . . . . . . . . . . . . . . . . . 89 D.2.8 Cancelar sesiones . . . . . . . . . . . . . . . . . . . . . . . . . 91 D.2.9 Ver asignaturas configuradas . . . . . . . . . . . . . . . . . . 92 D.2.10 Eliminar asignaturas configuradas . . . . . . . . . . . . . . . 92 D.2.11 Editar asignaturas configuradas . . . . . . . . . . . . . . . . . 92 D.2.12 Ver horarios de tutorías . . . . . . . . . . . . . . . . . . . . . 94 D.2.13 Modificar horarios de tutorías . . . . . . . . . . . . . . . . . . 95 D.2.14 Eliminar horarios de tutorías . . . . . . . . . . . . . . . . . . 95 D.2.15 Baja del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 96 D.2.16 Cambio de contraseña . . . . . . . . . . . . . . . . . . . . . . 96 D.2.17Verperfil ............................. 97 D.2.18Modificarperfil.......................... 97 D.3 ManualdelAlumno ........................... 99 D.3.1 Primerospasos.......................... 99 D.3.2 Iniciodesesión.......................... 99 D.3.3 Olvido de contraseña . . . . . . . . . . . . . . . . . . . . . . . 100 D.3.4 Reserva de cita de tutoría . . . . . . . . . . . . . . . . . . . . 100 D.3.5 Ver tutorías asignadas . . . . . . . . . . . . . . . . . . . . . . 102 D.3.6 Modificar la fecha y hora de tutorías asignadas . . . . . . . . 102 D.3.7 Cancelar tutorías asignadas . . . . . . . . . . . . . . . . . . . 103 D.3.8 Cerrarsesión ........................... 103 ÍNDICE GENERAL vii D.4 Manual del Administrador . . . . . . . . . . . . . . . . . . . . . . . . 104 D.4.1 Primerospasos.......................... 104 D.4.2 Cambiar la contraseña . . . . . . . . . . . . . . . . . . . . . . 105 D.4.3 Cambiar la cuenta de notificaciones . . . . . . . . . . . . . . 105 D.4.4 Configurar las fechas del curso . . . . . . . . . . . . . . . . . 106 D.4.5 Ver fechas actuales del curso . . . . . . . . . . . . . . . . . . 106 D.4.6 Realizar copias de seguridad . . . . . . . . . . . . . . . . . . . 107 D.4.7 Restaurar copias de seguridad . . . . . . . . . . . . . . . . . . 107 D.4.8 Ver estadísticas del sistema . . . . . . . . . . . . . . . . . . . 108 D.4.9 Verperfil ............................. 108 D.4.10 Modificar perfil . . . . . . . . . . . . . . . . . . . . . . . . . . 109 E Manual de Instalación y Mantenimiento 111 E.1 Instalación y mantenimiento de la aplicación Web . . . . . . . . . . . 111 E.1.1 Requisitos para la instalación . . . . . . . . . . . . . . . . . . 111 E.1.1.1 Instalar MySQL . . . . . . . . . . . . . . . . . . . . 111 E.1.1.2 Crear la base de datos de la aplicación . . . . . . . 112 E.1.1.3 Instalar Apache Tomcat . . . . . . . . . . . . . . . . 113 E.1.2 Instalación de la aplicación Web en Tomcat . . . . . . . . . . 114 E.2 Instalación y mantenimiento de la aplicación Portlet . . . . . . . . . 115 E.2.1 Requisitos para la instalación . . . . . . . . . . . . . . . . . . 115 E.2.2 Instalación de la aplicación Portlet en OpenPortal Portlet Container sobre Apache Tomcat . . . . . . . . . . . . . . . . 116 E.2.2.1 Integrar el Portlet en una página Web utilizando el driver de OpenPortal Portlet Container . . . . . . . 118 E.2.2.2 Integrar el Portlet en una página Web utilizando un IFrame ......................... 119 E.2.2.3 Utilizar el Portlet remotamente usando WSRP . . . 120 E.2.3 Instalación de la aplicación Portlet en Liferay Portal . . . . . 120 F Seminario de Portlets 123 Bibliografía 129 4 CAPÍTULO 1. INTRODUCCIÓN 1.4 Estructura de la memoria La memoria consta de cinco capítulos que resumen el proyecto. Además del presente capítulo de introducción al proyecto, el resto de capítulos profundizan en el trabajo realizado. El capítulo 2 describe el análisis del problema a resolver. En primer lugar, se describen los objetivos generales del proyecto. En segundo lugar, se detallan los requisitos concretos en los que se materializan los objetivos generales anteriores. Por último, se realiza un análisis de las tecnologías requeridas para el proyecto. En el capítulo 3 se explica el diseño del sistema. Se comienza con una visión global del entorno de aplicación del sistema. Posteriormente, se describe la arquitectura general del sistema. Y, sucesivamente, se va desglosando dicha arquitectura para mostrar las partes más relevantes del diseño. En el capítulo 4 se describe la gestión del proyecto: metodología utilizada, planificación, estimaciones iniciales y esfuerzo real dedicado. Finalmente, en el capítulo 5 se presentan los resultados del proyecto, reflexiones personales del autor y posibles trabajos futuros relacionados con el proyecto realizado. La memoria contiene, además, una serie de anexos que complementan la información de los capítulos anteriores. Estos anexos son los siguientes: •El anexo A contiene un análisis detallado de la tecnología de Portlets. •El anexo B contiene un análisis del resto de tecnologías principales utilizadas en el proyecto. •El anexo C contiene información complementaria del diseño del sistema. •En el anexo D se incluye el manual de usuario del sistema. •El anexo E corresponde al manual de instalación y mantenimiento del sistema. •El anexo F incluye las transparencias de un seminario sobre la tecnología de Portlets elaborado al principio del proyecto. Finalmente, se presentan las referencias bibliográficas que han servido de soporte al proyecto. Capítulo 2 Análisis del problema En este capítulo se presenta el análisis del problema a resolver. En la sección 2.1 se enumeran los objetivos generales del proyecto derivados del análisis de las necesidades de los usuarios del sistema y de la naturaleza del mismo. Estos objetivos se fueron refinando y descomponiendo en detalle para dar lugar a los requisitos concretos del sistema que se detallan en la sección 2.2. Por último, en la sección 2.3 se incluye un análisis de las tecnologías necesarias para desarrollar el sistema. 2.1 Objetivos generales El objetivo de este proyecto es el diseño e implementación de un sistema accesible vía Web que facilite a profesores y alumnos la gestión de la asistencia a las tutorías. Los objetivos generales derivados son los siguientes: •Estudiar y analizar el sistema utilizado actualmente por los profesores universitarios para la gestión de las tutorías. •Diseñar y desarrollar dos aplicaciones: una aplicación Web utilizada por los profesores y una aplicación Portlet utilizada por los alumnos. •Los objetivos de la aplicación Web son: –Permitirá a los profesores, de forma muy sencilla, configurar sus asignaturas, dar de alta a sus alumnos y establecer sus horarios de tutorías. –Permitirá visualizar, aplicando diferentes criterios, las tutorías pendientes de ser atendidas y las históricas, anotar qué alumnos acuden a las tutorías que solicitaron y cancelar sesiones de tutorías. 5 6 CAPÍTULO 2. ANÁLISIS DEL PROBLEMA –Permitirá al profesor recibir informes con las solicitudes de tutorías por correo electrónico. El profesor podrá configurar si desea recibir informes diarios con las tutorías del día, informes al principio de la semana con las tutorías de toda la semana o una notificación individual por cada nueva solicitud de tutoría. –El profesor podrá configurar si desea que los alumnos puedan elegir hora de tutoría entre las disponibles o si la aplicación asignará automáticamente horas de forma consecutiva. –La aplicación deberá ser accesible a una amplia comunidad de profesores sin que tengan que realizar una instalación previa. •Los objetivos de la aplicación Portlet son: –Permitirá a los alumnos consultar la disponibilidad horaria para asistir a las tutorías y solicitar una tutoría en base a esta disponibilidad. –Permitirá a los alumnos consultar las tutorías asignadas, modificarlas o cancelarlas. –La aplicación no requerirá que los alumnos se registren previamente. –La aplicación se integrará fácilmente en portales Web de forma que los profesores puedan ponerla a disposición de sus alumnos, para que éstos reserven cita de tutoría. Ambas aplicaciones deberán facilitar especialmente la mantenibilidad, tanto desde el punto de vista de la mejora de la funcionalidad existente, como para la adición de nueva funcionalidad en el futuro. 2.2 Especificación de requisitos Los objetivos generales se materializan en una serie de requisitos que se han clasificado en funcionales y no funcionales. Los requisitos funcionales son aquellos que describen el comportamiento del sistema. Los requisitos no funcionales se refieren a otras cuestiones como la tecnología concreta a utilizar, dónde se llevará a cabo la instalación y operación del sistema, etc. 2.2.1 Requisitos funcionales Los requisitos funcionales se han dividido en cuatro grupos: requisitos desde el punto de vista del profesor, requisitos desde el punto de vista del alumno, requisitos desde el punto de vista del administrador y requisitos generales del sistema. Estas cuatro visiones del sistema permiten capturar adecuadamente todas las necesidades según el tipo de usuario, así como necesidades estructurales del sistema. 2.2. ESPECIFICACIÓN DE REQUISITOS 7 Requisitos desde el punto de vista del profesor: 1. Un profesor podrá registrarse en el sistema para poder gestionar de manera automática sus tutorías. 2. Un profesor podrá configurar las asignaturas para las que quiere utilizar el sistema. Para cada asignatura, importará un fichero con un formato preestablecido que contenga el listado de alumnos matriculados. 3. Un profesor podrá configurar para cada asignatura el día y la hora de sus tutorías (es decir, sus sesiones de tutorías) y el tiempo asignado a cada alumno. 4. Un profesor podrá visualizar las solicitudes de tutoría para cada sesión. Podrán ser aplicados diferentes criterios: temporales, por asignatura, etc. 5. Un profesor podrá recibir por correo electrónico información puntual sobre las solicitudes de tutoría o una planificación completa de sus sesiones. 6. Un profesor podrá consultar su histórico de solicitudes de tutorías aplicando criterios temporales y por asignatura. 7. Un profesor podrá consultar las incidencias de los alumnos. Se entiende por incidencia la modificación del horario de una tutoría previamente reservada o la cancelación de la misma. 8. Un profesor podrá cancelar sus sesiones de tutorías en un rango de fechas determinado. El sistema lo notificará por correo electrónico a los alumnos que hubieran reservado tutorías para esas sesiones. 9. Un profesor podrá cancelar una determinada reserva de tutoría. El sistema notificará por correo electrónico al alumno al que corresponda la reserva cancelada. 10. Un profesor podrá imprimir los listados con las solicitudes de tutorías recibidas, los históricos de tutorías y las incidencias de alumnos, utilizando un fichero en formato PDF que contenga el listado correspondiente. 11. Un profesor podrá configurar si prefiere que el sistema asigne hora de tutoría a los alumnos de forma automática o si éstos pueden elegir hora entre las disponibles. 12. Un profesor podrá registrar si un alumno acude a la tutoría que había solicitado. 13. Un profesor podrá comprobar qué alumnos no acuden a las tutorías asignadas. 8 CAPÍTULO 2. ANÁLISIS DEL PROBLEMA Requisitos desde el punto de vista del alumno: 1. Un alumno accederá al sistema utilizando su NIP y su clave de acceso, que será válida para todas las asignaturas. 2. Un alumno podrá solicitar una tutoría indicando: la asignatura, el nombre del profesor, la fecha y hora a la que desea acudir (siempre que ésta esté libre). También podrá realizar comentarios que considere de interés para el profesor. 3. Una vez comprobado por el sistema que la solicitud de un alumno es correcta y factible, el alumno recibirá una notificación de aceptación por correo electrónico. 4. Un alumno podrá modificar o cancelar una tutoría previamente asignada (con al menos un día de antelación). 5. Un alumno podrá consultar las tutorías que tiene asignadas. Requisitos desde el punto de vista del administrador: 1. El administrador podrá consultar las estadísticas generales del sistema (profesores, asignaturas, alumnos, horarios, grupos, titulaciones, etc). 2. El administrador podrá introducir las fechas relevantes del curso académico actual (inicio y fin del curso, inicio y fin de cada cuatrimestre). 3. El administrador podrá introducir un fichero que contenga los días festivos del curso académico actual. 4. El administrador podrá realizar y restaurar copias de seguridad del sistema. Requisitos generales del sistema: 1. Para cada solicitud de tutoría, el sistema comprobará la disponibilidad del profesor para atender al alumno. 2. El sistema almacenará ficheros de log donde se registren las acciones más relevantes que realicen los usuarios del sistema. El formato del fichero deberá ser apropiado para futuros análisis de su contenido. 3. El sistema deberá ser capaz de realizar copias de seguridad de su información de manera periódica. 4. El sistema generará una clave de acceso concreta para cada nuevo alumno dado de alta. La clave será enviada a la cuenta de correo electrónico del alumno en la Universidad de Zaragoza. 2.3. ANÁLISIS DE TECNOLOGÍAS 9 2.2.2 Requisitos no funcionales Los requisitos no funcionales del sistema son los siguientes: 1. El sistema de solicitud de tutoría será desarrollado con tecnología de Portlets. 2. El sistema de solicitud de tutoría deberá integrarse en un portal Web con un esfuerzo mínimo (cualquier profesor sin conocimientos técnicos deberá ser capaz de hacerlo en un breve espacio de tiempo). 3. El sistema dispondrá de una aplicación Web para que cada profesor configure sus asignaturas y su perfil y consulte la planificación de sus sesiones. 4. El sistema deberá estar instalado y operativo en un servidor que favorezca el uso por parte de una amplia comunidad de profesores y alumnos en el futuro. 5. Al finalizar el proyecto, deberá estar operativo y siendo utilizado al menos por el director del proyecto. 2.3 Análisis de tecnologías En esta sección se presenta un análisis resumido de las tecnologías principales necesarias para el desarrollo del proyecto. El análisis completo se puede consultar en el anexo B. El anexo A es específico para la tecnología de Portlets. 2.3.1 Requisitos tecnológicos Este proyecto plantea una serie de necesidades tecnológicas para resolver diferentes cuestiones del mismo. A continuación se enumeran y justifican brevemente estas necesidades. 1. Plataforma de desarrollo y framework de soporte. La plataforma debe permitir desarrollar aplicaciones Web modulares formadas por diferentes capas y componentes. El framework de soporte para la plataforma permitirá simplificar la configuración del sistema y, en general, su implementación, coordinando las diferentes capas y componentes. 2. Tecnologías de soporte al almacenamiento de información. Se requiere un repositorio permanente de información así como tecnologías para acceder al mismo con el fin de gestionar la información relativa al dominio del sistema. 3. Tecnología Web orientada a servicios que facilite la integración en portales Web. Gracias a esta tecnología, los profesores podrán poner el sistema a disposición de sus alumnos de forma sencilla. 10 CAPÍTULO 2. ANÁLISIS DEL PROBLEMA 4. Tecnologías que permitan desarrollar interfaces Web de usuario dinámicas. Se necesitan tecnologías abiertas y basadas en estándares que estén soportadas por cualquier navegador Web para maximizar la accesibilidad del sistema. 5. Tecnologías que proporcionen el entorno de ejecución del sistema. Dado que el sistema a construir es accesible vía Web, se necesita un servidor Web en el que residirán las aplicaciones que forman el sistema. 2.3.2 Tecnologías elegidas Los requisitos tecnológicos anteriores llevan a elegir una serie de tecnologías. A continuación, se exponen dichas tecnologías explicando brevemente en qué consisten y justificando su elección. Plataforma de desarrollo y framework de soporte Se ha optado por la plataforma Java EE [16]. De esta forma, se aprovecha la experiencia previa del alumno con el lenguaje de programación Java y además el proyecto se beneficia de su compatibilidad con otras tecnologías empleadas. En particular, la tecnología de Portlets es un estándar de Java EE, por tanto, requería el uso de esta plataforma para la aplicación de reserva de cita de tutoría utilizada por los alumnos. Por ello, se decidió utilizar Java para el sistema completo. Como framework de soporte se decidió utilizar Spring [27]. Spring es un framework de desarrollo de aplicaciones para la plataforma Java que favorece la adopción de buenas prácticas de programación. Se eligió fundamentalmente dado que permite construir sistemas a partir de componentes con bajo acoplamiento entre sí, gracias al principio de inversión de control (Inversion of Control, IoC) o inyección de dependencias (Dependency Injection, DI) [10] [11]. También, debido a que es estable, muy utilizado, compatible con numerosos frameworks y librerías, cuenta con excelente documentación y se adapta perfectamente al tipo de sistema a desarrollar. Tecnologías de soporte al almacenamiento de información Se ha elegido utilizar como repositorio una base de datos relacional y el gestor de bases de datos relacional MySQL [28]. La razón principal es su contrastado funcionamiento en numerosas aplicaciones Web disponibles en el mercado. También, para servir de aprendizaje al alumno, ya que anteriormente había utilizado el sistema gestor de bases de datos Oracle. A pesar de elegir MySQL, se deseaba que el sistema diseñado fuera independiente del gestor de base de datos relacional concreto utilizado. Por ello, se ha utilizado el framework Hibernate. Hibernate [26] es el mapeador objeto-relacional (Object- Relational Mapping, ORM) por excelencia de la comunidad Java. Un mapeador objeto-relacional es una herramienta que facilita la conversión entre las entidades de una base de datos relacional y las clases del dominio de la aplicación. Además, 2.3. ANÁLISIS DE TECNOLOGÍAS 11 Hibernate se utiliza como tecnología de acceso a la base de datos relacional ofreciendo una capa de abstracción por encima de JDBC [79]. Por último, para facilitar el mantenimiento del sistema y permitir el cambio de Hibernate a otro proveedor de persistencia, se ha configurado Hibernate para que utilice la API estándar de Java para persistencia, conocida como JPA [18]. Tecnología Web orientada a servicios que facilite la integración en portales Web Para este requisito se ha elegido la tecnología de Portlets [1]. Intuitivamente, los Portlets se pueden considerar como la siguiente generación de servicios Web. Un servicio Web tradicional devuelve los datos con la respuesta a la invocación de un método en un documento con formato XML, JSON, etc. Sin embargo, la representación visual de esa información depende de la aplicación concreta que invoca el servicio Web. En cambio, los Portlets, además de devolver la respuesta a la invocación, también devuelven información de interfaz de usuario, es decir, de cómo representar visualmente la información devuelta. Para ello, devuelven directamente código de markup. Por tanto, podrían considerarse como servicios Web orientados a presentación o visuales. A nivel técnico, un Portlet es una mini aplicación Web interactiva gestionada y visualizada a través de un portal Web. La tecnología de Portlets es una API estándar de Java. La versión actual del estándar es la 2.0 [37]. La elección de la tecnología de Portlets se basó en dos razones fundamentales. Primero, en la necesidad de tener un sistema altamente modular e integrable que los profesores pudieran poner a disposición de sus alumnos de forma sencilla. En segundo lugar, por interés en aprender esta tecnología emergente, conocer sus posibilidades y, en definitiva, ampliar la formación del alumno. Durante la fase de formación del proyecto se realizó un análisis de esta tecnología donde se describe su contexto, estándares que intervienen, herramientas para desarrollar con ella, etc. Este análisis se puede consultar en el Anexo A. Como consecuencia de la utilización de la tecnología de Portlets, se requiere un contenedor de Portlets o un servidor de portales Web (que integra el contenedor de Portlets) para proveer al Portlet de su entorno de ejecución. En este proyecto se ha utilizado el contenedor de Portlets OpenPortal Portlet Container [20]. Se eligió este contenedor concreto ya que puede ser instalado de forma muy sencilla en numerosos contenedores Web como Tomcat, JBoss, Jetty, Oracle WebLogic y GlassFish. También se ha utilizado el servidor de portales Liferay Portal Server [55] para realizar pruebas con Portlets y adquirir formación relativa a esta tecnología. Tecnologías que permitan desarrollar interfaces Web de usuario dinámicas Para implementar la interfaz de usuario Web de la aplicación de los profesores, se ha utilizado Tapestry. Tapestry es un framework Web orientado a componentes, de forma que modela cada página Web como un componente que puede reaccionar a diversos eventos. Se ha elegido Tapestry debido a que facilita el desarrollo de interfaces Web de usuario, reduce la configuración necesaria en el sistema 12 CAPÍTULO 2. ANÁLISIS DEL PROBLEMA utilizando convenciones [14], se integra fácilmente con Hibernate y Spring y requiere escribir menos código fuente que otros frameworks Web similares como por ejemplo Struts [23]. Tapestry utiliza como tecnología subyacente la API estándar de Java Servlets [22]. Por tanto, el entorno de ejecución del sistema debe soportar esta tecnología. Sin embargo, el framework Tapestry en su versión actual (versión 5) no tiene soporte para desarrollo de Portlets. Por ello, para el desarrollo de la interfaz de usuario Web de la aplicación Portlet de los alumnos se ha utilizado la tecnología JavaServer Pages (JSP) [5]. De nuevo, el entorno de ejecución del sistema debe soportar esta tecnología. Tecnologías que proporcionen el entorno de ejecución del sistema Como tecnología que sirva para proveer al sistema de su entorno de ejecución se ha utilizado el servidor Web Apache Tomcat [21]. Tomcat es un servidor Web multiplataforma con soporte para Servlets y JavaServer Pages (JSP). Es un contenedor Web ligero ya que, al contrario que los servidores de aplicaciones de la plataforma Java EE como JBoss, GlassFish, etc., no requiere tantos recursos para su ejecución. La elección de Tomcat se basó en que utiliza pocos recursos y se integra muy fácilmente con el contenedor de Portlets OpenPortal Portlet Container. Se consideró también la posibilidad de usar Jetty, otro servidor Web con soporte para Servlets. Sin embargo, la disponibilidad de mejor documentación para Tomcat hizo que la decisión se decantara a favor de éste. Capítulo 3 Diseño de la solución En este capítulo se describe el diseño del sistema realizado. En la sección 3.1 se presenta el entorno de aplicación del sistema. En la sección 3.2 se explica su arquitectura. En las sucesivas secciones se explica y justifica el papel de cada una de las capas que conforman la arquitectura del sistema, sus aspectos de diseño de alto nivel y las tecnologías utilizadas. La sección 3.3 describe la capa de acceso a datos. La sección 3.4 describe la capa de dominio. La sección 3.5 describe la capa de lógica de negocio. Por último, la sección 3.6 corresponde a la capa de presentación. En el anexo C se ofrece información complementaria del diseño del sistema desde una perspectiva cercana a la implementación. 3.1 Entorno de aplicación del sistema El sistema diseñado se divide en dos aplicaciones tal y como se puede observar en la figura 3.1. Por un lado, una aplicación Portlet utilizada por los alumnos para la reserva de cita de tutorías, consulta de tutorías asignadas y modificación y cancelación de tutorías previamente asignadas. Por otro lado, una aplicación Web utilizada por los profesores para configurar su perfil, asignaturas y horarios de tutorías, gestionar la asistencia de los alumnos, consultar listados de solicitudes de tutorías, históricos e incidencias, etc. Esta aplicación también es utilizada por el administrador para configurar su perfil, las fechas del curso académico actual, visualizar estadísticas generales y realizar copias de seguridad de los datos. Ambas aplicaciones son accedidas por los usuarios utilizando un navegador Web. El sistema utiliza como mecanismo de almacenamiento de datos persistentes una base de datos que es compartida por ambas aplicaciones. 3.2 Arquitectura general del sistema La arquitectura del sistema se basa en un diseño multicapa [2]. Los diseños multicapa son muy utilizados en las aplicaciones de gestión ya que permiten separar claramente 13 20 CAPÍTULO 3. DISEÑO DE LA SOLUCIÓN Figura 3.5. Diagrama entidad-relación de la base de datos del sistema parte de una única titulación. Dado que un profesor imparte uno o varios grupos de una determinada asignatura, se ha utilizado una entidad agregada, denominada Asignatura-Grupo, para representar las asignaturas y los grupos de docencia. Cada profesor también tiene unas preferencias de configuración en el sistema. Tradicionalmente, cada profesor tiene un único horario de tutorías semanal en el que atiende dudas y consultas de los alumnos relativas a todas sus asignaturas. El sistema es más flexible dado que ofrece la posibilidad de tener horarios de tutorías diferentes para cada asignatura individual o para conjuntos de las asignaturas que imparte (por ejemplo, un horario para las asignaturas del primer cuatrimestre y otro para las del segundo). Por supuesto, también permite conservar la visión tradicional y utilizar el mismo horario de tutorías para todas las asignaturas que imparte. Esto es posible gracias a la interrelación ternaria atender entre las entidades Profesor, Asignatura-Grupo yTutoría. Un alumno puede estar matriculado en varias Asignaturas-Grupos y puede 3.3. CAPA DE ACCESO A DATOS 21 realizar el número de reservas de tutoría que desee. Cada reserva se corresponde con una determinada sesión de tutorías y también con una Asignatura-Grupo. Además, un alumno sólo puede realizar reservas de Asignaturas-Grupos en los que se encuentre matriculado durante el año académico. También se decidió almacenar información de las modificaciones o cancelaciones de reservas de tutorías realizadas por los alumnos. Se utiliza para ello la entidad Incidencia. Una incidencia la causa un alumno y está asociada una sesión de tutorías, aquella que tenía previamente reservada y que ha cancelado o modificado. Por último, también se muestran las entidades ConfigAdmin, donde se almacenan los datos del administrador del sistema y Festivo, donde se almacenan las fechas festivas del curso académico actual introducidas por el administrador. 3.3.2 Diseño de un DAO Un DAO, a nivel intuitivo, es un objeto que se encarga de acceder a un repositorio de información, ya sea un fichero, una base de datos relacional, etc. A nivel técnico, un DAO define una interfaz para las operaciones de persistencia (métodos CRUD, Create Read Update Delete, y de búsqueda) de una clase del dominio o persistente concreta. La aplicación concreta del patrón utilizada en el proyecto es posible gracias al uso de clases Java genéricas. Está basada en las explicaciones encontradas en [6] y [9]. En la figura 3.6 se puede ver el ejemplo del diseño de un DAO. Se ha tomado como ejemplo el AlumnoDao, utilizado para gestionar la clase persistente Alumno. Esta clase contendrá los datos de la entidad Alumno de la base de datos. El diseño del resto de DAOs se ha realizado de forma análoga. La aplicación del patrón DAO realizada utiliza una interfaz y una clase Java genéricas. En primer lugar, la interfaz genérica, GenericDao, recibe 2 argumentos: •E, la clase persistente para la que se implementará el DAO. •PK, define el tipo de identificador (clave primaria) de la clase persistente. Esta interfaz genérica declara las 4 operaciones de persistencia comunes a todas las entidades: •save: Guarda o actualiza la entidad E recibida como argumento en el repositorio de datos utilizado. •find: Si existe, devuelve la entidad cuya clave primaria es la recibida como argumento (PK). Si no existe, lanzará una excepción de tipo InstanceNotFoundException. 22 CAPÍTULO 3. DISEÑO DE LA SOLUCIÓN Figura 3.6. Diagrama de clases de un DAO •exists: Devuelve cierto, si existe una entidad cuya clave primaria es la recibida como argumento (PK) y falso, en caso contrario. •remove: Elimina, si existe, la entidad cuya clave primaria es la recibida como argumento (PK). Si no existe, lanzará una excepción de tipo InstanceNotFoundException. Con estas 4 operaciones anteriores declaradas en la interfaz genérica GenericDao es posible crear, leer, actualizar y borrar (CRUD) cualquier dato de tipo genérico en la base de datos. En segundo lugar, la clase genérica GenericDaoHibernate implementa la interfaz GenericDao y por tanto, también tiene los 2 argumentos mencionados anteriormente. Esta clase implementa los métodos save,find,exists yremove utilizando para ello los métodos de la API de Hibernate. Para cada clase persistente: •Se utiliza una interfaz (AlumnoDao en el ejemplo) que hereda del DAO genérico (GenericDao) proporcionando como argumentos el tipo de la clase 3.4. CAPA DE DOMINIO 23 persistente (Alumno en el ejemplo aunque no se muestra en el diagrama) y el tipo de la clave primaria de la clase persistente (Long en el ejemplo, tampoco se muestra en el diagrama). Esta interfaz también define métodos adicionales de búsqueda (listarAlumnosRegistrados,numAlumnosRegistrados, getAlumnoByNip) específicos de la clase persistente. •Se utiliza una clase (AlumnoDaoHibernate en el ejemplo) que implementa la interfaz anterior (AlumnoDao en el ejemplo) y hereda de la clase genérica (GenericDaoHibernate). Con este diseño se consigue no tener que replicar las operaciones básicas de acceso a datos en cada clase persistente al estar definidas en la interfaz genérica GenericDao. También es posible cambiar de mapeador objeto-relacional y dejar de usar Hibernate. Para ello, bastaría con crear una clase genérica que implementara la interfaz GenericDao utilizando los métodos del nuevo mapeador. Después, se proporcionaría para cada entidad una clase que herede de dicha clase genérica. De esta forma, el diseño tampoco depende del mapeador objeto-relacional concreto utilizado. 3.4 Capa de dominio En esta capa se encuentran las denominadas clases persistentes o del dominio. Estas clases se corresponden con entidades del modelo de datos existente en la base de datos del sistema. Cada clase se corresponde con una entidad o interrelación del modelo de datos. Cada objeto o instancia de una determinada clase se corresponde con una tupla de la entidad correspondiente. La función de esta capa es, por tanto, ofrecer una visión del modelo de datos utilizando para ello objetos de un lenguaje de programación orientado a objetos (en este caso Java). Los objetos de esta capa pueden ser requeridos desde cualquiera de las otras 3 capas. La capa de acceso a datos necesita estos objetos para almacenarlos en la base de datos. La capa de lógica de negocio utiliza estos objetos para implementar la funcionalidad del sistema. Por ejemplo, cuando un alumno solicita una cita de tutoría, se requiere crear un nuevo objeto de la clase Reserva utilizando los datos introducidos por el alumno en la pantalla correspondiente. La capa de presentación Web puede también utilizar las clases del dominio a la hora de implementar las acciones que se ejecutan en respuesta a eventos generados por la interfaz de usuario. Por ejemplo, cuando se pulsa el botón de enviar formulario en la pantalla de registro de un profesor, el método que se ejecuta en respuesta a este evento crea ya el objeto Profesor con los datos introducidos en el formulario. A nivel tecnológico, estas clases han sido generadas automáticamente utilizando la herramienta Hibernate Tools. Con ella, a partir de una base de datos preexistente y del fichero de configuración de Hibernate, se pueden obtener directamente estas 24 CAPÍTULO 3. DISEÑO DE LA SOLUCIÓN clases con sus atributos, métodos de acceso a los atributos y las anotaciones de Hibernate insertadas en el código de las clases que especifican la correspondencia con las entidades de la base de datos. Sin embargo, al tratarse de una herramienta genérica de generación de código, el código fuente generado junto con las anotaciones no siempre se adapta a las necesidades específicas del sistema. Por ejemplo, Hibernate Tools considera por defecto todas las relaciones como bidireccionales. Por ello, hay que realizar modificaciones en las anotaciones y añadir nuevas anotaciones con el fin de adaptar las clases a nuestro modelo de dominio. 3.4.1 Modelo de dominio En esta sección se muestran las clases del problema y las asociaciones que existen entre ellas. Se puede observar el diagrama de clases del dominio en la figura 3.7. Como se puede apreciar, el modelo de dominio es muy similar al modelo de datos del sistema, dado que se ha utilizado un mapeador objeto relacional. Una de las diferencias principales radica en que los objetos pueden contener referencias a otros objetos o incluso listas o conjuntos de otros objetos derivados de las asociaciones representadas. Sin embargo, el modelo relacional y la teoría de normalización de bases de datos impide que haya listas de datos en las entidades de la base de datos. Por ejemplo, se puede observar como un horario contiene una o varias franjas horarias. En la sección C.4.2 del anexo de diseño se explican una serie de patrones objeto-relacional que se utilizan para realizar la correspondencia. 3.5 Capa de lógica de negocio El propósito de esta capa es integrar los componentes que implementan la funcionalidad del sistema. Para ello, se ha agrupado la funcionalidad del sistema de forma lógica. Es decir, funcionalidades relacionadas forman parte del mismo componente. Estos componentes implementan la lógica principal de la aplicación. Para implementar las operaciones necesarias, esta capa utiliza las operaciones ofrecidas por las interfaces de la capa de acceso a datos y las clases de la capa de dominio. También los componentes de esta capa pueden utilizar operaciones ofrecidas por otros componentes de la propia capa. Esta capa ofrece sus operaciones a la capa de presentación. A nivel tecnológico, la implementación de esta capa se apoya en el contenedor de inversión de control (IoC container) de Spring para gestionar los diferentes componentes. Como consecuencia, las clases (beans en la terminología de Spring) son instanciadas e inicializadas por Spring. Además, las dependencias de cada clase (otras clases que utiliza) son inyectadas por Spring en tiempo de ejecución. Spring también se encarga de gestionar aspectos transversales del sistema (crosscutting concerns) [68], es decir, aquellos que afectan a todo el sistema. Algunos 3.5. CAPA DE LÓGICA DE NEGOCIO 25 Figura 3.7. Diagrama de clases de la capa de dominio ejemplos de estos aspectos son el logging, la gestión de excepciones y la gestión de transacciones. Para ello, Spring utiliza la programación orientada a aspectos [69]. Esta técnica de programación permite aislar estos aspectos y aplicarlos a los componentes que los precisen utilizando anotaciones en el código. De esta forma, se evita la pérdida modularidad que se produce al tener que repetir código en diferentes capas del sistema para gestionar adecuadamente estos aspectos. 3.5.1 Componentes de alto nivel del sistema En esta sección se presentan los principales componentes de la capa de lógica de negocio. Estos componentes se clasifican en: componentes funcionales y componentes de soporte. Los componentes funcionales se encargan de implementar la funcionalidad principal del sistema. Los componentes de soporte se ocupan de 26 CAPÍTULO 3. DISEÑO DE LA SOLUCIÓN funciones auxiliares o de utilidad genérica en el sistema y son utilizados por los componentes funcionales para llevar a cabo sus tareas. El diagrama de componentes del sistema se puede observar en la figura 3.8. Todos los componentes que se muestran han sido desarrollados en este proyecto a excepción de las librerías JavaMail y el planificador Quartz. Ambas librerías son utilizadas por algunos componentes, tal y como se representa a través de flechas punteadas. Para representar el resto de las relaciones entre los componentes, se ha utilizado la idea de bus, representado a través de la flecha horizontal gruesa. De esta forma, se evita que el diagrama esté plagado de líneas que se cruzan facilitando así su lectura. Además, dado que todos los componentes están desplegados en el mismo servidor Web, no se muestra su disposición física en nodos. Figura 3.8. Diagrama de componentes del sistema A continuación se describen los componentes que se muestran en el diagrama de componentes. 1. Funcionales: •Componentes de configuración y administración: AdminService para la administración del sistema y TutoriasService para la configuración de tutorías. •Componentes estadísticos: hay un único componente estadístico en el sistema, StatsService. Este componente se encarga de recopilar estadísticas generales de utilización. •Componente del profesor (ProfesorService): se encarga de implementar la funcionalidad del profesor. Por ejemplo, el registro, alta de asignaturas, gestión del perfil, etc. 3.5. CAPA DE LÓGICA DE NEGOCIO 27 •Componente del alumno (AlumnoService): se encarga de implementar la funcionalidad del alumno. Por ejemplo: reservar tutoría, consultar tutorías reservadas, modificar o cancelar reservas previas, etc. 2. De soporte: •Componente de mantenimiento (MantenimientoService). Se encarga de realizar periódicamente las copias de seguridad de los datos del sistema, de las operaciones de cambio de curso académico, etc. Este componente utiliza la librería del planificador Quartz. •Componente de informes (InformesService). Se encarga de generar los informes diarios y semanales de solicitudes de tutorías, utilizando Quartz para planificar las tareas que se han de ejecutar en segundo plano. •Componente para el envío de correos electrónicos (EnvioMails). Se utiliza para enviar los diferentes informes y notificaciones a los usuarios del sistema. Este componente se apoya en la librería JavaMail. •Componentes de generación y cifrado de contraseñas (PasswordGenerator yPasswordEncrypter). Se encargan de generar las contraseñas de los alumnos y cifrar las de los profesores y alumnos. •Analizadores sintácticos para procesar los ficheros de alumnos matriculados y días festivos (ParserFicherosAlumnos yParserFicheroFestivos). •Componente de generación del calendario de sesiones de tutorías (GeneracionCalendarioSesionesTutorias). Se encarga de calcular las sesiones de tutorías de un determinado horario. Algunos de estos componentes son utilizados exclusivamente por la aplicación Web (por ejemplo, el componente ProfesorService) o por la aplicación Portlet (por ejemplo, el componente AlumnoService) mientras que otros son utilizados por ambas aplicaciones (por ejemplo, el componente EnvioMails). 3.5.2 Diseño de un componente En esta sección se explica el diseño de un componente de la capa de lógica de negocio y se ilustra por medio de un ejemplo. El diseño de todos los componentes del sistema sigue la misma estrategia que la explicada a través del ejemplo. Los componentes de la capa de lógica de negocio están diseñados utilizando el mecanismo de abstracción de interfaces de Java y la técnica de inyección de dependencias [10] [11] soportada por el framework Spring gracias a su contenedor de inversión de control. La técnica de inyección de dependencias es una implementación sofisticada del patrón Factoría [25]. Se basa en la idea de que los módulos o componentes de alto nivel de un sistema no deben depender de componentes de bajo 28 CAPÍTULO 3. DISEÑO DE LA SOLUCIÓN nivel. En su lugar, ambos deben depender de abstracciones. Esta técnica se utiliza para indicar a una parte de un programa (un componente, un módulo, etc.) qué otras partes puede utilizar, proporcionándole para ello una dependencia externa (a través de una referencia). Esta técnica también se conoce con el nombre de inversión de control ya que, tradicionalmente, cada objeto es responsable de obtener sus propias referencias a los objetos con los que colabora. Sin embargo, con esta técnica, se invierte el control, ya que el objeto se limita a declarar los objetos que utiliza (sus dependencias) y un contenedor de inversión de control (el de Spring en este caso) inyecta las dependencias en tiempo de ejecución. Ambas estrategias de diseño benefician el mantenimiento del sistema ya que reducen el código repetitivo de instanciación e inicialización de los objetos y facilitan la sustitución de implementaciones concretas y la realización de pruebas. Para ello, se pueden crear nuevas clases que implementen la interfaz, o incluso clases mock ostubs, cuya implementación de los métodos de la interfaz sea vacía y que son utilizadas para realizar pruebas, sustituir implementaciones en tiempo de ejecución, etc. Por tanto, para el diseño de cada componente, se crea en primer lugar una interfaz Java donde se definen los métodos que ofrece. Posteriormente, se crea una clase que implementa dicha interfaz. Cada componente utilizará operaciones proporcionadas por los DAO de la capa de acceso a datos para almacenar datos en la base de datos. Los componentes también pueden utilizar operaciones proporcionadas por otros componentes de la capa de lógica de negocio, ya sean componentes creados específicamente para el proyecto o librerías genéricas empleadas (como Quartz, JavaMail, etc). Cada componente declara, utilizando anotaciones en el código de Spring, los componentes que requiere para implementar sus operaciones. Spring se encarga, en tiempo de ejecución, de instanciar los componentes necesarios y proporcionar las dependencias a los componentes que lo requieran. De esta forma, se reduce el acoplamiento entre los objetos del sistema. Los objetos conocen sus dependencias a través de interfaces con lo que es posible cambiar la implementación de estas dependencias de forma transparente para el objeto que las contiene. En la figura 3.9 se puede ver un diagrama de clases simplificado del diseño de un componente, en este caso el componente AlumnoService utilizado para implementar la funcionalidad de los alumnos. Como se puede observar, hay una interfaz Java, AlumnoService, donde se declaran los métodos del componente. Esta interfaz es implementada por la clase AlumnoServiceImpl, que provee de una implementación concreta a los métodos declarados en AlumnoService. Para proporcionar la implementación de los diferentes métodos, AlumnoServiceImpl utiliza métodos o servicios ofrecidos por otros componentes que están declarados como atributos (no se muestran en el diagrama por motivos de espacio). Se han representado sólo dos de los componentes de los que depende para facilitar la interpretación del diagrama. Estos dos componentes son: ProfesorService, componente de la capa de lógica de negocio 3.5. CAPA DE LÓGICA DE NEGOCIO 29 que implementa la funcionalidad de los profesores y AlumnoDao, componente de la capa de acceso a datos utilizado para acceder a la entidad Alumno de la base de datos. Como se puede apreciar, la clase AlumnoServiceImpl depende de los otros componentes a través de abstracciones (interfaces), no a través de implementaciones concretas. Se puede ver cómo depende del componente ProfesorService y que este componente tiene una clase, ProfesorServiceImpl, que implementa sus métodos. También se puede observar la dependencia con respecto al componente AlumnoDao, que es implementado por la clase AlumnoDaoHibernate. De esta forma, se reduce el acoplamiento de la aplicación, consiguiendo que esté formada por componentes poco acoplados entre sí. Figura 3.9. Diagrama de clases de un componente 36 CAPÍTULO 4. GESTIÓN DEL PROYECTO (eXtreme Programming, XP) [63] [15], Scrum [64] y el Agile Unified Process [65] (versión simplificada y ágil del Rational Unified Process [66]). Algunas de las estrategias típicas de implementación de este tipo de metodologías y que se han aplicado en el proyecto son: simplicidad en el código, frecuente refactorización del mismo, pruebas unitarias y de integración continuas y evaluación periódica del estado real del sistema por el cliente. El objetivo principal al introducir estas prácticas en el proyecto era que el director del mismo pudiera ir viendo la aplicación real, interactuar con ella, detectar errores, proponer cambios, modificaciones, mejoras, etc., desde el principio de la fase de implementación. De esta forma, se buscaba una mayor seguridad de que el sistema entregado al final del proyecto coincidiese con el esperado. Otros objetivos eran: simplificar la implementación y el mantenimiento del código, obtener formación a nivel teórico de estas estrategias y ponerlas en práctica en un proyecto de software real. Para ello, antes del comienzo de la fase de implementación, se priorizaron en detalle las funcionalidades del sistema. Se estimó el tiempo requerido para implementar cada funcionalidad, se llevó a cabo un análisis de los riesgos de implementación y se definieron estrategias de mitigación de dichos riesgos. Los diferentes casos de uso se fueron desarrollando por orden de prioridad. En las reuniones con el director del proyecto se revisaba la funcionalidad implementada hasta el momento. Conforme surgían nuevos requisitos o era necesaria la modificación o refinamiento de requisitos previos, se revisaba el diseño y se implementaba o modificaba la funcionalidad correspondiente. Con este desarrollo incremental, se conseguía una mayor flexibilidad ante cambios en los requerimientos durante el desarrollo. Asimismo, el sistema era utilizable en todo momento. Por último, para elaborar la presente memoria también se llevaron a cabo varias iteraciones. Se realizó una primera versión que luego se fue corrigiendo y mejorando hasta alcanzar el objetivo deseado. 4.2 Planificación La planificación de cada una de las fases del proyecto se puede observar en el diagrama Gantt de la figura 4.1. Como se puede ver, se estimó una fecha de comienzo y de finalización para cada fase. Esto implica una duración determinada, considerando como días hábiles de lunes a viernes (ambos incluidos) y una dedicación media por día hábil de 6 horas. A continuación, se describen brevemente los objetivos y resultados de cada una de las fases del proyecto. 4.2.1 Fase de formación y análisis de tecnologías Esta fase tenía dos objetivos principales. El primero era adquirir los conocimientos técnicos necesarios para desarrollar Portlets y aplicaciones Web. El segundo objetivo 4.2. PLANIFICACIÓN 37 Figura 4.1. Diagrama Gantt con la planificación estimada del proyecto era analizar y probar las tecnologías y herramientas más utilizadas para desarrollar estas aplicaciones con el fin de elegir aquellas más adecuadas para el proyecto. Esta fase culminó con la presentación de un seminario al director del proyecto sobre la tecnología de Portlets (dicho seminario está incluido en el anexo F). Sin embargo, la formación a lo largo de todo el proyecto ha sido continua ya que conforme se implementaba era necesario adquirir formación sobre las diferentes tecnologías y herramientas utilizadas. 4.2.2 Fase de análisis del problema Los objetivos de esta fase eran: analizar las necesidades de los usuarios del sistema y capturar los requisitos del mismo. Para ello se utilizaron tres tipos de técnicas: reuniones con el director, tablas de requisitos y casos de uso. Esta fase no fue especialmente compleja dado que muchos de los requisitos funcionales del sistema eran conocidos previamente por el director del proyecto. 4.2.3 Fase de diseño de la solución El objetivo de esta fase era definir la arquitectura general del sistema y diseñar cada uno de los elementos que conforman dicha arquitectura. Se realizó un diseño de abajo a arriba, empezando con el modelado de los datos y finalizando con el modelado de la interfaz de usuario. Los resultados de esta fase fueron: el diseño multicapa realizado, el modelado de los de datos del sistema, el diseño de los componentes de alto nivel y las clases del sistema y el modelado de la interfaz de usuario. Una vez elaborado un primer diseño del sistema, se planificó la fase de implementación. Se priorizaron las funcionalidades del sistema y se estimó su 38 CAPÍTULO 4. GESTIÓN DEL PROYECTO duración en jornadas de trabajo. En el diagrama Gantt de la figura 4.1 se muestra la fase de implementación desglosada en sus iteraciones y la aplicación afectada en cada iteración. 4.2.4 Fase de implementación El objetivo de esta fase era codificar el sistema siguiendo el diseño elaborado en la fase anterior. Esta fase se dividió en 7 iteraciones. En la iteración 1 se implementó el esqueleto de la aplicación Web con una interfaz básica que ofrecía una visión completa de las diferentes opciones de menú (siguiendo la filosofía de hacer que el sistema completo funcionase antes de hacerlo atractivo a nivel de interfaz de usuario). En la iteración 2 se implementó la funcionalidad principal o básica de la aplicación Web (registro e inicio de sesión, alta de asignaturas, alumnos, horarios, etc). En la tercera iteración, se implementó el esqueleto y funcionalidad básica de la aplicación Portlet (inicio de sesión y solicitar tutorías). En la cuarta y quinta iteraciones, se implementó la funcionalidad secundaria de la aplicación Web (preferencias de configuración, criterios de visualización de informes, generación de informes en formato PDF, etc.) y de la aplicación Portlet (cancelar y modificar solicitudes de tutorías, solicitud de nueva contraseña, etc.), respectivamente. En la iteración 6 se codificaron aspectos que afectaban al sistema completo: las copias de seguridad, la generación de ficheros de log, las operaciones de mantenimiento del sistema cada curso académico, etc. Finalmente, en la séptima iteración, se mejoró la interfaz gráfica del sistema completo. Además, durante la implementación se fueron realizando pruebas unitarias de los diferentes componentes así como pruebas de integración. El resultado de esta fase es el sistema funcionando de forma local en la máquina del alumno. 4.2.5 Fase de pruebas El objetivo de esta fase era detectar y posteriormente corregir errores en el sistema. Las pruebas abarcaron toda la funcionalidad del sistema. También se simuló un cambio de curso académico para comprobar que las operaciones de mantenimiento del sistema se realizaban correctamente. Del mismo modo, se simuló la pérdida de todos los datos de la aplicación para comprobar su correcta restauración mediante las copias de seguridad realizadas por el sistema. Como resultado de esta fase, se corrigieron errores de implementación que habían pasado desapercibidos en la fase anterior. 4.2.6 Fase de documentación Durante esta fase se escribió esta memoria con el resumen del proyecto así como los anexos, utilizando como base toda la documentación que había sido generada durante las diferentes fases del proyecto. 4.3. ESFUERZO REAL DEDICADO 39 4.2.7 Fase de transferencia del sistema En esta fase se instaló la aplicación Web en un servidor de la Universidad para ponerla a disposición de los profesores. Además, se integró en la página Web del director del proyecto la aplicación Portlet de petición de cita de tutoría para ponerla a disposición de los alumnos. 4.3 Esfuerzo real dedicado Al inicio del proyecto (julio de 2010), se estimó una duración del mismo de entre 5 y 7 meses, equivalentes a entre 650 y 800 horas de trabajo efectivo. Esta estimación estaba basada fundamentalmente en la experiencia del director del proyecto con otros proyectos similares de desarrollo de un sistema con un fuerte componente de aprendizaje tecnológico. Por tanto, se estableció como objetivo el depósito del proyecto en febrero de 2011 para concurrir a la convocatoria de marzo de 2011. La duración real de cada una de las fases del proyecto se puede observar en el diagrama Gantt de la figura 4.2. Si se compara con el de la figura 4.1, se observa que las fases que presentan diferencias en cuanto a su duración son la de implementación y la de documentación. La fase de implementación duró 9 jornadas de trabajo menos de lo planificado. Esta disminución se debe a que se sobrestimaron ligeramente los esfuerzos de implementación requeridos dada la inexperiencia del alumno con la mayoría de tecnologías utilizadas en el momento de realizar las estimaciones. Como consecuencia de la disminución de la duración de esta fase, la fase de documentación adelantó su fecha de inicio. Sin embargo, dicha fase duró 22 jornadas de trabajo más de lo planificado. La razón de este desvío reside en la menor dedicación al proyecto durante las 2 semanas correspondientes a las vacaciones de Navidad. En la figura 4.3 se muestra el tiempo en horas y el porcentaje dedicado a cada fase del proyecto. En total, el número de horas empleadas en el proyecto ha sido de 824. Esto implica un desvío de 24 horas con respecto a la cota superior de 800 horas estimada al inicio del proyecto. Este desvío se debe, fundamentalmente, al trabajo con numerosas tecnologías y herramientas novedosas, al interés del alumno por aprenderlas aun cuando no se utilizaran todas sus posibilidades de forma directa en el proyecto y a las revisiones de diseño necesarias en ciertas etapas de la fase de implementación. 40 CAPÍTULO 4. GESTIÓN DEL PROYECTO Figura 4.2. Diagrama Gantt con la duración real del proyecto Figura 4.3. Horas y porcentaje de esfuerzo dedicados a cada fase del proyecto Capítulo 5 Conclusiones En este último capítulo se reflexiona y concluye acerca del proyecto. En la sección 5.1 se resume el trabajo realizado en el proyecto, cumplimiento de los objetivos, principales problemas encontrados, etc. En la sección 5.2 se presentan las reflexiones personales del alumno sobre el proyecto. En la sección 5.3 se exponen una serie de trabajos futuros relacionados con este proyecto que podrían resultar interesantes, ya sea como proyectos fin de carrera o en otro marco de trabajo o investigación. 5.1 Resultados El propósito de este proyecto fin de carrera era diseñar e implementar un sistema accesible vía Web que facilitara a profesores y alumnos la gestión de la asistencia a las tutorías. Para ello, se ha diseñado e implementado una aplicación Web de configuración en la que los profesores pueden configurar las asignaturas para las cuales quieren utilizar el sistema y sus horarios de tutorías. También se ha desarrollado una aplicación Portlet para la reserva de cita de tutoría por los alumnos dados de alta por los profesores mediante la aplicación anterior. La aplicación Web de configuración se ha instalado en el servidor Alkaid y es accesible desde la URL http://alkaid.cps.unizar.es:8280/igetutor/. La aplicación Portlet se ha instalado en la página Web del director del proyecto, accesible a través de la URL http://webdiis.unizar.es/~alvaper/. Estas dos aplicaciones han permitido cumplir con los objetivos del proyecto detallados en la sección 2.1. Se ha conseguido desarrollar toda la funcionalidad especificada en los requisitos funcionales del sistema. También se han conseguido todos los aspectos de naturaleza no funcional descritos en los requisitos no funcionales. En cuanto a los objetivos de gestión, se ha cumplido la fecha de entrega planteada al principio del proyecto. 41 42 CAPÍTULO 5. CONCLUSIONES Los principales problemas encontrados a lo largo del proyecto han sido fundamentalmente consecuencia del aprendizaje y adaptación del alumno a las tecnologías y herramientas utilizadas. Es por ello que el proyecto ha tenido un fuerte componente formativo, tal y como se puede observar en los esfuerzos dedicados incluidos en el capítulo anterior. Conviene también resaltar que, en ocasiones, la formación adquirida a través de la lectura de libros y documentos no ha tenido aplicación directa en el proyecto. Sin embargo, el alumno consideraba este trabajo como una buena oportunidad para aprender otras cuestiones aunque no estuvieran directamente implicadas en el proyecto. Aparte de estos, no ha existido ningún otro problema relevante. 5.2 Opinión personal La realización del presente proyecto ha supuesto una experiencia muy enriquecedora para su autor desde varias perspectivas. Desde una perspectiva técnica, uno de los objetivos principales del proyecto para el alumno era el aprendizaje de nuevos tipos de aplicaciones, tecnologías y herramientas usadas ampliamente en la actualidad en la industria del software. En cuanto a los tipos de aplicaciones, esta es la primera aplicación Web desarrollada por el alumno, ya que el resto de aplicaciones realizadas durante la carrera habían sido aplicaciones de escritorio con interfaces gráficas o de línea de comandos. Para su diseño e implementación se han tenido que estudiar aplicaciones Web existentes y patrones de diseño. Esto ha incrementado el conocimiento del alumno de sistemas informáticos. En cuanto a las tecnologías, el uso de tecnologías Web como HTML, CSS, JavaScript y AJAX (combinación de las anteriores con JSON), ha permitido al alumno adquirir experiencia de gran valor a la hora de su futura incorporación al mercado laboral. La tecnología de Portlets utilizada es una tecnología emergente y, como tal, resulta difícil predecir en este momento sus perspectivas de futuro. El trabajo con esta tecnología novedosa ha permitido al alumno experimentar las dificultades típicas que existen al empezar a trabajar con una tecnología de reciente creación. Algunos ejemplos de estas dificultades son: la escasez de bibliografía y en general de documentación, el estado inicial de muchas herramientas de desarrollo, la falta de expertos en la tecnología con los que consultar dudas, etc. En cualquier caso, el uso de esta tecnología ha supuesto además la toma de contacto con otra serie de tecnologías relacionadas como por ejemplo los Servlets y las JavaServer Pages. Finalmente, se ha aprendido a utilizar herramientas ampliamente conocidas como los frameworks Hibernate y Spring. Estas herramientas son muy demandadas en la actualidad por las empresas del sector [12] por lo que su aprendizaje tiene de nuevo un gran valor para el futuro profesional del autor. También el uso de un 5.3. TRABAJO FUTURO 43 framework Web como Tapestry, no tan usado como los frameworks anteriores u otros frameworks Web como Struts, pero de gran utilidad práctica. De este modo, se ha complementado la formación adquirida durante la carrera. Desde la perspectiva de gestión del proyecto, se han aplicado los conocimientos teóricos y prácticos de gestión de proyectos adquiridos a lo largo de estos años. Actividades del proyecto como la planificación, la realización de estimaciones, el análisis de los posibles riesgos y la definición de estrategias de mitigación de los mismos, el control estricto de la gestión de esfuerzos, la gestión de las configuraciones de software, etc., se han puesto de relieve en el proyecto. Por último, en cuanto a los objetivos personales de índole no exclusivamente técnica, uno de ellos era la adquisición de mayor experiencia en la comunicación tanto de cuestiones técnicas de un sistema como de los aspectos de gestión. Esto se ha conseguido a través de las reuniones y correos electrónicos con el director del proyecto y se seguirá practicando con la defensa del proyecto. Por otro lado, el autor desea que esta aplicación sea de utilidad tanto a profesores como alumnos y que pueda ser ampliada en el futuro ante nuevas necesidades. 5.3 Trabajo futuro En esta sección se describen posibles trabajos futuros que podrían complementar o ampliar el proyecto realizado. 5.3.1 Comparativas de tecnologías Desde el principio, este proyecto se centró en la tecnología estándar de Java Portlets. Sin embargo, podría resultar interesante realizar una comparativa entre esta tecnología y su equivalente más cercano en la plataforma .NET, las Web Parts [31]. Se podría realizar un proyecto de software de pequeño tamaño utilizando ambas tecnologías para adquirir experiencia en su manejo y realizar un análisis de ambas tecnologías, comparando sus ventajas e inconvenientes, los tiempos de aprendizaje y desarrollo empleado en el proyecto con ambas tecnologías, etc. En la misma línea, también se podrían estudiar y comparar a nivel teórico y práctico los Portlets, los Google Gadgets [72] y los Web Widgets [73]. El World Wide Web Consortium (W3C) [74] se encuentra actualmente trabajando en la descripción de un conjunto de estándares para los Web Wigets [75]. Además, algunos trabajos en esta línea muestran que las relaciones entre Portlets y Widgets son aún difusas [76] por lo que este campo se encuentra totalmente abierto a nuevas publicaciones. 5.3.2 Ampliaciones del sistema actual Algunas de las ampliaciones que se podrían realizar al sistema actual son: 44 CAPÍTULO 5. CONCLUSIONES •Mejorar el formato de presentación de los informes en PDF utilizando herramientas avanzadas como por ejemplo JasperReports [61]. •Mejorar la interfaz de la aplicación Portlet utilizando componentes AJAX avanzados (calendarios, pestañas, etc.) proporcionados por librerías JavaScript como Dojo [32] y jQuery [33]. •Mejorar el formato de los correos electrónicos enviados a profesores y alumnos. •Dar la posibilidad al administrador de configurar la frecuencia con la que se realizan las copias de seguridad. •Ofrecer la aplicación Portlet en otros idiomas para los estudiantes Erasmus. •Permitir al administrador enviar notificaciones a todos los profesores registrados en el sistema. •Sincronizar las solicitudes de tutoría pendientes con aplicaciones como iCal [70] o Google Calendar [71] para que los profesores puedan recibir notificaciones por SMS. Como se puede ver, algunas de estas ampliaciones tienen que ver con la mejora de cuestiones estéticas del sistema y otras con la adición funcionalidad para futuras versiones del mismo. Anexo A Análisis de la tecnología de Portlets En este anexo se presenta un análisis completo de la tecnología de Portlets elaborado a partir del seminario de Portlets realizado durante la fase de formación y análisis de tecnologías del proyecto. El seminario original se incluye en el anexo F. En la sección A.1 se introduce la tecnología de Portlets. En la sección A.2 se ofrece una visión general de los estándares de Portlets. La sección A.3 se enfoca hacia la implementación de Portlets, analizando diferentes herramientas de desarrollo. Por último, en la sección A.4 se presentan una serie de reflexiones sobre esta tecnología. A.1 Introducción Un Portlet es una aplicación Web que proporciona un servicio o información y que se incluye en un portal Web. Facilitan por tanto la integración de aplicaciones en páginas de portales Web. Son utilizados por los portales Web como componentes integrables a nivel de interfaz de usuario, proporcionando una capa de presentación a sistemas de información. Son gestionados por un contenedor de Portlets. También se pueden considerar como servicios Web orientados a presentación. Esta visión se explicará en la sección A.2.2. Son una extensión de los Servlets (otra capa de abstracción por encima) aunque tienen importantes diferencias con respecto a éstos [43]. Por ejemplo, en un Portlet el desarrollador no se debe preocupar de qué método HTTP ha utilizado el cliente (GET, POST, etc.), ni de crear su propia infraestructura para capturar los eventos del cliente (por ejemplo, cuando se pulsa un botón). Los Portlets complementan y coexisten con las aplicaciones Web tradicionales, no están pensados para reemplazarlas. Algunas de las características funcionales más relevantes de un Portlet son: 45 52 ANEXO A. ANÁLISIS DE LA TECNOLOGÍA DE PORTLETS •Permite guardar las preferencias de los usuarios del Portlet en una base de datos interna gestionada por el contenedor de Portlets (transparente al desarrollador). •Modos del Portlet (formas de funcionamiento): –Estándares: View (tarea principal del Portlet), Edit (configuración de preferencias del Portlet) y Help (ayuda del Portlet). –Modos a medida (creados por el desarrollador). •Estados de la ventana del Portlet (cantidad de espacio que el portal asigna al fragmento generado por el Portlet): –Estándares: Maximizada, minimizada y normal. –Estados a medida (definidos por el desarrollador). •Procesamiento y manejo de las peticiones del Portlet refinado: –RenderRequest: Procesamiento de peticiones de renderización (producen el contenido que se muestra al usuario, es decir, los fragmentos de markup). –ActionRequest: Procesamiento de peticiones de acción (cambian el estado del sistema y no producen markup). En el momento en que los servidores de portales comenzaron a integrar la versión 1.0 de la especificación, empezaron a detectarse carencias importantes de funcionalidad que el estándar no contemplaba. Pronto comenzó el desarrollo de la versión 2.0 del estándar con el fin de subsanar estas carencias y proveer de nuevas funcionalidades a los Portlets. Entre las nuevas funcionalidades que introdujo JPS 2.0 destacan: •Dos mecanismos de coordinación entre Portlets: 1. Eventos: Mecanismo potente que permite la comunicación entre los Portlets de un portal a través del envío y recepción de eventos. 2. Parámetros públicos de renderización: Mecanismo menos potente que el anterior pero más sencillo de utilizar. Permite a los Portlets especificar qué parámetros de renderización (render parameters) desean compartir con otros Portlets. •Soporte para servir recursos (por ejemplo descarga de ficheros binarios) en el contexto del Portlet, lo que permite soportar interacciones AJAX. •Filtros de Portlets: Permiten transformar “al vuelo” el contenido de las peticiones y respuestas de los Portlets, crear cadenas de filtros, etc. A.2. ESTÁNDARES DE PORTLETS 53 •Anotaciones en el código para los métodos que procesan peticiones de acción, renderización, recursos y eventos. Estas anotaciones minimizan el código requerido haciendo uso del principio de convención sobre configuración [14]. Esta versión 2.0 del estándar JPS está totalmente sincronizada con la versión 2.0 del estándar WSRP. También mantiene total compatibilidad hacia atrás con la versión 1.0 del propio estándar, de hecho, es una extensión de ésta. Más detalle acerca de ambas versiones del estándar se puede consultar en los propios estándares [36] [37] o en artículos explicativos [39]. A.2.2 Web Services for Remote Portlets (WSRP) El estándar WSRP es un protocolo para la comunicación con Portlets remotos. Como se ha indicado anteriormente, los Portlets se pueden considerar como servicios Web orientados a presentación ya que integran tanto los datos como la lógica de presentación. Este enfoque es opuesto al tradicional de servicios Web orientados a datos. Los servicios Web tradicionales permiten reusar servicios de back-end, es decir, ofrecen reusabilidad a nivel funcional o de lógica de negocio. WSRP permite que los Portlets de un portal sean expuestos como servicios Web orientados a presentación y puedan ser consumidos remotamente. Permite por tanto reutilizar la interfaz de usuario completa. WSRP está construido sobre los estándares existentes de servicios Web como SOAP [81], WSDL [80] y UDDI [82]. Por ejemplo, define cómo usar SOAP para solicitar y recibir fragmentos HTML. De nuevo, este enfoque es diferente al tradicional de invocar un método a través de SOAP y obtener como respuesta típica datos en formato XML o JSON. El objetivo de WSRP es conseguir que Internet sea un mercado de servicios Web orientados a presentación o visuales (i.e. Portlets) listos para ser integrados en Portales Web. Los actores que intervienen en este estándar son: •Portal Web •Portlet •Productor WSRP •Consumidor WSRP El estándar define el API para exportar los Portlets de un productor a consumidores remotos. Este estándar permite comunicación entre Portlets remotos y por tanto la integración en un portal de Portlets procedentes de diversas fuentes. Además proporciona interoperabilidad, es decir, productor y consumidor de Portlets pueden usar tecnologías diferentes (por ejemplo, JEE y .NET). A nivel técnico, WSRP define: 54 ANEXO A. ANÁLISIS DE LA TECNOLOGÍA DE PORTLETS •Un conjunto de interfaces WSDL que debe implementar un productor para permitir a los consumidores invocar WSRP: –Service Description: Esta interfaz WSDL es de implementación obligatoria. Sirve para obtener una descripción del servicio ofrecido por el Portlet remoto. –Markup: Esta interfaz WSDL es de implementación obligatoria. Sirve para permitir la interacción con el Portlet remoto. –Registration: Interfaz opcional que permite al consumidor del Portlet remoto registrarse con el productor. –Portlet Management: Interfaz opcional que sirve para gestionar el ciclo de vida del Portlet remoto (por ejemplo para ofrecerlo sólo durante un periodo de tiempo). •Métodos para publicar, encontrar y asociar WSRP y metadatos. •Reglas para los fragmentos de markup emitidos por los WSRP. Para una información más detallada, se puede consultar la versión 2.0 del estándar WSRP [35]. A.3 Desarrollo de Portlets Una aplicación Portlet es una extensión de una aplicación Web JEE que se empaqueta en un fichero WAR (Web application Archive). La aplicación Portlet se instala en un servidor de portales o en un contenedor de Portlets. Cada aplicación Portlet puede constar de uno o más Portlets. Un Portlet no es más que una clase Java que implementa la interfaz javax.portlet.Portlet, o hereda de la clase GenericPortlet que implementa la interfaz anterior (estrategia usada en el proyecto). Las aplicaciones Portlet contienen un descriptor de despliegue que consiste en un fichero XML donde se especifican los Portlets disponibles para el contenedor y qué clase se debería utilizar para instanciarlos. Al ser un tipo especial de aplicación Web, también contienen el fichero XML que sirve como descriptor de despliegue para toda aplicación Web (web.xml) donde se define su estructura. Para empezar a desarrollar Portlets, es necesario tener conocimientos previos de X/HTML, XML, Servlets y páginas JSP. En la figura A.4 se puede observar la estructura típica de una aplicación Portlet. Como se puede ver, la estructura es similar a la de una aplicación Web tradicional. En la actualidad, no existen prácticamente herramientas gratuitas en estado de madurez que ayuden al desarrollo de Portlets. Las herramientas que se analizaron y probaron en el proyecto se describen a continuación. Los entornos de desarrollo NetBeans y Eclipse cuentan con un plugin denominado Portal Pack que facilita ligeramente el desarrollo de Portlets. A.3. DESARROLLO DE PORTLETS 55 Figura A.4. Estructura de una aplicación Portlet A.3.1 NetBeans Portal Pack El plugin Portal Pack de NetBeans [44] permite: •Creación automática de la estructura inicial de la clase Java, el descriptor XML y las páginas JSP del Portlet, añadiendo el tipo de proyecto Portlet a los proyectos de NetBeans. •Integración de NetBeans con el servidor de portales Liferay, funcionando sobre el servidor de aplicaciones J2EE GlassFish. •Integración de NetBeans con el servidor de portales Sun Java System Portal Server. •Integración de NetBeans con el contenedor de Portlets OpenPortal Portlet Container. 56 ANEXO A. ANÁLISIS DE LA TECNOLOGÍA DE PORTLETS •Integración de NetBeans con Spring Portlet MVC. •Desarrollo de aplicaciones Portlet con JavaServer Faces (JSF) [19], utilizando un editor visual (WYSIWYG). La versión actual de esta herramienta es la 3.0.4. A.3.2 Eclipse Portal Pack El plugin Portal Pack de Eclipse [45] está menos avanzado que el de NetBeans. Ofrece las siguientes funcionalidades: 1. Creación automática de la estructura inicial de la clase Java, el descriptor XML y las páginas JSP del Portlet, añadiendo el tipo de proyecto Portlet a los proyectos de Eclipse. 2. Integración de Eclipse con el servidor de portales WebSpace, funcionando sobre el servidor de aplicaciones J2EE GlassFish. 3. Integración de Eclipse con el contenedor de Portlets OpenPortal Portlet Container. La versión actual es la 2.0.1. A.3.3 Eclipse Portlet Tools Eclipse Portlet Tools [41] es otro plugin para Eclipse. Permite crear automáticamente el descriptor XML, completado de etiquetas en este fichero, etc., pero aún no permite integración con servidores de portales o contenedores de Portlets. La versión actual es la 0.2.0. A.3.4 Spring Portlet MVC El framework Spring cuenta con un módulo Web que además de soportar el desarrollo de aplicaciones Web convencionales (basadas en Servlets), también soporta el desarrollo de Portlets según la versión inicial del estándar JPS (1.0). Spring Web MVC es un framework Web orientado a acciones (request-driven Web MVC framework), en oposición a los framework Web orientados a componentes (event-driven Web UI frameworks) como Tapestry. Por tanto, requiere que el desarrollador trabaje con cuestiones de más bajo nivel. El desarrollo de Portlets usando Spring Portlet MVC [40] requiere experiencia previa, en general con el framework Spring y en particular con el módulo Spring Web MVC. A.4. CONCLUSIONES 57 A.3.5 Tapestry Portlet Support Tapestry es el framework Web que se ha utilizado para el desarrollo de la capa de presentación de la aplicación Web de configuración. La versión 4.1 del framework Web Tapestry tenía soporte para el estándar de Portlets de Java 1.0 (JSR-168) [38]. Sin embargo, la versión actual de dicho framework (versión 5) sufrió un profundo cambio y los desarrolladores de Tapestry tuvieron que desechar el soporte antiguo de Portlets. Actualmente, el soporte para Portlets continúa como uno de los objetivos a corto o medio plazo de la versión 5 de este framework Web. El soporte de Tapestry para Portlets podría facilitar considerablemente el desarrollo de la interfaz de usuario de los Portlets y permitir trabajar con plantillas HTML en lugar de tener que utilizar directamente páginas JSP. Éstas resultan tediosas de implementar ya que mezclan código Java y HTML, lo que dificulta su mantenibilidad. A.4 Conclusiones Los Portlets son una tecnología muy novedosa con una alta curva de aprendizaje, especialmente si no se tiene experiencia previa con otras tecnologías Web relacionadas como los Servlets, las JSP, la librería de tags de las JSP (JSTL), los servidores de portales Web, etc. Es una tecnología completamente ligada a los portales Web. Los Portlets permiten integración y reutilización a nivel de interfaz de usuario en portales. En la actualidad, no hay herramientas disponibles de forma gratuita para los desarrolladores, que simplifiquen el desarrollo de aplicaciones Portlet en la misma medida que ocurre con las aplicaciones Web convencionales. La mayoría de las herramientas todavía soportan únicamente la versión 1.0 del estándar JPS y no la nueva versión 2.0 que corrige carencias, fallos e incrementa notablemente la funcionalidad de la primera versión. En el caso del proyecto, se ha utilizado únicamente el plugin Portal Pack para el entorno de desarrollo Eclipse, ya que éste era el entorno de desarrollo elegido para el proyecto. En cuanto a las perspectivas de futuro de la tecnología de Portlets, resulta muy complicado de predecir en el actual estado emergente de la tecnología. La idea de los Portlets como servicios Web orientados a presentación que permiten reutilizar tanto la lógica de negocio como la interfaz de usuario, resulta muy atractiva. En el futuro se verá si este tipo de servicios Web se imponen como ocurrió en el pasado con los servicios Web tradicionales. 58 Anexo B Análisis de tecnologías En este anexo se presenta un análisis completo de las principales tecnologías utilizadas en el proyecto. La tecnología de Portlets tiene un anexo propio, el A. En la sección B.1 se describen los requisitos tecnológicos del sistema. En la sección B.2 se ofrece un listado completo de todas las tecnologías y herramientas utilizadas en el proyecto junto con una breve explicación de su función. La sección B.3 describe las principales tecnologías elegidas para satisfacer los requisitos tecnológicos del sistema. B.1 Requisitos tecnológicos Un primer requisito tecnológico es la necesidad de utilizar una plataforma de desarrollo estable y contrastada que soporte el paradigma de programación orientado a objetos predominante en la mayoría de aplicaciones actuales. También debe permitir la creación de aplicaciones Web modulares. Además, el sistema va a estar formado por varias capas o componentes que se han de coordinar entre si. Para facilitar su implementación, se consideró que sería también interesante utilizar algún framework o librería que facilite el desarrollo de aplicaciones en la plataforma elegida. El segundo requisito tecnológico que surge a la vista del análisis del problema es la necesidad de almacenar información relativa al dominio del sistema. Se requiere guardar datos de los profesores, alumnos, asignaturas, grupos de docencia, horarios de tutorías, etc. Para ello, hace falta un repositorio permanente de información así como tecnologías que permitan acceder a ese repositorio desde un lenguaje de programación de alto nivel. En definitiva, se precisan tecnologías de soporte al almacenamiento de información. El tercer requisito tecnológico es la necesidad de utilizar una tecnología Web orientada a servicios que facilite la integración en portales Web para que los 59 60 ANEXO B. ANÁLISIS DE TECNOLOGÍAS profesores puedan poner el sistema a disposición de sus alumnos de forma sencilla. Además, esta tecnología debe estar basada en estándares para incrementar la compatibilidad y estar soportada por la plataforma de desarrollo elegida. El cuarto requisito tecnológico surge de la necesidad de desarrollar interfaces Web de usuario dinámicas. Se necesitan tecnologías abiertas y basadas en estándares que estén soportadas por cualquier navegador Web para maximizar la accesibilidad del sistema. Por último, se requieren tecnologías que sirvan como entorno de ejecución del sistema. Dado que el sistema a construir es accesible vía Web, se necesita un servidor Web en el que residirá la aplicación. Este servidor debe soportar la tecnología concreta utilizada para desarrollar la aplicación Web. B.2 Listado de tecnologías y herramientas utilizadas Las tecnologías y herramientas utilizadas en el proyecto han sido las siguientes: •Java EE [16] como plataforma de desarrollo. •Java como lenguaje de programación del sistema. •Portlets como tecnología para la aplicación de reserva de cita de tutoría utilizada por los alumnos. •MySQL [28] como sistema gestor de base de datos relacional. •Hibernate Framework [26] como herramienta de mapeo objeto-relacional. •Hibernate Tools [48] como herramienta para la generación automática de clases Java del dominio. •Spring Framework [27] como herramienta de desarrollo de aplicaciones para la plataforma Java EE. •Apache Tapestry [24] como framework Web para el desarrollo de la interfaz de la aplicación Web de configuración utilizada por los profesores. •Librerías Chenillekit [77] y Ioko [78] de Tapestry para ofrecer componentes AJAX [4] en la aplicación Web. •Apache Tomcat [21] como contenedor Web. •OpenPortal Portlet Container [20] como contenedor de Portlets. •Liferay Portal Server [55] como servidor de portales para realizar pruebas con Portlets. B.2. LISTADO DE TECNOLOGÍAS Y HERRAMIENTAS UTILIZADAS 61 •Java Persistence API (JPA) [18] como API de persistencia para la plataforma Java EE. •HTML como lenguaje de markup para las páginas Web de la aplicación. •CSS como lenguaje para definir el estilo de las páginas Web de la aplicación. •JavaScript como lenguaje de programación para mejorar la interactividad de la aplicación Web. •JavaScript Object Notation (JSON) [57] como formato ligero para intercambio de datos. •JavaServer Pages (JSP) [5] y JavaServer Pages Standard Tag Library (JSTL) [54] como tecnologías para la interfaz de la aplicación Portlet de reserva de cita de tutoría. •Java Servlet [22] como tecnología subyacente de la aplicación Web. •XML como lenguaje declarativo para los ficheros de configuración del sistema. •DWR (Direct Web Remoting) [53] como librería que permite invocar métodos de clases Java ubicadas en el servidor Web desde código JavaScript ubicado en el cliente (navegador Web). •Subversion como sistema de control de versiones. •Maven [59] para gestionar y compilar el proyecto software. •Eclipse como entorno de desarrollo para la implementación y depuración del sistema. •JUnit [56] para las pruebas unitarias del sistema. •JavaMail [58] para el envío de correos electrónicos desde la aplicación. •Quartz [49] para la planificación de tareas en la aplicación. •iTextPDF [50] para la generación y manipulación de documentos PDF desde la aplicación. •SLF4J (Simple Logging Facade for Java) [51] con Log4J [52] para la generación de ficheros de log del sistema. •Microsoft Visio, ArgoUML y ObjectAid UML Explorer para la elaboración de diagramas de análisis y diseño del sistema. •Microsoft Project para la elaboración del diagrama Gantt con la planificación del proyecto. 68 ANEXO C. DISEÑO DEL SISTEMA Figura C.1. Estructura de paquetes de la aplicación Web •service: contiene las interfaces de componentes de la capa de lógica de negocio. –impl: contiene las implementaciones de las interfaces anteriores utilizando el framework Spring. •utils: contiene clases de utilidad genérica empleadas por los componentes de la capa de lógica de negocio. C.1. ESTRUCTURA DE PAQUETES 69 –dao: contiene la interfaz genérica GenericDao y su implementación genérica GenericDaoHibernate. –exceptions: contiene clases de excepciones personalizadas para la aplicación como InstanceNotFoundException oDuplicateInstanceException. –informes: contiene las clases utilizadas para generar los informes de solicitudes de tutorías, históricos de solicitudes, incidencias y los informes resumen del curso académico. –listados: contiene clases que se utilizan para transformar y listar datos recuperados de la base de datos. –parsers: contiene los dos analizadores sintácticos que procesan los ficheros de festivos y de alumnos matriculados. –passwords: contiene las clases relacionadas con la generación automática de contraseñas y cifrado de las mismas utilizando la utilidad Unix crypt. –taskExecutors: contiene clases que ejecutan tareas en segundo plano (por ejemplo, envío de correos electrónicos de notificaciones). A continuación, se detallan los subpaquetes del paquete de primer nivel web. Este paquete contiene clases y plantillas que implementan la capa de presentación de la aplicación Web. Las clases y plantillas de estos paquetes realizan las funciones de Controlador y Vista del patrón MVC, respectivamente. Los subpaquetes de la capa de presentación son los siguientes: •components: contiene las clases Java del framework Web Tapestry que actúan como controladoras para los componentes de las páginas. Por ejemplo, para el Layout de las páginas de los profesores y el Layout de las páginas del administrador. •mixins: contiene la clase Java Confirm que invoca código JavaScript para mostrar mensajes de confirmación al usuario en ciertas pantallas. •pages: contiene las clases Java de Tapestry que actúan como controladoras para las páginas Web comunes a todos los usuarios de la aplicación (Home, Index, etc). –admin: contiene las clases Java de Tapestry que actúan como controladoras para las páginas accesibles por el administrador. –user: contiene las clases Java de Tapestry que actúan como controladoras para las páginas accesibles por los profesores. •services: contiene clases Java encargadas de gestionar aspectos de la aplicación como: cookies, políticas de autenticación para permitir o denegar el acceso a las diferentes páginas Web de la aplicación según el perfil del usuario (profesor o administrador), el locale de la interfaz de usuario (que define el idioma y el país), etc. 70 ANEXO C. DISEÑO DEL SISTEMA •util: contiene clases Java de utilidad genérica. Por ejemplo, clases para mantener la sesión del profesor y del administrador en el sistema, permitir descargar ficheros en formatos ZIP, PDF, texto, etc. –grid: contiene clases Java del componente Grid de Tapestry para diferentes pantallas de la aplicación según el tipo de datos a mostrar. El componente Grid de Tapestry permite mostrar datos en una tabla. Además, por cada clase Java de los paquetes components,pages,pages.admin y pages.user, existen plantillas de Tapestry (ficheros con la extensión .tml, Tapestry Markup Language) que definen utilizando XML y HTML, el formato visual de las diferentes páginas Web de la aplicación. Por último, la aplicación Portlet sólo tiene 2 paquetes o subsistemas con código Java: •portlet: contiene la clase PortletReservaTutorias que hereda de GenericPortlet. Actúa como Controlador y utiliza el componente de los alumnos (AlumnoService) del Modelo. •utils: contiene la clase Constants que define constantes de uso general en el Portlet. En el directorio de recursos del proyecto correspondiente a la aplicación Portlet se encuentran todas las páginas JSP, que generan la parte visual de la interfaz de usuario del Portlet. C.2 Componentes del sistema En esta sección se describen los componentes principales del sistema. C.2.1 Desglose de los componentes A continuación, se enumeran los componentes principales del sistema. Estos componentes principales del sistema forman parte de la capa de lógica de negocio. •AdminService: Implementa la funcionalidad del administrador del sistema. •AlumnoService: Implementa la funcionalidad de los alumnos. •ProfesorService: Implementa las operaciones de los profesores. •TutoriaService: Implementa la funcionalidad relacionada con la gestión de tutorías por parte de los profesores. C.2. COMPONENTES DEL SISTEMA 71 •StatsService: Implementa la funcionalidad relacionada con las estadísticas generales del sistema. •InformeService: Implementa la funcionalidad relacionada con los informes o notificaciones del sistema. •MantenimientoService: Implementa las operaciones de mantenimiento del sistema (operaciones a realizar cuando cambia el curso académico, copias de seguridad del sistema, etc). •EnvioMails: Permite enviar correos electrónicos utilizando la librería JavaMail. Envía tanto correos sin ficheros adjuntos como correos con ficheros adjuntos en formato PDF (para los informes o notificaciones). •GeneracionCalendarioSesionesTutorias: Se encarga de calcular las sesiones de tutorías del curso académico correspondientes a un determinado horario de tutorías. •PasswordGenerator: Genera contraseñas aleatorias para los alumnos del sistema. •PasswordEncrypter: Componente para cifrar las contraseñas almacenadas en la base de datos del sistema utilizando el cifrado de la utilidad Unix crypt. •ParserFicheroAlumnos: Componente que implementa un analizador sintáctico sencillo para procesar los ficheros de alumnos matriculados, importados en el sistema por los profesores. •ParserFicheroFestivos: Componente utilizado para procesar sintácticamente los ficheros de festivos que no se corresponden con fechas fijas durante un curso académico. •Componentes TaskExecutor: Conjunto de componentes que se encargan de crear una tarea o proceso en segundo plano para realizar operaciones que pueden ser costosas en tiempo. Ejemplos de operaciones costosas son: el envío de correos electrónicos a usuarios del sistema y la generación del calendario de sesiones de tutorías. Todos los componentes del sistema están empaquetados en un fichero JAR. Esto permite que puedan ser utilizados tanto por la aplicación Web, como por la aplicación Portlet, incluyendo el fichero anterior como librería en el proyecto correspondiente a cada aplicación. 72 ANEXO C. DISEÑO DEL SISTEMA C.2.2 Interfaces de los componentes Durante la fase de diseño se decidieron las operaciones de los componentes del sistema. Las operaciones de los componentes funcionales del sistema se pueden observar en el diagrama de clases de la figura C.2. Las operaciones de los componentes de soporte del sistema se pueden observar en el diagrama de clases de la figura C.3. C.3 Diagrama de clases del dominio En la figura C.4 se muestra el diagrama de clases del dominio. Para indicar las asociaciones entre clases no se han utilizado flechas ya que esto disminuye considerablemente la legibilidad del diagrama. En su lugar, las relaciones entre clases pueden obtenerse a partir de los atributos de cada clase. Todo atributo cuyo tipo sea de una clase del dominio (o un conjunto, Set, de una clase del dominio), se corresponde con una relación. Tampoco se han indicado las operaciones de cada clase ya que éstas son únicamente constructores y métodos de acceso a los atributos (getters ysetters). C.4 Patrones de diseño Además del patrón de diseño DAO explicado en la sección 3.3.2, también se han aplicado otra serie de patrones en diferentes partes del sistema. En esta sección se presentan dichos patrones. C.4.1 Model View Controller (MVC) La aplicación Web sigue un diseño multicapa tal y como se ha explicado en el capítulo correspondiente. El diseño realizado, también se puede identificar con el patrón Model View Controller [2]. A continuación se explica este patrón y su correspondencia con el diseño realizado. MVC es un patrón de presentación utilizado ampliamente en las aplicaciones Web. Divide la interacción con la interfaz de usuario en 3 roles distintos: el Modelo, la Vista y el Controlador. El Modelo es la parte de la aplicación que representa información acerca del dominio del sistema. En el caso de la aplicación Web diseñada, el Modelo se corresponde con las capas de dominio, acceso a datos y lógica de negocio. Contiene toda la información (datos) y el comportamiento de la aplicación. La Vista se corresponde con la representación del Modelo en la interfaz de usuario. Sólo se encarga de mostrar la información, no de gestionar los cambios C.4. PATRONES DE DISEÑO 73 Figura C.2. Interfaces de los componentes funcionales del sistema de dicha información, ya que esa es precisamente la tarea del tercer rol del patrón, 74 ANEXO C. DISEÑO DEL SISTEMA Figura C.3. Interfaces de los principales componentes de soporte del sistema el Controlador. El Controlador se encarga de recibir las acciones del usuario, manipular el Modelo y hacer que la Vista se actualice de forma apropiada. Por ello, la interfaz de usuario es una combinación de la Vista y el Controlador. En este proyecto, en el caso de la aplicación Web, la Vista es generada a partir de plantillas del framework Web Tapestry. Las clases Java de Tapestry de la capa de presentación se encargan de recibir los eventos del usuario, actuando como Controlador. Tapestry se encarga de procesar adecuadamente estos eventos utilizando la API de Servlets. En el caso de la aplicación Portlet, la Vista es generada a partir de páginas JSP que al ser compiladas se transforman en Servlets. La clase Java del Portlet (que hereda de la clase GenericPortlet) actúa como controladora, gestionando las peticiones de renderización y acción que llegan al Portlet a través del usuario. Este patrón tiene 2 ventajas fundamentales: 1. Separación de la presentación y el Modelo: esta separación es una de las estrategias más importantes de diseño de software. En esencia, consiste en la separación de la interfaz de usuario y la lógica de las aplicaciones. La importancia de esta separación se explica por varias razones: •La presentación y el Modelo son cuestiones diferentes de un sistema. A la hora de desarrollar la Vista, el desarrollador se preocupa de mecanismos de la interfaz de usuario como por ejemplo, qué componentes visuales puede utilizar, y cómo se colocarán éstos, de forma que la interfaz C.4. PATRONES DE DISEÑO 75 Figura C.4. Diagrama de clases detallado de la capa de dominio sea amigable y respete principios básicos de usabilidad (consistencia, sencillez, mensajes de error informativos, etc). Sin embargo, a la hora de trabajar en el Modelo, el programador tiene que pensar en cuestiones como la lógica de negocio, interacciones con la base de datos del sistema, transacciones, etc. Además, típicamente, el diseño de la interfaz de usuario y la lógica de un sistema son tareas realizadas por personas con un perfil y formación diferentes. •Permite desarrollar múltiples presentaciones (diferentes interfaces de usuario) utilizando el mismo código del Modelo. Dependiendo del contexto del sistema, la interfaz de usuario puede tomar formas muy diferentes. Es posible tener interfaces de usuario de línea de comandos, 76 ANEXO C. DISEÑO DEL SISTEMA gráficas de escritorio, interfaces Web, interfaces remotas, etc. •Los objetos no visuales suelen ser más fáciles de probar de forma automatizada que los objetos visuales. Esta separación, facilita realizar pruebas sobre la lógica de negocio de las aplicaciones, sin tener en cuenta, en un primer momento, la interfaz de usuario. Es importante mencionar que la presentación depende del Modelo, pero éste, en cambio, no depende de la presentación. De esta forma, resulta más fácil añadir nuevas interfaces de usuario más adelante, o cambiar las existentes sin alterar para ello el Modelo. 2. Separación del Controlador y la Vista: esta separación es bastante menos importante que la anterior. De hecho, en muchas implementaciones de este patrón no se lleva a cabo. Un ejemplo de utilidad podría ser el tener comportamiento editable y no editable en una interfaz. Esto se podría lograr con una única vista y 2 controladores para los 2 casos. C.4.2 Patrones objeto-relacional (The ORM Patterns) Los patrones objeto-relacional [2] se corresponden con un conjunto de patrones de diseño estructurales y de comportamiento. Están implementados en los mapeadores objeto-relacional que realizan la correspondencia entre objetos de un lenguaje de programación orientado a objetos y entidades de una base de datos relacional. En este proyecto se ha utilizado el mapeador Hibernate. En la figura C.5 se muestra la arquitectura de una aplicación que utiliza Hibernate. En ella, se puede observar cómo los objetos persistentes (Persistence Objects), son accesibles a todo el resto de la aplicación que utiliza Hibernate. Estos objetos persistentes se corresponden con la capa de dominio del sistema, transversal al resto de capas. Hibernate también utiliza un fichero de configuración (Hibernate.properties), donde se especifican las propiedades de la base de datos relacional usada, y ficheros XML (XML Mapping) que realizan el mapeo entre las entidades de la base de datos y las clases persistentes. En el caso del proyecto, se han utilizado anotaciones en las clases en lugar de ficheros XML para facilitar el mantenimiento, al tener el código y las anotaciones en el mismo sitio. A continuación se explican los patrones objeto-relacional utilizados en el proyecto. C.4.2.1 Identity Field El patrón Identity Field [2] es un patrón objeto-relacional de tipo estructural. Es muy sencillo de utilizar y entender. Se basa únicamente en guardar la clave primaria de las entidades de la base de datos como un campo de identidad (Identity Field) C.4. PATRONES DE DISEÑO 77 Figura C.5. Arquitectura de Hibernate en el objeto persistente que representa a dicha entidad. De esta forma, se conserva la identidad entre el objeto en memoria y la tupla de la base de datos. En el caso del proyecto, se ha utilizado en los objetos persistentes un campo de tipo Long para almacenar la clave primaria de las entidades. Para los objetos persistentes que representan relaciones de la base de datos, se ha utilizado una clase que contiene las claves primarias de todas las entidades que intervienen en la relación. Esto se puede observar en la figura C.4. C.4.2.2 Foreign Key Mapping El patrón Foreign Key Mapping [2] es también un patrón objeto-relacional de tipo estructural. Se utiliza para hacer corresponder las asociaciones entre objetos del dominio en claves ajenas (foreign keys) que hacen referencia a tablas de la base de datos. Por ejemplo, a nivel de objetos, la clase Asignatura tiene una referencia a la titulación a la que pertenece. Cuando se cree una nueva asignatura y se almacene en la base de datos, esa referencia a la titulación se transformará en la clave primaria de la titulación que referencia, constituyendo una clave ajena. C.4.2.3 Association Table Mapping El patrón Association Table Mapping [2] es otro patrón objeto-relacional de tipo estructural. Se basa en utilizar una nueva entidad con claves ajenas para almacenar asociaciones Muchos a Muchos, dado que éstas no se pueden tratar utilizando el patrón anterior. Esta entidad, frecuentemente denominada Link Table, contendrá únicamente las claves primarias de las 2 entidades relacionadas. Este tipo de tablas pueden tener o no corresponencia con objetos en memoria. Si la asociación tiene información acerca de la misma (atributos de la asociación), 84 ANEXO D. MANUAL DE USUARIO Figura D.3. Pantalla principal del profesor Figura D.4. Pantalla de inicio de sesión del sistema quien se lo indicará. A partir del nombre de usuario, el sistema enviará una nueva contraseña a la cuenta de correo electrónico asociada. D.2. MANUAL DEL PROFESOR 85 Figura D.5. Pantalla de olvido de contraseña Los primeros pasos a realizar una vez que haya iniciado sesión en el sistema por primera vez serán: 1. Configurar sus asignaturas. 2. Configurar sus horarios de tutorías. 3. Configurar sus preferencias. D.2.2 Configuración de asignaturas Antes de configurar las asignaturas, debemos asegurarnos de que podemos descargarnos del sistema de la Universidad el fichero de alumnos matriculados en las asignaturas que queramos dar de alta. No es posible configurar las asignaturas sin tener el listado de alumnos matriculados. Una vez haya iniciado sesión en el sistema por primera vez, el primer paso será configurar las asignaturas para las cuales quiere gestionar sus tutorías de forma automática. Para ello, en el menú de Gestión de asignaturas pulsaremos en la opción Alta nueva asignatura. Esto nos mostrará la pantalla que aparece en la figura D.6. En ella aparece un formulario donde introducir los datos de la asignatura a dar de alta. El primer paso es introducir el código de la asignatura. Si la asignatura ya estaba registrada previamente en el sistema (por otro profesor), al introducir el código en su 86 ANEXO D. MANUAL DE USUARIO Figura D.6. Pantalla de alta de asignatura correspondiente campo y cambiar de campo en el formulario, el sistema recuperará el resto de datos de la asignatura y rellenará de forma automática la mayoría de los campos. Sin embargo, todavía deberemos rellenar el tipo de impartición que realizamos (teoría, prácticas o ambos) y los datos del grupo de la asignatura que impartimos. De nuevo, si el grupo ya estuviera registrado, aparecerá la descripción que éste tuviera asociada. En el caso de que imparta más de un grupo de una misma asignatura, se tratará como 2 asignaturas diferentes, es decir, habrá que dar de alta ambos de forma independiente. Será necesario volver a repetir estos pasos con la asignatura e introducir el otro grupo. Al haber registrado previamente la asignatura, ahora sólo tendremos que introducir los datos del grupo y el tipo de impartición que realizamos. Por último, introduciremos la ruta del fichero de alumnos matriculados en la asignatura. El formato de este fichero se puede consultar pulsando en el enlace Ver formato (luego podemos volver atrás, al formulario que estábamos rellenando, pulsando el correspondiente botón del navegador). Este fichero se creará de forma muy sencilla a partir del fichero de alumnos matriculados que nos hayamos descargado del sistema de la Universidad, tal y como se indica en las instrucciones al pulsar el enlace Ver formato. D.2.3 Configuración de horarios de tutorías Una vez haya configurado las asignaturas para las que quiere utilizar el sistema, el siguiente paso es configurar sus horarios de tutorías. El sistema permite flexibilidad D.2. MANUAL DEL PROFESOR 87 de forma que es posible tener: •Un horario de tutorías distinto para cada asignatura configurada. •El mismo horario para todas las asignaturas configuradas. •Horarios diferentes para grupos de asignaturas (por ejemplo, un horario para las asignaturas del primer cuatrimestre y otro para las del segundo). Para configurar los horarios de tutorías, iremos al menú Gestión de horarios y pulsaremos en la opción Configurar horario. Se mostrará la pantalla que aparece en la figura D.7. Figura D.7. Pantalla de configuración de nuevo horario de tutorías En esta pantalla, primero hay que introducir las franjas del horario de tutorías. Inicialmente aparece una única franja y la opción de añadir nuevas franjas. Para cada franja que se quiera añadir, se seleccionará el día de la semana del menú desplegable. A continuación, se seleccionará la hora de inicio y la hora de finalización de la franja. Para ello, pulsaremos en el icono del reloj donde se elige en primer lugar la hora. A continuación se mostrará la hora pulsada y el minuto actual. Para cambiar los minutos, pulsaremos de nuevo en el reloj y seleccionaremos los minutos. Alternativamente, también se puede introducir directamente la hora escribiéndola en formato hh:mm (siempre la hora y los minutos con 2 cifras y separadas por el carácter dos puntos). 88 ANEXO D. MANUAL DE USUARIO Para crear una nueva franja, pulsaremos en el enlace Añadir franja. Aparecerá una nueva franja donde introducir sus datos. Si se desea eliminar una franja concreta, pulsaremos en el enlace Eliminar de la franja concreta. Una vez configuradas todas las franjas del horario de tutorías, introduciremos el tiempo (en minutos) que deseamos asignar a cada tutoría. Por defecto, aparece 30 minutos pero se puede cambiar a cualquier otro valor (siempre que no sea mayor que la duración de la franja más corta del horario). Por último, seleccionaremos las asignaturas a las que queremos aplicar el horario de tutorías introducido. Para ello, se utiliza un componente que contiene 2 cuadros de texto. En el de la izquierda aparecen las asignaturas que hayamos configurado y que todavía no tienen horario de tutorías asignado. Podemos elegir entre estas asignaturas a cuáles queremos aplicar el horario haciendo doble click en el nombre de la asignatura o bien pulsando el botón que muestra la flecha apuntando hacia la derecha. También podremos cambiar asignaturas que habíamos elegido previamente utilizando la flecha que apunta hacia la izquierda o haciendo doble click en la asignatura en el cuadro de la derecha. Las asignaturas que queden finalmente en el cuadro de la derecha serán las que tengan el horario introducido. Finalmente, pulsaremos el botón Crear horario para configurar el horario definitivamente. D.2.4 Configuración de las preferencias Una vez haya configurado sus horarios de tutorías, es recomendable configurar sus preferencias. Para ello, pulse en la opción Configurar preferencias del menú Gestión de perfil. Aparecerá la pantalla que se muestra en la figura D.8. Primero, configuraremos los tipos de informes y notificaciones de solicitudes de tutorías que deseamos recibir por correo electrónico (se envían en un fichero adjunto en formato PDF con el fin de facilitar su impresión). Al registrarnos en el sistema, se añaden dos tipos de notificaciones automáticamente: el sistema le enviará un informe diario si hay tutorías reservadas para ese mismo día y también le enviará una notificación si se reservan tutorías durante el día actual que vayan a tener lugar ese mismo día. Sin embargo, estas opciones podrán ser personalizadas según sus preferencias. Además de las opciones anteriores, el sistema también permite recibir una notificación individual por cada nueva tutoría solicitada y un informe el primer día de la semana con todas las tutorías pendientes de la semana. Después, configuraremos si se quiere que los alumnos puedan elegir hora de tutoría entre las disponibles, o si preferimos que el sistema asigne automáticamente una hora a cada alumno con el fin de que las tutorías asignadas tengan lugar de forma consecutiva (y así evitar huecos libres). Una vez seleccionadas todas las preferencias, pulsaremos en el botón Guardar preferencias para almacenarlas. D.2. MANUAL DEL PROFESOR 89 Figura D.8. Pantalla de configuración de las preferencias D.2.5 Gestión de la asistencia a las tutorías El sistema permite registrar si las tutorías solicitadas han tenido lugar o no. Para ello, hay que pulsar en la opción Tutorías realizadas del menú Control de asistencia. Aparecerá una pantalla como la que se muestra en la figura D.9. En ella, aparece una tabla con las tutorías realizadas hasta la fecha y una columna donde indicar si el alumno acudió a la tutoría o no. Una vez indicadas las tutorías realizadas, pulsaremos en el botón Guardar para que el sistema almacene la información introducida. D.2.6 Consulta de ausencias de alumnos Para consultar los alumnos que no acuden a las tutorías solicitadas, pulsaremos en la opción Ausencias de alumnos del menú Control de asistencia. Aparecerá una pantalla como la que se muestra en la figura D.10. En ella aparece un listado con aquellos alumnos que no han acudido a alguna tutoría y el número de tutorías a las que no han acudido. D.2.7 Ver informes de tutorías El sistema permite consultar informes de las solicitudes pendientes, el histórico de solicitudes y las incidencias de los alumnos. Además, también ofrece la opción 90 ANEXO D. MANUAL DE USUARIO Figura D.9. Pantalla de gestión de la asistencia a las tutorías Figura D.10. Pantalla de visualización de las ausencias de alumnos de descargar un fichero en formato PDF con el informe consultado con el fin de facilitar su impresión. Para ello, aparece el enlace Descargar informe en PDF. En la D.2. MANUAL DEL PROFESOR 91 figura D.11 se muestra un ejemplo con el listado de solicitudes de tutorías pendientes. Figura D.11. Pantalla de visualización de las solicitudes de tutoría pendientes Las solicitudes pendientes y el histórico de solicitudes se pueden consultar utilizando 2 criterios: la asignatura y un rango de fechas. Para visualizar todas las solicitudes, simplemente dejaremos la opción por defecto en el campo Asignatura (Todas mis asignaturas) y no introduciremos ninguna fecha. En el listado de solicitudes pendientes existe la posibilidad de cancelar determinadas tutorías. Para ello, basta con pulsar el enlace Cancelar de la tutoría concreta. El sistema enviará una notificación por correo electrónico al alumno informándole de la cancelación de la tutoría. Las incidencias (modificaciones o cancelaciones de tutorías llevadas a cabo por los alumnos) pueden consultarse también utilizando 2 criterios: el tipo de incidencia (modificación o cancelación) y el rango de fechas en el que tuvo lugar la incidencia. D.2.8 Cancelar sesiones El sistema también ofrece la opción de cancelar sus sesiones de tutorías entre 2 fechas determinadas a través de la pantalla que se muestra en la figura D.12. Para ello, seleccionaremos la opción Cancelar sesiones del menú Gestión de horarios. Aparecen 2 campos de tipo fecha donde podemos seleccionar en un calendario desplegable las fechas entre las cuales queremos cancelar nuestras sesiones. Una vez introducidas las 2 fechas, hay que pulsar en el botón Cancelar. Si hubiera tutorías reservadas para alguna de las sesiones canceladas, se enviará un correo electrónico al alumno informándole de la cancelación de la tutoría. 92 ANEXO D. MANUAL DE USUARIO Figura D.12. Pantalla de cancelación de sesiones de tutorías D.2.9 Ver asignaturas configuradas Para ver las asignaturas configuradas pulsaremos en la opción Ver asignaturas actuales del menú Gestión de asignaturas. Se mostrará la pantalla que aparece en la figura D.13. En ella, aparece una tabla con las asignaturas. Desde esta tabla se puede consultar el listado de alumnos matriculados en cada asignatura pulsando en el número de alumnos que aparece en la columna Alumnos de la asignatura. D.2.10 Eliminar asignaturas configuradas Para eliminar asignaturas configuradas (en el caso de que haya dejado de impartirlas), pulsaremos en la opción Eliminar asignaturas del menú Gestión de asignaturas. Se mostrará la pantalla que aparece en la figura D.14. En ella, se muestran en una tabla todas las asignaturas configuradas. Para eliminar una asignatura, basta con pulsar el enlace Eliminar de la asignatura correspondiente. El sistema pedirá confirmación antes de proceder a eliminar la asignatura de forma definitiva. D.2.11 Editar asignaturas configuradas Para editar asignaturas configuradas, pulsaremos en la opción Editar asignaturas del menú Gestión de asignaturas. Los datos que se pueden editar de una asignatura son: D.2. MANUAL DEL PROFESOR 93 Figura D.13. Pantalla de visualización de las asignaturas configuradas Figura D.14. Pantalla para eliminar asignaturas configuradas •El acrónimo. •La página Web. 100 ANEXO D. MANUAL DE USUARIO Figura D.22. Menú principal de la aplicación D.3.3 Olvido de contraseña Para recibir una nueva contraseña por correo electrónico, pulsaremos en la opción Olvidé mi contraseña del menú principal de la aplicación. Aparecerá la pantalla que se muestra en la figura D.23. En ella, introduciremos nuestro NIP y DNI (incluida la letra). El sistema enviará una nueva contraseña a nuestro correo electrónico si los datos introducidos son correctos. D.3.4 Reserva de cita de tutoría Para reservar una cita de tutoría, pulsaremos en la opción Reservar tutoría del menú principal de la aplicación. Aparecerá la pantalla que se muestra en la figura D.24. En ella, tenemos que introducir, en orden, los datos de los menús desplegables. Opcionalmente podremos introducir, también, comentarios de interés para el profesor acerca de la tutoría. Una vez introducidos todos los datos necesarios, pulsaremos en el botón Confirmar. Se mostrará una nueva pantalla indicando si la tutoría se ha reservado correctamente o no. En el caso de que la reserva haya sido correcta, el sistema enviará un correo electrónico al alumno confirmándole los datos de la misma. D.3. MANUAL DEL ALUMNO 101 Figura D.23. Pantalla de olvido de contraseña del alumno Figura D.24. Pantalla de reserva de cita de tutoría 102 ANEXO D. MANUAL DE USUARIO D.3.5 Ver tutorías asignadas Para ver las tutorías asignadas pendientes de realizarse, pulsaremos en el enlace Ver/Eliminar/Modificar tutorías ya reservadas. Aparecerá la pantalla que se muestra en la figura D.25. En ella, podemos ver en una tabla todas las tutorías asignadas. Desde esta pantalla también hay enlaces para acceder a modificar o cancelar las tutorías asignadas. Figura D.25. Pantalla de ver, eliminar o modificar tutorías asignadas D.3.6 Modificar la fecha y hora de tutorías asignadas Para poder modificar una tutoría asignada, debe existir al menos un día de antelación con respecto a la fecha y hora de comienzo de la tutoría. Los datos que se podrán modificar son su fecha y hora. Para modificar el horario de una tutoría, pulsaremos en el enlace Modificar de la fila de la tabla correspondiente a la tutoría. El sistema nos preguntará si estamos seguros de que deseamos modificar esta tutoría. Al pulsar el botón OK se mostrará la pantalla de la figura D.26 donde podremos modificar los datos de la tutoría. Una vez realizados los cambios, pulsaremos en el botón Modificar. Si la modificación se realiza correctamente, el sistema enviará un correo electrónico al alumno con los datos de la tutoría modificados. El profesor también recibirá un correo si tenía configurada la opción de recibir una notificación por cada nueva solicitud de tutoría. D.3. MANUAL DEL ALUMNO 103 Figura D.26. Pantalla de modificación de una tutoría reservada D.3.7 Cancelar tutorías asignadas Para cancelar una tutoría asignada debe existir al menos un día de antelación con respecto a la fecha y hora de comienzo de la tutoría. Si queremos cancelar una tutoría, pulsaremos en el enlace Cancelar en la fila de la tabla correspondiente a la tutoría. El sistema nos preguntará si estamos seguros de que deseamos cancelar esta tutoría. Para hacer efectiva la cancelación, basta pulsar en el botón OK. Si la cancelación se realiza correctamente, el sistema enviará un correo electrónico al alumno con los datos de la tutoría cancelada. El profesor también recibirá un correo si tenía configurada la opción de recibir una notificación por cada nueva solicitud de tutoría. D.3.8 Cerrar sesión Para salir del sistema, en la pantalla principal de la aplicación que se muestra en la figura D.22, pulsaremos en la opción Cerrar sesión. 104 ANEXO D. MANUAL DE USUARIO D.4 Manual del Administrador D.4.1 Primeros pasos Para comenzar a utilizar el sistema, abra una ventana de su navegador Web preferido. Una vez abierta, introduzca la siguiente dirección: http://alkaid.cps. unizar.es:8280/igetutor/. Se recomienda guardar esta dirección en los favoritos del navegador. Al cargarse la dirección anterior, aparecerá la pantalla que se observa en la figura D.1. Una vez se encuentre en la pantalla inicial, el primer paso será iniciar sesión como administrador en el sistema. Para ello, pulsaremos en el enlace Inicio de sesión situado en la parte superior derecha de la pantalla. Aparecerá la pantalla que se observa en la figura D.4. En ella, introduciremos los datos de inicio de sesión del administrador. Una vez iniciada la sesión, aparece la pantalla principal que se puede observar en la figura D.27. Esta pantalla contiene todas las opciones disponibles para el administrador en menús organizados por categorías. Figura D.27. Pantalla principal del administrador Los primeros pasos que debería realizar el administrador una vez ha iniciado sesión del sistema por primera vez son: •Cambiar su contraseña. D.4. MANUAL DEL ADMINISTRADOR 105 •Cambiar los datos de la cuenta de correo electrónico utilizada para las notificaciones del sistema. •Configurar las fechas del curso académico actual. D.4.2 Cambiar la contraseña Para cambiar su contraseña de administrador, pulse en la opción Cambiar contraseña del menú Gestión de perfil. Aparecerá la pantalla que se muestra en la figura D.19. En ella, deberá introducir su contraseña antigua y su nueva contraseña. La contraseña escogida debe tener entre 4 y 8 caracteres. Como consejo de seguridad, trate de elegir una contraseña lo suficientemente segura, donde se combinen letras minúsculas, mayúsculas y números. D.4.3 Cambiar la cuenta de notificaciones Para cambiar los datos de la cuenta de correo electrónico que se utiliza para enviar las notificaciones a los profesores y alumnos del sistema, pulse en la opción Cambiar notificaciones del menú Gestión de perfil. Aparecerá la pantalla que se muestra en la figura D.28. En ella, deberá introducir la dirección de correo electrónico, el servidor SMTP y la contraseña de dicha cuenta. Figura D.28. Pantalla de cambio de la cuenta de notificaciones El sistema comprobará que la cuenta de correo es accesible con los datos introducidos; lo notificará en caso contrario. 106 ANEXO D. MANUAL DE USUARIO D.4.4 Configurar las fechas del curso Para cambiar las fechas del curso académico actual, pulse en la opción Configurar fechas del menú Gestión del curso. Aparecerá la pantalla que se muestra en la figura D.29. En ella, deberá introducir la fecha de inicio del curso académico, fecha de finalización del primer cuatrimestre, fecha de inicio del segundo cuatrimestre y fecha de finalización del curso académico. Para ello, aparece un icono de calendario que al pulsarlo permite elegir una fecha concreta. Figura D.29. Pantalla de configuración de las fechas del curso actual También deberá importar un fichero con las fechas de días festivos del curso académico actual. Si pulsa en el enlace Ver formato, se muestra una explicación del formato de dicho fichero y se le permite descargar el fichero de festivos del curso académico 2010/2011, a modo de ejemplo. Puede descargar y editar directamente ese fichero para adaptar las fechas al curso académico actual. Cuando tenga el fichero preparado, pulse en el botón Choose file para seleccionar su ubicación. Por último, pulse el botón Guardar para almacenar las fechas introducidas. D.4.5 Ver fechas actuales del curso Para visualizar las fechas del curso académico actual configuradas en el sistema, pulse en la opción Fechas actuales del menú Gestión del curso. Aparecerá la pantalla que se muestra en la figura D.30. En esta pantalla, se muestran todas las fechas introducidas. D.4. MANUAL DEL ADMINISTRADOR 107 Figura D.30. Pantalla de visualización de las fechas configuradas del curso actual D.4.6 Realizar copias de seguridad El sistema realiza de forma automática copias de seguridad de toda su información una vez al mes. Adicionalmente, el administrador puede realizar copias de seguridad de todos los datos del sistema en cualquier momento deseado. Para ello, pulse en la opción Realizar copia, del menú Copias de seguridad. Aparecerá la pantalla que se muestra en la figura D.31. Para descargar la copia de seguridad, simplemente pulse en el botón Descargar copia. Se realizará la copia y se descargará comprimida en formato ZIP. El nombre del fichero será: CS.fechaActual.zip (la fecha actual tendrá formato dd-mm-aaaa). D.4.7 Restaurar copias de seguridad El administrador puede restaurar todos los datos del sistema a partir de copias de seguridad. Para ello, se proporciona un sencillo script SQL de restauración llamado restaurar_BD.sql. Este script se puede encontrar en el directorio src/sql del proyecto pfc-tutorias-model. El script debe tener permiso de ejecución para poder ejecutarse en su sistema. Para utilizarlo, primero descomprima el fichero zip con la copia de seguridad que desea utilizar para la restauración en el mismo directorio donde tenga el script. Esto generará el fichero SQL que contiene el estado de la base de datos para restaurarla. En segundo lugar, abra una consola de comandos e introduzca la siguiente línea, desde el directorio donde estén situados el script y la copia de seguridad: 108 ANEXO D. MANUAL DE USUARIO Figura D.31. Pantalla de realización de copias de seguridad del sistema restaurarBD.sql < CS.fecha.sql Por ejemplo, si se quisiera restaurar la base de datos utilizando la copia de seguridad del 24 de diciembre de 2010, se ejecutaría lo siguiente: restaurarBD.sql < CS.24-12-2010.sql Si la ejecución del comando anterior no devuelve error alguno, la base de datos del sistema habrá sido restaurada con la copia de seguridad elegida. D.4.8 Ver estadísticas del sistema En el menú Estadísticas del sistema, el administrador puede consultar diferentes datos del sistema navegando a partir de los Profesores, Asignaturas, Grupos, Titulaciones y Alumnos. En la figura D.32 se puede ver una pantalla de ejemplo con estadísticas del sistema. D.4.9 Ver perfil Para ver los datos de su perfil, pulsaremos la opción Ver perfil en el menú de Gestión de Perfil. D.4. MANUAL DEL ADMINISTRADOR 109 Figura D.32. Pantalla de ejemplo con estadísticas del sistema D.4.10 Modificar perfil Para modificar su perfil, pulsaremos la opción Editar perfil en el menú de Gestión de Perfil. Modifique los datos que desee y pulse Actualizar para guardar su perfil con los datos actualizados. 116 ANEXO E. MANUAL DE INSTALACIÓN Y MANTENIMIENTO dispone de buena documentación, puede ser configurado en una gran variedad de servidores (Tomcat, Jetty, JBoss, Geronimo, GlassFish, Resin, JOnAS, etc.), resulta sencillo de utilizar y tiene una amplia comunidad de desarrolladores y usuarios detrás. Por último, es necesario recordar que la base de datos MySQL debe estar creada e instalada para que la aplicación Portlet funcione correctamente. Para ello, siga los pasos ya explicados en la sección E.1.1.1. E.2.2 Instalación de la aplicación Portlet en OpenPortal Portlet Container sobre Apache Tomcat Primeramente, para instalar Tomcat, siga los pasos explicados en la sección E.1.1.3. Para instalar OpenPortal Portlet Container sobre Apache Tomcat, siga los pasos que se especifican en el manual de usuario del contenedor de Portlets [8]. Una vez estén ambos instalados, para instalar la aplicación Portlet en este entorno, basta con desplegar el fichero WAR del Portlet sobre el contenedor. Por tanto, primero se generará el fichero WAR, utilizando la herramienta Maven. Para ello, desde el interior del directorio pfc-tutorias-model, ejecute el comando siguiente: mvn clean install A continuación, ejecutaremos el mismo comando desde el interior del directorio pfc-tutorias-portlet. Esto último habrá generado el fichero WAR en el directorio target de pfc-tutorias-portlet. Para instalar el fichero WAR, se puede emplear la utilidad de administración que posee el contenedor, realizando los pasos siguientes: 1. Abra la dirección Web http://alkaid.cps.unizar.es:8280/portletdriver/ admin. Desde ahí, se pueden administrar los Portlets instalados en el contenedor previa introducción de la contraseña de administración. 2. En la zona de desplegar Portlets (Deploy a Portlet), pulse el botón Choose file para seleccionar la ruta del fichero WAR del Portlet. Una vez seleccionada, pulse Deploy. Esto se puede observar en la figura E.1. 3. El contenedor desplegará el Portlet pasados unos segundos. 4. Pulsando en la pestaña Portlets, veremos el Portlet recién instalado. Puede tardar unos segundos en aparecer y que al principio se muestre minimizado. Para ver el Portlet completo, pulse en el icono con forma de ojo, correspondiente al modo View del Portlet. Esto se puede observar en la figura E.2. E.2. INSTALACIÓN Y MANTENIMIENTO DE LA APLICACIÓN PORTLET 117 Figura E.1. Pantalla de administración de Portlets de OpenPortal Portlet Container Figura E.2. Pantalla de visualización de Portlets instalados en OpenPortal Portlet Container Por último, hay que mencionar que los ficheros de log de la aplicación Portlet se llamarán igetutor_portlet.log. Estarán almacenados en el directorio logs de Tomcat. 118 ANEXO E. MANUAL DE INSTALACIÓN Y MANTENIMIENTO Al final de cada día se creará un nuevo fichero de log al que se le añadirá la fecha del día de forma que el nombre del fichero será igetutor_portlet.log.fecha. E.2.2.1 Integrar el Portlet en una página Web utilizando el driver de OpenPortal Portlet Container OpenPortal Portlet Container posee un driver que hace posible incluir Portlets en páginas JavaServer Pages (JSP). Si tenemos una página Web .html, basta con renombrar el fichero a .jsp para convertirlo en una página JSP. Las instrucciones que se exponen en este apartado están basadas en la sección correspondiente del manual de usuario del contenedor de Portlets [8]. Los pasos para añadir el Portlet a la página JSP creada son: 1. Añadir en la primera línea de la página JSP creada la referencia al driver del contenedor de Portlets. Esto se hace incluyendo la siguiente directiva: <%@taglib uri="http://portlet-container.dev.java.net" prefix="pcdriver" %> 2. Añadir el código necesario para mostrar el Portlet donde se desea que aparezca. Este código es el siguiente: <pcdriver:portlet portletName="reservaTutorias" applicationName="pfc-tutorias-portlet"> <pcdriver:title/> <pcdriver:render/> </pcdriver:portlet> 3. Copiar la página JSP creada al directorio ROOT de Apache Tomcat del servidor Alkaid donde está instalada la aplicación Portlet. La ruta del directorio es /home/mmainar/apache-tomcat-6.0.29/webapps/ROOT. Si no se posee cuenta en dicho servidor, se puede solicitar una al administrador o bien pedir a otro profesor que posea cuenta o al propio administrador que copie la página a la ruta indicada. 4. La página con el Portlet será accesible desde la URL http://alkaid.cps.unizar.es:8280/nombrePaginaCreada.jsp. Lo más sencillo será crear un hipervínculo desde nuestra página Web a dicha URL. El código incluido para mostrar el Portlet irá normalmente entre etiquetas HTML de estilo (div,span, etc.) utilizando el CSS de nuestra página Web. El Portlet utiliza en todas sus páginas una estructura en forma de tabla. Es posible que haya que definir estilos para la etiqueta table en el CSS si no están definidos previamente, E.2. INSTALACIÓN Y MANTENIMIENTO DE LA APLICACIÓN PORTLET 119 para diferenciar de alguna forma el título del resto de contenido del Portlet (por ejemplo con colores, letra más grande, ...), etc. Por ejemplo, el código anterior con etiquetas de estilo en una página Web concreta podría quedar así: <pcdriver:portlet portletName="reservaTutorias" applicationName="pfc-tutorias-portlet" > <div class="templatemo_post"> <div class="templatemo_post_top"> <h1><b style="color:#ccff00"><pcdriver:title/></b></h1> </div> <div class="templatemo_post_mid"> <pcdriver:render/> <div class="clear"></div> </div> <div class="templatemo_post_bottom"> <span class="post">* Requiere tener JavaScript activado en el navegador</span> </div> </div><!-- end of templatemo_post--> </pcdriver:portlet> Los estilos para la etiqueta table redefinidos en el CSS de esta página Web son: .templatemo_post_mid table{ /* Para que se vea bien el texto del contenido del Portlet con la letra en el color del resto de las páginas */ color: #FFFFFF; /* Para que haya espacio entre el recuadro (templatemo_section_box) y el comienzo del texto. */ margin : 0px 15px 15px 15px; } E.2.2.2 Integrar el Portlet en una página Web utilizando un IFrame Esta segunda estrategia de integración se basa en mostrar directamente la aplicación Portlet utilizando la etiqueta HTML IFrame como si se tratara de un Web Widget [73]. 120 ANEXO E. MANUAL DE INSTALACIÓN Y MANTENIMIENTO Para ello, simplemente deberemos añadir el siguiente código HTML (entre las correspondientes etiquetas de estilo para posicionar el Portlet donde queramos): <iframe src="http://alkaid.cps.unizar.es:8280/pfc-tutorias-portlet" frameborder="0" scrolling="no" id="FramePortletReservaTutorias" height="100%" width="100%"> <p>Su navegador no soporta iframes.</p> </iframe> E.2.2.3 Utilizar el Portlet remotamente usando WSRP Como tercera y última estragia de integración, el Portlet instalado se ofrece para ser utilizado remotamente gracias al estándar de servicios Web para Portlets remotos (WSRP [35]). Para más información sobre WSRP consultar la sección A.2.2 del anexo sobre la tecnología de Portlets. Esta posibilidad se puede utilizar para integrar el Portlet si se posee un portal Web o un servidor Web con un contenedor de Portlets instalado. Para ello, habrá que hacer uso del consumidor WSRP del portal Web o contenedor de Portlets concreto. Siga las instrucciones de su portal para realizar esto. La descripción del servicio Web del Portlet en formato WSDL [80] se encuentra en la ruta http://alkaid.cps.unizar.es:8180/producer/wsrp/wsdl/ portletReservaTutoriasRemoto. Esta dirección será la que habrá que introducir en el consumidor WSRP ofrecido por el portal Web o contenedor de Portlets. E.2.3 Instalación de la aplicación Portlet en Liferay Portal En esta sección se asume el uso de Liferay, versión Community Edition (gratuita), sobre Apache Tomcat. Se puede descargar todo junto desde la página web de Liferay http://www.liferay.com/. También se asumen ciertas nociones básicas sobre un portal Web y manejo previo básico de Liferay en concreto. Para instalar el Portlet en Liferay, en primer lugar, hay que configurarlo para que utilice como fuente de almacenamiento una base de datos MySQL por medio de JNDI. Para ello, dentro del directorio de Liferay, iremos al de Tomcat, donde editaremos los 2 ficheros XML de configuración (server ycontext) y añadiremos el driver JDBC para MySQL, tal y como se explicó en la sección E.1.1.3. También crearemos en el directorio webapps/ROOT/WEB-INF/classes de Tomcat, un fichero de configuración llamado portal-ext.properties. En este fichero se especificarán las propiedades de la base de datos a utilizar. El contenido de este fichero será el siguiente: E.2. INSTALACIÓN Y MANTENIMIENTO DE LA APLICACIÓN PORTLET 121 jdbc.default.driverClassName=com.mysql.jdbc.Driver jdbc.default.url=jdbc:mysql://localhost/igetutor? useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false jdbc.default.username=user jdbc.default.password=hiK9J2lvM En la propiedad url del código anterior, pondremos la URL de la base de datos configurada. También se hará lo propio en las propiedades username ypassword. A continuación, se desplegará el Portlet copiando el fichero WAR correspondiente en el directorio deploy de Liferay. Para obtener el fichero WAR, se han de seguir los pasos explicados en la sección E.2.2, utilizando la herramienta Maven. Cuando se inicie el portal, éste instalará automáticamente el Portlet. Para poder añadir el Portlet a una página Web del portal, iniciaremos sesión en el portal e iremos a una página Web pública. Pulsaremos en Add, situado en la parte superior izquierda de la pantalla, que despliega un menú donde seleccionaremos la opción More. Aparecerán una serie de categorías. Nuestro Portlet se ubicará bajo la categoría misPortlets, tal y como se observa en la figura E.3. Pulsando en el nombre de la categoría, aparece el Portlet cuyo nombre es Reserva de tutorías y la opción Add para añadirlo a la página actual del portal. Tras pulsar Add, el Portlet se añade a la página, tal y como se puede observar en la figura E.4. Figura E.3. Pantalla de Liferay para añadir el Portlet a una página Web del portal 122 ANEXO E. MANUAL DE INSTALACIÓN Y MANTENIMIENTO Figura E.4. Página Web de un portal Web Liferay con el Portlet integrado Anexo F Seminario de Portlets En este anexo se incluyen las transparencias del seminario de Portlets elaborado durante la fase de formación y análisis de tecnologías del proyecto. En la siguiente página comienzan las transparencias. Se han incluido ocho transparencias por cada página. 123 Marcos Mainar Lalmolda Proyecto fin de carrera 4 de Agosto de 2010 Seminario de Portlets 2 Índice de contenidos  Contexto: Portales Web •Servidores de portales Web  Qué son los portlets •Contenedor de portlets  Estándares de portlets •Java Portlet Specification (JPS) •Web Services for Remote Portlets (WSRP)  Desarrollo de portlets  Conclusiones  Demostraciones de portlets 3 Índice de contenidos  Contexto: Portales Web •Servidores de portales Web  Qué son los portlets •Contenedor de portlets  Estándares de portlets •Java Portlet Specification (JPS) •Web Services for Remote Portlets (WSRP)  Desarrollo de portlets  Conclusiones  Demostraciones de portlets 4 Portales Web (1/2) Aplicación Web que presenta información de diversas fuentes de forma unificada Portales Intranet (corporativos) vs Internet (iGoogle, Yahoo, MSN) Servicios típicos ●Buscador Web ●Correo electrónico ●Noticias ●Partes meteorológicos ●Calendario ●Blogs ●... 5 Portales Web (2/2) Integran aplicaciones a nivel de interfaz de usuario Funcionalidades genéricas •Inicio de sesión (Single Sign-On) •Agregación de contenido •Personalización de contenido El portal construye cada página agregando las respuestas de los portlets que contiene 6 Ejemplo de portal Web 7 Índice de contenidos  Contexto: Portales Web •Servidores de portales Web  Qué son los portlets •Contenedor de portlets  Estándares de portlets •Java Portlet Specification (JPS) •Web Services for Remote Portlets (WSRP)  Desarrollo de portlets  Conclusiones  Demostraciones de portlets Servidor de portales Web Proporcionan un portal pre-construido donde se puede instalar portlets ●Comerciales: IBM WebSphere Portal, Oracle Portal, Microsoft SharePoint Portal Server, etc. ●Open Source: Jetspeed2, Liferay, uPortal, GateIn Portal, etc.  Se instala en un servidor de aplicaciones (GlassFish, JBoss, Weblogic) o en un servidor web con soporte de Servlets y JavaServer Pages (Tomcat, Jetty, etc).  Decide el aspecto global de las páginas del portal.  Terminología: Portal Framework, Portal Platform, etc. 9 Índice de contenidos  Contexto: Portales Web •Servidores de portales Web  Qué son los portlets •Contenedor de portlets  Estándares de portlets •Java Portlet Specification (JPS) •Web Services for Remote Portlets (WSRP)  Desarrollo de portlets  Conclusiones  Demostraciones de portlets 10 Qué son los portlets (1/2) Componentes software modulares de las interfaces de usuario que proveen una capa de presentación a sistemas de información Proporcionan información o un servicio que se incluye en un portal Web Producen fragmentos de código markup (X/HTML, WML, etc.), no documentos completos No son directamente direccionables mediante una URL Generan contenido dinámico Se renderizan como una tabla HTML Locales o remotos al portal Web Servicios web orientados a presentación 11 Qué son los portlets (2/2) 2 partes 1) Decoración: barra de título, controles y bordes de las ventanas de los portlets 2) Contenido del portlet: la parte generada por la aplicación portlet Portlet API: contrato entre los portlets y el portal Los portlets interaccionan con el cliente Web mediante el paradigma petición/respuesta No pueden generan contenido arbitrario al ser parte de una página de un portal Web •Ejemplo: si el portal Web solicita html/text, todos los portlets deben generar contenido con formato html/text Para ejecutarlos se necesita un servidor de portales o al menos un contenedor de portlets 12 Índice de contenidos  Contexto: Portales Web •Servidores de portales Web  Qué son los portlets •Contenedor de portlets  Estándares de portlets •Java Portlet Specification (JPS) •Web Services for Remote Portlets (WSRP)  Desarrollo de portlets  Conclusiones  Demostraciones de portlets 13 Contenedor de portlets  Interfaz entre los portlets y el portal Web  Idea similar al contenedor de servlets  Donde se instalan los portlets  Típicamente es un componente del portal Web  Gestiona y ejecuta los portlets  Provee al portlet de recursos necesarios y de su entorno de ejecución  Controla su ciclo de vida •Inicializa y destruye los portlets •Recibe las peticiones del usuario y las traslada al portlet  Ejemplos: •OpenPortal Portlet Container •Apache Pluto 14 Ejemplo de portlet 15 Índice de contenidos  Contexto: Portales Web •Servidores de portales Web  Qué son los portlets •Contenedor de portlets  Estándares de portlets •Java Portlet Specification (JPS) •Web Services for Remote Portlets (WSRP)  Desarrollo de portlets  Conclusiones  Demostraciones de portlets 16 Estándares de portlets (1/2)  Hacen frente a 2 problemas tradicionales que existían en los primeros servidores de portales 1) Los portlets desarrollados con un determinado portal no podían ser instalados en otro portal Estándar: Java Portlet Specification (JPS) 2) Un portal no podía consumir remotamente los portlets instalados en otro portal (todos los portlets debian ser locales al portal) Estándar: Web Services for Remote Portlets (WSRP)  La mayor parte de los servidores de portales actuales soportan ambos estándares [47] Oracle. Java Naming and Directory Interface (JNDI). http://www.oracle. com/technetwork/java/index-jsp-137536.html [48] JBoss Community. Hibernate Tools for Enclipse and Ant. http://www. hibernate.org/subprojects/tools.html [49] Terracota. Quartz Enterprise Job Scheduler. http://www. quartz-scheduler.org/ [50] iText Software Corp. iTextPDF. http://itextpdf.com/ [51] Quality Open Software (QOS.ch). Simple Logging Facade for Java (SLF4J). http://www.slf4j.org/ [52] The Apache Software Foundation. Apache Log4J. http://logging.apache. org/log4j/ [53] The Dojo Foundation. Direct Web Remoting (DWR). http:// directwebremoting.org/dwr/index.html [54] Oracle. JavaServer Pages Standard Tag Library. http://www.oracle.com/ technetwork/java/index-jsp-135995.html [55] Liferay Inc. Liferay. http://www.liferay.com/ [56] JUnit.org. JUnit. http://www.junit.org/ [57] JSON. JavaScript Object Notation (JSON). http://www.json.org/ [58] Oracle. JavaMail. http://www.oracle.com/technetwork/java/ index-jsp-139225.html [59] The Apache Software Foundation. Apache Maven. http://maven.apache. org/ [60] SourceForge. Kile. http://kile.sourceforge.net/ [61] JasperForge. JasperReports. http://jasperforge.org/projects/ jasperreports [62] Wikipedia. Agile Software Development. http://en.wikipedia.org/wiki/ Agile_software_development [63] Wikipedia. Extreme Programming. http://en.wikipedia.org/wiki/ Extreme_Programming [64] Wikipedia. Scrum. http://en.wikipedia.org/wiki/Scrum_(development) [65] Wikipedia. Agile Unified Process. http://en.wikipedia.org/wiki/Agile_ Unified_Process 132 [66] Wikipedia. IBM Rational Unified Process Unified Process. http://en. wikipedia.org/wiki/IBM_Rational_Unified_Process [67] Wikipedia. Desarrollo iterativo y creciente. http://es.wikipedia.org/ wiki/Desarrollo_iterativo_y_creciente [68] Wikipedia. Cross-cutting concern. http://en.wikipedia.org/wiki/ Cross-cutting_concern [69] Wikipedia. Aspect-oriented programming. http://en.wikipedia.org/wiki/ Aspect-oriented_programming [70] Apple. iCal MacOS calendar. http://www.apple.com/macosx/ what-is-macosx/mail-ical-address-book.html [71] Google. Google Calendar. https://www.google.com/calendar/ [72] Google. Google Gadgets. http://code.google.com/apis/gadgets/ [73] Wikipedia. Web Widget. http://en.wikipedia.org/wiki/Web_widget [74] World Wide Web Consortium (W3C). Página oficial en español. http: //www.w3c.es/ [75] World Wide Web Consortium (W3C). WidgetSpecs. http://www.w3.org/ 2008/webapps/wiki/WidgetSpecs [76] E.L-C Law, D. Müller, A.V. Nguyen-Ngoc. Differentiating and Defining Portlets and Widgets: A survey approach. 2nd Workshop on Mash-Up Personal Learning Environments (MUPPLE-09), Nice, France, September 29, 2009. http://www.cs.le.ac.uk/people/avnn1/papers/LawMN-Mupple09.pdf [77] ChenilleKit. ChenilleKit Tapestry. http://www.chenillekit.org/ chenillekit-tapestry/index.html [78] Ioko Tapestry Commons Project. Ioko Tapestry. http://tapestry.ioko. com/ [79] Oracle. JDBC. http://download.oracle.com/javase/tutorial/jdbc/ index.html [80] W3C. Web Services Definition Language (WSDL). http://www.w3.org/TR/ wsdl [81] W3C. SOAP. http://www.w3.org/TR/soap12-part1/ [82] OASIS. UDDI. http://www.uddi.org/pubs/uddi_v3.htm Todas las referencias Web han sido visitadas por última vez el día 10 de febrero de 2011. 133