Repositorio Institucional de Documentos

PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” i “Diseño y desarrollo de un sistema de control de la dedicación basado en 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 el control y la previsión del coste temporal de la realización de una amplia variedad de tipos de proyectos. Dada la naturaleza de cualquier proyecto software es complicado prever con antelación el tiempo necesario para su realización. En algunos casos, puede ser la causa para que no se cumpla con la fecha de entrega, con la posible pérdida de confianza por parte del cliente. El sistema da acceso a los gestores y a los participantes en los proyectos. Un gestor puede configurar un proyecto y añadirle tareas y participantes. También puede configurar alarmas que permitan avisarle, tanto a él como a los participantes, de que el tiempo previsto para la realización de una tarea del proyecto ha sido superado. Además podrá generar informes de la dedicación de los proyectos que gestione. Por otro lado, un participante en un proyecto podrá introducir su dedicación diaria realizada a cada una de las tareas del proyecto en el que participe. También podrá ver las alarmas que el gestor haya configurado, así como crear informes de la dedicación que ha realizado en los proyectos. El sistema está compuesto por dos aplicaciones: Una aplicación Web que permitirá a los gestores configurar los proyectos y los participantes. Una aplicación Portlet que permitirá a los participantes en los proyectos introducir su dedicación diaria. La tecnología de Portlet permite crear aplicaciones que se integran fácilmente en un portal Web. Un gestor de un proyecto podrá añadir esta aplicación en su página Web para facilitar el acceso a los participantes. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” iii AGRADECIMIENTOS Quisiera agradecer a Pedro Álvarez por haberme dirigido este proyecto y a la Universidad de Zaragoza que me ha brindado la oportunidad de realizarlo. A todos mis profesores que tanto me han enseñado en estos años. Agradecer a mi familia por su apoyo incondicional y por la paciencia que han tenido durante todos estos años, en especial a Pilar. Recordar a todos mis amigos y compañeros que me han acompañado en los buenos y los malos tiempos, Virginia, Quique, Rafa, Juan, Cristina, Ángel, Luis, Pilar, ……........ No hay puntos suficientes para representarlos a todos, ni los puntos los representan como se merecen. Quiero dar mi más sincero agradecimiento a todo el personal de la EINA, que me ha adaptado en todo momento las salas, ordenadores y aulas para que pudiera realizar mis estudios. Y un especial agradecimiento a la ONCE, que sin su apoyo personal y tecnológico no podría haber realizado esta carrera. A todos muchas gracias. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” v ÍNDICE RESUMEN .......................................................................................................... i AGRADECIMIENTOS ....................................................................................... iii ÍNDICE DE FIGURAS ....................................................................................... ix ÍNDICE DE TABLAS .......................................................................................... x 1 INTRODUCCIÓN ........................................................................................... 1 1.1 CONTEXTO DEL PROYECTO ................................................................ 1 1.2 MOTIVACIÓN .......................................................................................... 1 1.3 ESTRUCTURA DE LA MEMORIA ........................................................... 2 2 ANÁLISIS DEL PROBLEMA .......................................................................... 3 2.1 OBJETIVOS GENERALES ...................................................................... 3 2.2 ESPECIFICACIÓN DE REQUISITOS ...................................................... 4 2.2.1 REQUISITOS FUNCIONALES .......................................................... 4 2.2.2 REQUISITOS NO FUNCIONALES .................................................... 5 2.3 ANÁLISIS DE LAS TECNOLOGÍAS......................................................... 6 2.3.1 REQUISITOS TECNOLÓGICOS ....................................................... 6 2.3.2 SELECCIÓN DE TECNOLOGÍAS ..................................................... 7 3 DISEÑO DEL SISTEMA ............................................................................... 11 3.1 CONTEXTO DEL SISTEMA .................................................................. 11 3.2 ARQUITECTURA DEL SISTEMA .......................................................... 12 3.2.1 DESPLIEGUE DEL SISTEMA ......................................................... 13 3.3 CAPA DE DATOS .................................................................................. 15 3.4 CAPA DE NEGOCIO ............................................................................. 17 3.4.1 EJEMPLO DE FUNCIONAMIENTO ................................................. 19 3.5 CAPA DE PRESENTACIÓN .................................................................. 21 3.5.1 APLICACIÓN WEB .......................................................................... 22 3.5.2 APLICACIÓN PORTLET .................................................................. 26 4 GESTIÓN DEL PROYECTO ........................................................................ 29 4.1 METODOLOGÍA .................................................................................... 29 4.2 PLANIFICACIÓN ................................................................................... 31 4.3 ESFUERZO REAL DEDICADO ............................................................. 32 vi EINA Universidad de Zaragoza 5 CONCLUSIONES ........................................................................................ 35 5.1 CONCLUSIONES TÉCNICAS ............................................................... 35 5.2 CONCLUSIONES PERSONALES ......................................................... 36 5.3 TRABAJO FUTURO .............................................................................. 37 ANEXO A DOCUMENTO DE ANÁLISIS DE REQUISITOS .......................... 39 A.1 INTRODUCCIÓN ...................................................................................... 41 A.2 REQUISITOS ........................................................................................... 43 A.2.1 REQUISITOS FUNCIONALES ........................................................... 43 A.2.2 REQUISITOS NO FUNCIONALES ..................................................... 44 A.3 CAPTURA DE REQUISITOS .................................................................... 45 A.3.1 APLICACIÓN WEB ............................................................................. 45 A.3.2 APLICACIÓN PORTLET .................................................................... 47 ANEXO B DOCUMENTO DE DISEÑO DEL SISTEMA .................................. 49 B.1 INTRODUCCIÓN ...................................................................................... 51 B.1.1 OBJETIVOS Y ALCANCE DEL DOCUMENTO .................................. 51 B.2 DISEÑO DEL SISTEMA ........................................................................... 53 B.2.1 DESCOMPOSICIÓN DEL SISTEMA .................................................. 53 B.2.2 DESPLIEGUE DEL SISTEMA ............................................................ 54 B.2.3 DISEÑO BOTTOM-UP ....................................................................... 54 B.3 DISEÑO DE LA BASE DE DATOS ........................................................... 55 B.3.1 DISEÑO CONCEPTUAL .................................................................... 55 B.3.1.1 DESCRIPCIÓN DE LAS ENTIDADES .......................................... 56 B.3.2 DISEÑO LÓGICO ............................................................................... 60 B.3.2.1 DESCRIPCIÓN DE LAS RELACIONES ....................................... 60 B.4 ESTRUCTURA DE LOS DATOS .............................................................. 65 B.4.1 CLASES ............................................................................................. 66 B.4.2 DESCRIPCIÓN DE LAS ALARMAS ................................................... 67 B.4.2.1 ALARMAS DE TIPO TAREA ........................................................ 68 B.4.2.2 ALARMAS DE TIPO PARTICIPANTE .......................................... 69 B. 5 CAPA DE DATOS .................................................................................... 71 B.5.1 ESTEREOTIPO DAO ......................................................................... 71 B.6 CAPA DE NEGOCIO ................................................................................ 73 B.6.1 COMPONENTES ............................................................................... 73 PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” vii B.6.1.1 GESTIÓN DE LOS PROYECTOS ................................................ 74 B.6.1.2 GESTIÓN DE LOS USUARIOS .................................................... 77 B.6.1.3 GESTIÓN DE LAS DEDICACIONES ............................................ 78 B.6.1.4 GESTIÓN DE LAS ALARMAS ...................................................... 78 B.6.1.5 GENERACIÓN DE INFORMES ESTADÍSTICOS ......................... 79 B.6.1.6 GENERACIÓN DE INFORMES DE LA DEDICACIÓN ................. 80 B.6.2 COMPORTAMIENTO DE LAS ALARMAS.......................................... 83 B.6.2.1 CREACIÓN Y MODIFICACIÓN DE UNA ALARMA ...................... 83 B.6.2.2 COMPORTAMIENTO DE UNA ALARMA ..................................... 84 B.7 OTROS COMPONENTES ........................................................................ 87 B.7.1 CONFIGURACIÓN ............................................................................. 87 B.7.1.1 NIVEL 1: CONFIGURACIÓN BÁSICA .......................................... 88 B.7.1.2 NIVEL 2: CONFIGURACIÓN POR PROPIEDADES ..................... 88 B.7.2 GESTIÓN DE LOS LOGS .................................................................. 88 B.8 CAPA DE PRESENTACIÓN DE LA APLICACIÓN WEB ......................... 91 B.8.1 CABECERA ........................................................................................ 92 B.8.1.1 MENÚS DEL ADMINISTRADOR .................................................. 92 B.8.1.2 MENÚS PARA LOS GESTORES ................................................. 94 B.8.1.3 OTROS MENÚS ........................................................................... 96 B.8.2 PIE DE PÁGINA ................................................................................. 97 B.8.3 INTERFACES DEL ADMINISTRADOR .............................................. 97 B.8.3.1 GESTIÓN DEL SISTEMA ............................................................. 97 B.8.3.2 GESTIÓN DE LOS USUARIOS .................................................... 99 B.8.3.3 ESTADÍSTICAS DEL USO DEL SISTEMA ..................................105 B.8.4 INTERFACES PARA LOS GESTORES ............................................105 B.8.4.1 GESTIÓN DE LOS PROYECTOS ...............................................106 B.8.4.2 GESTIÓN DE LOS PARTICIPANTES .........................................110 B.8.4.3 GESTIÓN DE LAS ALARMAS DE UN PROYECTO ....................112 B.8.4.4 DEDICACIÓN AGREGADA .........................................................116 B.8.5 INTERFACES COMUNES .................................................................117 B.8.5.1 ENTRADA A LA APLICACIÓN WEB ...........................................117 B.8.5.2 INFORMACIÓN ...........................................................................117 B.8.5.3 GESTIÓN DEL PERFIL DEL USUARIO ......................................118 4 EINA Universidad de Zaragoza 2.2 ESPECIFICACIÓN DE REQUISITOS Este apartado detalla con mayor precisión los requisitos descritos en los objetivos generales (apartado 2.1). Los requisitos del sistema se han dividido en funcionales y no funcionales. Los primeros describen la funcionalidad y comportamiento del sistema. Los requisitos no funcionales definen otros aspectos como las tecnologías que se deben emplear o el nivel de seguridad que se debe alcanzar. 2.2.1 REQUISITOS FUNCIONALES Los requisitos para cada aplicación son: Requisitos desde el punto de vista de la aplicación Web 1. Dar de alta y baja a los usuarios del sistema. 2. Configurar el sistema. 3. Consultar estadísticas de utilización del sistema. 4. Configurar y modificar el perfil de un usuario del sistema. 5. Dar de alta un nuevo proyecto. 6. Establecer la lista de tareas asociadas a un proyecto. 7. Establecer que usuarios registrados en el sistema van a participar en un proyecto concreto. 8. Consultar el listado de proyectos de los cuales es responsable el usuario. 9. Consultar el esfuerzo dedicado en un proyecto aplicando criterios temporales. 10. Consultar el esfuerzo dedicado a cada tarea de un proyecto aplicando criterios temporales. 11. Consultar el esfuerzo que un participante ha dedicado a un proyecto aplicando criterios temporales, según tareas o combinando ambos criterios. 12. Generar informes en formato PDF relativos a la dedicación de un proyecto concreto. 13. Modificar, añadir o dar de baja a los participantes de un proyecto. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 5 14. Configurar alertas de dedicación máxima asociadas a una tarea o a un participante de un proyecto. 15. Detectar e informar al gestor del proyecto cuando se sobrepase el tiempo asignado a una alerta de la dedicación de un proyecto. Requisitos desde el punto de vista de la aplicación Portlet 1. Configurar y modificar el perfil del usuario. 2. Consultar los proyectos. 3. Consultar las tareas de un proyecto. 4. Introducir la dedicación diaria en una tarea de un proyecto. 5. Consultar la dedicación en un proyecto aplicando criterios temporales, según tareas o combinando ambos criterios. 6. Generar informes en formato PDF relativos a la dedicación en un proyecto concreto. 7. Informar al participante si sobrepasa, en algún momento, alguna de las alertas de dedicación máxima establecidas. 2.2.2 REQUISITOS NO FUNCIONALES Los siguientes requisitos describen los aspectos que no tienen que ver con la funcionalidad ni el comportamiento del sistema. 1. La parte del sistema de gestión de la dedicación que utilizarán los participantes en los proyectos será desarrollado con tecnología de Portlets. 2. La parte del sistema desarrollada con tecnología de Portlet deberá integrarse en una página Web con un esfuerzo mínimo. 3. El sistema dispondrá de un portal Web para que el administrador o el gestor de proyectos configure su actividad. 4. Al finalizar el PFC deberá estar operativo y poder ser utilizado por al menos el director del proyecto. 5. El acceso al sistema será seguro, por medio de un mecanismo de login y contraseña. 6 EINA Universidad de Zaragoza 6. El sistema deberá ser capaz de realizar copias de seguridad de manera periódica. 7. El sistema almacenará ficheros de "log" de la actividad del sistema. El formato del fichero deberá ser apropiado para futuros análisis de su contenido. 2.3 ANÁLISIS DE LAS TECNOLOGÍAS Este apartado pretende describir brevemente las tecnologías elegidas para el desarrollo y despliegue del PFC. 2.3.1 REQUISITOS TECNOLÓGICOS Para el desarrollo del PFC se han necesitado una serie de tecnologías que resolvieran las distintas necesidades planteadas por los requisitos. A continuación se describen los principales requisitos tecnológicos: 1. Plataforma que permita desarrollar aplicaciones con múltiples capas y componentes. Deberá coordinar las capas y los componentes, así como facilitar la configuración del sistema. 2. Tecnologías que den soporte al almacenamiento y al acceso a la información. Ambas aplicaciones requieren compartir un repositorio permanente de los datos del dominio del problema. Se requiere de un mecanismo que facilite la conexión entre el sistema de almacenamiento y los datos de la aplicación. 3. Tecnologías que permitan desarrollar interfaces Web para los usuarios y que se adapten fácilmente a los navegadores más utilizados. 4. Tecnología Web orientada a servicios que facilite la integración en portales. Deberá facilitar a los gestores la integración de la aplicación en sus portales. 5. Tecnologías que faciliten el despliegue del sistema. Para ello será necesario un servidor Web que permita alojar las aplicaciones. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 7 2.3.2 SELECCIÓN DE TECNOLOGÍAS A continuación se listan las tecnologías que se han seleccionado en función de los requisitos tecnológicos descritos en el apartado 2.3.1. Plataforma de desarrollo Se ha elegido Java Platform Enterprise Edition [7] (JEE) como la plataforma de desarrollo. JEE es una plataforma basada en un lenguaje orientado a objetos, con un amplio repositorio de librerías. Uno de los factores más relevantes para esta decisión es el soporte que facilita para la creación de Portlets [5] (uno de los requisitos del PFC). Dado el soporte que ofrece para la creación de Servlets parece más que conveniente que también se utilice para crear la aplicación Web. Spring [8] es el framework que ha sido elegido para dar soporte al sistema. Se trata de un enorme y completo marco de trabajo que facilita el desarrollo de aplicaciones Web, dando soporte a muchas otras tecnologías y modelos de proyectos. Los motivos para elegir a Spring pueden resumirse en tres: el framework favorece la adopción de buenas prácticas de programación, permite construir aplicaciones basadas en componentes con bajo acoplamiento entre sí, gracias al principio de inversión de control (IoC) y la inyección de dependencias [9]. Además, da soporte a un gran número de otras tecnologías (Hibernate [10], Log4j [11],…). El incentivo de aprender el uso de un nuevo framework con tanta difusión y soporte debería ser suficiente para añadirlo como el cuarto motivo para utilizarlo. Tecnologías de soporte para el almacenamiento de la información Como repositorio de la información del sistema se ha utilizado MySQL [12]. Esta decisión se ha tomado en función del SGBD [40] que se encontraba previsto para éste y otros proyectos. Aunque no se hubiese dado esta situación, MySQL hubiera sido la principal opción para este objetivo. Esta aplicación es un SGDB muy completo, se basa en el lenguaje de consulta estructurado (SQL) con un gran soporte por parte de los programadores y es gratuito. 8 EINA Universidad de Zaragoza Tecnologías de mapeo Objeto-Relacional (ORM) Considerando que la BD será relacional y que la plataforma utilizada está basada en objetos, se debe incluir una tecnología que permita convertir las tuplas en objetos y los objetos en tuplas. Dada la buena experiencia utilizando Hibernate Framework [10] para este propósito se ha optado por tomarlo como el ORM [13] más adecuado. Como en las asignaturas de la carrera se utilizó esta tecnología con XML, se planteó como reto utilizar anotaciones para el mapeo de las clases. Tecnologías Web Desde un punto de vista técnico, un Portlet [5] es una pequeña aplicación que permite, de forma modular, ser añadida a un portal Web. Los Portlets suelen estar orientados a mostrar información a diferencia que otras aplicaciones Web. Se ha optado por tomar la última versión Portlet 2.0 [5] (JSR 286 [14]) por ser más completa que su predecesora (JSR 168 [15]). Aunque la decisión de utilizar un Portlet ha venido dada por los requisitos del PFC, se puede decir que la decisión de emprender este proyecto se debe al ímpetu de querer aprender esta tecnología. Durante la fase previa al desarrollo se realizó un pequeño estudio de la misma. Para el despliegue del Portlet es necesaria una aplicación que lo contenga. Se eligió Open Portal Portlet Container [16] como la mejor opción para este fin. Soporta numerosos contenedores Web como Tomcat [17], JBoss [18], Jetty [19], Oracle WebLogic [20] y GlassFish [21]. Para el despliegue de la aplicación Web se seleccionó Apache Tomcat [17], que es un contenedor de aplicaciones Web (Servlets [22] [23]) ligero y fácil de utilizar, que se adapta a las necesidades del PFC. Tecnologías de desarrollo de interfaces Web Para el desarrollo de la capa de presentación se decidió utilizar Java Server Pages [24] (JSP) como la solución más sencilla y completa. Permite la creación de HTML de forma dinámica con el código Java incrustado dentro del código de marcado. Junto con JSP se ha utilizado la tecnología de etiquetas que ofrece Java. Esta tecnología permite crear etiquetas que se pueden añadir dentro del HTML y que se implementan con código Java, facilitando crear código sin emborronar el código HTML. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 9 Para la comunicación asíncrona entre los servidores y los usuarios se ha empleado la tecnología Asynchronous JavaScript And XML (AJAX) [25]. Para ello se ha incorporado la librería Prototype Framework [26]. Este marco de trabajo facilita la adaptación del código de script a los diferentes navegadores (problema de no adaptarse al estándar). Tabla 2.1 Herramientas y tecnologías CATEGORÍA SOFTWARE/TECNOLOGÍA Soporte al análisis y diseño del sistema Edge Diagrammer 4.16 [27] Argo UML 0.32 [28] Tecnologías de desarrollo General JEE 6 [7] Apache Commons [29] iText [30] Log4j [11] XML Lógica de negocio y control Spring Framework 3 [8] Datos y mapeo Objeto-Relacional Hibernate Framework 3 [10] Java Validation API C3P0 Presentación HTML [31] CSS [31] AJAX [25] Prototype 1.7 [26] JSP [24] Pruebas JUnit 4 [32] Software de desarrollo JDK 6u24a [33] NetBeans 6.9.1 [34] Despliegue Apache Tomcat 6 [17] Open Portal Portlet Container 2 [16] Firefox 22.0 [35] Internet Explorer 7 [36] Almacenamiento y datos de prueba MySQL 5 [12] MySQL Workbench 5.2 [37] PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 11 3 DISEÑO DEL SISTEMA En este capítulo se presenta el diseño del sistema. El primer apartado muestra el contexto del proyecto. En el apartado 3.2 se describe la arquitectura empleada en el sistema, incluyendo la división del problema y la distribución de cada una de las partes. Los últimos tres apartados (3.3, 3.4 y 3.5) se dedican a la descripción de cada una de las partes en que se ha dividido el sistema e incluye una secuencia del funcionamiento de una de sus operaciones. 3.1 CONTEXTO DEL SISTEMA Como se observa en la Figura 3.1, el sistema está compuesto por una aplicación Web y una aplicación Portlet. Los usuarios podrán consultar los proyectos en los que participan e introducir su dedicación diaria a través de los distintos portales Web que hayan incorporado la aplicación Portlet entre sus contenidos. El administrador del sistema y los usuarios de tipo gestor compartirán la aplicación Web que les permitirá la gestión del sistema y de los proyectos respectivamente. Ambas aplicaciones compartirán una base de datos, que les permitirá almacenar y recuperar la información del sistema. Figura 3.1 Contexto general del sistema 12 EINA Universidad de Zaragoza 3.2 ARQUITECTURA DEL SISTEMA La arquitectura del sistema se basa en un diseño multicapa [38]. Los diseños multicapa son muy utilizados en las aplicaciones de gestión ya que permiten separar claramente las tres funciones principales presentes en la mayor parte de este tipo de aplicaciones: tratamiento de los datos persistentes, lógica de negocio e interfaz del usuario. Esto permite reducir las dependencias entre capas facilitando el mantenimiento del sistema, dado que los cambios en una parte del mismo sólo afectarán a la capa concreta, sin necesidad de tener que modificar el resto de capas. El sistema diseñado consta de tres capas que se pueden ver en la Figura 3.2. Estas capas se corresponden con las tres funcionalidades descritas en el párrafo anterior. Cada capa se construye en términos de la capa inmediatamente inferior. Este modelo se corresponde con el patrón MVC [38] [39], donde el modelo viene dado por la capa de datos, el control por la capa de negocio y la vista por la capa de presentación. Este patrón facilita la división entre capas, encapsulando su comportamiento a través de una interfaz y permite definir la interacción entre ellas. Figura 3.2 Descomposición del sistema La capa de datos está formada por un componente, el “Data Access Object” (DAO), que se encargará de todas las operaciones relacionadas con la BD, incluido el mapeo Objeto-Relacional entre la BD y los datos de la aplicación. La capa de negocio está formada por varios componentes, cada uno de ellos asume una parte de las funciones del sistema. Los principales objetivos que se han pretendido alcanzar con esta capa son los siguientes: PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 13 1. Abstraer a la capa de presentación de las operaciones con los datos. 2. Proveer métodos que encapsulen las funciones con cierto grado de complejidad (funciones compuestas de varias operaciones). 3. Facilitar un medio transaccional que atomice las operaciones. 4. Comprobar que el usuario tiene permiso para realizar una operación sobre ciertos datos. 5. Comprobar que los datos son válidos antes de guardarlos. La capa de presentación encapsula todos los componentes de la interfaz de usuario: las pantallas de cada aplicación y la lógica para el tratamiento de todos los eventos que pueda generar el usuario en cada pantalla. Las capas de datos y de negocio son compartidas por ambas aplicaciones (Web y Portlet). El diseño de la capa de presentación será distinto para cada aplicación, dado que las interfaces de cada una, sus pantallas y eventos no son iguales para ambas. En el diagrama de la Figura 3.2 se puede ver que la capa de presentación no tiene acceso directo a la capa de datos, teniendo que interactuar con la capa de negocio para obtenerlos. También hay que aclarar que la capa de negocio depende de la capa de presentación para lanzar sus operaciones, es esta última la que tiene que lanzar peticiones a la primera para que se actualice la interfaz, esto se debe al contexto Web en el que se desarrollan las aplicaciones. Las capas interactúan de arriba hacia abajo, siendo la capa de presentación la que inicia los procesos y se comunica con la capa de negocio enviándole peticiones. A su vez la capa de negocio se comunica con la capa de datos para acceder a la información almacenada en el repositorio. 3.2.1 DESPLIEGUE DEL SISTEMA En la Figura 3.3 se puede observar el diagrama de despliegue a nivel de software. Cada nodo, representado por una caja tridimensional, se corresponde con un elemento software. La caja central representa el contenedor Web que almacenará las aplicaciones descritas en los apartados anteriores. El Contenedor Web alojará la aplicación Web y el contenedor de Portlets (“Open Portal”, véase el apartado “2.3 Requisitos tecnológicos”). El contenedor de Portlets alojará a la aplicación Portlet. De esta forma las dos aplicaciones que componen el sistema se ejecutarán en aplicaciones distintas, pero podrán compartir los ficheros de configuración. La caja de la derecha representa el Sistema de Gestión de Bases de Datos (SGBD [40]) que gestionará la BD que almacenará los datos de la aplicación. El sistema está preparado para que 20 EINA Universidad de Zaragoza Figura 3.6 Diagrama de secuencia del método “actualizarAlarmas” La capa de presentación siempre se encarga de iniciar los procesos del sistema. En este ejemplo le envía un mensaje a “Gestión Alarmas” de la capa de negocio (INI). Internamente, el objeto “ActualizaciónAlarmas” se encarga de gestionar la petición recibida por la interfaz del componente (por motivos de representación, la flecha apunta directamente sobre el objeto, en vez del componente). El proceso se realiza en dos fases divididas en tres pasos cada una. La primera fase pretende actualizar la alarma que controla toda la dedicación de la tarea en la que el participante añadió su dedicación. La segunda fase se dedica a actualizar las alarmas que tienen una duración limitada a un mes o una semana. La primera fase se divide en tres pasos (A, B y C). Primero se realiza la búsqueda de los datos de la tarea, para ello se envía un mensaje al componente “Gestión Proyectos” (A1) que tiene los mecanismos para llevarla a cabo, éste prepara la búsqueda y delega en la capa de datos para acceder al repositorio (A2). Una vez se haya recuperado la información se envía hacia atrás (flecha discontinua). Después de comprobar que la alarma se encuentra activada (en cualquier otro caso se saltarían los pasos siguientes), se le pide al componente “Gestión Dedicación” que calcule el número total de horas empleadas en la tarea (B1), entonces el componente delega en la capa de datos (B2) y el valor es devuelto sucesivamente hasta el principio. En ese momento se puede comparar el valor máximo asignado a la tarea con el PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 21 número de horas reales que se han empleado. Entonces, si es necesario, se modifica el estado de la alarma y se procede a guardarla (C), para ello se inicia una secuencia parecida a la de la búsqueda (C1 y C2). La segunda fase también se divide en tres pasos (U, V, W) con funciones parecidas a las anteriores. Primero se le pide al objeto “Alarmas Participantes” (de forma interna al componente) la lista de alarmas semanales y mensuales que se encuentren activadas (U1), entonces utilizará la capa de datos para este fin (U2), este paso solo se realizará una vez. A continuación los pasos V y W se repetirán para cada alarma que se haya devuelto en el paso anterior. El paso V calculará la dedicación realizada en la tarea durante el periodo de tiempo indicado por la alarma enviando un mensaje al componente “Gestión Dedicación” (V1), que como anteriormente) se comunicará con la capa de datos (V2). En caso de que no se modifique el estado de la alarma se seguirá con la siguiente, por el contrario se pasará al paso W que le pedirá al objeto “Alarmas Participante” (W1) que guarde el nuevo estado, entonces se comunicará con la capa de datos (W2). Los pasos V y W se repetirán para cada alarma que se haya encontrado en el paso U. En resumen, las distintas partes que conforman el sistema dependen entre ellas para la realización de sus tareas. La capa de presentación utiliza a la capa de negocio (INI) y ésta utiliza a la capa de datos (A2, B2,…, W2). Dentro de la capa de negocio, cada componente está especializado en un conjunto de tareas, para desempeñarlas necesitan de otras tareas que no son capaces de realizar y para ello envían mensajes a los componentes que se han especializado en ellas (A1, B1,…, W1). Todos los componentes acaban comunicándose con la capa de datos (A2, B2,…, W2) que se encarga de conectar con el repositorio de los datos. 3.5 CAPA DE PRESENTACIÓN La capa de presentación ofrece la interfaz gráfica de usuario (GUI). Captura los eventos que produce el usuario (pulsar un botón, desplegar una lista de selección,...), realiza un pequeño filtrado de los datos introducidos y envía un mensaje a la capa de negocio para que realice las operaciones oportunas. Cuando la capa de negocio termina sus tareas y le da una respuesta, entonces se genera la nueva interfaz con los parámetros indicados por la capa de negocio. El funcionamiento de esta capa viene dado por la página en la que se encuentra el usuario, los eventos que éste genera y por el control de la capa de negocio que se encarga de indicarle que debe mostrar y de restringir que se puede hacer en cada página. La capa ha sido dividida en dos partes, una para la aplicación Web y otra para el Portlet. La primera 22 EINA Universidad de Zaragoza permite el acceso a los gestores y al administrador y la segunda facilita la gestión de la dedicación de los participantes en los proyectos. La capa de presentación genera dinámicamente las páginas que los usuarios pueden ver. Ambas aplicaciones codifican las páginas en Unicode, permitiendo un amplio abanico de caracteres, y pueden dar soporte a múltiples idiomas. El administrador puede configurar distintos parámetros que modifican las páginas, como el número de entradas que se muestran en una tabla o los valores por defecto que filtran las búsquedas. También puede configurar, para cada tipo de usuario, el tema que define el aspecto de las páginas, incluyendo las imágenes utilizadas y las hojas de estilo. Los usuarios podrán configurar sus datos personales, incluyendo el idioma con el que desean que se muestren las páginas. 3.5.1 APLICACIÓN WEB Los usuarios de tipo “Gestor” y el administrador del sistema podrán utilizar un navegador para visualizar la página de acceso de la aplicación Web, en ella podrán acceder a las demás páginas identificándose con su login y contraseña. Cada tipo de usuario dispone de sus propias páginas Web, especializadas en las funciones que debe desarrollar. En ambos casos la estructura de las páginas se compone de una cabecera y de un pie de página, entre los dos se encuentra el contenido de la sección. La cabecera contiene tres menús y un botón para ver la ayuda. Los menús se configuran en función del tipo de usuario y la sección en la que se encuentre. La Figura 3.7 muestra la imagen de un navegador Web con una página que contiene la información de un proyecto gestionado por un usuario. La parte superior de la página muestra la cabecera, arriba a la izquierda se muestra el nombre de la aplicación y a la derecha el login del usuario con el menú auxiliar, que contiene tres botones para ver la información de contacto, modificar la información del perfil del usuario y poder salir de la aplicación. Un poco más abajo se ven dos filas de pestañas, la fila superior (algo mayor) es el menú principal que permite acceder a las distintas secciones de la aplicación. Las pestañas que se encuentran debajo son el menú secundario, que contiene enlaces para ir a las distintas páginas donde el usuario puede realizar ciertas operaciones sobre el proyecto mostrado, como son añadir nuevas tareas y/o participantes o ver el listado de participantes del proyecto. El menú principal se personaliza para cada tipo de usuario y nunca se modifica. Por el contrario, el menú secundario se adaptará a la sección en la que se encuentre el usuario. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 23 En la Figura 3.8 se puede observar que el menú secundario se encuentra vacío, debido a que el listado de proyectos no requiere de ninguna opción. Por último las cabeceras disponen de un botón para acceder a la ayuda, el usuario puede consultarla en cualquier momento y moverse por las distintas páginas que ofrece y pulsar el botón para volver sin perder la información que previamente hubiera introducido en los formularios de la página en que se encontrase. La opción de emplear una cabecera para albergar los menús frente a la alternativa de un menú lateral le ofrece mayor espacio al resto del contenido de la página, facilita la utilización de pestañas que permiten mostrar todas las opciones de un menú sin que se salgan de la ventana, son bastante estéticas, se emplean en muchos sitios Web y son muy fáciles de utilizar por parte de los usuarios. Debajo de la cabecera se encuentra el contenido de la página. En la Figura 3.7 se puede ver la información del proyecto “1002” llamado “Analizador Léxico”, debajo se dispone de botones para realizar operaciones como cerrar o reabrir el proyecto, seguido de su lista de tareas, la cual se extiende fuera de la parte visible de la ventana. El contenido de la página de la Figura 3.8 muestra el listado de los proyectos que gestiona el usuario donde puede ir avanzando y retrocediendo en la lista utilizando los botones marcados con los símbolos “<<” y “>>”, también puede modificar los parámetros de la lista con el formulario dispuesto a tal fin. Cada entrada de la lista dispone de un enlace que lleva a la sección que muestra la información del proyecto (ver Figura 3.7) y botones para realizar distintas operaciones con los proyectos. Otras páginas de la aplicación Web contienen formularios para introducir datos en el sistema o configurar informes. Figura 3.7 Interfaz “Información de un proyecto” 24 EINA Universidad de Zaragoza En la parte inferior de la página de la Figura 3.8 se encuentra el pie de página donde el administrador, mediante la configuración del sistema, puede mostrar una dirección de correo que permita a los usuarios reportarle problemas en el sistema. Figura 3.8 Interfaz “Listado de los proyectos gestionados” Figura 3.9 Mapa Web de los gestores PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 25 Las Figuras 3.9 y 3.10 muestran los mapas Web de las distintas páginas de los gestores y el administrador del sistema respectivamente. Desde el nodo inicial (en color verde) los usuarios pueden utilizar sus menús principales para acceder a una de las páginas, una vez en ella se puede utilizar un enlace o las pestañas del menú secundario para seguir navegando. Por ejemplo, un gestor puede editar una tarea entrando en “Proyectos” con el menú principal, seleccionar el proyecto en la lista accediendo a “Info Proyecto” y pulsar el botón de edición para acabar en “Editar tarea”. De igual manera, el administrador puede utilizar la pestaña del menú para acceder a “Lista usuarios” y, utilizando el menú secundario, acceder a “Nuevo Grupo” y rellenar el formulario para crear un nuevo grupo de usuarios. Figura 3.10 Mapa Web del administrador 26 EINA Universidad de Zaragoza 3.5.2 APLICACIÓN PORTLET La aplicación Portlet permite gestionar la dedicación de los participantes en los proyectos, esto incluye, sin ningún tipo de diferencia, a los usuarios de tipo gestor y de tipo normal. Los Portlets van dentro de otras páginas Web (portales), por ello el espacio que disponen suele ser algo menor. Para reducir el tamaño de la cabecera se ha creado una sección “Menú” (ver Figura 3.11) que incluye un menú principal que facilita el acceso a las demás secciones. La aplicación Portlet también incluye un sistema de ayuda integrada, similar al de la aplicación Web, que podrá ser consultado por los usuarios a través del botón azul con un interrogante. Figura 3.11 Menú principal En la Figura 3.12 se ve el mapa Web del Portlet. Se puede observar que, como ya se ha dicho, se accede a todas las secciones a través de “Menú”. Por ejemplo, un usuario puede ir a la lista de proyectos (“Mis proyectos”), seleccionar uno de ellos (“Proyecto”) y entrar a la página donde puede introducir su dedicación diaria (“Mi dedicación”). PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 27 Figura 3.12 Mapa Web del Portlet Las Figuras 3.13 y 3.14 muestran dos ejemplos de GUI del Portlet. La cabecera de cada página contiene un botón para ver la ayuda y otro para salir de la aplicación y de una línea con la ruta de navegación que ha seguido el usuario, que le informa donde se encuentra y que puede utilizar para regresar a las secciones superiores. Por ejemplo, en la Figura 3.14 la ruta es “Menú/Mis Proyectos/Dedicación/”. El contenido de la página de la Figura 3.13 muestra la lista de proyectos en los que participa el usuario. La Figura 3.14 muestra la lista de tareas de un proyecto y permite al usuario introducir su dedicación diaria, se puede seleccionar un día, ver la dedicación total del día, del usuario, de las tareas, etc. 28 EINA Universidad de Zaragoza Figura 3.13 Interfaz “Listado de las participaciones” Figura 3.14 Interfaz “Introducción de la dedicación diaria” PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 29 4 GESTIÓN DEL PROYECTO Este capítulo describe el proceso seguido para la gestión del PFC. El apartado 4.1 explica la metodología empleada para su desarrollo. En el apartado 4.2 se expone la planificación realizada en las primeras etapas del desarrollo. Por último, el capítulo 4.3 muestra el esfuerzo real realizado, comparando los tiempos empleados con los estimados y justificando sus diferencias. 4.1 METODOLOGÍA Para la realización de este PFC, se ha seguido una metodología de desarrollo iterativo e incremental [42]. En este proceso, el desarrollo del software se divide en una serie de iteraciones, cada una de ellas cumple con unos objetivos definidos. Cada iteración incrementa la funcionalidad del sistema o, visto de otra manera, cubre algunos de los requisitos especificados para el PFC. Desde las primeras etapas del proceso el cliente puede ver su aplicación con la mínima funcionalidad y en cada iteración puede comprobar cómo va creciendo. Como paso previo al desarrollo del PFC se realizó un proceso de formación y selección de tecnologías y herramientas. Principalmente se centró en la tecnología de Portlets. El proceso terminó con una presentación ante el director del PFC sobre los Portlets. Tras el proceso de formación y de búsqueda de tecnologías, se comenzó con las fases de análisis y diseño del sistema. Primero se realizó el análisis que permitió definir los requisitos funcionales y no funcionales del problema. Posteriormente se realizó el diseño en alto nivel de la solución. Se incluyó la arquitectura del sistema, el modelo de los datos, los componentes con sus interfaces y se modeló la interfaz gráfica de los usuarios. En la fase de diseño se tomó la decisión de dividir el desarrollo en ocho iteraciones, planificando el orden que llevaría su inicio y fin. Cada iteración fue realizada en un modelo en cascada en cuatro fases. Primero se refinaba el análisis y el diseño de la parte que se acometía, definiendo de forma más precisa sus requisitos y detallando con más precisión los componentes, luego se acometía la implementación de las funcionalidades requeridas y, por último, se realizaba un juego de pruebas unitarias y de integración. Durante este proceso se fue realizando parte de la documentación, que finalmente se juntó en tres documentos que se han añadido en los anexos de la memoria. Estos 36 EINA Universidad de Zaragoza tienen que ver con la Web y los servidores de aplicaciones Jonas [44] y JBoss [18]. A nivel de diseño y de desarrollo se han podido consolidar conocimientos de UML, diseño Web, diseño de base de datos y los conocimientos aprendidos en distintas asignaturas como “Ingeniería del Software”, “Proyectos”, “Bases de Datos”, “Sistemas Informáticos”,... Otro aspecto positivo sería el grado de conocimiento que se ha alcanzado con los servidores y las herramientas asociadas a éstos, por ejemplo Tomcat, Open Portal y MySQL. Los aspectos más negativos se pueden dividir en dos partes. Todas las tecnologías, frameworks y herramientas citadas anteriormente disponen de su propia documentación, pero en la mayoría de los casos es demasiado larga, poco concisa, repetitiva y los ejemplos disponibles suelen ser demasiado superficiales. Esto y el grado de complejidad al que han llegado algunas de ellas hacen que aprenderlas sea un proceso largo, que obliga a realizar un gran esfuerzo a los ingenieros. Por otra parte, se encontrarían las herramientas de desarrollo e implementación. Dada la discapacidad visual del autor, la elección de utilizar NetBeans como IDE de desarrollo fue una decisión inadecuada. NetBeans es una aplicación que no cumple con las normas de accesibilidad, esto ha repercutido en el tiempo de desarrollo. El autor reconoce que hubiera sido mucho mejor la utilización del IDE Eclipse [45], que como se descubrió demasiado tarde, sí era accesible, pero que se descartó por motivos técnicos y personales. También se quiere hacer notar la inestabilidad de otras herramientas utilizadas como son Open Portal y Argo UML. En el caso de Open Portal se ha experimentado un alto grado de auto-bloqueo y en el caso de Argo UML se ha padecido una alta corrupción en los esquemas que ha obligado a modificarlos de manera repetitiva. 5.2 CONCLUSIONES PERSONALES Independientemente de los problemas técnicos descritos anteriormente y del sobrecoste de tiempo empleado para la realización del trabajo, el autor del PFC considera que el aprendizaje de nuevas tecnologías y la posibilidad de haber realizado un proyecto de cierta envergadura le han permitido madurar como ingeniero y persona. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 37 El autor ha podido aprender y mejorar en ciertas tecnologías que por distintos motivos no se pueden abordar de forma tan intensa en la carrera. Las asignaturas relacionadas con diseño, bases de datos, sistemas de la información y algunas otras, muestran una amplia variedad de conocimientos, pero de una manera superficial. Las prácticas que se realizan en las asignaturas, por motivos evidentes, no se pueden comparar a la realización de un proyecto real. Por estos motivos, el proyectando considera que la realización de este PFC le ha sido de gran utilidad en diversos aspectos y le ha permitido darse cuenta de los puntos más débiles de su formación. Entre estos puntos se pueden destacar la falta de formación en distintas tecnologías y la necesidad de introducirse en ellas. También la necesidad de buscar buenas herramientas de desarrollo que le faciliten el trabajo, en este apartado queda todavía muchas cosas pendientes. En conclusión, el autor, tras haber cursado la carrera, haber realizado prácticas en una empresa (ajena al proyecto) y haber realizado este PFC, cree encontrarse en una posición que le permita desarrollar su carrera profesional de forma adecuada. 5.3 TRABAJO FUTURO Considerando que se trata de un proyecto que acaba de nacer es difícil saber cuáles serán las necesidades que los usuarios de la misma reclamarán en un futuro cercano y/o lejano. El PFC ha cubierto todas las necesidades especificadas por el cliente. Aun así sería posible mejorar en algunos aspectos que afectan a la funcionalidad del sistema. A nivel de los usuarios se pueden considerar las siguientes mejoras: Sería necesario, tras cierto tiempo de funcionamiento, ampliar las posibilidades que ofrecen los informes de la dedicación, en base a las propuestas que realicen los usuarios. En estos momentos la única forma que tienen los usuarios de saber que han sido dados de baja o alta en un proyecto es accediendo a la aplicación. Sería muy interesante para ellos la realización de un sistema que les notificara estos sucesos mediante el envío de un correo electrónico. 38 EINA Universidad de Zaragoza Igualmente sería interesante que los usuarios recibieran notificaciones vía correo electrónico cuando se sobrepase el límite de tiempo dedicado a una tarea de un proyecto. En este caso y el anterior sería conveniente que se pudiera configurar este comportamiento de forma personalizada, utilizando cada usuario su propia configuración. Sería muy interesante adaptar las interfaces a otros medios como tabletas y móviles. En este momento la aplicación se encuentra dirigida hacia los navegadores Web de los ordenadores personales. Debería permitirse a los usuarios de la aplicación Web poder mantener la configuración de la presentación de cada sección (valores de búsqueda, número de elementos mostrados,…). En estos momentos, esta configuración solo se mantiene durante el tiempo que permanece conectado a la aplicación. Respecto de la gestión de la aplicación se pensaron varias mejoras durante su desarrollo, pero algunas de ellas se quedaron como posibles ampliaciones del PFC. La introducción de nuevos usuarios en el sistema se realiza de uno en uno. Sería más que recomendable permitir al administrador introducir una lista de nuevos miembros. Este proceso podría realizarse tanto manualmente como a través de un fichero. También se podría permitir que los gestores pudieran introducir nuevos usuarios, con objeto de que el administrador confirmase su aceptación. La introducción de un nuevo miembro obliga al administrador a informar a la persona de su nueva condición de usuario. Sería recomendable automatizar este proceso mediante un sistema de notificación por correo electrónico. Igualmente se podría enviar un aviso cuando se da de baja o alta a un usuario. El acceso y modificación de la configuración del sistema se realiza modificando el texto de los ficheros de propiedades (mediante la aplicación Web). Se podría facilitar esta operación cambiando la interfaz para que se mostrara un formulario con las opciones y los valores permitidos. La generación de informes del sistema se ha realizado de forma global, podría ser recomendable que se facilitara una manera de limitar el alcance temporal de los valores, permitiendo fijar unas fechas que acotaran los datos utilizados. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 39 ANEXO A DOCUMENTO DE ANÁLISIS DE REQUISITOS PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 41 A.1 INTRODUCCIÓN El Documento de Análisis de Requisitos (DAR) contiene todos los requisitos que se han definido durante el análisis previo al diseño del proyecto. Para capturar los requisitos se han definido casos de uso derivados de los objetivos planteados en función de las necesidades del cliente. En el capítulo A.2 se muestran las tablas donde se listan los requisitos del sistema. Los requisitos se han clasificado, estructurado y numerado para poder ser referenciados en los demás documentos del proyecto. Cada requisito tiene un nombre que lo identifica unívocamente (basado en su clasificación y orden). Tabla A.1.1 Notación de los requisitos Notación Significado RFx Requisito funcional x. RNFx Requisito no funcional x. RSx Requisitos del sistema x. En el capítulo A.3 se muestran dos figuras con los diagramas de casos de uso que han permitido capturar los requisitos del capítulo A.2. Para cada caso de uso se definen los requisitos capturados y se describe brevemente la funcionalidad que representan. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 43 A.2 REQUISITOS A.2.1 REQUISITOS FUNCIONALES Tabla A.2.1 Requisitos funcionales # Requisito RF1 El sistema tendrá tres tipos de usuarios: el administrador general del sistema, los gestores de proyectos y los participantes en proyectos. A Requisitos punto de vista del administrador RF2 El administrador dará de alta y baja en el sistema a los gestores de proyectos y a los participantes. RF3 El administrador será el responsable de la configuración general del sistema (sistema de logs, copias de seguridad, etc.). RF4 El administrador podrá consultar estadísticas de utilización del sistema: número de proyectos gestionados, número de gestores y participantes, asignación de gestores y participantes a proyectos, etc. B Requisitos punto de vista del gestor de proyectos RF5 Un gestor de proyectos podrá configurar y modificar su perfil de usuario del sistema. RF6 Un gestor de proyectos podrá dar de alta un nuevo proyecto. RF7 Dado un nuevo proyecto, un gestor podrá establecer la lista de tareas asociada al mismo (por ejemplo, formación previa, análisis, diseño, implementación, etc.). RF8 Un gestor de proyectos podrá establecer qué participantes registrados en el sistema van a participar en un proyecto concreto. RF9 Un gestor de proyectos podrá consultar el listado de proyectos de los cuales es responsable. RF10 Dado un proyecto, el gestor podrá consultar el esfuerzo dedicado aplicando criterios temporales (en total, por meses o entre dos fechas concretas). RF11 Dado un proyecto, el gestor podrá consultar el esfuerzo dedicado a cada tarea aplicando criterios temporales (total, meses o entre dos fechas). RF12 Dado un proyecto, el gestor podrá consultar el esfuerzo que un participante ha dedicado al mismo aplicando criterios temporales (total, meses o entre dos fechas), según tareas o combinando ambos criterios. RF13 A partir de las posibles consultas, el sistema podrá generar informes en formato PDF relativos a un proyecto concreto. RF14 El gestor podrá modificar (añadir nuevo o dar de baja uno ya existente) los participantes de un proyecto. RF15 Un gestor de proyecto podrá configurar alertas de dedicación máxima, por ejemplo, a nivel de tarea de un proyecto, a nivel de tarea/mes, a nivel de tarea/participante o a nivel tarea (participante/mes). 44 EINA Universidad de Zaragoza RF16 El sistema deberá ser capaz de detectar cuando una dedicación máxima previamente configurada es excedida e informar de ello al gestor del correspondiente proyecto. C Requisitos punto de vista del participante en un proyecto RF17 Un participante podrá configurar y modificar su perfil de usuario del sistema. RF18 Un participante podrá consultar los proyectos en los que está participando o en los que participó. RF19 Dado un proyecto en el que participa, un participante podrá consultar las tareas en las que trabaja. RF20 Dado un proyecto en el que participa, un participante podrá introducir para una tarea su dedicación diaria (en número de horas o fracciones). RF21 Un participante podrá consultar su dedicación en un proyecto aplicando criterios temporales (total, por meses o entre dos fechas), según tareas o combinando ambos criterios. RF22 A partir de las posibles consultas, el sistema podrá generar informes en formato PDF relativos a un participante concreto. RF23 Un participante será informado si sobrepasa en algún momento alguna de las alertas de dedicación máxima establecidas. A.2.2 REQUISITOS NO FUNCIONALES Tabla A.2.2 Requisitos no funcionales # Requisito RNF1 El sistema de gestión de la dedicación será desarrollado con tecnología de Portlets. RNF2 El sistema deberá integrarse en la página Web de un participante cualquiera con un esfuerzo mínimo. RNF3 El sistema dispondrá de un portal Web para que el administrador o el gestor de proyectos configuren su actividad. RNF4 El sistema deberá estar instalado y operativo en un servidor que favorezca el uso por parte de una amplia comunidad de usuarios en un futuro. RNF5 Al finalizar el proyecto deberá estar operativo y siendo utilizado por al menos el director del proyecto. Tabla A.2.3 Requisitos de seguridad # Requisito RS1 El acceso al sistema será seguro, por medio de un mecanismo de clave y palabra clave. RS2 El sistema deberá ser capaz de realizar copias de seguridad de manera periódica. RS3 El sistema almacenará ficheros de "log" de la actividad del sistema. El formato del fichero deberá ser apropiado para futuros análisis de su contenido. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 45 A.3 CAPTURA DE REQUISITOS En este capítulo se describen los casos de uso que han permitido capturar los requisitos funcionales del sistema. Cada caso de uso encierra un conjunto de funcionalidades del sistema que podrían derivar en nuevos casos de uso, pero, por motivos de simplificación, se ha preferido utilizar casos de uso más generales que abarquen las principales partes que se esperan de la aplicación. Los distintos casos de uso han sido creados en función del contexto del sistema y de los objetivos definidos en función de las necesidades especificadas por el cliente. El sistema se relacionará con tres tipos de actores “Admin”, “Gestor” y “Participante”, requisito capturado en el RF1. El sistema se dividirá en dos partes (requisitos RNF3 y RNF1), los actores “Admin” y “Gestor” harán uso de la aplicación Web y el actor “Participante” se relacionará con la aplicación Portlet. En los siguientes apartados del capítulo se muestra como se han capturado los requisitos funcionales en cada aplicación. Cada caso de uso dispondrá de un nombre abreviado “CUxx”, donde xx serán dos valores numéricos, que permitirán referenciarlos en la documentación. A.3.1 APLICACIÓN WEB En la Figura A.3.1 se puede ver el diagrama que define los casos de uso que han permitido capturar los requisitos de RF2 a RF16. El diagrama muestra dos actores “Gestor” y “Admin”, representados por la figura de un señor, que se unen mediante líneas con los casos de uso con los que se relacionan, representados por óvalos amarillos. El actor “Gestor” se relaciona con cuatro casos de uso. El caso de uso “Gestión Proyectos” (CU01) permite capturar los requisitos RF6, RF7, RF8, RF9 y RF14, facilitando la gestión de los proyectos, las tareas y los participantes. El caso de uso “Gestión Alarmas” (CU02) permite capturar los requisitos RF15 y RF16, facilitando la configuración de las alarmas de la dedicación y permitiendo comprobar cuando se ha superado el límite establecido por la alarma. Los requisitos RF10, RF11, RF12 y RF13 han sido capturados a partir del caso de uso “Informes Dedicación” (CU03) que permitirá crear informes del esfuerzo realizado por los participantes en los proyectos. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 53 B.2 DISEÑO DEL SISTEMA El diseño del sistema se basa en una arquitectura cliente-servidor. Se ha dispuesto un servidor Web para los gestores y el administrador y un servidor de tipo Portlet para los participantes en los proyectos. Los distintos clientes pueden hacer uso de sus navegadores Web para comunicarse con ambos servidores y acceder a las aplicaciones. B.2.1 DESCOMPOSICIÓN DEL SISTEMA La arquitectura se basa en un sistema multicapa. El sistema se ha dividido en tres capas, cada una con un objetivo concreto. Su diseño se ha realizado de manera que las funciones de una capa ofrecen servicio a la capa inmediatamente superior. Cada capa cumple con una necesidad del sistema, evitando la solapación y duplicación de funcionalidades. Se facilita la abstracción entre capas a través de APIs que permiten comunicarse entre ellas. De esta manera, se permite un mejor desarrollo y mantenimiento del software, haciendo más fácil la modificación del contenido interno de las capas sin afectar a las demás. La capa de presentación facilita las GUIs que permiten a los usuarios comunicarse con la aplicación, las interfaces se basan en páginas Web con contenido dinámico en el lado del cliente. La capa de negocio se encarga de las distintas funciones que ofrece el sistema, dando servicio a la capa de presentación. La capa de datos ofrece el acceso al repositorio de la información del sistema (una base de datos) de forma transparente al medio de almacenamiento. El diseño de las capas se detalla en los capítulos B.5, B.6, B.8 y B.9 de este documento: Figura B.2.1 Secuencia de una petición 54 EINA Universidad de Zaragoza La Figura B.2.1 muestra una secuencia de una petición de un cliente a una de las aplicaciones. Toda petición comienza en la capa de presentación (GUI) enviando un mensaje a la capa de negocio, la capa de negocio envía uno o más mensajes a la capa de datos para acceder al repositorio. Tras realizar sus funciones, la capa de datos responde a la petición devolviendo los datos pedidos. Entonces, la capa de negocio se encarga de darle una respuesta a la capa de presentación. B.2.2 DESPLIEGUE DEL SISTEMA El sistema dispone de dos niveles, el cliente y el servidor. Las capas de negocio y de datos se quedan en el nivel del servidor, los componentes que forman ambas capas son compartidos por las dos aplicaciones que forman el sistema. La capa de presentación se distribuye en el nivel del servidor, personalizándose para cada una de las aplicaciones. La Figura B.2.2 muestra la distribución de las capas en ambos niveles. Figura B.2.2 Despliegue del sistema B.2.3 DISEÑO BOTTOM-UP En los siguientes capítulos se presenta el diseño de cada una de las partes del sistema. Para su diseño se ha seguido un modelo de abajo hacia arriba, donde primero se han diseñado los componentes inferiores, empezando por la capa de datos y se ha ido ascendiendo hacia la capa de presentación. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 55 B.3 DISEÑO DE LA BASE DE DATOS En este capítulo se describe el diseño de la base de datos. La BD ofrecerá al sistema un repositorio que almacenará los datos del negocio de forma persistente. La estructura de datos que se describe a continuación influirá en el diseño del resto de la aplicación. B.3.1 DISEÑO CONCEPTUAL El diagrama Entidad-Relación de la Figura B.3.1 (y su nomenclatura en la Figura B.3.2) muestra el modelo conceptual de la base de datos. A continuación se describirán con más detalle las entidades y relaciones que lo componen. USUARIO PROYECTO TAREA PARTICIPANTE DEDICACIÓN LIMITE_DEDICACIÓN (0,N) (0,N) 1 1 1 ORGANIZACIÓN GRUPO NOMBRE DESCRIPCIÓN 1 TELÉFONO EMAIL NÚMERO DESCRIPCIÓN DIRECCIÓN DESCRIPCIÓN 1 1(0,N) (0,N) LOGOIN PASSWORD NOMBRE DIRECCIÓN APELLIDO1 APELLIDO2 ESTADO INICIO ESTADO NOMBRE FINAL NOMBRE DESCIPCIÓN FECHA FECHA LÍMITE FIN LÍMITE INICIO TIPO_ALARMA ESTADO_ALARMA ESTADO FECHA INICIO FIN FECHA DÍA VALOR LÍMITE TIPO_ALARMA ESTADO_ALARMA (0,N) 1 1 11 CONTENER PARTICIPAR GESTIONAR HABLAR COMUNICAR CONTROLAR ASOCIAR INTEGRAR PERTENECE s CÓDIGO ACRÓNIMO DESCRIPCIÓN TIPO TIPO_ALARMA ESTADO_ALARMA (0,N) (0,N) (0,N) (0,N) 11 MAX_DEDICACIÓN ACOTAR (0,N) LIMITAR DEDICAR (0,N) (0,N) IDIOMA ORDEN ORDEN INICIO FINAL Figura B.3.1 Diagrama Entidad-Relación de la BD 56 EINA Universidad de Zaragoza ENTIDAD FUERTE ENTIDAD DÉBIL ENTIDAD FUERTE RELACIÓN RELACIÓN Relación E. fuerte y entidad débil (0,N) (0,N) A B R (0,N) 1 A B R A se relaciona con 0 a N Bs y viceversa A se relaciona con 1 solo B, y B con 0 a N As (0,N) 1 A B R Todo A se relaciona con 1 B, y B puede relacionarse con 0 a N As Figura B.3.2 Notación del diagrama Entidad-Relación B.3.1.1 DESCRIPCIÓN DE LAS ENTIDADES Las siguientes tablas describen las entidades que aparecen en el diagrama. Tabla B.3.1 Descripción de las entidades (tabla dividida en varias partes) ENTIDAD USUARIO Descripción Datos de un usuario del sistema. Atributo Descripción Nombre Nombre de la persona Apellido1 Primer apellido Apellido2 Segundo apellido (si existe) Login Identificador de acceso al sistema Password Clave privada de acceso al sistema Dirección Dirección del usuario (calle, edificio, ciudad, código postal) Idioma Idioma que se aplicará a la interfaz de la aplicación para este usuario. Estado Estado del usuario, posibilita el acceso y uso del sistema (Activo, no activo) Tipo Tipo de usuario, lleva asociado ciertos privilegios (Administrador, gestor, usuario normal) PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 57 Organización Organización o empresa a la que pertenece Restricciones El atributo “Login” debe ser único para cada usuario. Todo usuario debe estar asociado a un grupo. ENTIDAD GRUPO Descripción Permite agrupar los usuarios y restringir su visibilidad y asociación a un proyecto. Atributo Descripción Nombre Nombre dado al grupo Descripción Breve descripción del grupo. Restricciones ENTIDAD TELÉFONO Descripción Número de teléfono o fax asociado a un usuario del sistema. Atributo Descripción Número Número de teléfono o fax. Descripción Breve descripción del teléfono (casa, oficina, móvil,…). Orden Orden por el que se mostrará el número de teléfono de un usuario. Restricciones ENTIDAD EMAIL Descripción Dirección de correo electrónico asociada a un usuario del sistema. Atributo Descripción Dirección Dirección del correo electrónico. Descripción Descripción del correo (Ej. Oficial, personal,…). Orden Orden por el que se mostrará la dirección de correo de un usuario. Restricciones ENTIDAD Proyecto 58 EINA Universidad de Zaragoza Descripción Datos de un proyecto. Atributo Descripción Código Código asociado al proyecto. Nombre Nombre asociado al proyecto. Descripción Descripción del proyecto. Acrónimo Acrónimo asociado al proyecto. Estado Estado actual del proyecto (Activo, cerrado). Inicio Fecha de inicio del proyecto Final Fecha de finalización del proyecto Restricciones La fecha final de un proyecto debe ser nula si el estado del mismo no es un estado de finalización. El código de un proyecto debe ser único. Un proyecto debe ir asociado a un usuario de tipo “gestor”. El proyecto debe estar relacionado con un usuario gestor que esté activo en el sistema si el proyecto está en el estado abierto. ENTIDAD Participante Descripción Asociación de un usuario dentro de un proyecto de su grupo de pertenencia. Atributo Descripción Estado Estado actual del participante (activo, no activo). Inicio Fecha en que el participante es añadido al proyecto. Final Fecha en la que el participante es dado de baja en el proyecto. Restricciones Un participante debe estar asociado con un usuario del sistema. El usuario asociado al participante debe estar en un estado activo si el participante lo está. El participante no puede estar en un estado activo si el proyecto asociado está en un estado de cerrado. El usuario asociado al participante debe pertenecer al mismo grupo que el gestor asociado al proyecto. ENTIDAD Tarea Descripción Datos de una tarea asociada a un proyecto. Atributo Descripción Nombre Nombre asociado a la tarea. Descripción Descripción de la tarea. Fecha Fecha de la última actualización de la alarma. Límite Número máximo de horas que se deberían emplear en esta tarea (incluyendo la agregación de todas las horas empleadas por todos los participantes del proyecto). TipoAlarma Tipo de alarma que se aplicará si se sobrepasa el límite de PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 59 horas asociadas al proyecto. EstadoAlarma Estado en el que se encuentra la alarma actualmente (activada, desactivada, limite sobrepasado,…). Restricciones Toda tarea debe estar relacionada con un proyecto. ENTIDAD Maxdedicación Descripción Límite máximo de tiempo que se deberá dedicar a una tarea dentro de unas fechas dadas (incluyendo todas las horas de todos los participantes en el proyecto). Atributo Descripción Fecha Fecha de la última actualización de la alarma. Inicio Fecha inicial del intervalo de tiempo a tener en cuenta para el cálculo de las horas. Final Fecha final del intervalo de tiempo a tener en cuenta para el cálculo de las horas. Límite Número máximo de horas que se deberían emplear en esta tarea dentro del periodo de fechas indicado (incluyendo la agregación de todas las horas empleadas por todos los participantes del proyecto). TipoAlarma Tipo de alarma que se aplicará si se sobrepasa el límite de horas asociadas al proyecto. EstadoAlarma Estado en el que se encuentra la alarma actualmente (activada, desactivada, limite sobrepasado,…). Restricciones Toda entidad “Maxdedicación” debe estar relacionada con una tarea de un proyecto. ENTIDAD Dedicación Descripción Cantidad de tiempo que un participante ha dedicado a una tarea en un día concreto. NOTA: Por el atributo “Fecha” se entiende el día en el que se insertó el dato en la BD y por el atributo “Día” la fecha asociada con las horas dedicadas a la tarea del proyecto. Atributo Descripción Fecha Fecha de introducción de los datos. Día Fecha del día en que se realizó la dedicación. Valor Cantidad de tiempo empleada en la tarea. Restricciones “Valor” debería ser mayor que 0 e inferior a 24 horas. Toda entidad “Dedicación” tiene que estar relacionada con una tarea y un participante de un mismo proyecto. No puede relacionarse con participantes y tareas de distintos proyectos. 60 EINA Universidad de Zaragoza ENTIDAD Limitededicación Descripción Límite máximo de tiempo que un usuario se debe dedicar a una tarea dentro de unas fechas dadas Atributo Descripción Fecha Fecha de la última actualización de la alarma. Inicio Fecha inicial del intervalo de tiempo a tener en cuenta para el cálculo de las horas. Final Fecha final del intervalo de tiempo a tener en cuenta para el cálculo de las horas. Límite Número máximo de horas que el usuario debería emplear en esta tarea dentro del periodo de fechas indicado. TipoAlarma Tipo de alarma que se aplicará si se sobrepasa el límite de horas asociadas al proyecto. EstadoAlarma Estado en el que se encuentra la alarma actualmente (activada, desactivada, limite sobrepasado,…). Restricciones Toda entidad “Limitededicación” tiene que estar relacionada con una tarea y un participante de un mismo proyecto. No puede relacionarse con participantes y tareas de distintos proyectos. B.3.2 DISEÑO LÓGICO A continuación se describen las relaciones generadas al convertir diagrama Entidad-Relación en un modelo relacional que cumple la 2ª Forma Normal. B.3.2.1 DESCRIPCIÓN DE LAS RELACIONES Tabla B.3.2 Notación del diseño Relacional PK Clave Primaria. NN No Nulo. UQ Único. FK(x) RF t(y) X clave Ajena de la tabla t clave y. GRUPO ( Nombre Cadena PK, Descripción Cadena ); PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 61 USUARIO ( Login Cadena PK NN Password Cadena NN, Nombre Cadena NN, Apellido1 Cadena NN, Apellido2 Cadena, Dirección Cadena, Idioma Cadena NN, Organización Cadena, Tipo {SUPERADMIN, GESTOR, NORMAL} NN, Estado {ACTIVO, INACTIVO} NN, Grupo Cadena, FK (Grupo) RF Grupo (Nombre), Restricción: Solo puede haber un usuario de tipo “SUPERADMIN”, éste tendrá el login “admin” y será el único usuario que no tenga asociado un grupo. Los demás usuarios deberán tener asociado un grupo. ); TELÉFONO ( Id Número NN; Usuario Cadena NN, Orden Número NN, Número Cadena NN, Descripción Cadena, PK (Usuario, Id), UQ (Usuario, Orden), FK (Usuario) RF Usuario (Login) ); EMAIL ( Id Número NN, Usuario Cadena NN, Orden Número NN, Dirección Cadena NN, Descripción Cadena, PK (Usuario, Id), UQ (Usuario, Orden), FK (Usuario) RF Usuario (Login) ); PROYECTO ( Código Número PK, Nombre Cadena NN, 68 EINA Universidad de Zaragoza Hay dos tipos de alarmas que permiten limitar el conjunto de participantes que ven la alarma y los avisos que producen las alertas: 1. Gestor: Solo el gestor del proyecto ve la alarma y los avisos que producen las alertas. 2. General: El gestor y todos los participantes implicados en la alarma la pueden ver, así como los avisos que producen las alertas. Dependiendo del modelo de alarma se podrán dar algunos de los siguientes estados: 1. Desactivada: La alarma no se ha activado, no dará ninguna alerta. 2. Activada: La alarma está activa, pero no se ha excedido el número de horas. 3. Alerta: El número de horas ha sido excedido, nadie ha atendido el aviso de la alerta. 4. Parada: El gestor y el participante (en su caso) han atendido el aviso de la alerta. 5. Parada-Gestor: El gestor del proyecto ha respondido al aviso de la alerta, pero el participante no lo ha hecho todavía. 6. Parada-Usuario: El aviso ha sido recibido por el participante implicado, pero el gestor no ha respondido al aviso de la alerta. NOTA: El uso y el significado depende de cada modelo de alarma: B.4.2.1 ALARMAS DE TIPO TAREA Las alarmas de tipo tarea formarán los modelos 1 y 2. El primero cubrirá las alarmas asociadas a toda la dedicación de una tarea (incluidas en la clase “Tarea”) y el segundo estará compuesto por las alarmas asociadas a la dedicación en una tarea dentro de un periodo dado (clase “Maxdedicación”). A continuación se enumeran los valores de los tipos y estados que se utilizarán para ambos modelos. Tipos 1. Gestor. 2. General (Todos los participantes del proyecto podrán ver la alarma y recibirán las alertas. solo el gestor podrá dar por atendida una alerta). PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 69 Estados 1. Desactivada. 2. Activada. 3. Alerta. 4. Parada. B.4.2.2 ALARMAS DE TIPO PARTICIPANTE Estas alarmas conformarán el modelo 3 (asociadas a la clase “Limitededicación”). Cada alarma estará asociada a un único par tareaparticipante de un mismo proyecto. A continuación se enumeran los valores de los tipos y estados asociados a este modelo: Tipos 1. Gestor. 2. General (El participante asociado con la alarma podrá verla y podrá atender una alerta de la misma). NOTA: en ambos casos el participante podrá cambiar el estado de la alarma de forma implícita modificando sus valores de dedicación en la tarea del proyecto. Estados 1. Desactivada. 2. Activada. 3. Alerta. 4. Parada. 5. Parada-Gestor (Este estado solo se dará si la alarma es de tipo “General”). 6. Parada-Usuario (Este estado solo se dará si la alarma es de tipo “General”). PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 71 B. 5 CAPA DE DATOS En el modelo de programación por capas, la capa de datos tiene la responsabilidad de facilitar los datos a las demás capas, permitiéndoles abstraerse del método de almacenamiento. La capa de datos está formada por una clase que implemente el estereotipo “Data Access Object” o “Dao” que se describe en el apartado B.5.1. La utilización del estereotipo puede, en un futuro, facilitar la modificación del modelo de almacenamiento, permitiendo crear otras clases que lo implementen, facilitando el acceso a distintas fuentes de datos. En este momento solo se creará una única clase que lo implemente, permitiendo el acceso a la base de datos que se ha definido en el capítulo B.3. Los objetivos de este estereotipo son los siguientes: 1. Cargar datos. 2. Crear datos. 3. Guardar datos 4. Borrar datos. 5. Realizar búsquedas complejas sobre los datos. La capa de datos se encargará del mapeo Objeto-Relacional entre los datos de la aplicación y el repositorio de los datos. Tal como se ha mencionado en el capítulo anterior los atributos de los datos del negocio tienen el mismo nombre que los campos de las tablas, igualmente las clases tienen el mismo nombre que las tablas, indicando cómo se realizará el mapeado. B.5.1 ESTEREOTIPO DAO La clase que conforme la capa de negocio deberá implementar el estereotipo Dao con los siguientes métodos: vacio crear (PojoDedicación pojo) o Guarda un POJO que no existía en la aplicación. vacio guardar (PojoDedicación pojo) o Persiste los datos del POJO (que ya existía) en el medio de almacenamiento. vacio guardar (PojoDedicación pojo, Boolean forzarCrear) o Persiste los datos del POJO en el medio de almacenamiento. Si “forzarCrear” es verdadero y el POJO no existe en la aplicación entonces se crea. 72 EINA Universidad de Zaragoza vacio guardar (Colección <PojoDedicación> pojos) o Guarda una colección de POJO s de forma persistente. PojoDedicación cargar (Clase clase, Clave clave) o Carga el POJO de la clase que tenga la clave dada. Si no existe devuelve null. PojoDedicación cargar (Clase clase, Mapa claves) o Carga el POJO de la clase que coincida con el conjunto de claves dado. Claves debe contener un conjunto de pares (clave, valor) que sea único (dos POJO s con las mismas propiedades deberán ser el mismo), si no el comportamiento no será predecible. Si no hay ninguno devuelve null. Lista <PojoDedicación> cargar (Clase clase) o Carga todos los POJOs de la clase dada. Lista buscar (Clase clase, Cadena filtro, Cadena orden) o Busca todos los POJOs de la clase mediante un filtro y los ordena. Lista buscar (Cadena búsqueda) o Realiza una búsqueda directa. Long contar (Clase clase, Cadena filtro) o Cuenta el número de POJOs de una clase que cumplen el filtro aplicado. Long contar (Clase clase, Cadena filtro, Cadena atributo) o Cuenta el número de POJOs de la clase dada filtrados por filtro. El parámetro “atributo” indica que atributo de la clase se empleará para contar. Este método se debe emplear para contar elementos de una clase que tenga una clave embebida (claves compuestas). Decimal sumar (Clase clase, Cadena filtro, Cadena atributo) o Suma los valores del atributo con el nombre pasado en el parámetro “atributo” contenido en los POJOs filtrados en la búsqueda. El atributo obligatoriamente debe ser de tipo numérico y debe pertenecer a la clase. vacio borrar (PojoDedicación pojo) o Borra de forma permanente el POJO en el medio de almacenamiento. Vacio borrar (Colección <PojoDedicación> pojos) o Borra de forma permanente todos los POJOs de la colección. Errores validar (PojoDedicación, pojo) o Valida un POJO y devuelve el conjunto de errores producidos. Si el conjunto es vacío los datos del POJO son correctos. Nota: en todos los casos el parámetro “clase” será la definición de una clase que deberá implementar “PojoDedicación”. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 73 B.6 CAPA DE NEGOCIO La capa de negocio da servicio a la capa de presentación facilitándole las operaciones relacionadas con la lógica de negocio que realiza la aplicación. No incluirá las operaciones relacionadas con la configuración ni mantenimiento del sistema (ver capítulo B.7 “Otros componentes"). La capa se comunica con cada una de las otras dos capas de forma distinta. Recibe mensajes desde la capa de presentación para realizar las operaciones que piden los usuarios y envía mensajes a la capa de datos para acceder al repositorio del sistema (base de datos). La capa de negocio dispone de una interfaz que la capa de presentación utiliza para comunicarse con ella. La interfaz se distribuirá entre varios componentes especializados en los distintos tipos de información. El conjunto cubre los casos de uso relacionados con los gestores, los participantes y el administrador, con la excepción de la gestión del sistema. Los componentes trabajarán con distintos tipos de datos, principalmente con los POJOs descritos en el capítulo B.4. B.6.1 COMPONENTES El diagrama de la Figura B.6.1 muestra los distintos componentes en que se divide la capa de negocio y las dependencias entre ellos. Los siguientes apartados describen las clases que los componen (se ha incluido los métodos de la clase “GestiónProyectos” que forman parte de la interfaz del componente “Gestión Proyectos” como un ejemplo del resto de las interfaces, que no se han incluido en este documento). 74 EINA Universidad de Zaragoza Figura B.6.1 Componentes de la capa de negocio B.6.1.1 GESTIÓN DE LOS PROYECTOS Este componente se encarga de la gestión de los proyectos, permitiendo su creación, almacenamiento y destrucción. Facilitará la gestión de los participantes y las tareas de los proyectos. Cubrirá los requisitos de los casos de uso CU01, CU08 y dará soporte a los demás componentes. Se compondrá de las clases que se detallan a continuación. Gestión de los proyectos Desarrolla las necesidades de gestión de los proyectos. Cubrirá los requisitos RF6 y RF9. 1) void crearProyecto o Proyecto proyecto o Valida y crea el proyecto. 2) Proyecto buscarProyecto o Integer código o Busca y devuelve el proyecto que tenga el código pasado como parámetro. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 75 3) Proyecto buscarProyecto o Integer código o String login o Busca y devuelve el proyecto que tenga el código pasado como parámetro, antes comprueba que el login sea igual al del gestor del proyecto. 4) Proyecto buscarProyecto o Integer código o String login o String estado o Busca y devuelve el proyecto que tenga el código pasado como parámetro, antes comprueba que el login sea igual al del gestor del proyecto y que el proyecto se encuentre en el estado dado. 5) void guardarProyecto o Proyecto proyecto o Valida y guarda el proyecto. 6) void guardarDatosProyecto o Proyecto proyecto o Valida y guarda el proyecto sin alterar su estado. 7) Proyecto abrirProyecto o Integer código o String loginGestor o Busca, cambia el estado del proyecto a “ABIERTO” y lo guarda. Primero comprueba que el login coincide con el del gestor del proyecto. 8) Proyecto abrirProyecto o Proyecto proyecto o Cambia el estado del proyecto a “ABIERTO” y lo guarda, antes se dará de baja a todos sus participantes. 9) Proyecto cerrarProyecto o Integer código o String loginGestor o Busca, da de baja a todos sus participantes, cambia el estado del proyecto a “CERRADO” y lo guarda. Primero comprueba que el login coincide con el del gestor del proyecto 10) Proyecto cerrarProyecto o Proyecto proyecto o Da de baja a todos sus participantes y cambia el estado del proyecto a “CERRADO” y lo guarda. 11) void borrarProyecto o Integer código o Busca el proyecto, comprueba que su estado sea “CERRADO” y lo borra del sistema. De forma implícita se borrará a todos los participantes, tareas, dedicaciones y alarmas del proyecto. 76 EINA Universidad de Zaragoza 12) Long numProyectos o String estadoProyecto o String estadoGestor o Devuelve el número de proyectos filtrados por el estado de su gestor y del proyecto. 13) Long numProyectos o String estadoProyecto o String estadoGestor o String grupo o Devuelve el número de proyectos pertenecientes a un grupo filtrados por el estado de su gestor y el del proyecto. 14) Long numProyectosParticipantes o String estadoProyecto o Long minParticipantes o Long maxParticipantes o Devuelve el número de proyectos en un estado que tengan asociados un número mínimo y máximo de participantes. 15) Long numProyectosTareas o String estadoProyecto o Long minTareas o Long maxTareas o Devuelve el número de proyectos que se encuentren en un estado y que contengan un número mínimo y máximo de tareas. 16) List <Proyecto> listarProyectos o String loginUsuario o String estadoProyecto o String estadoParticipante o Devuelve los proyectos en los que participa un usuario filtrados por el estado del proyecto y el del participante. 17) List <Proyecto> listarProyectosGestionados o String loginGestor o String estado o Devuelve una lista de proyectos filtrados por el login del gestor y el estado del proyecto. 18) List <Proyecto> listarProyectosGrupo o String nombreGrupo o String estado o Devuelve una lista de proyectos filtrados por el grupo y el estado del proyecto. 19) List <Participante> listarParticipantesProyecto o Integer código o String estado o Devuelve una lista con los participantes de un proyecto que se encuentre en el estado dado. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 77 20) Long numParticipantesProyecto o Integer código o String estado o Devuelve el número de participantes en un proyecto, que se encuentre en el estado dado. Gestión de los participantes Esta clase se encarga de gestionar las participaciones de los usuarios en los proyectos. Cumple con los requisitos RF8, RF14, RF18 y Rf19. Gestión de las tareas Contiene los métodos necesarios para gestionar las tareas de los proyectos. Resuelve el requisito RF7. B.6.1.2 GESTIÓN DE LOS USUARIOS Este componente se encarga de manejar toda la información relacionada con los usuarios del sistema. Permitirá crear, guardar, borrar, dar altas y bajas y listar tanto a los grupos como a los usuarios. También permitirá modificar el perfil de un usuario. Este componente debe cubrir los casos de uso CU04 y CU06. Gestión de los grupos Facilitará los métodos para la gestión de los grupos de usuarios. Cumplirá una parte del requisito RF2. Gestión de los usuarios Se encargará de la gestión de los usuarios del sistema, permitiendo crearlos, darlos de alta y baja. Deberá resolver los requisitos RF2, RF5 y RF17. Gestión de la agenda de los usuarios Contendrá los métodos que permitirán a un usuario crear y modificar los números de teléfono y las direcciones de correo electrónico de su perfil. Ofrecerá métodos para cumplir parte de los requisitos RF5 y RF17. 84 EINA Universidad de Zaragoza Todas las alarmas tendrán un valor que indicará el límite de horas de la dedicación, este valor deberá ser mayor que 0.0 y múltiplo de 0.5. Si no es positivo se producirá un error, además el sistema lo redondeará a múltiplos de 0.5 Cada modelo de alarma tendrá una forma distinta de contabilizar el tiempo dedicado a la tarea. Una alarma general (modelo 1) tendrá en cuenta todas las dedicaciones realizadas por todos los usuarios del proyecto en la tarea. Una alarma de tipo tarea (modelo 2) limitará la dedicación al intervalo especificado por los valores “inicio” y “fin”. Una alarma de tipo participante (modelo 3) contabilizará solo la dedicación del usuario asociado realizada dentro del periodo inicio y fin (ambos incluidos). Los usuarios que participen en un proyecto no podrán modificar los valores de las alarmas con la única excepción de su estado. Cuando un usuario introduzca su dedicación en una tarea de un proyecto, el sistema deberá actualizar el estado de todas las alarmas activas y en alerta que se vean afectadas por la tarea, usuario y fecha de la dedicación. Las alarmas que hayan sido atendidas por el usuario o por el gestor no serán modificadas. Además un usuario podrá dar por atendida una alarma, produciendo el cambio de estado de la misma. Un gestor podrá cambiar el estado de una alarma de forma explícita activándola o desactivándola, así como de forma implícita al dar por atendida una alerta. El siguiente apartado describe estos comportamientos. Los valores de los atributos tarea, participante, inicio y fin no serán modificables, para ello se deberá crear una tarea nueva. B.6.2.2 COMPORTAMIENTO DE UNA ALARMA En función de lo descrito en el capítulo B.4 y en los apartados anteriores, se pueden derivar los 2 siguientes diagramas de estado para definir el comportamiento de las alarmas. El diagrama de la Figura B.6.2 se utilizará para los modelos 1 y 2 y para el modelo 3 cuando la alarma sea de tipo “GESTOR”. El diagrama de la Figura B.6.3 se aplicará al modelo 3 cuando la alarma sea de tipo “GENERAL”. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 85 Figura B.6.2 Diagrama de estado 1 de las alarmas Figura B.6.3 Diagrama de estado 2 de las alarmas 86 EINA Universidad de Zaragoza Aunque no aparezca reflejado en los diagramas es posible ir al estado “DESACTIVADA” desde cualquier estado. Podemos clasificar las transiciones en tres tipos: las generadas explícitamente al guardar los datos de una alarma (solo el gestor), las que se producen explícitamente al dar por atendida una alarma (gestor y participante) y las que se producen implícitamente cuando un participante introduce su dedicación. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 87 B.7 OTROS COMPONENTES En este capítulo se describen los componentes transversales del sistema que no pertenecen a la lógica de negocio de la aplicación. Estos componentes cubrirán el caso de uso “Gestión sistema”, además de otras funciones que darán soporte a la capa de negocio. B.7.1 CONFIGURACIÓN Este componente permitirá acceder y modificar la configuración del sistema. Facilitará la lectura y escritura de los ficheros de configuración y la lectura y escritura de sus propiedades. Deberá dar soporte tanto dentro del Portlet como de la aplicación Web. El componente dará soporte al caso de uso CU05. El acceso a los ficheros de configuración se podrá realizar en dos niveles, según sea conveniente. El primer nivel solo permitirá leer y sobrescribir el contenido de un fichero de configuración. El segundo nivel dará soporte para el acceso a las propiedades del fichero (lectura y escritura individual). Cada fichero de configuración consistirá en un archivo de propiedades. En caso de que un fichero de propiedades contenga dos entradas con la misma clave, ambas serán cargadas, pero solo se tendrá en cuenta la última (ver clase “Propiedades”). La función que guarda las propiedades mantendrá todos los comentarios y líneas en blanco, así como el orden de las propiedades tal como estaban al ser leídas. Las nuevas propiedades serán añadidas en una línea nueva al final de la lista. El sistema deberá disponer de una copia, no modificable por parte de la aplicación para que el administrador pueda restaurar la configuración del sistema. Tanto los ficheros de configuración, como los ficheros con la configuración por defecto se almacenarán en “WEB-INF/config” y “WEBINF/config/defautl” respectivamente, ambos tipos de archivos no se incluirán en este componente. La configuración del programa será compartida por todos los usuarios y los cambios producidos serán visibles por todos ellos. Este componente garantizará la exclusión mutua en el acceso y modificación de las propiedades de la configuración dentro de la misma aplicación. Esto solo garantiza que no se producirán errores al leer o escribir la configuración, pero habrá que tener en cuenta que podrán crearse incoherencias de tipo lector-escritor. Se asumirá 88 EINA Universidad de Zaragoza que este problema (común a todos los sistemas) no afectará al correcto funcionamiento de la aplicación y que su solución produciría problemas mucho más graves. B.7.1.1 NIVEL 1: CONFIGURACIÓN BÁSICA El nivel uno permitirá el acceso y modificación de los ficheros de configuración... Deberá ser utilizado por aquellas configuraciones que se carguen en componentes que ya disponen de mecanismos para leer los archivos y manejar sus propiedades. B.7.1.2 NIVEL 2: CONFIGURACIÓN POR PROPIEDADES Las configuraciones que requieran acceder a las propiedades deberán implementar el segundo nivel. Tanto en la aplicación Web como en el Portlet todos los hilos compartirán las propiedades. Esto significa que solo se realizará una lectura de las mismas y en el caso de ser modificado el fichero se producirá una nueva recarga. Dado que el Portlet no detectará estas modificaciones deberá recargar la configuración por cada lectura. La implementación se hará de tal manera que la carga de las propiedades sea totalmente transparente a la petición, los cuales se encargarán de comprobar si es necesario hacerlo. B.7.2 GESTIÓN DE LOS LOGS El objetivo de este componente es ofrecer las funcionalidades para la gestión de los ficheros de log. Los logs o bitácoras son un medio para registrar los sucesos que ocurren durante la ejecución del programa (errores, advertencias, información, depuración, etc.), los cuales ayudan a la gestión por parte del administrador. Deberá cubrir parte del caso de uso CU05. La forma de registrar y almacenar estos sucesos vendrá dada por el fichero de configuración, localizado en “WEB-INF/log4j.properties”, el cual podrá ser modificado por el administrador (véase el componente “Configuración”). Dada la naturaleza Web de la aplicación, lo lógico es que este registro se almacene en ficheros y que el administrador pueda consultarlos y gestionarlos mediante la aplicación. Esto no significa que no se puedan utilizar otros métodos para su almacenamiento y/o notificación (pues esto dependerá de la configuración dispuesta en “log4j.properties”), tan solo hay que considerar que el alcance de este componente se restringe a los logs almacenados en ficheros. Para utilizar otros medios será necesario crear/usar otras formas de acceso no contempladas en este componente. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 89 El fichero “log4j.properties”” deberá cumplir con la especificación dada por log4j y a su vez con el formato de ficheros de propiedades (“.properties”). Consistirá en un fichero de propiedades (“.properties”) que contendrá una o más definiciones de Loggers, cada uno de ellos irá asociado a uno o más appenders, los cuales pueden ser compartidos por más de un Logger. Las funciones de este componente serán: Clase para la gestión de los logs Esta clase contendrá los métodos necesarios para la gestión de los ficheros de logs. Permitirá las funciones descritas previamente. La clase mantendrá una lista con todos los appenders. Será recomendable que se llame a la función “actualizar” antes de realizar alguna consulta, especialmente si se ha actualizado la configuración del logs. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 91 B.8 CAPA DE PRESENTACIÓN DE LA APLICACIÓN WEB Este capítulo y el siguiente presentan el diseño de la capa de presentación. Dentro de este capítulo se mostrará la parte que afecta a la aplicación Web, mientras que en el siguiente se desarrollará la parte que se refiere al Portlet. Cada apartado describe las GUI de una de las secciones de la aplicación. La GUI de la aplicación Web se compondrá de un Font-End y un BackEnd. La parte del Front-End será utilizado por los usuarios de tipo gestor para realizar la gestión de la dedicación y el Back-End será utilizado por el administrador del sistema para su configuración. Las GUIs serán generadas con código HTML de manera dinámica, utilizando el lenguaje JSP, con cierto apoyo de etiquetas de Java. El código solo incluirá los datos y la estructura del documento, apoyándose en hojas de estilo (CSS) para definir el aspecto de las páginas. La información mostrada por las GUIs se obtendrá de la capa de negocio añadiéndole los textos e imágenes necesarios para su comprensión, así como formularios para que los usuarios puedan introducir nuevos datos y realizar búsquedas. Para la realización de ciertas funciones en el navegador del cliente se añadirá lenguaje de script con soporte de la tecnología AJAX para la comunicación asíncrona con el servidor. Las interfaces estarán compuestas de una cabecera (optativa), el contenido principal y un pie de página. Para nombrar a cada una de ellas se utilizará una clave (que se empleará en la implementación) que designará, de forma unívoca, a cada una de ellas y que seguirá las siguientes reglas: 1. Comenzarán por la letra „V‟ 2. La segunda letra denotará el usuario „A‟ administrador „G‟ gestor „C‟ común a ambos 3. Una o más letras denotando la sección 4. Dos números comenzando en „01‟ 92 EINA Universidad de Zaragoza B.8.1 CABECERA Las GUIs de la parte privada del Front-End y del Back-End mostrarán una cabecera con las distintas opciones disponibles, Incluyendo un menú principal (adaptado a cada usuario y que no variará) con enlaces a las secciones a las que puede acceder cada tipo de usuario. Dependiendo de la sección en la que se encuentre el usuario, se podrá ver un menú secundario con las diversas opciones de la sección. En algunas secciones este menú no aparecerá. Además se incluirá un menú auxiliar con enlaces que permitirán salir de la aplicación y acceder a la sección que facilita modificar el perfil del usuario. Dispondrá de un botón que permitirá cambiar el contendido de la sección por el de la ayuda, el contenido de la ayuda se colocará encima del contenido de la sección mostrada hasta que se pulse el botón para ocultarla. Cada menú podrá ser identificado por su clave, compuesta por un acrónimo (sin puntos) que permitirá identificarlo y estará compuesto según las reglas siguientes: 1. Comenzará por la letra „M‟. 2. El tipo de menú „P‟ principal „S‟ secundario „Aux‟ auxiliar 3. En el caso de un menú principal o secundario „A‟ administrador „G‟ gestor 4. Una secuencia de números comenzando en „01‟ B.8.1.1 MENÚS DEL ADMINISTRADOR Menú principal del administrador (MPA01) El menú principal del administrador le ofrecerá acceso a la configuración del sistema, la gestión de logs y la gestión de los usuarios. Nombre Evento Descripción Estado infoEstado Enlace a la sección que muestra la información del estado del sistema. Configuración listarConfiguración Enlace a la sección que facilita la modificación de los ficheros de configuración. Logs listarLogs Enlace que permite el acceso a los ficheros de logs. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 93 Nombre Evento Descripción Usuarios listarUsuarios Facilita el acceso a la sección que permite gestionar los usuarios del sistema. Estadísticas nuevoInformeEstadístico Permite mostrar la sección dedicada a la generación de estadísticas del sistema. Menú secundario “Configuración” (MSA01) El menú dispondrá de una lista con las opciones de configuración disponibles (general, logs,…). Nombre Evento Descripción General editarConfiguración Enlace a la sección que facilita la modificación de los ficheros de configuración. Admin editarConfiguración Enlace a la sección que facilita la modificación de los ficheros de configuración. Gestor editarConfiguración Enlace a la sección que facilita la modificación de los ficheros de configuración. Participantes editarConfiguración Enlace a la sección que facilita la modificación de los ficheros de configuración. Logs editarConfiguración Enlace a la sección que facilita la modificación de los ficheros de configuración. Menú secundario “Logs” (MSA02) El menú contendrá un enlace que llevará a la sección principal de la gestión de los ficheros de logs. Nombre Evento Descripción Listado listarLogs Enlace que muestra la lista de ficheros de logs disponibles. Menú secundario “Gestión de los usuarios” (MSA03) El menú facilitará el acceso a las secciones que permiten la gestión de los usuarios y de los grupos del sistema. 100 EINA Universidad de Zaragoza Listado de los grupos (VAU01) Contendrá una tabla con un subconjunto de los grupos ordenados por su nombre. Inicialmente se mostrarán los primeros grupos de la lista completa y se dispondrán de botones para actualizar la lista y para mostrar el siguiente y el anterior tramo de la lista. Se añadirán dos entradas de texto que permitan indicar el índice del primer elemento de la lista y el número de elementos que se desea mostrar. Al pulsar el botón para actualizar se recargará la tabla con el número de elementos indicados a partir del índice. Si no hubiera suficientes elementos se mostrarán los que estén disponibles. Si cualquiera de las entradas son igual o menor que 0 se tomará el valor por defecto. Ambas entradas serán rellenadas por el último valor introducido o el valor por defecto. También dispondrá de otra entrada de texto que permitirá filtrar la lista de los grupos a través de su nombre. Al presionar el botón correspondiente se actualizará la tabla, desde el índice descrito anteriormente, con los grupos resultantes de la búsqueda mediante el filtro introducido. Cada entrada de la lista contendrá el nombre del grupo, el número de usuarios contenidos dentro de él, parte de la descripción del grupo (las primeras palabras) y permitirá la posibilidad de ir a la lista de usuarios del grupo, ver sus datos y borrarlo (si el grupo está vacío) Menú secundario MSA03 PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 101 Nuevo grupo (VAU02) Muestra un formulario con los campos necesarios para crear un grupo. Dispondrá de un botón para enviar la información al servidor. El formulario podrá ir precedido de una lista de errores producidos al intentar crear un grupo previamente. En este caso los campos del formulario estarán rellenados con los datos que se enviaron. Menú secundario MSA03 Editar un grupo (VAU03) Muestra un formulario con los datos de un grupo, junto con un botón que enviará la información al servidor para que remplace a la actual. Al igual que cuando se crea un grupo, el formulario irá precedido de la lista de errores que se produjeron al intentar modificar un grupo, entonces el formulario vendrá inicializado con los nuevos datos. Menú secundario MSA03 102 EINA Universidad de Zaragoza Información de un grupo (VAU04) Muestra toda la información asociada a un grupo. Su nombre, descripción y número de usuarios. Si el grupo es borrable (no tiene usuarios) se incluirá un botón para borrarlo. Delante de los datos de un grupo podrá ir un mensaje que confirma si un grupo se ha creado o se ha modificado correctamente. Menú secundario MSA03 Listado de los usuarios (VAU05) De forma parecida al listado de los grupos, esta interfaz mostrará una tabla con los usuarios del sistema, ordenados por su login. Los usuarios podrán ser filtrados por su login, su estado, su tipo y su grupo. Para ello se incluirá un campo para introducir un filtro para el login y listas de selección con todos los grupos que contenga el sistema, así como las distintas posibilidades de los estados y tipos de usuarios. Al igual que con los grupos, se podrá seleccionar el índice del primer elemento y el tamaño de la lista. Cada elemento de la tabla contendrá el login del usuario, su primer y segundo apellido, su nombre, su grupo, su estado y su tipo. Además de botones para dar de baja, alta y para mostrar toda la información de uno de ellos. Además se podrán marcar un subconjunto (casilla de selección) para realizar una operación sobre los elementos seleccionados, para estas operaciones se dispondrá de los botones necesarios. Delante de la lista de elementos podrá situarse un mensaje que confirme o muestre los errores producidos al realizar una acción sobre los elementos mostrados. Cuando se realice una operación sobre la lista no se modificarán los parámetros de estas (índice inicial, tamaño de la lista). PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 103 Menú secundario MSA03 Nuevo usuario (VAU06) Muestra un formulario para introducir los datos de un nuevo usuario. Previo al formulario se puede incluir una lista de errores producidos al haber intentado crear un usuario, en este caso se rellenará el formulario con los datos introducidos previamente. Menú secundario MSA03 Editar los datos de un usuario (VAU07) Muestra un formulario con los datos de un usuario. Al pulsar el botón correspondiente los datos serán guardados. De igual forma que al crear un usuario, si se producen errores se mostrarán en una lista previa al formulario. Se incluirán botones para dar de alta y baja, así como para borrar al usuario. 104 EINA Universidad de Zaragoza Menú secundario MSA03 Información de un usuario (VAU08) Muestra toda la información personal asociada a un usuario (nombre, apellidos, teléfonos, emails,...). Se incluirán botones para dar de alta y baja, así como para borrar al usuario. Delante de los datos se podrá incluir un mensaje que confirme la creación o modificación del usuario. Menú secundario MSA03 PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 105 B.8.3.3 ESTADÍSTICAS DEL USO DEL SISTEMA Esta sección permitirá al administrador generar informes estadísticos del uso que se hace del sistema. Los informes generados contendrán información del número, media y porcentaje de grupos, usuarios,… que contiene el sistema. Cubrirá el requisito RF4 y el caso de uso CU07. Mostrar un informe estadístico del sistema (VAE01) Muestra un informe de las estadísticas del sistema que ha sido pedido por el administrador. Facilitará un enlace para generar un recurso en PDF con el contenido del informe que podrá ser guardado por el administrador donde desee. Menú secundario MSA04 Nuevo informe de las estadísticas del sistema (VAE02) Esta GUI muestra un formulario mediante el cual el administrador puede configurar un informe estadístico del uso del sistema. Se dispondrá de dos enlaces, uno permitirá ir a la sección que muestra el informe generado en base a la información introducida en el formulario y otro que generará un recurso con el informe en formato PDF. El formulario mostrará entradas de texto que permitirán introducir el título y una descripción para el informe. Además se incluirán casillas de verificación para indicar que se añadan las estadísticas descritas en el documento de diseño de la capa de negocio. Cada una de las opciones contendrá varios datos según las combinaciones de parámetros indicadas (ver componente “Generación de Informes de la Dedicación”, apartado B.6.1.5). Menú secundario MSA04 B.8.4 INTERFACES PARA LOS GESTORES Los usuarios de tipo gestor necesitarán acceder a un conjunto de interfaces que les permitan gestionar la información referente a los proyectos de los que son responsables. Las siguientes interfaces facilitarán la labor de crear, modificar y borrar proyectos, así como seleccionar aquellos usuarios que participen en ellos Además de otras funcionalidades como alarmas e informes de la dedicación. 106 EINA Universidad de Zaragoza B.8.4.1 GESTIÓN DE LOS PROYECTOS Dado el caso de uso CU01 y los requisitos RF6, RF7 y RF9 un gestor podrá gestionar sus proyectos y las tareas y participantes asociados en cada uno de ellos. Listado de los proyectos gestionados (VGP01) Muestra una tabla con los proyectos que gestiona el usuario. Al igual que con las tablas descritas anteriormente, solo se mostrará un subconjunto de la lista completa de proyectos gestionados. Se dispondrá de campos para indicar el índice del primer elemento de la lista que mostrará la tabla, el tamaño de la tabla y un filtro por el estado de los proyectos. Se facilitarán botones para ir actualizando los elementos de la tabla. Cada elemento de la tabla mostrará el código del proyecto, su nombre, su estado y botones para abrir, cerrar o borrar el proyecto (según sea su estado), así como un enlace para mostrar la información del proyecto. Previamente a la tabla se podrá mostrar el resultado de una operación realizada sobre un elemento. Menú secundario Ninguno Nuevo proyecto (VGP02) Muestra un formulario que permite introducir los datos para crear un nuevo proyecto. Delante del formulario se podrá incluir una lista con los errores que se produjeron al intentar crear un proyecto. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 107 Menú secundario Ninguno Editar proyecto (VGP03) Muestra la información de un proyecto en un formulario que permite modificarla. Si se han cometido errores al intentar modificar un proyecto se mostrará una lista delante del formulario. Menú secundario MSG01 Información de un proyecto gestionado (VGP04) Muestra la información de un proyecto gestionado por el usuario junto con una tabla con la lista de sus tareas. Dispondrá de botones para abrir, cerrar, borrar y editar el proyecto (según su estado). La tabla de tareas del proyecto incluirá el nombre y la descripción de la tarea, así como el estado y tipo de alarma, las horas totales dedicadas a la misma, límite de la dedicación, número de dedicaciones, alarmas asociadas, alarmas no atendidas. Se añadirán botones para modificarlas, borrarlas y para cambiar su posición. Si la alarma ha producido una alerta que no ha sido atendida se marcará en rojo. 108 EINA Universidad de Zaragoza Menú secundario MSG01 Nuevas tareas (VGP05) Presenta un formulario que permite añadir nuevas tareas al proyecto. El formulario estará compuesto por bloques iguales, cada bloque permitirá crear una nueva tarea. Habrá un botón que permitirá añadir nuevos bloques. En el caso de que se hubiera intentado crear nuevas tareas y se hubiera producido algún error, los primeros bloques irían rellenados con los datos de las tareas que los produjeron y cada uno precedidos de una descripción del error. Delante del formulario se mostrará una tabla con los nombres y las descripciones de cada tarea que ya existen en el proyecto. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 109 Menú secundario MSG01 Información de una tarea (VGP06) Muestra la información de una tarea, permitiendo modificar su descripción y el estado y tipo de la alarma asociada. Menú secundario MSG01 116 EINA Universidad de Zaragoza Nueva alarma de tipo tarea (VGA06) Muestra un formulario que permite añadir una nueva alarma de tipo tarea al proyecto. Si se hubiera producido un error al crear una alarma, se mostraría la lista con la descripción de los errores y el formulario se iniciaría con los datos introducidos. Menú secundario MSG03 B.8.4.4 DEDICACIÓN AGREGADA Las siguientes interfaces permiten calcular la dedicación agregada realizada dentro de los proyectos. Cubriendo los requisitos RF10, RF11, RF12 y RF13 y el caso de uso CU03. Permitirá calcular la dedicación agregada que realizan los participantes en los proyectos, Además facilitará la creación de un documento PDF con el contenido de un informe que el usuario podrá guardar donde desee. Para ver la estructura de un informe, consultar el apartado B.6.1.6. Dedicación agregada de un proyecto (VGD01) Muestra un informe con la dedicación agregada de un proyecto gestionado por el usuario. La información dependerá de los parámetros pasados en la petición. El informe podrá contener varios apartados, con distinta información Menú secundario MSG04 Nuevo informe de la dedicación (VGD02) Esta sección mostrará un formulario que permitirá introducir los parámetros de un informe de la dedicación y poder crearlo posteriormente. Facilitará dos tipos de informes, según lo descrito en el apartado B.6.1.6, uno PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 117 sobre la dedicación agregada de un proyecto y otro de la dedicación de varios participantes. Menú secundario MSG04 B.8.5 INTERFACES COMUNES Los siguientes apartados describen el resto de las interfaces de la aplicación Web, las cuales podrán ser utilizadas por todos sus usuarios. B.8.5.1 ENTRADA A LA APLICACIÓN WEB Ofrecerá un punto de acceso común a todos los usuarios de la aplicación Web. Acceso a la aplicación (VCA01) Mostrará un formulario con dos entradas de texto correspondientes al login y al password, junto con un botón cuya acción mandará los datos al servidor, permitiendo a los usuarios acceder a sus contenidos. Si los datos de identificación suministrados por el cliente Web fueran incorrectos mostrará un mensaje de error y el login se iniciará con el valor introducido. Algo parecido pasará cuando caduque la sesión de un usuario, entonces se mostrará un mensaje advirtiendo el suceso Menú secundario Ninguno B.8.5.2 INFORMACIÓN Contiene una GUI que permite ver la información de contacto con el administrador. 118 EINA Universidad de Zaragoza Información de contacto (VCI01) Muestra cierta información del administrador que puede servir a los demás usuarios para contactar con él en caso de necesidad. La información mostrada será extraída del perfil del administrador, e incluirá los teléfonos y direcciones de correo electrónico que haya incluido en su perfil. Menú secundario Ninguno B.8.5.3 GESTIÓN DEL PERFIL DEL USUARIO Permiten a los usuarios gestionar sus perfiles en el sistema, como pueden ser su dirección, teléfonos y direcciones de correo electrónico. Cubrirá el caso de uso CU04 y el requisito RF5. Datos personales (VCP01) Muestra un formulario con el perfil del usuario, permitiendo cambiar algunos de sus datos. Delante del formulario podrá aparecer una lista con los errores que se produjeron al intentar guardar el perfil, en este caso el formulario será rellenado con los datos introducidos y no con los que almacena el sistema. También contendrá otro formulario que permitirá cambiar la contraseña. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 119 Menú secundario MSAux01 Listado de teléfonos (VCP02) Muestra la lista de los teléfonos asociados con el usuario ordenados por el campo “orden”. Para cada teléfono se incluirán botones para cambiarlo de posición. También se dispondrá de botones para borrar los teléfonos. Además habrá un formulario que permitirá añadir un nuevo teléfono al final de la lista. El número y la descripción del teléfono podrán ser modificados escribiendo en los campos correspondientes. Un botón permitirá guardar los cambios. 120 EINA Universidad de Zaragoza Menú secundario MSAux01 Listado de emails (VCP03) Muestra la lista de direcciones de correo electrónico asociados con el usuario ordenados por el campo “orden”. Para cada dirección se incluirán botones para cambiarlo de posición. También se dispondrá de botones para borrar las direcciones. Además habrá un formulario que permitirá añadir una nueva dirección al final de la lista. El email y la descripción de la dirección de uno de los elementos podrán ser modificados escribiendo en los campos correspondientes. Un botón permitirá guardarlos. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 121 Menú secundario MSAux01 B.8.5.4 PANTALLAZO DE ERROR La mayoría de los errores se gestionarán dentro de las pantallas generadas por las GUIs descritas en estos apartados. Para aquellos errores que no estén previstos en un uso normal de la aplicación se generará una pantalla mostrando una descripción del error que se ha producido. Pantallazo de error (VCError) La pantalla mostrará un mensaje que describa de forma breve que ha sucedido y que acción ha generado el error. B.8.6 AYUDA INTEGRADA La aplicación Web dispondrá de un sistema de ayuda integrada dentro del sistema. Para ver su contenido se deberá presionar el botón y con el botón se podrá volver a la sección que se estaba visualizando. La 122 EINA Universidad de Zaragoza aplicación Web mantendrá el contenido introducido en la sección actual durante el tiempo que se consulte la ayuda. Se podrá navegar dentro de las distintas secciones de la ayuda utilizando una lista de secciones. Habrá una página de ayuda por cada sección a la que pueda acceder el usuario (según su tipo). Las páginas públicas no dispondrán de este servicio. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 123 B.9 CAPA DE PRESENTACIÓN DE LA APLICACIÓN PORTLET En este capítulo se describe la capa de presentación de la aplicación Portlet. Un Portlet es una pequeña aplicación que forma parte de un conjunto mayor de aplicaciones afines que se muestran dentro de un mismo contenedor (normalmente una página Web). Un Portlet suele disponer de menos espacio que una aplicación Web de otro tipo, haciendo que sea necesario reducir el número de componentes mostrados. La GUI estará compuesta por una pequeña cabecera, el contenido principal y un pie. Cada GUI será nombrado por una clave (un acrónimo) que la identificará unívocamente. Esta clave cumplirá las siguientes reglas: Primera letra „V‟ Segunda letra „P‟ Una letra que designará la sección 2 números comenzando en 01 B.9.1 CABECERA Cada sección dispondrá de una cabecera que contendrá botones para salir de la aplicación y para mostrar la ayuda. También mostrará una línea con la ruta que lleva a la sección en la que se encuentra el usuario, cada sección padre dispondrá de un enlace a su página (P.e. “Mis Proyectos/Info Proyecto/”). B.9.2 PIE DE PÁGINA Las GUI dispondrán de un pie de página que podrá contener el nombre y la dirección de correo electrónico del administrador del sistema (será configurable desde la aplicación Web). B.9.3 INTERFACES PARA LOS USUARIOS Los participantes en los proyectos podrán hacer uso de estas interfaces para introducir su dedicación en los proyectos en los que participan y poder generar informes sobre su dedicación. 124 EINA Universidad de Zaragoza B.9.3.1 MENÚ PRINCIPAL Cuando un usuario acceda a la aplicación verá una pantalla con varios botones que le permitirán acceder a las distintas secciones. Menú de inicio (VPM01) El menú de inicio se mostrará cuando el usuario se haya identificado correctamente en el sistema. Mostrará varios botones que le llevarán a las distintas secciones. Estas secciones incluirán la gestión diaria de la dedicación, la gestión de las alarmas de tipo participante, la consulta de las alarmas de tipo tarea, la generación de informes de la dedicación, la modificación del perfil del usuario, ver la información de contacto con el administrador y la opción de salir de la aplicación. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 125 B.9.3.2 PARTICIPACIONES EN LOS PROYECTOS Este conjunto de interfaces mostrará los listados de los proyectos en los que participa el usuario y permitirá mostrar la información de una participación concreta. Cubrirá el caso de uso CU08 y los requisitos RF18 y RF19. Listado de las participaciones del usuario (VPP01) Muestra una tabla con las participaciones del usuario en los proyectos ordenados por su código. Habrá un enlace que permitirá cambiar entre la lista de proyectos activos e inactivos. La tabla mostrará un subconjunto de la lista total y el usuario podrá utilizar los botones para ir actualizando los datos mostrados. Cada entrada de la tabla contendrá el código del proyecto que enlazará con la sección que muestra la información de la participación. También mostrará el nombre y el acrónimo. Se podrá seleccionar un proyecto concreto y con los botones correspondientes se podrá ir a la secciones de alarmas del participante, dedicación y generar informes del proyecto. 132 EINA Universidad de Zaragoza Listado de las alertas de las tareas (VPA06) De forma similar a las alarmas de las tareas, muestra una lista con las alarmas en estado de alerta de tipo tarea más recientes. A diferencia que las alarmas de tipo participante, el usuario no podrá realizar ninguna acción sobre ninguna alarma. B.9.3.4 GENERAR INFORMES DE LA DEDICACIÓN Los usuarios podrán utilizar las páginas de esta sección para configurar informes de su dedicación en los proyectos en los que participan. Informe de la dedicación agregada del participante (VPI01) Mostrará un informe con la dedicación agregada que el participante ha realizado en el proyecto. Se mostrará el resultado de la petición introducida por el usuario y permitirá copiar el resultado en un archivo externo que generará la aplicación. Esta sección solo mostrará el resultado del informe de la dedicación agregada, para generar uno nuevo se deberá ir a la sección descrita más abajo (VUD02) con el enlace correspondiente. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 133 Nuevo informe de un participante (VPI02) Esta GUI consistirá en un formulario donde el usuario podrá configurar las distintas partes de un informe, en base a los proyectos en los que participa. El informe podrá contener la dedicación realizada por el usuario en el proyecto, agregada por semanas, meses o en total. B.9.3.5 GESTIÓN DEL PERFIL DEL USUARIO A continuación se describen las GUIs que utilizarán los usuarios para ver y modificar su perfil. Gestión del perfil del usuario (VPD01) De forma muy parecida a la aplicación Web, esta GUI mostrará un formulario que le permitirá cambiar alguno de sus datos personales. En otro formulario el usuario podrá cambiar su password. La interfaz contendrá enlaces que permitirán ver la lista de teléfonos y emails del usuario. 134 EINA Universidad de Zaragoza Listado de los teléfonos del usuario (VPD02) Muestra la lista de teléfonos del usuario. Cada entrada permitirá ser borrada y ser subida o bajada un nivel. Además se dispondrá de un botón para añadir un nuevo teléfono y otro para guardar los cambios. Dispondrá de enlaces para ver el perfil y la lista de emails del usuario. Lista de los emails del usuario (VPD03) De forma similar a la lista de teléfonos muestra la lista de direcciones de correo electrónico del usuario. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 135 B.9.3.6 CONTACTO CON EL ADMINISTRADOR Permite mostrar la información para poder contactar con el administrador del sistema. Información de contacto (VPC01) Muestra ciertos datos del perfil del administrador junto con la lista de teléfonos y emails. Al igual que en la aplicación Web el administrador del sistema podrá configurar esta información modificando los datos de su perfil. B.9.3.7 ACCESO AL PORTLET El Portlet contará con una interfaz que permita acceder a él. Acceso al sistema (VPS01) Esta interfaz permitirá a los usuarios que no estén conectados identificarse, mediante su login y contraseña, y poder acceder al sistema como usuarios de tipo participante. 136 EINA Universidad de Zaragoza B.9.3.8 PANTALLAZOS DE ERROR Al igual que con la aplicación Web, aquellos errores que el sistema no sepa manejar generarán pantallazos de error. Pantallazo de error (VPError) La pantalla mostrará un mensaje que describa de forma breve que ha sucedido y qué acción ha generado el error. También contendrá un botón que permitirá al usuario ir al menú principal y continuar trabajando. B.9.4 AYUDA INTEGRADA Al igual que la aplicación Web, la aplicación Portlet dispondrá de un sistema de ayuda integrada dentro de la misma. Para ver su contenido se deberá presionar el botón y con el botón se podrá volver a la sección que se estaba visualizando. Por motivos de simplificación, el sistema de ayuda del Portlet no mantendrá el contenido de la sección que se estuviera consultando. Dado el bajo número de formularios, este comportamiento apenas afectará al usuario. Se podrá navegar dentro de las distintas secciones de la ayuda utilizando la lista que se disponga. Habrá una página de ayuda por cada sección a la que pueda acceder el usuario. Las páginas públicas no dispondrán de este servicio. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 137 B.10 COPIAS DE SEGURIDAD En este capítulo se describe como llevar a cabo las copias de seguridad de los datos de la aplicación, cumpliendo con el requisito RS-2 especificado en el “Documento de Análisis de Requisitos”. Las copias de seguridad y el proceso de restauración de los datos se llevarán a cabo a través de aplicaciones ya existentes que se gestionarán de forma ajena a las aplicaciones descritas en los demás capítulos. MySQL ofrece la aplicación “mysqldump” que realiza copias de seguridad de una o más bases de datos alojadas en un servidor MySQL. Con ellas se pueden conseguir archivos con el contenido de la base de datos con un formato de texto plano que incluye el código SQL necesario para su restauración. Esta aplicación está incluida en MySQL [12]. B.10.1 REALIZAR UNA COPIA DE SEGURIDAD Realizar una copia de seguridad de los datos de la aplicación es muy sencillo con “mysqldump”. La aplicación dispone de distintos parámetros de configuración, que se pueden listar escribiendo en la línea de comandos “mysqldump –help”, o en el manual en línea en la página: “http://dev.mysql.com/doc/refman/5.0/es/mysqldump.html”. “mysqldump dedicacion01 --single-transaction --quick --extended-insert -- host=<su host> --user=<su login> --pass=<su password> --skip-add-drop-table --no-create-info --result-file=<archov salida> --tables grupo usuario teléfono email proyecto tarea participante dedicación limitededicación maxdedicación” Se debe sustituir el contenido entre corchetes angulares („<‟ y „>‟) por los datos indicados. Esto generará un fichero de texto plano que contendrá una secuencia de instrucciones SQL “insert” con los datos del sistema. B.10.2 RESTAURAR UNA COPIA Para restaurar una copia de seguridad será necesario conectarse al gestor MySQL que contenga la base de datos de la aplicación. Se recomienda que antes de iniciar este proceso se cierre el acceso a los demás usuarios de la aplicación. 138 EINA Universidad de Zaragoza En primer lugar, se deben borrar los datos existentes escribiendo en la línea de comandos: “delete from dedicacion01.<tabla> Donde “<tabla>” se debe sustituir por el nombre de cada una de las tablas. Se debe realizar esta operación en el siguiente orden de las tablas “dedicación”, “maxdedicación”, “limitededicación”, “participante”, “tarea”, “proyecto”, “teléfono”, “email”, “usuario” y “grupo”. A continuación se debe lanzar a ejecución el fichero que contiene la copia de seguridad. Desde la línea de comandos de MySQL, esto se realiza de la siguiente forma: “source <nombre_fichero>” Donde se debe sustituir “<nombre_fichero” por el nombre del archivo que contiene la copia de seguridad. PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 139 ANEXO C DOCUMENTO DE TEST DE PRUEBAS PFC: “Sistema de control de la dedicación basado en tecnología de Portlets” 141 C.1 INTRODUCCIÓN El Documento de Test de Pruebas (DTP) contiene la descripción del conjunto de pruebas que permiten verificar el correcto funcionamiento de los componentes del sistema desarrollado. Las pruebas han incluido componentes de la capa de datos, de la capa de negocio y componentes transversales. Las pruebas han sido desarrolladas de forma incremental, comenzando por los componentes inferiores, ascendiendo cada vez. Este modelo permite integrar las pruebas unitarias con las pruebas de integración, evitando tener que utilizar módulos conductores, permitiendo un desarrollo más rápido de las mismas y una mejor comprobación del correcto funcionamiento de las interfaces de cada componente. Cada conjunto de pruebas irá integrado dentro del subproyecto creado para el componente correspondiente. Para ello se utilizará la carpeta “test”, que no se integrará en el código final de la aplicación. La ejecución de los test de pruebas se realizará desde el entorno del IDE, siendo capaces de verificar el correcto funcionamiento de las distintas partes del sistema sin la necesidad de interactuar con ellas. Para la realización de estas pruebas se utilizarán los datos ficticios creados en la BD. AVISO IMPORTANTE: En este anexo solo se ha incluido una pequeña parte del DTP, a modo de ejemplo, el documento completo contiene el conjunto de pruebas de los distintos componentes del sistema.