Desarrollo de un Sistema de Gestión de Proyectos mediante framework GWT

Proyecto de Fin de Carrera Universidad Politécnica de Valencia Escuela Técnica Superior de Informática Desarrollo de un Sistema de Gestión de Proyectos mediante el framework GWT Realizado por: Reyes Martínez Durbán Dirigido por: D. Moisés Pastor i Gadea Valencia, Junio 2012 Proyecto Final de Carrera Reyes Martínez Durbán Índice 1. DESCRIPCIÓN ............................................................................................. 2 1.1. MOTIVACIÓN ............................................................................................ 2 1.2. OBJETIVOS ............................................................................................... 3 2. ANÁLISIS DE REQUISITOS ........................................................................... 3 2.1. REQUISITOS DE INFORMACIÓN ................................................................ 5 2.2. REQUISITOS FUNCIONALES ...................................................................... 8 2.1.1. DIAGRAMAS DE CASOS DE USO ............................................................ 8 2.2.2. DEFINICIÓN DE ACTORES ..................................................................... 9 2.2.3. DESCRIPCIÓN TEXTUAL DE CASOS DE USO .......................................... 9 2.3. REQUISITOS NO FUNCIONALES .............................................................. 33 3. APLICACIÓN .............................................................................................. 33 3.1. PROCESO DE INSTALACIÓN ................................................................... 33 3.2. BASE DE DATOS ..................................................................................... 35 3.3. DESCRIPCIÓN DE LA APLICACIÓN .......................................................... 36 3.4. PRUEBAS ............................................................................................... 41 4. CONCEPTOS TEÓRICOS ........................................................................... 42 4.1. AJAX ....................................................................................................... 42 4.1.1. DEFINICIÓN AJAX ................................................................................ 42 4.2. GWT ....................................................................................................... 43 4.2.1. DEFINICIÓN GWT ................................................................................ 43 4.2.1.1. VENTAJAS ......................................................................................... 44 4.2.1.2. INCONVENIENTES ............................................................................ 44 4.2.2. ARQUITECTURA DE GWT ..................................................................... 44 4.2.3. INTERFAZ DE USUARIO ....................................................................... 45 4.2.4. EL PATRÓN MODELO-VISTA-PRESENTADOR ......................................... 50 4.2.4.1. DEFINICIÓN ...................................................................................... 50 4.2.4.2, IMPLEMENTACIÓN DEL PATRÓN MVP: ACTIVITIES Y PLACES ............. 50 4.2.5. COMUNICACIÓN CON EL SERVIDOR ................................................... 52 4.2.5.1. LLAMADAS RPC ............................................................................... 53 4.2.5.2. MODOS DE EJECUCIÓN .................................................................... 56 5. CONCLUSIONES ........................................................................................ 56 6. BIBLIOGRAFÍA ........................................................................................... 56 Página 2 Proyecto Final de Carrera Reyes Martínez Durbán 1. DESCRIPCIÓN El proyecto a desarrollar consiste en una aplicación Web cuya finalidad será la de administrar y controlar los distintos proyectos desarrollados por una organización. Además, pretende cubrir la necesidad de establecer un seguimiento sobre las tareas desarrolladas por los distintos técnicos, con lo cual se cumple una doble finalidad: La primera es el control de las propias tareas en las que se descomponen los distintos módulos de cada proyecto de la organización y la segunda consiste en un control exhaustivo de las tareas desarrolladas por los distintos técnicos de la organización y el tiempo empleado en cada una de ellas. Por tanto, la aplicación puede proporcionar un mecanismo muy útil a la hora de realizar estimaciones para proyectos futuros, en cuanto a coste, complejidad, duración, etc., así como la posibilidad de medir el rendimiento y la productividad de los técnicos, que puede permitir a la organización optimizar futuros proyectos. El proyecto se divide cinco partes funcionales, las cuales serían: Gestionar los Proyectos: El sistema deberá gestionar toda la información referente a los proyectos software desarrollados por una organización. Por lo tanto se contemplarán tareas de gestión como: alta de proyectos en el sistema, baja de uno o varios de ellos, modificaciones sobre los datos de cada uno, consultas, etc. Gestionar los Módulos: El sistema deberá gestionar la información del conjunto de módulos que constituyen cada uno de los proyectos del sistema. Por tanto debe permitir: añadir módulos a proyectos, borrar módulos de un proyecto determinado, modificaciones de los datos de un módulo, consultas, etc. Página 3 Proyecto Final de Carrera Reyes Martínez Durbán Gestionar las Tareas: El sistema deberá gestionar toda la información relativa a las tareas que se realizan para construir cada uno de los módulos de los proyectos software. Por tanto debe incluir actividades como: dar de alta tareas y asociarlas a módulos, especificar el/los técnico(s) que van a ejecutar cada tarea y cuándo la harán, modificar datos de tareas existentes, consultas, etc. Gestionar los Técnicos: El sistema deberá gestionar los técnicos susceptibles de ser asignados a las tareas de los módulos de los proyectos software, ya sea como responsable o como desarrollador. Por tanto deberá incluir tareas como: alta de técnicos, baja, modificaciones, consultas, asignación a tareas de módulos de proyectos, mantenimiento, etc. Gestionar las Asignaciones de Técnicos a Tareas: El sistema deberá poder consultar el conjunto de actividades, desarrolladas por cada técnico asociado a alguno de los proyectos del sistema, en un periodo de tiempo establecido por el usuario bajo unos criterios específicos: técnicos de un proyecto dado, técnicos por módulo de un proyecto dado, técnicos por tarea de un proyecto dado, todos los técnicos del sistema o un técnico en concreto. 1.1. MOTIVACIÓN La idea de realizar este proyecto final de carrera surgió como consecuencia del trabajo desarrollado en una empresa de desarrollo de software, en el cual estuve desarrollando aplicaciones utilizando la tecnología utilizada en el proyecto y la que considero puntera y demandada en el mercado actual por su fácil mantenimiento y su flexibilidad a la hora de realizar cambios. Página 4 Proyecto Final de Carrera Reyes Martínez Durbán Después de haber utilizado GWT en varios proyectos y tener los conocimientos suficientes para desarrollar una aplicación con esta tecnología, me decanté por ésta para aprovechar los conocimientos adquiridos durante este periodo. 1.2. OBJETIVOS 1. Ser capaz de descargar, instalar y configurar el software necesario para la aplicación. 2. Aprender a desarrollar portales Web con GWT. 3. Aprender a instalar el servidor Apache Tomcat. 4. Aprender a instalar el servidor de BBDD MySQL. 5. Desarrollar un portal web sobre la gestión de proyectos. 6. Ampliar el conocimiento del entorno de desarrollo Eclipse. 7. Ampliar los conocimientos sobre patrones de diseño. 8. Mejorar la capacidad de comunicación escrita debido a la realización de la memoria del PFC. 9. Aumentar la capacidad de autoformación, tanto de búsqueda de información como de comprensión de los distintos manuales utilizados. 2. ANÁLISIS DE REQUISITOS El proyecto “Sistema de Gestión de Proyectos” está estructurado de la siguiente manera: los proyectos son los sistemas o aplicaciones a desarrollar en la organización, así como los trabajos globales. Se componen de módulos y cada módulo se descompone a su vez en tareas más concretas. Una tarea la ejecutan uno o varios técnicos, si bien existe un técnico responsable en cada proyecto. Página 5 Proyecto Final de Carrera Reyes Martínez Durbán Tanto el proyecto como el módulo y cada tarea tienen fecha de comienzo y fecha de finalización. Las tareas son realizadas por técnicos, los cuales tienen asignada una tarea durante un periodo de tiempo. Una vez descrito brevemente como sería la estructura de la aplicación, los puntos fundamentes que se abordarían en ella serían los siguientes: Referente a proyectos: 1. Alta de nuevos proyectos 2. Consulta de proyectos 3. Modificación de proyectos 4. Baja de proyectos Referente a técnicos: 1. Alta de nuevos técnicos 2. Consulta de técnicos 3. Modificación de técnicos 4. Baja de técnicos Referente a módulos: 1. Alta de nuevos módulos 2. Consulta de módulos 3. Modificación de módulos 4. Baja de módulos Referente a tareas: 1. Alta de nuevas tareas 2. Consulta de tareas 3. Modificación de tareas 4. Baja de tareas Página 6 Proyecto Final de Carrera Reyes Martínez Durbán Referente a asignaciones: 1. Alta de nuevas asignaciones 2. Consulta de asignaciones 3. Modificación de asignaciones 4. Baja de asignaciones Tareas Combinadas: 1. Añadir módulos a proyectos 2. Suprimir módulos de proyectos 3. Añadir tareas a módulos 4. Suprimir tareas de módulos 5. Asignación de técnicos responsables a proyectos 6. Suprimir asignaciones de técnicos responsables a proyectos 7. Consultas de asignaciones por proyecto, módulo, tarea o técnico, tanto activos como dados de baja. 2.1. REQUISITOS DE INFORMACIÓN En este apartado se identifican los requisitos de almacenamiento de información que debe cumplir el sistema. Estos requisitos son los que deben contestar a la pregunta: “¿Qué información, relevante para los objetivos de negocio, debe ser almacenada por el sistema?”. Esta información necesaria para los objetivos propuestos sería: El sistema debe almacenar la información correspondiente a los proyectos software. En concreto: •Identificador del proyecto (clave primaria en la BBDD) •Nombre •Descripción Página 7 Proyecto Final de Carrera Reyes Martínez Durbán •Alcance •Objetivos •Origen •Coste total •Técnico responsable (jefe de proyecto) •Fecha de inicio del desarrollo •Fecha de finalización del desarrollo La información almacenada por el sistema deberá satisfacer las siguientes restricciones: •El identificador del proyecto debe ser único, por tanto, no podrán existir dos proyectos distintos con el mismo identificador. •El identificador del proyecto es un campo autogenerado por la BBDD al crear el proyecto, por tanto, no puede ser modificado. •Los campos Nombre, Coste y Técnico Responsable del proyecto no pueden tomar valores nulos. El sistema deberá almacenar la información correspondiente a los módulos o subsistemas que componen cada proyecto software. En concreto: •Identificador de módulo (clave primaria en la BBDD) •Proyecto al que pertenece (clave ajena en la BBDD) •Nombre •Descripción •Fecha de inicio del desarrollo •Fecha de finalización del desarrollo •Observaciones Página 8 Proyecto Final de Carrera Reyes Martínez Durbán La información almacenada por el sistema deberá satisfacer las siguientes restricciones: •El identificador del módulo debe ser único, por tanto, no podrán existir dos módulos distintos con el mismo identificador. •El identificador del módulo es un campo autogenerado por la BBDD al crear el módulo, por tanto, no puede ser modificado. •Los campos Nombre y Proyecto al que pertenece no pueden tomar valores nulos. El sistema deberá almacenar la información correspondiente a las tareas a realizar en el desarrollo de cada uno de los módulos de los proyecto software. En concreto: •Identificador de tarea (clave primaria en la BBDD) •Módulo al que pertenece (clave ajena en la BBDD) •Nombre •Descripción •Fecha de inicio del desarrollo •Fecha de finalización del desarrollo •Observaciones La información almacenada por el sistema deberá satisfacer las siguientes restricciones: •El identificador de la tarea debe ser único, por tanto, no podrán existir dos tareas distintas con el mismo identificador. •El identificador de la tarea es un campo autogenerado por la BBDD al crear la tarea, por tanto, no puede ser modificado. •Los campos Nombre y Módulo al que pertenece no pueden tomar valores nulos. Página 9 Proyecto Final de Carrera Reyes Martínez Durbán Postcondiciones El proyecto queda almacenado en el sistema Incluye - Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de alta de un nuevo proyecto 2. El sistema solicita los datos del nuevo proyecto indicando cuales de ellos son obligatorios: nombre, coste y responsable del proyecto. Además, solicita otros datos de carácter opcional como: descripción, alcance, origen, fecha de inicio y fecha de finalización 3. El actor proporciona los datos requeridos por el sistema y solicita a éste que los almacene 4. El sistema almacena los datos introducidos por el actor, genera un identificador de proyecto que identifica unívocamente al nuevo proyecto registrado en el sistema e informa al administrador de que el proyecto ha sido registrado con éxito. A continuación ejecuta el caso de uso Consulta de Proyectos Flujo Alternativo 3. Si el actor selecciona limpiar, el sistema borra todos los datos introducidos por el actor. Debe volverse al paso 3 del flujo normal para proseguir con este caso de uso Página 16 Proyecto Final de Carrera Reyes Martínez Durbán Excepciones # 3. Si el actor no proporciona alguno de los datos obligatorios, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación, este caso de uso continua # 3. Si el actor introduce una fecha de baja anterior a la fecha de alta del proyecto, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación, este caso de uso continua # 3. Si el actor solicita cancelar la operación, este caso de uso queda sin efecto y a continuación, el sistema ejecuta el caso de uso Consulta de Proyectos Prioridad Alta Frecuencia de uso 2-3 veces por mes Requisitos no funcionales - Observaciones La frecuencia de ejecución de este caso de uso será mucho más elevada durante los primeros meses de utilización UC-02 Consulta Proyectos Autor Reyes Martínez Durbán Versión 1.0 (05/04/2011) Actores Usuario Propósito Consultar la información de un proyecto Descripción El actor realiza una búsqueda con o sin filtros (en cuyo caso se mostrarían todos) y el sistema muestra la Página 17 Proyecto Final de Carrera Reyes Martínez Durbán información del proyecto Precondiciones - Postcondiciones Se muestra la información del proyecto Incluye - Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de consulta de proyectos 2. El actor introduce algún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con los proyectos registrados en el sistema que cumplen los criterios de búsqueda. La información que se muestra para los proyectos es: nombre, descripción, alcance, origen, coste, responsable, fecha de inicio y fecha de finalización. Flujo Alternativo 2. El actor no introduce ningún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con todos los proyectos registrados en el sistema. La información que se muestra para los proyectos es: nombre, descripción, alcance, origen, coste, responsable, fecha de inicio y fecha de finalización. Flujo Alternativo 2. Si el actor selecciona limpiar, el sistema borra todos los filtros introducidos por el actor. Debe volverse al paso 2 del flujo normal para proseguir con este caso de uso Página 18 Proyecto Final de Carrera Reyes Martínez Durbán Excepciones # 3. Si no hay proyectos registrados, el sistema informa de esta situación. A continuación, este caso de uso queda sin efecto Prioridad Alta Frecuencia de uso 15-20 veces por mes Requisitos no funcionales - Observaciones - UC-03 Edición Proyecto Autor Reyes Martínez Durbán Versión 1.0 (05/04/2011) Actores Usuario Propósito Modificar los datos de un proyecto Descripción El actor modifica los datos de un proyecto existente en el sistema Precondiciones El proyecto está registrado en el sistema Postcondiciones Se almacenan en el sistema las modificaciones del proyecto, el cual sigue registrado en el sistema Incluye UC-02 Consulta Proyectos Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de consulta de proyectos Página 19 Proyecto Final de Carrera Reyes Martínez Durbán 2. El actor introduce algún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con los proyectos registrados en el sistema que cumplen los criterios de búsqueda. La información que se muestra para los proyectos es: nombre, descripción, alcance, origen, coste, responsable, fecha de inicio y fecha de finalización. 3. El actor solicita al sistema comenzar con el proceso de edición de proyectos, seleccionando el proyecto que desea modificar de la lista al pulsar en el enlace Editar 4. El sistema abre un popup con los siguientes datos correspondientes al proyecto a modificar: nombre, descripción, alcance, coste, responsable, origen, fecha de inicio y fecha de fin 5. El sistema permite al actor modificar todos los campos del proyecto 6. El actor modifica los datos deseados y solicita al sistema que los almacene 7. El sistema modifica los datos del proyecto y cierra el popup de edición. A continuación, ejecuta el caso de uso Consulta de Proyectos Flujo Alternativo 2. El actor no introduce ningún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con todos los proyectos registrados en el sistema. La información que se muestra para los proyectos es: nombre, descripción, alcance, origen, coste, responsable, fecha de inicio y fecha de finalización. Flujo Alternativo 2. Si el actor selecciona limpiar, el Página 20 Proyecto Final de Carrera Reyes Martínez Durbán sistema borra todos los datos introducidos por el actor. Debe volverse al paso 6 del flujo normal para proseguir con este caso de uso Excepciones # 3. Si no hay proyectos registrados, el sistema informa de esta situación. A continuación, este caso de uso queda sin efecto # 6. Si el actor no proporciona alguno de los datos obligatorios, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación este caso de uso continua # 6. Si el actor introduce una fecha de baja anterior a la fecha de alta del proyecto, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación, este caso de uso continua # 6. Si el actor solicita cancelar la operación, este caso de uso queda sin efecto y a continuación, el sistema ejecuta el caso de uso Consulta de Proyectos Prioridad Alta Frecuencia de uso 2-3 veces por mes Requisitos no funcionales - Observaciones - UC-04 Baja Proyecto Autor Reyes Martínez Durbán Versión 1.0 (05/04/2011) Actores Usuario Propósito Eliminar del sistema un proyecto Página 21 Proyecto Final de Carrera Reyes Martínez Durbán Descripción El actor da de baja un proyecto en el sistema, borrando todos sus datos Precondiciones El proyecto está registrado en el sistema Postcondiciones El proyecto es eliminado del sistema Incluye UC-02 Consulta Proyectos Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de consulta de proyectos 2. El actor introduce algún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con los proyectos registrados en el sistema que cumplen los criterios de búsqueda. La información que se muestra para los proyectos es: nombre, descripción, alcance, origen, coste, responsable, fecha de inicio y fecha de finalización. 3. El actor solicita al sistema comenzar con el proceso de baja de proyectos, seleccionando el proyecto que desea eliminar de la lista al pulsar en el enlace Eliminar 4. El sistema solicita confirmación del borrado del proyecto 5. El actor confirma el borrado del proyecto 6. El sistema elimina el proyecto e informa al actor de que el proyecto ya no existe en el sistema. A continuación se ejecuta el caso de uso Página 22 Proyecto Final de Carrera Reyes Martínez Durbán Consulta de Proyectos Flujo Alternativo 2. El actor no introduce ningún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con todos los proyectos registrados en el sistema. La información que se muestra para los proyectos es: nombre, descripción, alcance, origen, coste, responsable, fecha de inicio y fecha de finalización. Excepciones # 3. Si no hay proyectos registrados, el sistema informa de esta situación. A continuación, este caso de uso queda sin efecto # 5. Si el actor no confirma la operación de borrado del proyecto seleccionado, el sistema cancela el procedimiento. A continuación, este caso de uso queda sin efecto # 6. Si el proyecto a eliminar tiene dependencias en la base de datos del sistema, el sistema lanza una excepción solicitando que se eliminen en primer lugar sus dependencias. A continuación, este caso de uso queda sin efecto Prioridad Alta Frecuencia de uso 1 vez por mes Requisitos no funcionales - Observaciones - UC-05 Alta Módulo Autor Reyes Martínez Durbán Página 23 Proyecto Final de Carrera Reyes Martínez Durbán Versión 1.0 (05/04/2011) Actores Usuario Propósito Almacenar en el sistema un módulo Descripción El actor inserta un nuevo módulo con todos sus datos en el sistema Precondiciones El módulo no está registrado en el sistema Postcondiciones El módulo queda almacenado en el sistema Incluye - Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de alta de un nuevo módulo 2. El sistema solicita los datos del nuevo módulo indicando cuales de ellos son obligatorios: nombre y proyecto al que pertenece. Además, solicita otros datos de carácter opcional como: descripción, fecha de inicio, fecha de finalización y observaciones 3. El actor proporciona los datos requeridos por el sistema y solicita a éste que los almacene 4. El sistema almacena los datos introducidos por el actor, genera un identificador de módulo que identifica unívocamente al nuevo módulo registrado en el sistema e informa al administrador de que el módulo ha sido registrado con éxito. A continuación ejecuta el caso de uso Página 24 Proyecto Final de Carrera Reyes Martínez Durbán Consulta de Módulos Flujo Alternativo 3. Si el actor selecciona limpiar, el sistema borra todos los datos introducidos por el actor. Debe volverse al paso 3 del flujo normal para proseguir con este caso de uso Excepciones # 3. Si el actor no proporciona alguno de los datos obligatorios, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación, este caso de uso continua # 3. Si el actor introduce una fecha de baja anterior a la fecha de alta del módulo, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación, este caso de uso continua # 3. Si el actor solicita cancelar la operación, este caso de uso queda sin efecto y a continuación, el sistema ejecuta el caso de uso Consulta de Módulos Prioridad Alta Frecuencia de uso 7-8 veces por mes Requisitos no funcionales - Observaciones La frecuencia de ejecución de este caso de uso será mucho más elevada durante los primeros meses de utilización. La frecuencia de este caso de uso está ligada a la frecuencia de uso del caso UC-01 Alta Proyecto Página 25 Proyecto Final de Carrera Reyes Martínez Durbán Frecuencia de uso 1-2 veces por mes Requisitos no funcionales - Observaciones - UC-09 Alta Tarea Autor Reyes Martínez Durbán Versión 1.0 (05/04/2011) Actores Usuario Propósito Almacenar en el sistema una tarea Descripción El actor inserta una nueva tarea con todos sus datos en el sistema Precondiciones La tarea no está registrada en el sistema Postcondiciones La tarea queda almacenada en el sistema Incluye - Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de alta de una nueva tarea 2. El sistema solicita los datos de la nueva tarea indicando cuales de ellos son obligatorios: nombre, proyecto y módulo al que pertenece. Además, solicita otros datos de carácter opcional como: descripción, fecha de inicio, fecha de finalización y observaciones 3. El actor proporciona los datos requeridos por el Página 32 Proyecto Final de Carrera Reyes Martínez Durbán sistema y solicita a éste que los almacene 4. El sistema almacena los datos introducidos por el actor, genera un identificador de tarea que identifica unívocamente a la nueva tarea registrada en el sistema e informa al administrador de que la tarea ha sido registrada con éxito. A continuación ejecuta el caso de uso Consulta de Tareas Flujo Alternativo 3. Si el actor selecciona limpiar, el sistema borra todos los datos introducidos por el actor. Debe volverse al paso 3 del flujo normal para proseguir con este caso de uso Excepciones # 3. Si el actor no proporciona alguno de los datos obligatorios, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación, este caso de uso continua # 3. Si el actor introduce una fecha de baja anterior a la fecha de alta del módulo, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación, este caso de uso continua # 3. Si el actor solicita cancelar la operación, este caso de uso queda sin efecto y a continuación, el sistema ejecuta el caso de uso Consulta de Tareas Prioridad Alta Frecuencia de uso 10-12 veces por mes Requisitos no funcionales - Observaciones La frecuencia de ejecución de este caso de uso será mucho más elevada Página 33 Proyecto Final de Carrera Reyes Martínez Durbán durante los primeros meses de utilización. La frecuencia de este caso de uso está ligada a la frecuencia de uso del caso UC-05 Alta Modulo UC-10 Consulta Tareas Autor Reyes Martínez Durbán Versión 1.0 (05/04/2011) Actores Usuario Propósito Consultar la información de una tarea Descripción El actor realiza una búsqueda con o sin filtros (en cuyo caso se mostrarían todas) y el sistema muestra la información de la tarea Precondiciones - Postcondiciones Se muestra la información de la tarea Incluye - Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de consulta de tareas 2. El actor introduce algún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con las tareas registradas en el sistema que cumplen los criterios de búsqueda. La información que se muestra para las tareas es: nombre, descripción, proyecto y módulo al que pertenece, fecha de inicio, fecha de finalización y observaciones Página 34 Proyecto Final de Carrera Reyes Martínez Durbán Flujo Alternativo 2. El actor no introduce ningún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con todas las tareas registradas en el sistema. La información que se muestra para las tareas es: nombre, descripción, proyecto y módulo al que pertenece, fecha de inicio, fecha de finalización y observaciones Flujo Alternativo 2. Si el actor selecciona limpiar, el sistema borra todos los filtros introducidos por el actor. Debe volverse al paso 2 del flujo normal para proseguir con este caso de uso Excepciones # 3. Si no hay tareas registradas, el sistema informa de esta situación. A continuación, este caso de uso queda sin efecto Prioridad Alta Frecuencia de uso 15-20 veces por mes Requisitos no funcionales - Observaciones - UC-11 Edición Tarea Autor Reyes Martínez Durbán Versión 1.0 (05/04/2011) Actores Usuario Propósito Modificar los datos de una tarea Página 35 Proyecto Final de Carrera Reyes Martínez Durbán Descripción El actor modifica los datos de una tarea existente en el sistema Precondiciones La tarea está registrada en el sistema Postcondiciones Se almacenan en el sistema las modificaciones de la tarea, la cual sigue registrada en el sistema Incluye UC-10 Consulta Tareas Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de consulta de tareas 2. El actor introduce algún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con las tareas registrados en el sistema que cumplen los criterios de búsqueda. La información que se muestra para las tareas es: nombre, descripción, proyecto y módulo al que pertenece, fecha de inicio, fecha de finalización y observaciones 3. El actor solicita al sistema comenzar con el proceso de edición de tareas, seleccionando la tarea que desea modificar de la lista al pulsar en el enlace Editar 4. El sistema abre un popup con los siguientes datos correspondientes a la tarea a modificar: nombre, descripción, proyecto y módulo al que pertenece, fecha de inicio, fecha de finalización y observaciones 5. El sistema permite al actor modificar todos los campos de la tarea 6. El actor modifica los datos deseados y solicita al sistema que los almacene Página 36 Proyecto Final de Carrera Reyes Martínez Durbán 7. El sistema modifica los datos de la tarea y cierra el popup de edición. A continuación, ejecuta el caso de uso Consulta de Tareas Flujo Alternativo 2. El actor no introduce ningún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con todas las tareas registradas en el sistema La información que se muestra para las tareas es: nombre, descripción, proyecto y módulo al que pertenece, fecha de inicio, fecha de finalización y observaciones Flujo Alternativo 2. Si el actor selecciona limpiar, el sistema borra todos los datos introducidos por el actor. Debe volverse al paso 6 del flujo normal para proseguir con este caso de uso Excepciones # 3. Si no hay tareas registradas, el sistema informa de esta situación. A continuación, este caso de uso queda sin efecto # 6. Si el actor no proporciona alguno de los datos obligatorios, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación este caso de uso continua # 6. Si el actor introduce una fecha de baja anterior a la fecha de alta del módulo, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación, este caso de uso continua # 6. Si el actor solicita cancelar la operación, este caso de uso queda sin efecto y a continuación, el sistema Página 37 Proyecto Final de Carrera Reyes Martínez Durbán ejecuta el caso de uso Consulta de Tareas Prioridad Alta Frecuencia de uso 4-5 veces por mes Requisitos no funcionales - Observaciones - UC-12 Baja Tarea Autor Reyes Martínez Durbán Versión 1.0 (05/04/2011) Actores Usuario Propósito Eliminar del sistema una tarea Descripción El actor da de baja una tarea en el sistema, borrando todos sus datos Precondiciones La tarea está registrada en el sistema Postcondiciones La tarea es eliminada del sistema Incluye UC-10 Consulta Tareas Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de consulta de tareas 2. El actor introduce algún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con las tareas registrados en el sistema que cumplen los criterios de búsqueda. La información que se muestra para las tareas es: nombre, descripción, Página 38 Proyecto Final de Carrera Reyes Martínez Durbán proyecto y módulo al que pertenece, fecha de inicio, fecha de finalización y observaciones 3. El actor solicita al sistema comenzar con el proceso de baja de tareas, seleccionando la tarea que desea eliminar de la lista al pulsar en el enlace Eliminar 4. El sistema solicita confirmación del borrado de la tarea 5. El actor confirma el borrado de la tarea 6. El sistema elimina la tarea e informa al actor de que la tarea ya no existe en el sistema. A continuación se ejecuta el caso de uso Consulta de Tareas Flujo Alternativo 2. El actor no introduce ningún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con todas las tareas registradas en el sistema. La información que se muestra para las tareas es: nombre, descripción, proyecto y módulo al que pertenece, fecha de inicio, fecha de finalización y observaciones Excepciones # 3. Si no hay tareas registradas, el sistema informa de esta situación. A continuación, este caso de uso queda sin efecto # 5. Si el actor no confirma la operación de borrado de la tarea seleccionada, el sistema cancela el procedimiento. A continuación, este caso de uso queda sin efecto # 6. Si la tarea a eliminar tiene dependencias en la base de datos Página 39 Proyecto Final de Carrera Reyes Martínez Durbán del sistema, el sistema lanza una excepción solicitando que se eliminen en primer lugar sus dependencias. A continuación, este caso de uso queda sin efecto Prioridad Alta Frecuencia de uso 2-3 veces por mes Requisitos no funcionales - Observaciones - UC-13 Asignar Tarea Autor Reyes Martínez Durbán Versión 1.0 (05/04/2011) Actores Usuario Propósito Asignar una tarea a un técnico Descripción El actor realiza una búsqueda de tareas y técnicos registrados en el sistema y asigna la tarea al técnico Precondiciones La tarea y el técnico están registrados en el sistema Postcondiciones La asignación tarea-técnico queda almacenada en el sistema Incluye - Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de asignación de tareas 2. El actor selecciona el proyecto 3. El sistema carga el combo de módulos con los módulos del proyecto Página 40 Proyecto Final de Carrera Reyes Martínez Durbán seleccionado 4. El actor selecciona el módulo 5. El sistema carga el combo de tareas con las tareas del módulo seleccionado 6. El actor selecciona la tarea 7. El actor selecciona el técnico 8. El actor solicita al sistema que almacene la asignación 9. El sistema almacena la asignación, genera un identificador de asignación que identifica unívocamente a la nueva asignación registrada en el sistema e informa al administrador de que la asignación ha sido registrada con éxito. La nueva asignación se añade al listado de asignaciones Flujo Alternativo 2. El actor selecciona directamente la tarea 3. El actor selecciona el técnico 4. El actor solicita al sistema que almacene la asignación 5. El sistema almacena la asignación, genera un identificador de asignación que identifica unívocamente a la nueva asignación registrada en el sistema e informa al administrador de que la asignación ha sido registrada con éxito. La nueva asignación se añade al listado de asignaciones Flujo Alternativo 2. Si el actor selecciona limpiar, el sistema borra todos los filtros introducidos por el actor. Debe volverse al paso 2 del flujo normal para proseguir con este caso de uso Página 41 Proyecto Final de Carrera Reyes Martínez Durbán 2. El actor no introduce ningún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con todas las asignaciones registradas en el sistema que cumplen los criterios de búsqueda. La información que se muestra es: proyecto, módulo, tarea, técnico, fecha de inicio y fecha de finalización Flujo Alternativo 2. Si el actor selecciona limpiar, el sistema borra todos los filtros introducidos por el actor. Debe volverse al paso 2 del flujo normal para proseguir con este caso de uso Excepciones # 2. Si no hay tareas o técnicos registrados, el sistema informa de esta situación. A continuación, este caso de uso queda sin efecto # 5. Si el actor no confirma la operación de borrado del técnico seleccionado, el sistema cancela el procedimiento. A continuación, este caso de uso queda sin efecto Prioridad Frecuencia de uso 3-4 veces por mes Requisitos no funcionales - Observaciones - UC-17 Alta Técnico Autor Reyes Martínez Durbán Página 48 Proyecto Final de Carrera Reyes Martínez Durbán Versión 1.0 (05/04/2011) Actores Usuario Propósito Almacenar en el sistema un técnico Descripción El actor inserta un nuevo técnico con todos sus datos en el sistema Precondiciones El técnico no está registrado en el sistema Postcondiciones El técnico queda almacenado en el sistema Incluye - Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de alta de un nuevo técnico 2. El sistema solicita los datos del nuevo técnico indicando cuales de ellos son obligatorios: nombre, apellidos, NIF y perfil. Además, solicita otros datos de carácter opcional como: fecha de inicio y fecha de finalización 3. El actor proporciona los datos requeridos por el sistema y solicita a éste que los almacene 4. El sistema almacena los datos introducidos por el actor, genera un identificador de técnico que identifica unívocamente al nuevo técnico registrado en el sistema e informa al administrador de que el técnico ha sido registrado con éxito. Página 49 Proyecto Final de Carrera Reyes Martínez Durbán A continuación ejecuta el caso de uso Consulta de Técnicos Flujo Alternativo 3. Si el actor selecciona limpiar, el sistema borra todos los datos introducidos por el actor. Debe volverse al paso 3 del flujo normal para proseguir con este caso de uso Excepciones # 3. Si el actor no proporciona alguno de los datos obligatorios, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación, este caso de uso continua # 3. Si el actor introduce una fecha de baja anterior a la fecha de alta del proyecto, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación, este caso de uso continua # 3. Si el actor solicita cancelar la operación, este caso de uso queda sin efecto y a continuación, el sistema ejecuta el caso de uso Consulta de Técnicos Prioridad Alta Frecuencia de uso 2-3 veces por mes Requisitos no funcionales - Observaciones La frecuencia de ejecución de este caso de uso será mucho más elevada durante los primeros meses de utilización Página 50 Proyecto Final de Carrera Reyes Martínez Durbán UC-18 Consulta Técnicos Autor Reyes Martínez Durbán Versión 1.0 (05/04/2011) Actores Usuario Propósito Consultar la información de un técnico Descripción El actor realiza una búsqueda con o sin filtros (en cuyo caso se mostrarían todos) y el sistema muestra la información del técnico Precondiciones - Postcondiciones Se muestra la información del técnico Incluye - Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de consulta de técnicos 2. El actor introduce algún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con los técnicos registrados en el sistema que cumplen los criterios de búsqueda. La información que se muestra para los técnicos es: nombre, apellidos, NIF, puesto, fecha de inicio y fecha de finalización Flujo Alternativo 2. El actor no introduce ningún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con todos los técnicos registrados Página 51 Proyecto Final de Carrera Reyes Martínez Durbán en el sistema. La información que se muestra para los técnicos es: nombre, apellidos, NIF, puesto, fecha de inicio y fecha de finalización Flujo Alternativo 2. Si el actor selecciona limpiar, el sistema borra todos los filtros introducidos por el actor. Debe volverse al paso 2 del flujo normal para proseguir con este caso de uso Excepciones # 3. Si no hay técnicos registrados, el sistema informa de esta situación. A continuación, este caso de uso queda sin efecto Prioridad Alta Frecuencia de uso 15-20 veces por mes Requisitos no funcionales - Observaciones - UC-19 Edición Técnico Autor Reyes Martínez Durbán Versión 1.0 (05/04/2011) Actores Usuario Propósito Modificar los datos de un técnico Descripción El actor modifica los datos de un técnico existente en el sistema Precondiciones El técnico está registrado en el sistema Postcondiciones Se almacenan en el sistema las modificaciones del técnico, el cual sigue registrado en el sistema Incluye UC-18 Consulta Técnicos Página 52 Proyecto Final de Carrera Reyes Martínez Durbán Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de consulta de técnicos 2. El actor introduce algún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con los técnicos registrados en el sistema que cumplen los criterios de búsqueda. La información que se muestra para los técnicos es: nombre, apellidos, NIF, puesto, fecha de inicio y fecha de finalización 3. El actor solicita al sistema comenzar con el proceso de edición de técnicos, seleccionando el técnico que desea modificar de la lista al pulsar en el enlace Editar 4. El sistema abre un popup con los siguientes datos correspondientes al técnico a modificar: nombre, apellidos, NIF, perfil, fecha de inicio y fecha de fin. 5. El sistema permite al actor modificar todos los campos del técnico salvo el NIF 6. El actor modifica los datos deseados y solicita al sistema que los almacene 7. El sistema modifica los datos del técnico y cierra el popup de edición. A continuación, ejecuta el caso de uso Consulta de Módulos Flujo Alternativo Página 53 Proyecto Final de Carrera Reyes Martínez Durbán 2. El actor no introduce ningún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con todos los técnicos registrados en el sistema. La información que se muestra para los técnicos es: nombre, apellidos, NIF, puesto, fecha de inicio y fecha de finalización Flujo Alternativo 2. Si el actor selecciona limpiar, el sistema borra todos los datos introducidos por el actor. Debe volverse al paso 6 del flujo normal para proseguir con este caso de uso Excepciones # 3. Si no hay técnicos registrados, el sistema informa de esta situación. A continuación, este caso de uso queda sin efecto # 6. Si el actor no proporciona alguno de los datos obligatorios, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación este caso de uso continua # 6. Si el actor introduce una fecha de baja anterior a la fecha de alta del técnico, el sistema informa de esta situación y solicita nuevamente la entrada de estos datos. A continuación, este caso de uso continua # 6. Si el actor solicita cancelar la operación, este caso de uso queda sin efecto y a continuación, el sistema ejecuta el caso de uso Consulta de Técnicos Prioridad Alta Frecuencia de uso 2-3 veces por mes Página 54 Proyecto Final de Carrera Reyes Martínez Durbán Requisitos no funcionales - Observaciones - UC-20 Baja Técnico Autor Reyes Martínez Durbán Versión 1.0 (05/04/2011) Actores Usuario Propósito Eliminar del sistema un técnico Descripción El actor da de baja un técnico en el sistema, borrando todos sus datos Precondiciones El técnico está registrado en el sistema Postcondiciones El técnico es eliminado del sistema Incluye UC-19 Consulta Técnicos Extiende - Hereda de - Flujo Normal Intenciones de usuario Obligaciones de sistema 1. El actor solicita al sistema comenzar con el proceso de consulta de técnicos 2. El actor introduce algún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con los técnicos registrados en el sistema que cumplen los criterios de búsqueda. La información que se muestra para los técnicos es: nombre, apellidos, NIF, puesto, fecha de inicio y fecha de finalización Página 55 Proyecto Final de Carrera Reyes Martínez Durbán 3. El actor solicita al sistema comenzar con el proceso de baja de técnicos, seleccionando el técnico que desea eliminar de la lista al pulsar en el enlace Eliminar 4. El sistema solicita confirmación del borrado del técnico 5. El actor confirma el borrado del técnico 6. El sistema elimina el técnico e informa al actor de que el técnico ya no existe en el sistema. A continuación se ejecuta el caso de uso Consulta de Técnicos Flujo Alternativo 2. El actor no introduce ningún criterio de búsqueda y pulsa buscar 3. El sistema muestra un listado con todos los técnicos registrados en el sistema. La información que se muestra para los técnicos es: nombre, apellidos, NIF, puesto, fecha de inicio y fecha de finalización Excepciones # 3. Si no hay técnicos registrados, el sistema informa de esta situación. A continuación, este caso de uso queda sin efecto # 5. Si el actor no confirma la operación de borrado del técnico seleccionado, el sistema cancela el procedimiento. A continuación, este caso de uso queda sin efecto # 6. Si el técnico a eliminar tiene dependencias en la base de datos del sistema, el sistema lanza una excepción solicitando que se eliminen en primer lugar sus dependencias. A continuación, este caso de uso queda Página 56 Proyecto Final de Carrera Reyes Martínez Durbán sin efecto Prioridad Alta Frecuencia de uso 1 vez por mes Requisitos no funcionales - Observaciones - 2.3. REQUISITOS NO FUNCIONALES En este apartado se identifican los requisitos no funcionales, los cuales se corresponden normalmente con requisitos de carácter técnico o legal. •Servidor de Bases de Datos Gestor de BBDD MySQL, versión 5.5.20 •Entorno de Explotación El sistema debe funcionar en un entorno de PC's que tengan acceso a Internet como mínimo con módem a 56K y utilicen como explorador Microsoft Internet Explorer versión 7 como mínimo, aunque debe ser también accesible en otros navegadores. •Servidor Web El sistema utilizará el Servidor de Tomcat, versión 6.0.35 3. APLICACIÓN 3.1. PROCESO DE INSTALACIÓN Para compilar y ejecutar un programa java, es necesario instalar la plataforma java JDK (Java Development Kit). El JDK es el conjunto Página 57 Proyecto Final de Carrera Reyes Martínez Durbán 1. Primera forma normal Una relación está en primera forma normal (1FN) si y sólo si todos los dominios son atómicos. Un dominio es atómico si los elementos del dominio son indivisibles. Es decir, no tenemos grupos de repetición o un conjunto de valores asociados repetidos asociados a una misma tupla. 2. Segunda forma normal Una relación está en segunda forma normal (2FN) si y sólo si está en 1FN y todos los atributos que no sean llaves dependen por completo de llave primaria. 3. Tercera forma normal Una relación están en tercera forma normal (3FN) si y sólo si están en 2FN y todos los atributos no llave dependen de manera no transitiva de la llave primaria. Integridad relacional En un momento dado, los valores de los datos en una base de datos son una representación de un fragmento de la realidad. Es decir, si tenemos una tabla con los atributos de personas y entre ellos el peso o la edad, estos no pueden ser negativos, porque en el mundo real, esto no es posible. Si añadimos una restricción de este tipo a una base de datos, estamos incluyéndole una regla de integridad. Una vez comentadas algunos conceptos básicos sobre base de datos, para esta aplicación la base de datos se compone de 6 tablas: Proyecto, Modulo, Tarea, Tecnico, TareaTecnico y Perfil. El modelo de datos para la aplicación sería: Página 64 Proyecto Final de Carrera Reyes Martínez Durbán Figura: Modelo de Datos Aquellos atributos que empiezan con PK, son claves primarias, por lo que no pueden estar repetidos, deben tener un identificador único, para ello se han utilizan las secuencias, una por cada clave primaria, de manera que los valores de ese atributo es autoincrementable en uno. Utilizando MySQL esto se conseguiría utilizando la palabra “AUTO_INCREMENT” en la declaración del atributo clave primaria de cada tabla. 3.3. DESCRIPCIÓN DE LA APLICACIÓN Al acceder a la aplicación, se muestra una página en blanco con el menú disponible con las siguientes entradas: Proyecto, Módulo, Tarea y Técnico. Al seleccionar cada una de ellas, la aplicación muestra las posibles opciones, que serían, Alta y Consulta, estando dentro de Consulta las opciones de Edición y Eliminación. Página 65 Proyecto Final de Carrera Reyes Martínez Durbán Dentro de la opción de Tarea, se encuentra el submenú “Asignar Tarea” que permite tanto asignar una tarea a un técnico como modificar o eliminar dicha asignación. Gestión de Proyectos: La opción de alta de un nuevo proyecto lleva a un formulario donde se podrán introducir los campos asociados a dicho proyecto, en su caso, Nombre, Descripción, Alcance, que sería la prioridad del proyecto dentro de la organización, Coste total del proyecto, Técnico responsable, Origen o área en que se desarrolla el proyecto, Fecha de inicio, por defecto sería la fecha actual y Fecha de finalización del proyecto. Para facilitar la tarea de asignar a un técnico responsable del proyecto, el sistema muestra una lista con todos los técnicos que pertenecen actualmente a la organización. Los campos marcados con un * serían obligatorios. La opción de consulta de nuevo proyecto permite introducir diferentes criterios de búsqueda, mostrando por defecto un listado de todos los proyectos existentes en el sistema. Página 66 Proyecto Final de Carrera Reyes Martínez Durbán Existe la posibilidad de mostrar en el listado los proyectos dados de baja haciendo click en el check “Incluir proyectos dados de baja”. Para cada proyecto del listado, se muestran dos links, Editar y Eliminar. Si se hace click sobre Editar, el sistema abre una ventana de pop up con un formulario relleno con los datos del proyecto. El usuario tiene la opción de modificar cualquier campo del proyecto y pulsar sobre Guardar si desea guardar sus cambios o Cancelar para desecharlos. En ambos casos, la aplicación cierra el pop up y vuelve al listado de proyectos anterior, actualizándolo. Página 67 Proyecto Final de Carrera Reyes Martínez Durbán Si el usuario hace click sobre Eliminar, el sistema muestra un mensaje de confirmación de eliminación del proyecto en primera plana, con las opciones ok y cancel. Si el usuario selecciona ok, el proyecto es eliminado del sistema y se vuelve al listado de proyectos, habiéndose suprimido de éste el proyecto seleccionado. Si el usuario selecciona cancel, se cierra la ventana de aviso y se continúa en el listado. Página 68 Proyecto Final de Carrera Reyes Martínez Durbán Gestión de Módulos: En la aplicación, los proyectos se componen de módulos de manera que a la hora de gestionar un módulo, este irá siempre relacionado con un determinado proyecto, por tanto, un módulo nunca existirá por si solo. La opción de alta de un nuevo módulo lleva a un formulario donde se podrán introducir los campos asociados a dicho módulo, en su caso, Nombre, Descripción, Proyecto al que pertenece, mediante una lista desplegable con todos los proyectos existentes en el sistema, Fecha de inicio, por defecto sería la fecha actual Fecha de finalización del proyecto y Observaciones. El campo Nombre y Proyecto son obligatorios. La opción de consulta de nuevo módulo permite introducir diferentes criterios de búsqueda, mostrando por defecto un listado de todos los módulos existentes en el sistema. Página 69 Proyecto Final de Carrera Reyes Martínez Durbán Existe la posibilidad de mostrar en el listado los módulos dados de baja haciendo click en el check “Incluir módulos dados de baja”. Para cada módulo del listado, se muestran dos links, Editar y Eliminar. Si se hace click sobre Editar, el sistema abre una ventana de pop up con un formulario relleno con los datos del módulo seleccionado. El usuario tiene la opción de modificar cualquier campo del módulo y pulsar sobre Guardar si desea guardar sus cambios o Cancelar para desecharlos. En ambos casos, la aplicación cierra el pop up y vuelve al listado de módulos anterior, actualizándolo. Página 70 Proyecto Final de Carrera Reyes Martínez Durbán Si el usuario hace click sobre Eliminar, el sistema muestra un mensaje de confirmación de eliminación del módulo en primera plana, con las opciones ok y cancel. Si el usuario selecciona ok, el módulo es eliminado del sistema y se vuelve al listado de módulos, habiéndose suprimido de éste el módulo seleccionado. Si el usuario selecciona cancel, se cierra la ventana de aviso y se continúa en el listado. Página 71 Proyecto Final de Carrera Reyes Martínez Durbán Gestión de Tareas: Al igual que los módulos no pueden existir por sí solos, las tareas no pueden existir sin estar asociadas a un módulo determinado, es por ello que a la hora de insertar una nueva tarea, el sistema solicite como obligatorios, además del nombre de la tarea, el proyecto al que se quiere asociar dicha tarea. Una vez seleccionado el proyecto el sistema desplegará los módulos asociados a dicho proyecto. Cuando se hayan seleccionado tanto proyecto como módulo, el sistema permitirá la creación de la nueva tarea. Al seleccionar Alta Tarea en el menú, el sistema muestra un formulario con los campos Nombre, Descripción, Proyecto al que pertenece, mediante una lista desplegable con todos los proyectos existentes en el sistema, Módulo al que pertenece, con la lista rellena con los módulos pertenecientes al proyecto, en caso de tener uno seleccionado, Fecha de inicio, por defecto sería la fecha actual Fecha de finalización del proyecto y Observaciones. Página 72 Proyecto Final de Carrera Reyes Martínez Durbán La opción de consulta de nueva tarea permite introducir diferentes criterios de búsqueda, mostrando por defecto un listado de todas las tareas existentes en el sistema. Existe la posibilidad de mostrar en el listado las tareas dadas de baja haciendo click en el check “Incluir tareas dadas de baja”. Página 73 Proyecto Final de Carrera Reyes Martínez Durbán Una vez seleccionados al menos la tarea y el técnico, el sistema permite la asignación, que pasará a mostrarse en el listado de la parte inferior de la pantalla. Para cada asignación del listado, se muestran dos links, Editar y Eliminar. Si se hace click sobre Editar, el sistema abre una ventana de pop up con un formulario relleno con los datos de la asignación seleccionada. El sistema sólo permite modificar la fecha de inicio y la de finalización de la asignación. En caso de querer cambiar el técnico o la tarea, deberá procederse a la eliminación de la asignación seleccionada y a la posterior creación de la nueva. El usuario debe pulsar sobre Guardar si desea guardar sus cambios o Cancelar para desecharlos. En ambos casos, la aplicación cierra el pop up y vuelve al listado de asignaciones anterior, actualizándolo. Página 80 Proyecto Final de Carrera Reyes Martínez Durbán Si el usuario hace click sobre el link Eliminar, el sistema muestra un mensaje de confirmación de eliminación de la asignación en primera plana, con las opciones ok y cancel. Si el usuario selecciona ok, la asignación es eliminada del sistema y se vuelve al listado de asignaciones, habiéndose suprimido de éste la asignación seleccionada. Si el usuario selecciona cancel, se cierra la ventana de aviso y se continúa en el listado. Página 81 Proyecto Final de Carrera Reyes Martínez Durbán Para todos los formularios de la aplicación, se tiene la opción de Limpiar que dejaría en blanco todos los campos del formulario en cuestión. En todos los listados de la aplicación, existe paginación cuando el número de elementos en el listado es superior a 10. Los iconos de calendario mostrados en la aplicación abren una ventana pop up con un calendario que permite seleccionar el día deseado al usuario. Página 82 Proyecto Final de Carrera Reyes Martínez Durbán 3.4. PRUEBAS El proceso de pruebas consiste, básicamente, en la realización de una serie de pruebas al código para observar con que frecuencia podría fallar ese código, encontrar esos errores y solucionarlos. Estas pruebas hay que realizarlas al comienzo del ciclo de vida del software ya que, cuando se avanza en el ciclo de vida, más costoso sería solucionar el fallo encontrado. Funcionalmente, por pruebas se entiende el análisis experimental que permite aumentar la confianza en que la implementación que una aplicación proporciona es correcta respecto a sus requisitos. Las prueban se pueden dividir en dos grupos: 1. Pruebas Unitarias, probamos el funcionamiento de cada módulo por separado. 2. Pruebas de Integración, probamos el funcionamiento del sistema. Pruebas unitarias Cuando cierta parte de un proyecto software está terminada, se debe realizar una serie de pruebas en busca de fallos a través de unos criterios llamados pruebas de caja negra y/o de caja blanca, no son excluyentes, sino complementarias, y ambos deben ser utilizados. Si nos lo que importa son las devoluciones de cada una de las funciones de la CUT (Class Under Test), estaremos ante lo que se llaman pruebas funcionales, de comportamiento o de caja negra. Estas pruebas no están basadas en el conocimiento del código o Página 83 Proyecto Final de Carrera Reyes Martínez Durbán diseño interno y determinan la funcionalidad del sistema de acuerdo con los requisitos funcionales. El proceso de una prueba de caja negra es simple, se ejecuta la unidad de prueba con datos, se observa la salida y se compara con el resultado esperado. Si la salida y el resultado esperado son iguales, la prueba ha sido superada. Conforme se van pasando las pruebas de caja negra se puede determinar que “cantidad” de código ha sido cubierto, es decir, cuanto porcentaje de código se ha ejecutado. Esto son las pruebas de caja blanca o de implementación. Estas pruebas están basadas en la lógica interna de la aplicación y el código y se encargan de realizar una cobertura de declaraciones de código, ramas, caminos y condiciones. Con las pruebas de caja blanca se busca encontrar fragmentos del programa que no son ejecutados por los casos de pruebas. Si encontramos que el resultado de estas pruebas es menor al 100%, se debe ejecutar otros casos para intentar llegar al 100%. Si aun así no se consigue ese 100%, deberíamos preguntarnos si sirve de algo ese trozo de código. El proceso de realizar estas pruebas es simple, como muestra el diagrama: Página 84 Proyecto Final de Carrera Reyes Martínez Durbán Pruebas de integración Se basan en las pruebas de conexiones y comunicaciones entre distintos módulos, una vez probados unitariamente. Este tipo de pruebas son esenciales en sistemas cliente-servidor o red. En este tipo de pruebas se combinan los módulos individuales y se prueban en grupo para asegurar el correcto funcionamiento del sistema o subsistema en cuestión. En concreto, para el proyecto realizado, se han ejecutado pruebas mayoritariamente dinámicas, esto es, ejecutando el código fuente para comprobar si las operaciones llevadas a cabo han sido reflejadas en la base de datos. Al disponerse del código fuente de la aplicación, las pruebas unitarias han sido de caja blanca, intentando encontrar errores en los requisitos funcionales y de información y comprobando que el estilo de las interfaces se adapta a la resolución correspondiente. Página 85 Proyecto Final de Carrera Reyes Martínez Durbán También se han realizado pruebas de integración consistentes en probar la interacción de la aplicación con la base de datos. Para facilitar la tarea de la ejecución de pruebas, se han utilizado clases con casos de prueba mediante JUnit. JUnit es un conjunto de clases (framework) que permite realizar la ejecución de clases Java de manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se comporta como se espera. Gracias a él, es posible automatizar las pruebas de las aplicaciones Java. La única precaución que se debe de tener para utilizar JUnit es añadir la librería al classpath y tener el driver jdbc también añadido si se desea interactuar con la base de datos. Algunas de las pruebas realizadas han sido: •Comprobar que la base de datos devuelve los proyectos correctos al invocar la búsqueda. •Comprobar que la aplicación no deja introducir una fecha de baja anterior a la fecha de alta de un técnico, mostrando un mensaje de aviso. •Comprobar que se introducen los campos requeridos al dar de alta una nueva tarea. •Comprobar que las tareas mostradas para un determinado módulo son las correctas. •Comprobar que no es posible la eliminación de un módulo si tiene tareas asociadas, mostrando un mensaje de aviso. 4. CONCEPTOS TEÓRICOS 4.1. AJAX 4.1.1. DEFINICIÓN AJAX Página 86 Proyecto Final de Carrera Reyes Martínez Durbán AJAX, es una técnica muy atractiva para muchos desarrolladores web de aplicaciones interactivas o RIA (Rich Internet Applications).Permite que los usuarios interactúen con un sitio y comunicarse con su base de datos sin actualizar las páginas. Sin embargo, debido a su naturaleza dinámica, las interfaces Ajax son a menudo más difíciles de desarrollar, en comparación con las páginas estáticas. A fin de reducir la complejidad del desarrollo, se han creado algunas bibliotecas de soporte de AJAX, como jQuery y GWT. AJAX (Asynchronous JavaScript And XML) es un grupo de técnicas de desarrollo web que se utilizan en el lado del cliente para crear aplicaciones web interactivas. Ajax permite a las aplicaciones web recuperar datos del servidor de forma asincrónica en segundo plano sin interferir con la visualización o el comportamiento de la página existente, lo que significa aumentar la interoperabilidad, velocidad y usabilidad en las aplicaciones. AJAX no constituye una tecnología en si, sino que combina tres tecnologías ya existentes: •XHTML y hojas de estilos (CSS) para el diseño que formatea la información. •Document Object Model (DOM) que es el encargado de interactuar con la información presentada y es el que se ejecuta en el cliente (navegador), y •XMLHttpRequest, que es un objeto encargado de intercambiar datos con el servidor web. Estos datos son devueltos en formato XML o JSON y se añaden a la página que estamos visualizando integrándose de nuevo gracias a XHTML y CSS. En el gráfico siguiente se muestra cómo trabaja Ajax: Página 87 Proyecto Final de Carrera Reyes Martínez Durbán El navegador está a la escucha de un evento y cuando éste se produce, crea un objeto XMLHttpRequest. El objeto XMLHttpRequest es el objeto que se utiliza para la comunicación entre servidor y el navegador en lugar de HttpRequest, que actualizaría la página entera. La mayoría de los navegadores modernos tienen un XMLHttpRequest built-in, pero las versiones anteriores a IE6 no son compatibles con este objeto. Si sólo hay una aplicación Ajax en la página, el concepto anterior se implementa fácilmente mediante un par de líneas en Javascript, pero cuando el proyecto incluye grandes usos de Ajax como Google Docs o Google Wave, el manejo de Javascript puede hacerse muy complejo. Y en el siguiente, se muestra la diferencia entre las aplicaciones web clásicas y las aplicaciones web utilizando AJAX. Página 88 Proyecto Final de Carrera Reyes Martínez Durbán Las aplicaciones RIA son aplicaciones web con muchas de las características de las aplicaciones de escritorio, normalmente entregadas ya sea por medio de webs basadas en los estándares de los navegadores, vía plugins del navegador o independientemente, vía sandboxes o máquinas virtuales. Desarrollar aplicaciones RIA utilizando Javascript tiene una serie de inconvenientes: •Conseguir que el código sea cross-browser (funcione sin problemas en la mayoría de navegadores). •Modularización del código cuando las aplicaciones crecen. •Falta de herramientas avanzadas para el desarrollo con Javascript. •Necesidad de tener un conocimiento avanzado en Javascript para obtener aplicaciones optimizadas. Página 89 Proyecto Final de Carrera Reyes Martínez Durbán El contenido completo del elemento body puede ser generado de forma dinámica. En este caso, se ha creado un elemento <div> HTML para usarlo como marcador de posición para los componentes GWT generados dinámicamente, que serán asignados al cuerdo de la etiqueta de la página HTML. El aspecto de este archivo sería algo similar a: <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF8"> <link type="text/css" rel="stylesheet" href="GestionProyectos.css"> <title>Gestion Proyectos</title> <script type="text/javascript" language="javascript" src="gestionproyectos/gestionproyectos.nocache.js"></script> </head> <!-- The body can have arbitrary html, or --> <!-- you can leave the body empty if you want --> <!-- to create a completely dynamic UI. --> <body> <h1>Sistema de Gestion de Proyectos</h1> <table id="main" style="height: 100%; width: 100%;" cellpadding="0" cellspacing="0"> <tr> <td id="menu" style="width: 100%;"></td> </tr> <tr> <td valign="top"> <table width="100%" cellspacing="0" cellpadding="0" border="0"> <tr> <td id="gwt_content"></td> </tr> </table> </td> </tr> <tr> <td align="right" nowrap> <div class="footer"></div> </td> </tr> </table> </body> </html> Página 96 Proyecto Final de Carrera Reyes Martínez Durbán Una clase de Java que es punto de entrada debe implementar la interfaz "com.google.gwt.core.client.EntryPoint", que define el método de onModuleLoad (), en este caso, la clase que contiene el código fuente de Java para la aplicación de arranque es GestionProyectos.java. Como la clase GestionProyectos.java ha sido especificada como la clase de punto de entrada en la definición del módulo GestionProyectos, cuando se lance GestionProyectos, se llamará al método onModuleLoad, que contiene la inicialización de la aplicación. Para construir la interfaz de usuario, se ha utilizado UIBinder, que permite diseñar las interfaces de usuario de forma declarativa a través de XML. Un ejemplo de código que usa UiBinder sería: <ui:UiBinder xmlns:ui="urn:ui:com.google.gwt.uibinder" xmlns:g="urn:import:com.google.gwt.user.client.ui"> <ui:style> .mainPanel { border: 1px solid #e0e0e0; } </ui:style> <g:VerticalPanel height="100%" width="600px" horizontalAlignment="ALIGN_CENTER" styleName='{style.space_panel}'> <g:Grid width="250px" height="291px" ui:field="mainGrid" > <g:row> <g:customCell> <g:Label text="Nombre: *" width="85px" height="18px" styleName="text_label"/> </g:customCell> <g:customCell> <g:TextBox width="150px" height="18px" styleName="textbox" ui:field="nameField"/> </g:customCell> </g:row> . . . </g:Grid> <g:HorizontalPanel width="475px" height="54px" ui:field="createButton" > <g:Button width="80px" height="26px" text="Crear" styleName='{style.gpButton}' ui:field="saveButton" /> </g:HorizontalPanel> </g:VerticalPanel> </ui:UiBinder> Página 97 Proyecto Final de Carrera Reyes Martínez Durbán Las plantillas UiBinder tienen asociada una clase java propietaria que permite el acceso a los widgets y paneles declarados en la plantilla, en este caso sería: public class CrearProyectoImpl extends GPPanel implements CrearProyecto { private static CrearProyectoImplUiBinder uiBinder = GWT.create(CrearProyectoImplUiBinder.class); @UiField TextBox nameField; @UiField HorizontalPanel createButton; interface CrearProyectoImplUiBinder extends UiBinder<Widget, CrearProyectoImpl> {} public void initUI() { setWidget(uiBinder.createAndBindUi(this)); . . . } @UiHandler("saveButton") void onSaveButtonClick(ClickEvent event) { . . . } } Cualquier objeto declarado en el archivo de ui.xml, incluidos todos los elementos DOM, puede ponerse a disposición de la clase Java propietaria a través del nombre del campo. Los elementos que se quieren tener accesibles desde el código java, se marcan como ui:field en el ui.xml. Cuando uiBinder.createAndBindUi (this) se ejecuta, el campo anotado como @UiField en la clase Java se llena con la instancia adecuada del elemento. La anotación @ UiHandler agrega un controlador al botón de GWT y sólo se tiene que escribir lo que se deberá ejecutar después que el botón mande un evento click. 4.2.4. EL PATRÓN MODELO-VISTA-PRESENTADOR 4.2.4.1. DEFINICIÓN Página 98 Proyecto Final de Carrera Reyes Martínez Durbán Este proyecto se basa en el patrón MVP, Model-View-Presenter, que es un patrón derivado del patrón Modelo Vista Controlador (MVC) que ayuda a ofrecer una clara separación entre la vista, el modelo y el controlador y cuyo esquema sería el siguiente: La clave del patrón MVP es una estricta regulación de la interacción entre la vista y el controlador, aunque en el patrón MVP, al controlador se le conoce como presentador. La idea básica es que la clase Presenter haga de intermediario entre la Vista (la interfaz gráfica de usuario) y el modelo de datos y es ahí donde se realiza toda la lógica, que no depende en absoluto de los componentes de la interfaz gráfica y que, por tanto, es más fácil de realizar pruebas. 4.2.4.2, IMPLEMENTACIÓN DEL PATRÓN MVP: ACTIVITIES Y PLACES En este proyecto, la implementación de este patrón se consigue mediante la utilización de Activities y Places, introducido a partir de la versión GWT 2.1, que además proporciona un marco integrado para la gestión del historial del navegador, permitiendo que el botón atrás del navegador funcione como el usuario espera, aunque en este proyecto, el mecanismo de control del historial del navegador no ha sido utilizado. Una “Activity” (presentador) representa simplemente algo que el usuario está haciendo. Una actividad no contiene widgets o código de interfaz de usuario. Página 99 Proyecto Final de Carrera Reyes Martínez Durbán Las actividades suelen restaurar el estado ("despertar"), realizar la inicialización ("set up"), y cargar una interfaz de usuario correspondiente ("aparecer"). Las actividades se inician y se detiene por un ActivityManager asociado con un widget contenedor. Una actividad puede mostrar automáticamente una confirmación de advertencia cuando la ésta está a punto de ser detenida (por ejemplo, cuando el usuario navega a un nuevo lugar). Además, el ActivityManager avisa al usuario antes de la ventana está a punto de ser cerrada. Un ejemplo de esto lo encontramos en el siguiente código: public class CrearProyectoActivity implements CrearProyecto.Presenter{ private CrearProyecto view = null; private CrearProyectoPlace place = null; public CrearProyectoActivity(final CrearProyectoPlace place) { this.place = place; } public void start() { view = new CrearProyectoImpl(); view.setPresenter(this); Utils.changePage((CrearProyectoImpl) view); ((CrearProyectoImpl) view).initUI(); } @Override public void onSaveButtonClick(ProyectoBean projectBean) { ProyectoServiceAsync rpc; rpc = (ProyectoServiceAsync) GWT.create(ProyectoService.class); rpc.createProject(projectBean, new AsyncCallback<Boolean>() { public void onSuccess(Boolean result) { if(result){ Window.alert("Proyecto creado correctamente."); ConsultarProyectoActivity activity = new ConsultarProyectoActivity(new ConsultarProyectoPlace()); activity.start(); } } public void onFailure(Throwable caught) { System.out.println("Error!! "); super.onFailure(caught); } }); } } Lo primero a notar es que CrearProyectoActivity hace referencia a CrearProyecto, que es una interfaz de vista, no una implementación. Un Página 100 Proyecto Final de Carrera Reyes Martínez Durbán estilo de MVP codificación define la interfaz de vista en el presentador. Esto es perfectamente legítimo, sin embargo, no hay ninguna razón fundamental por la cual una actividad y una interfaz de vista correspondiente tengan que estar estrechamente unidos. Hay que tener en cuenta que CrearProyectoActivity también implementa la interfaz de la vista del Presenter. Esto se utiliza para permitir a la vista llamar a los métodos de la actividad, lo que facilita el uso de UiBinder. El constructor CrearProyectoActivity toma como argumento CrearProyectoPlace. El CrearProyectoPlace simplemente hace que sea fácil para CrearProyectoActivity para obtener las propiedades del estado representado por CrearProyectoPlace. Las actividades están diseñadas para ser desechables, mientras que las vistas, que son más caras de crear debido a las llamadas DOM necesarias, debe ser reutilizable. Cuando se invoca al método start, las cosas se ponen en movimiento. En él se actualiza la vista y luego se redirige a ella. Un “Place” es un objeto Java que representa un estado particular de la interfaz de usuario. Un place puede convertirse a y desde un token de historia URL mediante la definición de un PlaceTokenizer para cada place, y el PlaceHistoryHandler actualiza automáticamente la URL del navegador correspondiente a cada place en la aplicación. Un place extiende de com.google.gwt.place.shared.Place y debe tener un PlaceTokenizer asociado que sabe cómo serializar el estado del place a un token URL. Por defecto, la dirección consiste en el nombre del place de clase simple (como "CrearProyectoPlace ") seguido de dos puntos (:) y el token devuelto por el PlaceTokenizer. Un ejemplo de esto sería: import com.google.gwt.place.shared.Place; public class CrearProyectoPlace extends Place{ public static class Tokenizer implements PlaceTokenizer<CrearProyectoPlace> { @Override public CrearProyectoPlace getPlace(String token) { return new CrearProyectoPlace(); Página 101 Proyecto Final de Carrera Reyes Martínez Durbán } @Override public String getToken(final CrearProyectoPlace place) { return null; } } } Es conveniente (aunque no es obligatorio) declarar PlaceTokenizer como una clase estática dentro de la que corresponda. Sin embargo, no es necesario tener un PlaceTokenizer para cada place. Muchos places simplemente declaran un PlaceTokenizer que devuelve un token nulo porque no precisan guardar el estado de la URL, como es este caso. Una “View” es simplemente la parte de la interfaz de usuario asociada a una actividad. En el desarrollo MVP, una vista se define por una interfaz, que permite múltiples implementaciones de la vista basadas en las características del cliente (como móvil vs escritorio) y también facilita las pruebas unitarias ligeras, evitando el consumo de tiempo que genera GWTTestCase. No hay ninguna interfaz o clase en GWT que la vista deba implementar o extender, sin embargo, GWT 2.1 presenta una interfaz IsWidget que es implementada por la mayoría de los Widgets, así como los Composite. Es útil para las vistas extender IsWidget si de hecho, proporcionan un Widget. La vista contiene todos los componentes de interfaz de usuario que componen nuestra aplicación. Esto incluye todas las tablas, etiquetas, botones, cuadros de texto, etc. Las vistas son responsables de la distribución de los componentes de interfaz de usuario y no tienen noción del modelo. Es decir, un punto de vista no sabe que está mostrando un proyecto, simplemente sabe que tiene, por ejemplo, 3 etiquetas, cuadros de texto 3, y 2 botones que se organizan en forma vertical. Ejemplos de código de la vista ya se proporcionaron al describir la interfaz de usuario con UiBinder. El Modelo incluye objetos de negocio, en nuestro caso, por ejemplo, tendríamos un ProyectoBean.java, una representación del proyecto que contendría el identificador del proyecto, el nombre, la descripción, el Página 102 Proyecto Final de Carrera Reyes Martínez Durbán alcance, el origen, el coste, las fechas de inicio y finalización y el técnico responsable. 4.2.5. COMUNICACIÓN CON EL SERVIDOR Todas las aplicaciones GWT se ejecutan como código JavaScript en el navegador web del usuario final. Con frecuencia, sin embargo, se desea crear algo más que una aplicación standalone en el lado del cliente. La aplicación tendrá que comunicarse con un servidor web, enviar solicitudes y recibir las actualizaciones. GWT ofrece un par de maneras diferentes para comunicarse con un servidor vía HTTP: Se pueden utilizar llamadas a procedimiento remoto, esto es, el framework GWT RPC para hacer llamadas de forma transparente a los servlets de Java y dejar que GWT cuide de los detalles de bajo nivel como la serialización de objetos. Alternativamente, se pueden usar clases genéricas HTTP que ofrece GWT para construir la petición, como RequestBuilder, y clases JSON y XML de cliente para procesar la respuesta. Tanto si se utiliza GWT RPC como datos JSON vía HTTP, todas las llamadas realizadas desde la página HTML al servidor son asíncronas. Esto significa que no se bloquean mientras esperan que retorne la llamada hecha al servidor. El código que va a continuación de la llamada se ejecuta inmediatamente. Cuando la llamada se completa, el método de devolución de llamada (callback) que se especificó cuando se hizo la llamada se ejecutará. 4.2.5.1. LLAMADAS RPC El mecanismo para interactuar con un servidor a través de una red se le llama hacer una llamada a procedimiento remoto (RPC), también referido a veces como llamada al servidor. GWT RPC hace que sea fácil para el cliente y el servidor pasar objetos Java de ida y vuelta a través de HTTP. Cuando se utiliza correctamente, RPC da la oportunidad de pasar toda la Página 103 Proyecto Final de Carrera Reyes Martínez Durbán lógica de la interfaz de usuario para el cliente, resultando en un rendimiento mejorado en gran medida, ancho de banda reducido, reducción de la carga del servidor web, y una experiencia de usuario agradable y fluida. El código del lado del servidor que se invoca desde el cliente se refiere a menudo como un servicio, por lo que el acto de hacer una llamada a un procedimiento remoto se refiere a veces como la invocación de un servicio. Para ser claros, sin embargo, el servicio a largo plazo en este contexto no es el mismo que el concepto más general de "servicios web". En particular, los servicios de GWT no están relacionados con el Simple Object Access Protocol (SOAP). Para invocar a un servicio, se necesitan una serie de elementos. Cada servicio tiene una pequeña familia de interfaces y clases de ayuda. Algunas de estas clases, como el proxy de servicio, se generan automáticamente y por lo general es como si no existieran. El modelo para las clases de ayuda es idéntico para todos los servicios que se implementan, y sigue el siguiente esquema: Con el fin de definir una interfaz RPC, es necesario: 1. Definir una interfaz para el servicio que se extiende RemoteService y lista todos los métodos de RPC. Esta interfaz síncrona es la versión Página 104 Proyecto Final de Carrera Reyes Martínez Durbán definitiva de la especificación del servicio. Es el stub de cliente. No es posible llamar a esta versión del RPC desde el cliente, para ello se utiliza una interfaz asíncrona. package com.ejemplo.client; import com.google.gwt.user.client.rpc.RemoteService; import com.google.gwt.user.client.rpc.RemoteServiceRelativePath; @RemoteServiceRelativePath("proyecto") public interface ProyectoService extends RemoteService { public boolean createProject(ProyectoBean project); . . . } 2. Definir una clase para implementar el código del lado del servidor que extiende RemoteServiceServlet e implementa la interfaz que se ha creado anteriormente. Cada implementación del servicio es en última instancia, un servlet, pero en lugar de extender HttpServlet, extiende RemoteServiceServlet. RemoteServiceServlet maneja automáticamente la serialización de los datos que pasan entre el cliente y el servidor e invocar el método previsto en la implementación del servicio. package com.ejemplo.server; import com.ejemplo.client.ProyectoService; import com.google.gwt.user.server.rpc.RemoteServiceServlet; @SuppressWarnings("serial") public class ProyectoServiceImpl extends RemoteServiceServlet implements ProyectoService { public boolean createProject(ProyectoBean project){ . . . } } 3. Definir una interfaz asíncrona al servicio para llamar desde el código del lado del cliente. La naturaleza de las llamadas asíncronas requiere que el método que realiza la petición pase un objeto de devolución de llamada (callback) para que sea notificado cuando la llamada asincrónica se ha completado, ya que por definición quien llama no se puede bloquear hasta que la llamada se complete. Por la misma razón, los Página 105