ESCUELA SUPERIOR DE INGENIERÍA

Transcripción

1 ESCUELA SUPERIOR DE INGENIERÍA INGENIERÍA INFORMÁTICA ABFREFORJAS Ignacio Traverso Ribón 5 de septiembre de 2013

2

3 ESCUELA SUPERIOR DE INGENIERÍA INGENIERÍA INFORMÁTICA ABREFORJAS Departamento: Ingeniería Informática Director del proyecto: Iván Ruíz Rube Autor del proyecto: Ignacio Traverso Ribón Cádiz, 5 de septiembre de 2013 Fdo: Ignacio Traverso Ribón Fdo: Iván Ruíz Rube

4

5 Agradecimientos En primer lugar debo agradecer a mi familia la oportunidad de estudiar que me han brindado. Ha sido gracias a su esfuerzo diario por lo que a día de hoy puedo escribir estas líneas. En segundo lugar debo dar las gracias a Juan M. Dodero, Iván Ruíz y Manuel Palomo por haber conado en mí hace ya dos años y permitirme realizar este proyecto. Vosotros habéis sabido guiarme en términos académicos y profesionales. Ha sido un placer trabajar con vosotros y espero poder seguir haciéndolo en el futuro. En tercer lugar a mis amigos de siempre y a aquellos que compartieron conmigo una inolvidable experiencia Erasmus. Por último y no menos importante a Laura, por aceptar y apoyar todas las decisiones tan importantes que he tenido que tomar este último año.

6 Resumen Abreforjas es una herramienta para la extracción de datos de proyectos alojados en forjas públicas. Estos datos van desde la distribución del trabajo en tickets e hitos a la información de carácter general que está registrada en la forja para la clasicación del proyecto (lenguaje, sistema operativo, licencia, etc). Estos datos permitirán la obtención de conclusiones acerca de diversos aspectos (lenguajes de programación, metodologías de desarrollo, etc) y, en el caso de aquellos proyectos cuya nalidad es el aprendizaje, concederán a los alumnos la oportunidad de conocer puntuaciones orientativas en diversos puntos de la rúbrica que utilice el profesor. Palabras clave: ETL Forja Ticket Repositorio SVN PBL

7 Índice general I Prolegómeno 1 1. Introducción Motivación Alcance Glosario de términos Organización del documento Planicación Metodología de desarrollo Primer ciclo Segundo ciclo Tercer ciclo Cuarto ciclo Quinto ciclo Planicación del proyecto Organización Costes Riesgos II Desarrollo Requisitos del Sistema Situación Actual Entorno Tecnológico Fortalezas y Debilidades Objetivos del Sistema Catálogo de Requisitos Requisitos Funcionales Requisitos de Información Requisitos No Funcionales Alternativas de Solución Análisis del Sistema Modelo Conceptual Datasets Forja i

8 Milestone Métrica Proyecto Ticket Usuario_Forja Usuario_Sistema Modelo de Casos de Uso Actores Subsistema de Gestión de Usuarios Subsistema de Gestión de Datasets Subsistema de Gestión de Proyectos Modelo de Comportamiento Servicios Modelo de Interfaz de Usuario Subsistema de Gestión de Datasets Subsistema de Gestión de Proyectos Subsistema de Gestión de Usuarios Diseño del Sistema Arquitectura del Sistema Pipes and Filters Arquitectura Modelo-Vista-Controlador Arquitectura física Arquitectura lógica Parametrización del Software base D2R-Server Django Pentaho Diseño físico de datos Base de datos Vocabulario VSPF Diseño detallado de componentes Subsistema de Gestión de Datasets Subsistema de Gestión de Proyectos Subsistema de Gestión de Usuarios Procesos de Pentaho Servicios comunes Construcción del Sistema Entorno tecnológico Nivel de presentación Nivel de aplicación Nivel de persistencia Herramientas Código fuente Aplicación Web Procesos de Pentaho Scripts de Base de Datos

9 abreforjas.sql Pruebas del Sistema Estrategia Entorno de pruebas Roles Desarrollador Testeadores independientes Niveles de prueba Pruebas Unitarias Pruebas Integración Pruebas Sistema Pruebas Aceptación III Epílogo Manual de implantación y explotación Introducción Requisitos Previos Requisitos Software Requisitos Hardware Inventario de Componentes Pentaho Data Integration D2R-Server Aplicación Web Django Fichero de instalación Procedimiento de Instalación Procedimientos de Operación y Nivel de Servicio Pruebas de Implantación Instrucciones para seguir desarrollando Abreforjas Manual de usuario Introducción Características Requisitos previos Requisitos del cliente Requisitos del servidor Uso del Sistema Registrar Usuario Login Usuario Editar Usuario Logout Crear Dataset Actualizar Dataset Eliminar Dataset Ver Dataset Ver Proyecto

10 Ver Métricas de Proyecto Ver Grácas de Proyecto Acceder a D2R-Server Conclusiones Objetivos alcanzados Lecciones aprendidas Costes Trabajo futuro Bibliografía 135 GNU Free Documentation License APPLICABILITY AND DEFINITIONS VERBATIM COPYING COPYING IN QUANTITY MODIFICATIONS COMBINING DOCUMENTS COLLECTIONS OF DOCUMENTS AGGREGATION WITH INDEPENDENT WORKS TRANSLATION TERMINATION FUTURE REVISIONS OF THIS LICENSE RELICENSING ADDENDUM: How to use this License for your documents

11 Índice de guras 2.1. Diagrama de Gantt Modelo conceptual Modelo de Casos de Uso Actores Diagrama de casos de uso para la gestión de usuarios Diagrama de casos de uso para la gestión de datasets Diagrama de casos de uso para la gestión de proyectos Diagrama de Servicios Diagrama de secuencia Actualizar Dataset Diagrama de secuencia Crear Dataset Diagrama de secuencia Eliminar Dataset Diagrama de secuencia Visualizar Dataset Diagrama de secuencia Visualizar Datos Proyecto Diagrama de secuencia Visualizar Datos Proyecto Diagrama de secuencia Login Usuario Diagrama de secuencia Logout Usuario Diagrama de secuencia Registrar Usuario Modelo de Navegación de la interfaz gráca Interfaz Gráca Gestión de Datasets Interfaz Gráca Actualizar Dataset Interfaz Gráca Crear Dataset Interfaz Gráca Ver Dataset Interfaz Gráca Gestión de Proyectos Interfaz Gráca Métricas Interfaz Gráca Editar Usuario Interfaz Gráca Login Usuario Interfaz Gráca Registrar Usuario Esquema de Pipes and Filters Esquema del MVC Arquitectura física del sistema Arquitectura lógica del sistema Diseño de la Base de Datos Diseño del vocabulario VSPF Diagrama de componentes del sistema Diagrama de interacción Actualizar Dataset Diagrama de comportamiento Actualizar Dataset v

12 5.10. Diagrama de comportamiento Crear Dataset Diagrama de interacción Eliminar Dataset Diagrama de comportamiento Eliminar Dataset Diagrama de interacción Ver Dataset Diagrama de comportamiento Ver Dataset Diagrama de comportamiento Ver Lista Datasets Diagrama de interacción Ver Grácas Diagrama de comportamiento Ver Grácas Diagrama de interacción Ver Métricas Diagrama de comportamiento Ver Métricas Diagrama de interacción Ver Proyecto Diagrama de comportamiento Ver Proyecto Diagrama de comportamiento Editar Usuario Diagrama de comportamiento Login Usuario Diagrama de comportamiento Registrar Usuario Job Assembla Discoverer Transform Assembla Discoverer Job Generic Wrapper Job Integration Generic Process Transform Assembla to Database Job Redmine Discoverer Transform Redmine Process Job Metricas Pantalla de inicio de Abreforjas Botón de Registro Formulario de Registro Botón de Login Formulario de Login Formulario de Editar Usuario Formulario de Cambio de Contraseña Botón de Logout Página de inicio Formulario Crear Dataset Formulario Actualizar Dataset Página General Dataset Página General Proyecto Página Métricas de Proyecto Página Grácas de Proyecto Página de información de proyectos en D2R Diagrama de Gantt Real

13 Índice de cuadros 2.1. Desglose de tareas planicadas OBJ OBJ OBJ RQF RQF RQF RQF RQF RQF RQF RQF IRQ IRQ IRQ IRQ IRQ IRQ IRQ IRQ NRQ NRQ NRQ NRQ NRQ NRQ vii

14

15 Parte I Prolegómeno 1

16

17

18

19 Capítulo 1 Introducción 1.1. Motivación El desarrollo de los procesos de aprendizaje está cada día más apoyado por el uso de diversas herramientas software. Sin embargo la evaluación no se ha adaptado a los nuevos tiempos y sigue haciéndose del modo convencional, no aprovechándose los datos recolectados por las mismas. Entre estos sistemas se encuentran las forjas de software. Las forjas asisten al desarrollo colaborativo del software ofreciendo herramientas para la gestión temporal y/o planicación del proyecto y para el alojamiento del código fuente. Entre las primeras herramientas se encuentran la gestión de milestones o hitos y tickets. Los milestones permiten planicar el desarrollo de un proyecto en base a una serie de deadlines. En la metodología Scrum se corresponde con el concepto de sprint, aunque puede ser considerado como una iteración en las metodologías iterativas. Cada milestone tiene asociado una serie de tickets o tareas que deben ser acometidas antes de la fecha de vencimiento del mismo. En cada ticket se describe textualmente la tarea a llevar a cabo y tiene asociado el usuario que debe solventarla así como un estado (pendiente, arreglado, en pruebas, etc) y la posibilidad de asignarle una prioridad. De esta manera, el desarrollador sabe qué tareas debe llevar a cabo (las que tiene asignadas) y en qué orden debe realizarlas (en base a la fecha de vencimiento de los milestones y las prioridades de las tareas). Para almacenar el código fuente, las forjas ofrecen repositorios de código (Subversión o Git frecuentemente), también llamados sistemas de control de versiones. Estas herramientas facilitan el desarrollo colaborativo del software ofreciendo un lugar donde alojar la última versión del software, así como un histórico de las mismas. De esta manera se evita la existencia de varias versiones distribuidas en los equipos de los diferentes desarrolladores y la aparición de conictos y complicaciones a la hora de construir la versión nal a partir de las diversas versiones que los desarrolladores posean, pues las fusiones de las versiones se realizan en cada commit o subida del código al repositorio. Estos sistemas son capaces incluso de fusionar diferentes versiones de un mismo archivo cuando las diferencias entre las mismas se producen en líneas distintas. De esta manera se permite que, aun en el caso de que dos desarrolladores debieran trabajar en el mismo chero y al mismo tiempo (lo que indica una mala modularización del software), si cada uno debe realizar modicaciones en partes diferentes del chero distintas los conictos sean resueltos automáticamente por el sistema de control de versiones. En estos sistemas se registran, por tanto, las modicaciones realizadas por los diversos usuarios, en qué fecha fueron realizadas, cuantas líneas de código conllevaron, etc. Abreforjas se ha desarrollado como herramienta de apoyo a la investigación y al aprendizaje 5

20 dentro del grupo SPI-FM del departamento de Ingeniería Informática de la Universidad de Cádiz. Una de las líneas de investigación de dicho grupo trabaja en la evaluación asistida de proyectos software que siguen el enfoque PBL (Project Based Learning). Es aquí donde se sitúa Abreforjas, que nace con el objetivo de extraer datos referentes a proyectos software alojados en forjas privadas o públicas y aumentar su visibilidad de cara al usuario, de manera que el supervisor no tenga que navegar por la web de la forja en búsqueda de cada proyecto ni tenga que lidiar con las diferentes APIs. Abreforjas facilitará datos objetivos extraídos simples y agregados en base a datos presentes en la forja. De esta manera se alivia la carga de trabajo del supervisor, que no tiene que buscar todos estos datos manualmente. Aunque Abreforjas facilitará directamente la información de métricas simples, por si estas no fueran sucientes para el usuario, los datos serán publicados en base a un vocabulario en formato RDF para facilitar tanto su consumo por parte de aplicaciones externas como la interconexión con otras fuentes de datos mediante las tecnologías Linked Data Alcance En la actualidad, la información referente a los proyectos es visualizada directamente en las webs de las forjas correspondientes. Esto hace que el revisor navegue de una web a otra apuntando ciertos parámetros de interés para posteriormente realizar una valoración personal, la cual es una tarea pesada, tediosa e ineciente. El revisor deberá acceder a la sección de gestión de tickets y observar cómo se distribuyeron el trabajo los miembros del equipo, qué usuario fue el que creó más tickets, quién solventó más. Es por ello que la información referente a los milestones también es relevante y el revisor deberá comprobar si el milestone se cerró en el tiempo previsto, qué usuario la creó, si la distribución de tickets entre los milestones es coherente, etc. Éstos sólo son algunos ejemplos de posibles métricas que un revisor podría utilizar para valorar el proceso de desarrollo de un proyecto. Puede haber otras muchas que requieran un nivel superior de agregación de datos o que conlleven relaciones más complejas entre los conceptos que se han citado. Otro factor importante en la valoración de proyectos alojados en forjas es el repositorio. Los más comunes en la actualidad son aquellos basados en Git y Subversion. A partir de la información que se registra en estos sistemas se puede conocer qué usuario realizó más commits, quién escribió más líneas, cómo se distribuyó temporalmente el trabajo, etc. Existen herramientas como StatSVN [StatSVN, 2013] que proporcionan información en formato visual de algunas de estas estadísticas, pero el ser HTML su formato de salida complica la importación de datos desde otra aplicación. Otras herramientas con CVSAnaly [Libresoft, 2012] hacen un análisis más exhaustivo de los repositorios y almacenan la información en una base de datos relacional, lo que hace su manipulación mucho más sencilla Glosario de términos Forja: Plataforma de desarrollo colaborativo de software Git: Sistema de control de versiones libre y distribuido. Se usa en el desarrollo del kernel de Linux. Linked Data: Describe un método de publicación de datos estructurados de forma que puedan ser enlazados y llegar a ser más útiles que aislados. Se construye sobre los estándares de la Web como HTTP, RDF y URIs, pero en lugar de servir datos aptos para ser

21 consumidos por los humanes, la información de comparte de manera que pueda ser leída automáticamente por los ordenadores. Milestone: Concepto utilizado en la gestión de proyectos para marcar en la línea temporal un punto de especial importancia, ya sea por la llegada de un evento, la nalización de una fase, etc. PBL: Project Based Learning es un estilo colaborativo de educación en el que los profesores intentan que los alumnos retengan el conocimiento a través del desarrollo de proyectos que se pueden aplicar en la vida real, en lugar limitarse únicamente a explicar conceptos teóricos. Subversion: Popular sistema de control de versiones centralizado. Ticket: Unidad de trabajo para la mejora de un sistema informático. Puede signicar el arreglo de un fallo, la implementación de una característica solicitada, etc. Web Semántica: Animando a la inclusión de contenido semántico, la Web Semántica lucha por convertir la web actual, dominada por datos semi o desestructurados en la Web de los datos. Provee un framework común que permite que los datos sean compartidos y reutilizados por diferentes aplicaciones, empresas y comunidades Organización del documento En el documento se presenta primero la planicación llevada a cabo para el desarrollo del proyecto así como los costes del mismo. En el apartado de desarrollo se comienza con el análisis de requisitos, incluyendo un estudio de la situación en la que se encontraba el grupo de investigación previamente al desarrollo de este proyecto. En los capítulos 4, 5 y 6 se tratará el análisis, el diseño del sistema y la implementación del mismo. El séptimo contendrá las pruebas llevadas a cabo con el sistema. Los últimos capítulos se corresponderán con el manual de usuario, el manual de instalación y explotación, las conclusiones y la bibliografía utilizada.

22

23 Capítulo 2 Planicación En esta sección se describen todos los aspectos relativos a la planicación del proyecto: metodología, organización, costes, planicación y gestión de riesgos Metodología de desarrollo El modelo de desarrollo de software utilizado ha sido el iterativo e incremental. Con este modelo de desarrollo se han creado versiones del producto que poco a poco han ido creciendo en prestaciones hasta llegar al producto nal. A continuación se describen las funcionalidades que tenían cada una de estas versiones Primer ciclo El primer ciclo de abreforjas consistió en: Estudio por parte del alumno de los conceptos API ReST, XML, RDF y ontologías de la web semántica. El estudio de las APIs de diferentes forjas para el diseño de un modelo común de datos que abarcara toda la información de interés que ofrecen las diversas forjas. Familiarización con el software Pentaho BI para utilizarlo como herramienta ETL en la extracción de datos vía ReST. El desarrollo de los procesos en Pentaho para la extracción de datos de Sourceforge Segundo ciclo En este segundo ciclo se produjo un ligero giro en el proyecto. Los procesos programados para SourceForge en Pentaho no funcionaban correctamente por diversas causas que se explicarán detalladamente en el desarrollo de este documento. Es por ello que se pasó al desarrollo de los procesos para la forja Assembla. La elección de esta forja no es baladí. Se escogió la misma por ser la que alojaba proyectos realizados en asignaturas impartidas por docentes del grupo de investigación y por la posibilidad de utilizar los datos extraídos de dichos proyectos para la sustentación de artículos de investigación. Se llevó a cabo, por tanto: 9

24 Modicaciones en el modelo de datos Desarrollo de los procesos para la extracción de datos de Assembla Tercer ciclo En este ciclo Abreforjas se desvió de sus objetivos iniciales de análisis de los datos ofrecidos por las APIs de las diversas forjas software y se trató de extraer información de los repositorios de código y del propio código fuente. Por tanto, se llevaron a cabo: Estudio de las herramientas CVSAnaly y Sonar. Integración de CVSAnaly con los procesos de Pentaho desarrollados. Intento de integración de Sonar con los mismos procesos. Finalmente dicha integración no concluyó exitosamente por la imposibilidad de automatizar el análisis del código fuente con Sonar de diversos proyectos. Estudio y obtención de diversas métricas de los proyectos escogidos de Assembla Cuarto ciclo Concluido el desarrollo de Assembla se prosiguió con la obtención de datos de otra forja que también alojara proyectos llevados a cabo por alumnos en asignaturas anes al grupo de investigación. Al tener el grupo una forja Redmine que cumplía con los requisitos mencionados se procedió a: Desarrollar los procesos Pentaho para obtener datos vía Redmine API. Intento de generalización de dichos procesos para hacerlos válidos para ambas forjas. Este intento no fructicó por las diferencias a la hora de trabajar con ambas APIs. Adaptación del modelo de datos para hacerlo compatible con Redmine. Modicación de los procesos de Assembla para adaptarlos al nuevo modelo de datos Quinto ciclo Llegados a este punto se consideró que los datos extraídos de las forjas era suciente y se procedió al desarrollo de una interfaz visual para Abreforjas. Los pasos realizados fueron: Toma de decisión de hacer de Abreforjas una aplicación web. Elección del framework de desarrollo web. Diseño y desarrollo de la web de abreforjas Desarrollo de la parte de servidor de la aplicación Diseño de una ontología para la publicación de los datos extraídos, tomando como base el vocabulario ADMS.SW Integración de la aplicación web con D2R-Server para la publicación de los datos extraídos en formato RDF en base a la ontología diseñada.

25 Tarea Fecha de inicio Fecha de n Descripción A1 01/09/11 Estudio de conceptos A2 Estudio APIs y diseño modelo A3 Familiarización Pentaho A4 01/12/11 Desarrollo SourceForge B1 01/12/11 20/01/12 Desarrollo Assembla C1 01/03/12 Estudio CVSAnaly y Sonar C2 Integración CVSAnaly C3 Integración Sonar C4 30/04/12 Obtención Métricas D1 01/05/12 Desarrollo Redmine D2 Intento generalización procesos D3 Adaptación modelo de datos D4 25/07/12 Pruebas con Assembla y Redmine E1 02/04/13 Estudio frameworks web E2 HTML y CSS de la web E3 Desarrollo Aplicación Web E4 Desarrollo Ontología E5 26/07/13 Integración con D2R-Server 2.2. Planicación del proyecto Cuadro 2.1: Desglose de tareas planicadas En la tabla 2.1 se desglosan las tareas en las que se descompone la planicación de este proyecto. La letra inicial de la etiqueta de cada tarea indica al ciclo al que corresponde. Así la A corresponde al primer ciclo, la B al segundo, etc Organización En el desarrollo de este proyecto han intervenido Juan M. Dodero e Iván Ruiz Rube, miembros del grupo de investigación SPI-FM, como clientes proporcionando los objetivos y requisitos que debía cumplir este proyecto así como testeadores del mismo. Servidor, alumno de la Universidad de Cádiz, ha sido el único desarrollador del proyecto, actuando por tanto como analista, diseñador y desarrollador al mismo tiempo. Para testear el software se han utilizado proyectos alojados en las forjas de Assembla (pública) y Redmine (privada de la ESI) que fueron desarrollados por equipos de alumnos matriculados en las asignaturas Comercio Electrónico e Ingeniería Web, así como proyectos nales de carrera. El hardware necesario para el desarrollo y puesta en producción de este proyecto han sido dos equipos. Durante el desarrollo se utilizó el portátil personal del alumno y para la puesta en producción un servidor de los disponibles por el grupo de investigación. El software utilizado durante el desarrollo de este proyecto comprende los siguientes: Ubuntu o como sistema operativo. Pentaho BI como herramienta para el desarrollo de las interacciones con las diversas APIs de las forjas de software e integración de la información.

26 Figura 2.1: Diagrama de Gantt

27 MySQL como sistema de gestión de base de datos para almacenar un modelo de datos común que almacene los datos procedentes de las diversas forjas. Python y Django como framework para el desarrollo de la aplicación web. Celery como gestor de tareas para la ejecución programada de los procesos desarrollados en Pentaho BI. HTML, Javascript y Twitter Bootstrap para el desarrollo del front-end de la aplicación web. Redmine y RedIRIS como forjas de código con Subversion como Sistema de Control de Versiones. Neologism para la denición de un vocabulario Linked Data en el que publicar los datos extraídos de las forjas. El vocabulario desarrollado utiliza ADMS.SW como base. D2R-Server para la publicación de los datos almacenados en la base de datos en un formato Linked-Data. APIs REST de las forjas Redmine y Assembla mediante las cuales se hacen peticiones a las mismas y se obtienen los datos que posteriormente son integrados en el modelo común Costes Aunque la organización cuenta con la infraestructura mencionada en el apartado anterior, para la realización de este proyecto sólo es necesario un único equipo PC con GNU/Linux y conexión a internet. Las herramientas que se utilizarán tienen licencia libre por lo que tampoco requiere coste. Para la realización de este proyecto fueron necesarias 1240 horas de trabajo o 7,75 personas/mes. En el gantt 2.1 se puede observar que el proyecto está planicado para acabarse en 310 días, aunque con una jornada de trabajo de 4 horas/día. La categoría de los trabajadores será: T. S. Apoyo a la Docencia e Investigación. Salario base mensual de los trabajadores + Complemento categoría: 2.746,65 e[ccoo, 2010] Total estimado = 7,75 trabajadores x 2.746,65 e= ,53 e 2.5. Riesgos Se identican tres riesgos en Abreforjas: 1. Cambios en las licencias de las herramientas auxiliares utilizadas. 2. Cambios en la política de publicación de datos de las forjas con las que se ha trabajado. 3. Cambios en el formato de las APIs de las forjas anteriormente citadas.

28 El primer riesgo no es muy peligroso. Simplemente implica que en futuras versiones de Abreforjas habría que permanecer utilizando la última versión de las respectivas herramientas con licencia compatible. El segundo riesgo es más delicado, pues el diseño del modelo de datos conlleva unas restricciones y la obligatoriedad o no de incluir ciertos datos, las cuales se verían afectadas por cambios en la política de publicación. Este tipo de cambios podrían dejar inutilizable una versión de Abreforjas, aunque lo lógico es que el cambio no fuera inmediato, sino avisado con antelación por parte de los desarrolladores de dichas APIs. De hecho, lo lógico sería que la API actual pasara a ser considerada obsoleta, pero en ningún caso fuera desactivada. En este último caso habría que modicar el diseño del modelo de datos y algunos procesos desarrollados en Pentaho, aunque la aplicación web no debería verse afectada por el desacople entre ambas partes del proyecto. Un cambio así de radical en la API dejaría inservible no sólo a Abreforjas, sino a todas aquellas aplicaciones que hicieran uso de la misma. Es un riesgo que debe ser asumido. El tercer riesgo también es delicado. El formato de las peticiones a las APIs será almacenado en una tabla de la base de datos, de manera que determinados cambios sean relativamente fácilmente salvables. Sin embargo la inclusión de nuevos parámetros en la URL o de cabeceras en las peticiones ReST conllevarían el mismo tipo de cambios que el riesgo anterior. Es, por tanto, un riesgo que debe ser asumido y cuya mitigación es, al igual que en el caso anterior, el desacople máximo de las diferentes partes de la aplicación, de manera que los cambios no se expandan por la misma sino queden localizados en ciertos cheros. Tanto el segundo como el tercer riesgos fueron mitigados en tiempo de diseño y el resultado puede verse en el apartado 5.1.4

29 Parte II Desarrollo 15

30

31

32

33 Capítulo 3 Requisitos del Sistema 3.1. Situación Actual En esta sección se describirá la situación actual del grupo de investigación en el que se desarrolla Abreforjas Entorno Tecnológico Antes del comienzo de este proyecto el entorno tecnológico de la organización constaba de dos equipos: un equipo Mac que actuaba como servidor y que poseía varias máquinas virtuales instaladas con diversos sistemas operativos (Windows y Ubuntu principalmente) y otro equipo menos potente que servía una forja Redmine para el desarrollo de PFCs y artículos de investigación del grupo. Ambos equipos estaban autorizados por los administradores de red de la organización para servir webs y otros servicios al exterior de la misma. De las máquinas virtuales instaladas fue una de las que tenía Ubuntu instalado la designada para el desarrollo del proyecto y que como software instalado tenía Pentaho BI y Oracle como sistema de gestión de base de datos así como Apache y Tomcat como servidores web Fortalezas y Debilidades No hay un sistema actualmente parecido a Abreforjas, por lo que los supervisores de los proyectos realizan la evaluación de los mismos de manera manual a partir de las interfaces que las propias forjas ofrecen. Esto es una tarea tediosa que llega a ser insostenible cuando el número de proyectos y usuarios es relativamente elevado. El supervisor debe buscar cada uno de los proyectos a su cargo en la forja y recoger manualmente los datos que le interesen correspondientes a los milestones (nombre, descripción, fechas de creación y vencimiento), tickets (fechas de creación y n, estado, prioridad, usuarios implicados en el mismo), etc. y calcular posteriormente los datos agregados para realizar la evaluación del estado actual del proyecto. Algunas forjas como Assembla ofrecen a partir de su interfaz web una serie de métricas y grácas de los proyectos alojados en ellas. De esta manera se presentan muchos datos ya agregados que facilitan la tarea del supervisor. Sin embargo esto no es algo común a todas las plataformas y el supervisor sigue teniendo que navegar proyecto por proyecto para buscar y anotar las métricas que a él le resulten útiles. 19

34 3.2. Objetivos del Sistema En esta sección se especican los objetivos de Abreforjas. Facilitar acceso a los datos de proyectos Versión 1.0 (11/04/2013) Descripción Abreforjas facilitará el acceso a los datos y/o metadatos de proyectos software de manera uniforme y centralizada. Cuadro 3.1: OBJ-1 Obtener masa de datos Versión 1.0 (11/04/2013) Descripción Uno de los objetivos de Abreforjas es obtener una cantidad suciente de datos referentes a proyectos libres alojados en forjas públicas para poder realizar análisis de los mismos posteriormente (análisis estadístico, minería de datos, etc). Cuadro 3.2: OBJ-2 Publicación Linked Data Versión 1.0 (11/04/2013) Descripción Abreforjas publicará tanto los datos extraídos de las forjas como los resultados de las métricas de manera uniforme y en un formato abierto aprovechando las tecnologías que las tecnologías Linked Data ofrecen. Cuadro 3.3: OBJ Catálogo de Requisitos Requisitos Funcionales Gestión de Datasets Observar Datasets Versión 1.0 (11/04/2013) Descripción El usuario debe ser capaz de observar todos los datasets que están registrados en el sistema. Cuadro 3.4: RQF-1

35 Crear Dataset Versión 1.0 (11/04/2013) Descripción Un usuario logueado deberá ser capaz de crear un nuevo dataset compuesto de datos referentes a un conjunto de proyectos de una determinada forja. Abreforjas será capaz de, a partir de las APIs ofrecidas por las diferentes forjas, extraer la información general de los proyectos. El usuario podrá proporcionar como entrada el conjunto de proyectos que le son de interés. En caso de que no indique ninguno se descargarán todos los de la forja si esta así lo permitiera. La información relevante se denirá en los requisitos de información. Cuadro 3.5: RQF-2 Actualizar Dataset Versión 1.0 (11/04/2013) Descripción Un usuario logueado deberá ser capaz de actualizar un determinado dataset. Para ello Abreforjas deberá volver a conectarse a las forjas y repositorios para obtener información actual. Esta tarea puede ser ordenada explícitamente por el usuario o programada para realizarse periódicamente. Cuadro 3.6: RQF-3 Eliminar Dataset Versión 1.0 (11/04/2013) Descripción Un usuario logueado podrá eliminar la información referente a un dataset y los datos referentes a proyectos asociados a dicho dataset. Gestión de Proyectos Cuadro 3.7: RQF-4 Cálculo de métricas Versión 1.0 (11/04/2013) Descripción Abreforjas será capaz de, a partir de los datos extraídos de las fuentes ya citadas, calcular una serie de métricas para los proyectos del dataset que se le indique. Cuadro 3.8: RQF-5 Métricas en formato textual y visual Versión 1.0 (11/04/2013) Descripción De cada proyecto, además de su información general, se publicarán en formato textual todas las métricas calculadas y en formato visual aquellas que resulten más interesantes y cuya representación gráca facilite su compresión. Cuadro 3.9: RQF-6

36 Linked Data Publicación de datos en la web Versión 1.0 (11/04/2013) Descripción Abreforjas publicará los datos extraídos en formato RDF con una extensión propia del vocabulario Asset Description Metadata Schema for Software (ADMS.SW). Dicha extensión podría integrarse en el LOD Cloud. Cuadro 3.10: RQF-7 Responder consultas SPARQL Versión 1.0 (11/04/2013) Descripción Abreforjas debe ser capaz de responder a consultas SPARQL que realicen los usuarios sobre los datos RDF que publica Requisitos de Información Cuadro 3.11: RQF-8 Datos especícos Proyecto Nombre Descripción Homepage Tipo de repositorio (SVN o Git) Datasets con los que está relacionado Usuarios que participan en él Resultados de las métricas. Cuadro 3.12: IRQ-1 Datos especícos Usuario del Sistema Login Contraseña Cuadro 3.13: IRQ-2

37 Datos especícos Usuario de Forja Nombre Login Forja a la que pertenece Cuadro 3.14: IRQ-3 Datos especícos Dataset Nombre Descripción Forja a la que pertenece Fecha de última actualización Frecuencia de actualización Usuario que lo creó Cuadro 3.15: IRQ-4 Datos especícos Forja Nombre Descripción Formato de las peticiones a realizar a su API Cuadro 3.16: IRQ-5

38 Datos especícos Ticket Identicador que el propio sistema de gestión proporciona Fecha de creación Fecha de actualización Fecha de compleción Título Descripción Autor Usuario al que está asignado Estado (abierto, cerrado, test) Prioridad Milestone al que pertenece (si lo hubiera) Proyecto al que pertenece Cuadro 3.17: IRQ-6 Datos especícos Milestones Identicador que el propio sistema de gestión proporciona Fecha de creación Fecha de vencimiento Fecha de compleción Título Descripción Autor Estado Proyecto al que pertenece Cuadro 3.18: IRQ-7

39 Datos especícos Métricas Nombre Descripción Tipo de métrica (pertenece a un proyecto o a un usuario dentro de un proyecto) Cuadro 3.19: IRQ Requisitos No Funcionales Requisitos de Tecnología Pentaho BI Versión 1.0 (11/04/2013) Descripción Para la recolección de datos de las diversas forjas se utilizará la herramienta Kettle de la suite de código abierto Pentaho BI. Cuadro 3.20: NRQ-1 Requisitos de Interoperabilidad Comunicación con las forjas Versión 1.0 (11/04/2013) Descripción Abreforjas se conectará a las APIs de las forjas. Los permisos para poder obtener respuesta de las mismas quedan fuera del ámbito del proyecto. En el caso de Assembla, los datos son públicos por lo que, siempre que no haya un cambio de política no habrá problemas. En el caso de Redmine es necesario proporcionar una clave de un usuario con rol de administrador para obtener los datos de los usuarios registrados. Cuadro 3.21: NRQ-2 Requisitos de Seguridad Cifrado de contraseñas Versión 1.0 (11/04/2013) Descripción Las contraseñas de los usuarios se almacenarán cifradas, preferiblemente y por mayor seguridad con un algoritmo de un sólo sentido. Cuadro 3.22: NRQ-3

40 Requisitos de Fiabilidad Tiempo medio entre fallos Versión 1.0 (11/04/2013) Descripción El tiempo medio entre fallos en el sistema Abreforjas será inferior a 3 días. Requisitos de Usabilidad Cuadro 3.23: NRQ-4 La facilidad con la que los supervisores puedan utilizar Abreforjas para extraer los datos de los proyectos de sus asignaturas o equipo de trabajo es uno de los objetivos principales de la herramienta. Abreforjas está orientado a usuarios con cierto conocimiento de los conceptos de forja, tickets o repositorio. No obstante la interfaz debe ser fácil de usar, entendible e intuitiva. Requisitos de Eciencia Abreforjas trabaja realizando peticiones a webs externas. Es por ello que la velocidad de extracción y carga de datos no sólo depende de ella, sino de la conexión a internet disponible y la capacidad de dichas webs para responder a las peticiones en cada momento. Es por ello que no se puede imponer ningún requisito a la aplicación mas que extraiga los datos y los almacene con la mayor brevedad posible. Requisitos de Mantenibilidad Extensibilidad Versión 1.0 (11/04/2013) Descripción El proyecto que aquí se presenta es sólo la primera piedra de un software más ambicioso que trabajará con más forjas e incluso formará parte de un ecosistema de aprendizaje donde quizás haya que analizar otro tipo de evidencias basadas en wikis u otros software, por lo que la extensibilidad de Abreforjas también es un requisito importante para su desarrollo. Requisitos de Portabilidad Cuadro 3.24: NRQ-5 Semiportabilidad Versión 1.0 (11/04/2013) Descripción Abreforjas podrá ser accedido desde cualquier sistema operativo o navegador. Sin embargo la ejecución de los procesos subyacentes a la interfaz web tendrá lugar en un sistema Linux. Cuadro 3.25: NRQ-6

41 3.4. Alternativas de Solución En este apartado se indican las alternativas contempladas para cubrir ciertas necesidades de Abreforjas así como también se describen sus características principales. Sistemas de Gestión de Bases de Datos Oracle: Reconocido SGBD de código cerrado aunque con versión gratuita para el mundo académico. Al ser un sistema muy potente consume muchos recursos y posee una gran variedad de funcionalidades, la mayoría de las cuales no serán utilizadas por nuestro sistema. MySQL: Menos potente que el anterior pero con licencia libre. Se considera este sistema suciente para nuestras necesidades actuales ya que no se va a trabajar con almacenes de datos, bases de datos distribuidas o balanceo de carga entre varios sistemas. El sistema sólo constará de una base de datos relacional con tablas con relaciones simples entre las mismas. Frameworks para el desarrollo de aplicaciones web Django: Popular framework con Python como lenguaje base. Posee una amplia variedad de funcionalidades incorporadas y al tener Python como base permite el desarrollo rápido de la aplicación por ser un lenguaje sencillo tanto en cuanto a sintaxis como a semántica. Se optó nalmente por este framework por tener el desarrollador principal experiencia con Python y no con los lenguajes de los dos siguientes frameworks. Rails: Framework de aplicaciones web de código abierto escrito en el lenguaje de programación Ruby, siguiendo el paradigma de la arquitectura Modelo Vista Controlador. Cada día alcanza índices más elevados de popularidad. Symfony: Framework para el desarrollo web con PHP. Posee una comunidad bastante amplia debido a su antigüedad. También sigue el Modelo Vista Controlador. Sistemas de programación de ejecución de tareas Crontab: Propio de los sistemas operativos UNIX. Muy potente aunque dependiente del sistema operativo. Celery: Es independiente del sistema operativo por lo que permite un menor solapamiento entre las aplicaciones y no evita tener que modicar archivos propios del sistema. Publicación Linked Data D2R-Server: Realiza un mapeo automático entre un sistema de bases de datos relacional con un vocabulario Linked Data. Ofrece los datos tanto a partir de una interfaz web como en cheros RDF. Triplify: Liviano plugin para aplicaciones web que permite publicar un una base de datos relacional en formato RDF, JSON o Linked Data. Al igual que D2R-Server provee al usuario de un endpoint SPARQL.

42 Obtención de datos de forjas FLOSSmole: Se trata de un conjunto de datos organizado en diferentes esquemas, según la forja de la que sean los datos, que se puede obtener mediante cheros sql o con acceso directo a la base de datos previo permiso de la comunidad. El valor añadido que Abreforjas presenta con respecto a estos datasets es que los datos con Abreforjas son actuales y el usuario tiene libertad de actualización de los mismos, mientras que en el caso de FLOSSmole los datos se actualizan con una frecuencia determinada que el usuario no puede controlar y se depende en este caso de los administradores de la comunidad. Además Abreforjas integra todos los datos en un modelo común, mientras que FLOSSmole mantiene un esquema para cada forja.

43 Capítulo 4 Análisis del Sistema Esta sección cubre el análisis del sistema de información a desarrollar, haciendo uso del lenguaje de modelado UML Modelo Conceptual A partir de los requisitos de información, se desarrollará un diagrama conceptual de clases 4.1 UML, identicando las clases, atributos, relaciones, restricciones adicionales y reglas de derivación necesarias Datasets Atributo fecha_actualización frecuencia_actualización URL_base Descripción Fecha de actualización del dataset. Frecuencia de actualización automática del dataset. URL base de la instancia concreta de la forja Forja Atributo nombre URIs_API Descripción Fecha de actualización del dataset. URLs de las diversas peticiones a realizar a la API de la forja correspondiente Milestone Atributo descripción fecha_compleción fecha_creación frecuencia_vencimiento IDExterno titulo Descripción Descripción que el creador del milestone dio al mismo. Fecha en la que se completó el milestone. Fecha en la que se creó el milestone. Fecha en la que el milestone debería estar previsiblemente nalizado. Identicador que la forja le da al milestone. Nombre que el creador del milestone dio al mismo. 29

44 Figura 4.1: Modelo conceptual

45 Métrica Atributo descripción nombre Descripción Breve descripción de la métrica. Nombre de la métrica Proyecto Atributo descripción fecha_creación homepage nombre Descripción Descripción que el creador del proyecto dio al mismo. Fecha en la que el proyecto se dio de alta en la forja. Página web del proyecto. Nombre del proyecto Ticket Atributo descripción estado fecha_actualización fecha_compleción fecha_creación IDExterno prioridad usuario_creador usuario_responsable Descripción Descripción que el creador del ticket dio al mismo. Estado en el que se encuentra el ticket (abierto, prueba, cerrado) Fecha de actualización del ticket Fecha de compleción del ticket Fecha de creación del ticket Identicador que la forja proporciona a este ticket Prioridad con la que se debe llevar a cabo la tarea descrita en el ticket Usuario que dio de alta el ticket en la forja y lo asignó a otro usuario. Usuario que debe llevar a cabo la tarea descrita en el ticket Usuario_Forja Atributo nickname nombre Descripción Correo electrónico del usuario Nombre de usuario. Nombre real del usuario Usuario_Sistema Atributo contraseña nickname Descripción Contraseña del usuario. Correo electrónico. Nombre de usuario.

46 4.2. Modelo de Casos de Uso Actores Figura 4.2: Modelo de Casos de Uso En este apartado se describirán los diferentes roles que juegan los usuarios que interactúan con el sistema. Los actores pueden ser roles de personas físicas, sistemas externos o incluso el tiempo (eventos temporales). Puede observarse el diagrama de actores en la gura 4.3 Usuario Usuario Versión 1.0 (30/07/2013) Descripción Usuario de la aplicación web. No tiene por qué estar logueado ni registrado en el sistema. Usuario logueado Usuario logueado Versión 1.0 (30/07/2013) Descripción Usuario logueado y por tanto registrado en el sistema. Tiempo Tiempo Versión 1.0 (30/07/2013) Descripción El transcurso del tiempo activará determinados casos de uso.

47 Figura 4.3: Actores Subsistema de Gestión de Usuarios En la gura 4.4 pude visualizarse el diagrama de este caso de uso. Registrar Usuario Registrar Usuario Versión 1.0 (30/07/2013) Descripción Un usuario se podrá registrar en el sistema teniendo a partir de ese momento permisos de escritura en la aplicación. Escenario y tipo Descripción y pasos Principal 1. Un usuario indica que quiere registrarse en el sistema 2. El usuario introduce su seudónimo, su , su contraseña y la vericación de la misma 3. El sistema comprueba que el formato de los datos es válido 4. El sistema comprueba que no existe otro usuario con el mismo seudónimo o 5. El sistema registra al usuario Continúa en la siguiente página

48 Escenario y tipo Formato Incorrecto (Excepción) Cuadro 4.1 Continuación de la página anterior Descripción y pasos 3a El formato de alguno de los campos requeridos no es correcto y así lo indica el sistema al usuario, solicitándole que corrija el error. Usuario existente (Excepción) 4a Ya existe un usuario con el mismo seudónimo o en el sistema. El sistema solicita al usuario que introduzca un seudónimo o distinto. Loguear Usuario Login Versión 1.0 (30/07/2013) Descripción Loguear al usuario con el nombre de usuario y contraseña especicados. El usuario debe estar registrado en el sistema para que este caso de uso tenga éxito. Escenario y tipo Descripción y pasos Principal 1. Un usuario quiere loguearse en el sistema. 2. El usuario introduce su seudónimo y su contraseña 3. El sistema comprueba que la combinación seudónimocontraseña es válida y loguea al usuario Usuario y/o contraseña incorrectos (Excepción) 3a La combinación seudónimo-contraseña no es correcta y el sistema solicita al usuario una combinación correcta. Editar Usuario Editar Usuario Versión 1.0 (30/07/2013) Descripción Un usuario podrá modicar su contraseña, correo electrónico y nombre de usuario, siempre que el nuevo no coincida con uno ya registrado. Escenario y tipo Descripción y pasos Continúa en la siguiente página

49 Escenario y tipo Principal Cuadro 4.3 Continuación de la página anterior Descripción y pasos 1. Un usuario quiere editar sus datos 2. El usuario introduce su nuevo nombre de usuario, correo electrónico. 3. El sistema registra los cambios en el sistema Cambio de contraseña (Alternativo) 2a 1. El usuario indica que quiere modicar su contraseña 2. El sistema solicita la contraseña actual y la nueva junto con su conrmación 3. El usuario introduce los datos requeridos 4. El sistema registra los cambios en la contraseña Seudónimo existente (Excepción) 3a La combinación seudónimo-contraseña no es correcta y el sistema solicita al usuario una combinación correcta Subsistema de Gestión de Datasets En la gura 4.5 pude visualizarse el diagrama de este caso de uso. Actualizar Dataset Precondiciones: El usuario está logueado en el sistema. Actualizar Dataset Versión 1.0 (30/07/2013) Descripción Un usuario logueado será capaz de actualizar los datos de un determinado dataset, previamente creado. El sistema acudirá a la forja en cuestión para obtener datos recientes y almacenarlos en la base de datos, sobrescribiendo los existentes. Escenario y tipo Descripción y pasos Continúa en la siguiente página

50 Escenario y tipo Principal Cuadro 4.4 Continuación de la página anterior Descripción y pasos 1. El usuario indica que quiere actualizar un dataset a partir de una lista de los existentes 2. El sistema muestra una pantalla editable con los datos modicables del dataset (nombre, descripción, URL y frecuencia de actualización) 3. El usuario introduce los campos requeridos y pulsa actualizar 4. El sistema actualiza el dataset con los valores introducidos y carga los datos del dataset de nuevo 5. La carga se realiza correctamente y el sistema informa al usuario mediante un correo electrónico Carga de datos fallida (Excepción) 5a La carga no se realizó correctamente y el usuario es informado por correo electrónico Crear Dataset Precondiciones: El usuario está logueado en el sistema. Crear Dataset Versión 1.0 (30/07/2013) Descripción Un usuario logueado será capaz de crear un nuevo dataset. El sistema acudirá a la forja en cuestión en busca de los datos requeridos por el usuario y los almacenará en la base de datos. Escenario y tipo Descripción y pasos Principal 1. El usuario indica que quiere crear un nuevo dataset e introduce nombre, descripción y URL de la forja 2. El sistema crea el dataset y comienza a cargar los datos solicitados de la forja especicada. 3. La carga naliza correctamente y el usuario recibe un correo informando del éxito Continúa en la siguiente página

51 Escenario y tipo Forja Assembla (Alternativo) Cuadro 4.5 Continuación de la página anterior Descripción y pasos 1a El usuario introducirá un chero de acuerdo a un formato especicado en la documentación con los proyectos de los que desea obtener información Forja Redmine (Alternativo) Error en la carga (Excepción) 1b El usuario además introducirá la clave para poder obtener todos los datos a partir de la API 3a El sistema no puede nalizar correctamente la carga y envía al usuario un correo informando de la situación Eliminar Dataset Precondiciones: El usuario está logueado en el sistema. Eliminar Dataset Versión 1.0 (30/07/2013) Descripción Un usuario logueado será capaz de eliminar un dataset y los datos de los proyectos asociados al mismo. Escenario y tipo Descripción y pasos Principal 1. El usuario indica que quiere eliminar un determinado dataset a partir de una lista de los existentes 2. El sistema elimina dicho dataset y los datos relacionados con él Ver Proyectos Dataset

52 Figura 4.4: Diagrama de casos de uso para la gestión de usuarios Ver Proyectos Dataset Versión 1.0 (30/07/2013) Descripción Un usuario será capaz de observar los datos de un determinado dataset así como los proyectos que están contenidos en él y los datos particulares de dichos proyectos. Se podría decir que un usuario sin loguear tiene permisos de lectura pero no de escritura. Escenario y tipo Descripción y pasos Principal 1. Un usuario indica que quiere visualizar un determinado dataset a partir de una lista de los existentes 2. El sistema proporciona al usuario la información general del dataset así como una lista de los proyectos que pertenecen a dicho dataset y acceso a la información referente a los mismos Subsistema de Gestión de Proyectos En la gura 4.6 pude visualizarse el diagrama de este caso de uso.

53 Figura 4.5: Diagrama de casos de uso para la gestión de datasets

54 Figura 4.6: Diagrama de casos de uso para la gestión de proyectos Ver Grácas de Proyectos Ver Grácas de Proyectos Versión 1.0 (30/07/2013) Descripción Un usuario será capaz de observar las métricas de un proyecto de forma gráca, si éstas pudieran ser así representadas. Escenario y tipo Descripción y pasos Principal 1. El usuario indica que quiere visualizar grácamente las métricas de un determinado proyecto. 2. El sistema muestra aquellas métricas que estén disponibles. Ver Información General de Proyectos Ver Información General de Proyectos Versión 1.0 (30/07/2013) Descripción Un usuario será capaz de observar la información general de los proyectos analizados de las forjas Escenario y tipo Descripción y pasos Principal 1. El usuario selecciona un proyecto a partir de una lista que contiene los existentes en el dataset que previamente el usuario seleccionó 2. El sistema muestra la información general de dicho proyecto

55 Escenario y tipo Principal Cuadro 4.10 Continuación de la página anterior Descripción y pasos 1. El usuario elige un proyecto a partir de una lista que muestra los existentes en el dataset que previamente el usuario seleccionó para visualizar 2. El usuario indica que quiere visualizar las métricas del proyecto 3. El sistema muestra una lista con todas las métricas disponibles para ese proyecto 4.3. Modelo de Comportamiento A partir de los casos de uso anteriores, se crea el modelo de comportamiento. Para ello, se realizarán los diagramas de secuencia del sistema, donde se identicarán las operaciones o servicios del sistema. Luego, se detallará el contrato de las operaciones identicadas Servicios Servicios del Sistema Subsistema de Gestión de Datasets Clase SubsistemaDatasets Operación void actualizardataset (int id,string nombre,string descripción,string url,enum frecuencia_actualizacion) boolean buscardataset (int id) void creardataset () void eliminardataset (int id) void verdataset (int id) Descripción Esta operación actualiza el dataset con la información pasada como parámetros. Esta operación busca un dataset en el sistema cuyo identicador sea id. Recibe como parámetros los necesarios para crear un dataset, anteriormente citador en el diagrama de clases Elimina el dataset con el identicador proporcionado Esta operación muestra el dataset con identicador id. Actualizar Dataset El diagrama de secuencia de este caso de uso se puede observar en la gura 4.8 Crear Dataset El diagrama de secuencia de este caso de uso se puede observar en la gura 4.9

56 Figura 4.7: Diagrama de Servicios Eliminar Dataset El diagrama de secuencia de este caso de uso se puede observar en la gura 4.10 Visualizar Dataset El diagrama de secuencia de este caso de uso se puede observar en la gura 4.13 Subsistema de Gestión de Proyectos

57 Figura 4.8: Diagrama de secuencia Actualizar Dataset Clase SubsistemaProyectos Operación void void vergrácas (int id) void verinfogeneral (int id) void verresultadometricas (int id) Descripción Esta operación permite al usuario visualizar grácamente los resultados de algunas de las métricas del proyecto con identicador id. Esta operación muestra la información general del proyecto cuyo identicador sea id. Esta operación muestra en formato textual los resultados de las métricas para el proyecto con identicador id. Subsistema de Gestión de Usuarios

58 Figura 4.9: Diagrama de secuencia Crear Dataset Clase SubsistemaUsuario Operación Descripción void login (string contraseña,string Trata de loguear al usuario con nombre seudónimo) de usuario seudónimo y contraseña contraseña. void logout () Con esta operación el usuario que la invoca sale del sistema. void Registro (string seudónimo,string Mediante esta operación se registra en el ,string contraseña,string conrmación_contraseña) sistema un usuario con los datos pasados como parámetros siempre y cuando no exista ya otro con el mismo seudónimo. El diagrama de secuencia de los casos de uso relacionados con los proyectos se puede observar en la gura 4.13 Login Usuario El diagrama de secuencia de este caso de uso se puede observar en la gura 4.14 Logout Usuario El diagrama de secuencia de este caso de uso se puede observar en la gura 4.15

59 Figura 4.10: Diagrama de secuencia Eliminar Dataset Registrar Usuario El diagrama de secuencia de este caso de uso se puede observar en la gura 4.16 Servicios Externos Forja de Software Clase ForjaSoftware Operación void solicitardatosproyectos () Descripción Esta operación devuelve los datos extraídos de las forjas que guran en el modelo de datos. Debería desglosarse en diversas peticiones a la API pero por simplicidad se reeja como una sola Modelo de Interfaz de Usuario En esta sección se incluye un prototipo de baja delidad de la interfaz de usuario del sistema. Así como un diagrama de navegación, que reeja la secuencia de pantallas a las que tienen acceso los diferentes roles de usuario y la conexión entre éstas. El modelo de navegación se puede observar en la gura Subsistema de Gestión de Datasets El prototipo de interfaz gráca para la gestión de proyectos puede visualizarse en la gura En el combobox llamado Datasets aparecerán todos los datasets registrados en el sistema que contengan la cadena, si es que el usuario ha introducido alguna, en el campo de texto Filtro

60 Figura 4.11: Diagrama de secuencia Visualizar Dataset datasets. Actualizar Dataset El prototipo de interfaz gráca para la actualización de un dataset puede visualizarse en la gura Crear Dataset El prototipo de interfaz gráca para la creación de un dataset puede visualizarse en la gura Ver Dataset El prototipo de interfaz gráca para la creación de un dataset puede visualizarse en la gura En esta lista Proyectos aparecerán todos los proyectos pertenecientes al dataset actual y cuyo nombre contiene la cadena, si es que hay alguna, introducida en el campo de texto Filtro Proyectos Subsistema de Gestión de Proyectos El prototipo de interfaz gráca para la gestión de proyectos puede visualizarse en la gura Métricas El prototipo de interfaz gráca para la visualización de métricas puede visualizarse en la gura 4.23.

61 Figura 4.12: Diagrama de secuencia Visualizar Datos Proyecto Subsistema de Gestión de Usuarios Editar Usuario El prototipo de interfaz gráca para la edición de usuario puede visualizarse en la gura Login Usuario El prototipo de interfaz gráca para el logueo de usuario puede visualizarse en la gura Registrar Usuario El prototipo de interfaz gráca para el registro de usuario puede visualizarse en la gura 4.26.

62 Figura 4.13: Diagrama de secuencia Visualizar Datos Proyecto

63 Figura 4.14: Diagrama de secuencia Login Usuario Figura 4.15: Diagrama de secuencia Logout Usuario

64 Figura 4.16: Diagrama de secuencia Registrar Usuario

65 Figura 4.17: Modelo de Navegación de la interfaz gráca

66 Figura 4.18: Interfaz Gráca Gestión de Datasets Figura 4.19: Interfaz Gráca Actualizar Dataset

67 Figura 4.20: Interfaz Gráca Crear Dataset Figura 4.21: Interfaz Gráca Ver Dataset

68 Figura 4.22: Interfaz Gráca Gestión de Proyectos Figura 4.23: Interfaz Gráca Métricas

69 Figura 4.24: Interfaz Gráca Editar Usuario Figura 4.25: Interfaz Gráca Login Usuario

70 Figura 4.26: Interfaz Gráca Registrar Usuario

71 Capítulo 5 Diseño del Sistema En esta sección se recoge la arquitectura general del sistema de información, la parametrización del software base, el diseño físico de datos, el diseño detallado de componentes software y el diseño detallado de la interfaz de usuario Arquitectura del Sistema A partir del quinto ciclo de la planicación Abreforjas presenta una arquitectura Modelo- Vista-Controlador. Sin embargo, hasta ese momento la arquitectura seguida era la de Pipes and Filters Pipes and Filters Esta arquitectura provee una estructura para los sistemas que procesan un ujo de datos. Cada unidad de procesamiento se encapsula en un lter y los datos son transferidos a través de los pipes entre los diferentes lters 5.1 [Buschmann, 1999]. Esta arquitectura es la que sigue cualquier proceso desarrollado con Pentaho Data Integration. De esta manera los lters son independientes entre sí, de manera que el procesamiento que se lleva a cabo en ellos pueda ser modicado sin afectar a los adyacentes. Un lter puede: Enriquecer los datos a partir de cálculos realizados con los datos de entrada que son añadidos a la salida. Renar los datos extrayendo información de los datos de entrada y pasando únicamente esta información a la salida. Transformar los datos de entrada a un nuevo formato y pasándolos a la salida. Combinar cualquiera de las posibilidades anteriores Arquitectura Modelo-Vista-Controlador Abreforjas sigue la arquitectura Modelo-Vista-Controlador, una evolución del modelo clienteservidor y la más simple de todas las versiones de la arquitectura de n-capas [Kappel, 2006]. Siendo n 3 en este caso. 57

72 Figura 5.1: Esquema de Pipes and Filters Modelo: representa la estructura de datos. Las clases que componen la capa de modelo poseen funciones de recuperación, inserción y actualización de la información almacenada en la base de datos. Vista: Es la capa más externa y por tanto más cercana al usuario. Una página web o un fragmento de la misma puede considerarse una vista. Controlador: Es la capa que actúa de intermediaria entre las vistas y los modelos ayudando a procesar y dirigir las peticiones HTTP y generando las páginas pertinentes Arquitectura física En este apartado, se describen los principales elementos hardware que forman la arquitectura física del sistema, recogiendo por un lado los componentes del entorno de producción y los componentes de cliente. Componentes Hardware Entorno de Producción Se considera el entorno de producción como una única máquina que dispone de un servidor de base de datos, un servidor de aplicaciones y un servidor web. Los requisitos de esta máquina son: Sistema Operativo Ubuntu Linux GB de RAM Los servicios que deberían estar instalados ya están reejados en la gráca. Estaciones de trabajo Al realizarse todo el procesamiento en el lado del servidor las necesidades de las estaciones de trabajo son mínimas. Como requisitos únicamente se presentan la necesidad de conexión a internet y la existencia de un navegador web instalado en el sistema.

73 Figura 5.2: Esquema del MVC Componentes Software WSGI: Permite desplegar aplicaciones web en Django con un servidor Apache. Abreforjas: Aplicación web principal desarrollada con el framework Django de Python. MySQL: Almacena: Los datos extraídos de las forjas de software. Los datos propios de la gestión de usuarios de la aplicación web. Los procesos desarrollados en Pentaho para la extracción de datos de las forjas. Apache Server: Actúa como servidor HTTP de la aplicación web. Apache Tomcat: Permite desplegar la aplicación Java D2R-Server D2R-Server: Esta aplicación se encarga de mapear una base de datos relacional con un vocabulario RDF Arquitectura lógica La arquitectura lógica del sistema puede observarse en la gura 5.4. En ella puede observarse el desacople entre los diversos componentes. Los procesos de Pentaho serán los encargados de comunicarse con las APIs de las forjas, siendo los detalles de este proceso desconocidos para el módulo consistente en la aplicación web. De esta manera, cualquier cambio en la política de publicación de datos o en el formato de los mismos sólo afectará a esta parte de la aplicación.

74 Figura 5.3: Arquitectura física del sistema

75 Figura 5.4: Arquitectura lógica del sistema Componentes Desarrollados Abreforjas: Orquesta la actividad del resto de aplicaciones basándose en las órdenes del usuario, el cual interactuará con el sistema vía interfaz web. Componentes Reutilizados Celery: Celery es una herramienta que permite la programación de tareas en el tiempo. En este caso se utiliza para programar el refresco o actualización de los datos de los diferentes datasets que estuvieran almacenados en el sistema [Celery, 2013]. D2R-Server: Asiste a la aplicación web en la publicación de los datos almacenados en la base de datos conforme a una ontología y un vocabulario RDF. Además ofrece un endpoint de SPARQL que posibilita la realización de consultas [D2R, 2012]. Pentaho: Conjunto de programas libres para generar inteligencia empresarial que incluye herramientas integradas para realizar peticiones HTTP y API ReST, trabajar con bases de datos, calcular datos agregados, etc. En denitiva se trata de una herramienta ETL (Extraction, Transform, Loading) [Pentaho, 2013]. Servicios Utilizados Assembla: Se trata de una forja software que ofrece tanto repositorios de código como sistemas de gestión de tickets y milestones. Sólo hay una instancia de esta forja en la web. Redmine: Al igual que Assembla ofrece un repositorio y un sistema de gestión de tickets y milestones. Sin embargo existen muchas instancias de esta forja en Internet, pues se trata de un software de código abierto que puede instalarse en cualquier equipo personal.

76 5.2. Parametrización del Software base D2R-Server Para el correcto funcionamiento de este software hay que proveerlo de un chero de conguración en un lenguaje propio de dicho software (D2RQ Mapping Language) que permita denir el mapeo entre las tablas relacionales y las clases de la ontología así como entre los atributos de las tablas y las propiedades de las clases de la ontología. D2R-Server ofrece una herramienta para realizar un mapeo automático entre la base de datos y un vocabulario RDF cticio. Aunque no es una solución automática es un paso que facilita el posterior renamiento del mapeo a un vocabulario real. En primer lugar es necesario denir la conexión a la base de datos. Para ello la herramienta utiliza el siguiente código: map:database a d2rq:database; d2rq:jdbcdriver "com.mysql.jdbc.driver"; d2rq:jdbcdsn "jdbc:mysql:///basedatos"; d2rq:username "usuario"; d2rq:password "pass"; jdbc:autoreconnect "true"; jdbc:zerodatetimebehavior "converttonull"; jdbc:keepalive "3600";. La última linea es de vital importancia cuando se desea que D2R no se desconecte de la base de datos. Habitualmente las bases de datos poseen un timeout para cada conexión, de manera que cuando transcurre dicho timeout sin actividad del usuario se cierra la conexión. Con esta linea se obliga a D2R a realizar algún tipo de actividad antes del n del timeout, evitando así el cierre de la conexión. El mapeo de una tabla a una clase del vocabulario se realiza de la siguiente manera: map:tabla a d2rq:classmap; d2rq:datastorage map:database; d2rq:uripattern "taba/@@tabla.pk urlify@@"; d2rq:class vocab:clase; d2rq:classdefinitionlabel "Clase"; Una vez mapeada la tabla con una clase se puede comenzar a mapear las columnas de la tabla con las propiedades de la clase de la siguiente manera: map:tabla_description a d2rq:propertybridge; d2rq:belongstoclassmap map:tabla; d2rq:property dc:description; d2rq:property vocab:description; d2rq:propertydefinitionlabel "table description"; d2rq:column "tabla.description"; Como se observa, es posible mapear una columna con varias propiedades de diferentes vocabularios. No es necesario denir una propiedad en el vocabulario que se desarrolle para cada columna, pues muchas de ellas son mapeables a propiedades ya existentes en otros vocabularios.

77 En el caso del vocabulario VSPF desarrollado se han reutilizado conceptos de ADMS.SW [ADMS.SW, 2012] (Asset Description Metadata Schema for Software), un vocabulario para describir proyectos software, preferiblemente de fuentes abiertas. Este vocabulario incluye conceptos como lenguaje de programación, tipo de interfaz gráca o sistema operativo. Desafortunadamente hasta el momento sólo ha podido reutilizarse el concepto Software Project, ya que en ni en Assembla ni en Redmine hay información de categorización del proyecto en base a estos conceptos. Sin embargo otras como Sourceforge sí que la proporcionan, por lo que la decisión de reutilizar este vocabulario tienen la nalidad de facilitar el desarrollo futuro de Abreforjas Django La instalación del framework Django queda fuera del alcance y objeto de este documento. Sin embargo se van a exponer a continuación algunos de los cambios necesarios en el chero de conguración "settings.py". Las acciones a realizar en dicho chero son: Congurar los parámetros de conexión a la base de datos. La base de datos ya habrá sido creada en el servidor de base de datos elegido aunque sin estructura. En este chero se determinará el host, el puerto, el usuario y la contraseña para un correcto acceso. Denición del directorio donde se almacenarán las plantillas y los cheros estáticos. Comandos para la inicialización del programador de tareas Celery Pentaho En el desarrollo de los procesos de Pentaho necesarios para la extracción de los datos de las forjas así como de los cálculos de las métricas de los proyectos se utilizó la modalidad de almacenamiento de los procesos en repositorio. Esta modalidad consiste en la utilización de una base de datos relacional como repositorio de los procesos de Pentaho, en lugar de utilizar el modo clásico de sistema de cheros. Para habilitar dicha modalidad es necesario crear: Una base de datos en el sistema de gestión de base de datos preferido. Una conexión a dicha base de datos desde Pentaho. Una vez creada la conexión, Pentaho creará las tablas y otras estructuras internas que necesite de manea transparente al usuario. La creación de estas conexiones no se limitan a la utilización de las bases de datos como repositorios de procesos. También son necesarias para la utilización de cualquier base de datos como fuente o destino de resultados de una transformación. Es por ello que para la construcción de abreforjas se crearon dos conexiones y por tanto dos bases de datos: Una que almacenaba los procesos propios de la herramienta que habían sido desarrollados. Otra que conectaba con la base de datos donde eran almacenados los datos extraídos de las forjas.

78 5.3. Diseño físico de datos En esta sección se dene la estructura física de datos que utilizará el sistema, a partir del modelo de conceptual de clases. Se corresponde con la capa de modelos de la arquitectura MVC. Como se ha mencionado anteriormente en este documento, el framework de desarrollo web que se ha utilizado es Django. Este framework permite la denición del modelo de datos de manera independiente al sistema nal de almacenamiento que se utilice (CSV, XML, MySQL, Oracle, etc). No obstante, la denición aquí realizada está orientada al uso de una base de datos como sistema de almacenamiento Base de datos El diseño de la base de datos puede observarse en la gura 5.5.A continuación se detallan algunos de los atributos de las tablas en la gura 5.5: Descripción Deadline para la nalización del milestone. Número total de tickets que pertenece a dicho milestone. Número de tickets abiertos (no cerrados) que pertenecen a el milestone. Fecha de compleción del milestone. Usuario de la forja que creó el milestone- Proyecto al que pertenece el milestone. Dataset Atributo forge_id url user_id update_date access_key scheduled_id Milestones Atributo due_on totaltickets opentickets completed user_id project Descripción Identicador de la forja con la que está asociado. URL base para poder realizar posteriormente las peticiones a la API. Identicador del usuario del sistema que creó el dataset. Fecha de actualización del dataset. Clave necesaria para acceder a las APIs de las forjas de tipo Redmine. Frecuencia de actualización automática del dataset, si la hubiera. Project users Tabla que implementa la relación muchos a muchos entre proyectos y usuarios. Ticket priorities En esta tabla se almacenan las posibles prioridades que pueden recibir los tickets. Atributo Descripción code Identicador numérico de la prioridad description Descripción de la prioridad (alta, media, baja, etc).

79 Figura 5.5: Diseño de la Base de Datos

80 Ticket status En esta tabla se almacenan los posibles estados que pueden recibir los tickets. Atributo Descripción code Identicador numérico del estado description Descripción del estado del ticket (abierto, cerrado, etc). Tickets Atributo created updated completed status priority author_id owner_id milestone_id Descripción Fecha de creación del ticket. Fecha de actualización del ticket. Fecha de compleción del ticket. Estado del ticket. Prioridad del ticket. Usuario que creó el ticket. Usuario que debe resolver el ticket Milestone al que pertenece el ticket, si existiera. Users Esta entidad representa a los usuarios de las forjas de software. Atributo Descripción externalid Identicador con el que la forja identica al usuario dataset Dataset que reveló la existencia de este usuario en la forja username Nombre de usuario. name Nombre real Correo electrónico del usuario. Django user Esta tabla es una mera representación de la que verdaderamente crea el framework Django para controlar la gestión de usuarios. No se entra en más detalles por ser irrelevante para la comprensión del esquema. Forge apis Esta entidad es necesaria para la realización de las peticiones a las APIs de las diferentes forjas. Atributo Descripción request_uri Patrón de la URI de la API. Suele incluir macros para sustituir la URL base de la forja o el identicador del proyecto. request_accept_header Este atributo representa las diferentes cabeceras necesarias en las peticiones HTTP para el éxito de la misma. type Este atributo representa el tipo de información que se extrae de la uri correspondiente. Puede ser información general del proyecto, usuarios del proyecto, tickets, milestones, etc.

81 Vocabulario VSPF Para la publicación de los datos de acuerdo con las tecnologías Linked Data se ha desarrollado el vocabulario VSPF ( Vocabulary for Software Projects in Forges). En la gura 5.6 se puede observar el diseño de dicho vocabulario y se encuentra publicado en neologism/vspf Diseño detallado de componentes Para cada uno de los módulos funcionales del sistema se realizará un diagrama de secuencia, para denir la interacción existente entre las clases de objetos que permitan responder a eventos externos. En la gura 5.7 puede observarse un esquema general con los componentes del sistema Subsistema de Gestión de Datasets Clases de diseño Nombre Descripción Operaciones DatasetForm Esta clase permite mostrar al usuario un formulario para crear un nuevo dataset. Los campos de dicho formulario son: Nombre Descripción URL base de la forja Forja Fichero con los proyectos a buscar Clave de acceso a la API Frecuencia de actualización add_dataset (string nombre,string descripción,string url,enum forja,string clave,string chero,enum frecuencia)

82 Figura 5.6: Diseño del vocabulario VSPF

83 Figura 5.7: Diagrama de componentes del sistema Nombre Descripción Operaciones DatasetManagementForm Esta clase permite mostrar al usuario una lista con todos los datasets almacenados en el sistema y permite ejecutar tres operaciones sobre los mismos: Actualización Eliminación Consulta void delete (Dataset dataset): Esta operación eliminará el dataset pasado por parámetro del sistema. Es seguro que dicho dataset se encuentra en el sistema por haberlo escogido el usuario de una lista de los existentes en el sistema. También se eliminarán del sistema todos los datos (proyectos, tickets, milestones, usuarios, etc) relacionados con el dataset indicado. void show (Dataset dataset): Esta operación devolverá al usuario un a nueva página con la información general del dataset escogido así como los proyectos que dicho dataset contiene. void update (Dataset dataset): Esta operación permitirá al usuario actualizar ciertos parámetros del dataset (nombre, descripción, url de la forja y frecuencia de actualización del mismo). Según la frecuencia de actualización indicada se iniciará o no un refresco de los datos del dataset.

84 Nombre Operaciones PentahoProcesses Assembla_Discoverer (int dataset_id,string chero,string user_ ): Extrae del chero que se le pasa los proyectos a descargar de Assembla. void calcular_metricas (): Refresca las métricas de todos los datasets. void Generic_Wrapper (int dataset_id,string url,string user_ ): Descarga los cheros ofrecidos por las APIs de las forjas. void Integration_Process (string user_ ): Analiza los cheros descargados de las forjas y almacena la información en la base de datos. void Redmine_Process (string url,string clave): Extrae y almacena la información de todos los proyectos de una instancia de Redmine. Nombre Descripción Operaciones TaskScheduler Esta clase la provee el framework Celery para la programación de tareas. En este caso se utiliza para programar la actualización de los datasets. void new (int dataset,enum frecuencia,string user_ ,): Esta operación registrará en el sistema una nueva tarea programada en el framework Celery. Dicho framework se encargará de ejecutar periódicamente las tareas aquí registrada mediante esta clase. void terminate (): Elimina la programación de una determinada tarea del sistema. También se ven implicadas dos páginas web: CrearDataset: Esta página contendrá un DatasetForm a través del cual se permitirá al usuario la creación de un nuevo dataset. Inicio: Esta página incluye un DatasetManagementForm y permite al usuario seleccionar uno de los datasets almacenados en el sistema y realizar alguna de las siguientes acciones con él: Mostrar Dataset

85 Figura 5.8: Diagrama de interacción Actualizar Dataset Actualizar Dataset Eliminar Dataset También da acceso a la funcionalidad Crear Dataset. Actualizar Dataset El diagrama de secuencia de esta funcionalidad puede observarse en la gura 5.9 Crear Dataset El diagrama de secuencia de esta funcionalidad puede observarse en la gura 5.10 Eliminar Dataset El diagrama de secuencia de esta funcionalidad puede observarse en la gura 5.12 Ver Dataset El diagrama de secuencia de esta funcionalidad puede observarse en la gura 5.14 Ver Datasets El diagrama de secuencia de esta funcionalidad puede observarse en la gura 5.15

86 Figura 5.9: Diagrama de comportamiento Actualizar Dataset

87 Figura 5.10: Diagrama de comportamiento Crear Dataset

88 Figura 5.11: Diagrama de interacción Eliminar Dataset Figura 5.12: Diagrama de comportamiento Eliminar Dataset

89 Figura 5.13: Diagrama de interacción Ver Dataset Figura 5.14: Diagrama de comportamiento Ver Dataset

90 Figura 5.15: Diagrama de comportamiento Ver Lista Datasets Subsistema de Gestión de Proyectos Clases de diseño Nombre Operaciones Project get_info(): Esta operación devuelve la información principal del proyecto, que incluye nombre, fecha de creación, página web y descripción. get_metrics(): Esta operación devolverá las métricas del proyecto. Algunas de las métricas además de ir ligadas a un proyecto pertenecerán a un determinado usuario.

91 Nombre Operaciones ProjectForm void new (Project Proyecto): Esta operación construirá un ProjectForm o formulario de proyecto, el cual permitirá mostrar al usuario a través de la interfaz gráca la información general del proyecto. Nombre Descripción Operaciones ProjectManagementForm Este tipo de formulario muestra al usuario una lista con todos los proyectos pertenecientes a un determinado dataset y almacenados en el sistema. void show (Project Proyecto): Esta operación mostrará al usuario la información general de un determinado proyecto de los que el formulario maneja. También se ven implicadas tres páginas web: Grácas: Esta página web presentará al usuario algunas de las métricas pertenecientes a un proyecto de forma gráca. Métricas: Esta página web mostrará al usuario las métricas de un determinado proyecto de manera textual, sin gráco alguno. Proyecto: Esta página web mostrará al usuario la información general de un determinado proyecto: Nombre, descripción, homepage y fecha de creación. Ver Grácas El diagrama de secuencia de esta funcionalidad puede observarse en la gura 5.17 Ver Métricas El diagrama de secuencia de esta funcionalidad puede observarse en la gura 5.19 Ver Proyecto El diagrama de secuencia de esta funcionalidad puede observarse en la gura 5.21

92 Figura 5.16: Diagrama de interacción Ver Grácas Figura 5.17: Diagrama de comportamiento Ver Grácas

93 Figura 5.18: Diagrama de interacción Ver Métricas Figura 5.19: Diagrama de comportamiento Ver Métricas

94 Figura 5.20: Diagrama de interacción Ver Proyecto Figura 5.21: Diagrama de comportamiento Ver Proyecto

95 Subsistema de Gestión de Usuarios Clases de diseño Nombre Operaciones Usuario Usuario nd(username): Esta operación devuelve el usuario con nombre de usuario username si existiera. void set_ ( ): Esta operación establece como el nuevo correo electrónico del usuario en cuestión. void set_password(password): Esta operación establece password como la nueva contraseña del usuario en cuestión. int set_username(username): Esta operación establece username como el nombre de usuario del usuario en cuestión, siempre y cuando no exista otro usuario con dicho nombre de usuario. Nombre Descripción Operaciones EditUserForm Esta clase representa un formulario de edición de datos de usuario. Serán modicables el nombre de usuario, el correo electrónico y la contraseña. new(username): Esta operación crea un nuevo objeto de esta clase con los campos inicializados con los datos ya almacenados del usuario pasado como parámetro. save(new_username, , password, password_conf): Esta operación registrará los nuevos datos proporcionados para el usuario en cuestión. El nombre de usuario sólo será cambiado siempre y cuando no haya otro igual registrado en el sistema. De la misma manera, la contraseña y su conrmación deberán coincidir para que los cambios surtan efecto.

96 Nombre Description Operaciones LoginForm Esta clase representa un formulario con dos campos: nombre de usuario y contraseña. login(username, password): Esta operación pasará el control de autenticación a la clase django.users con los datos pasados como parámetros. Nombre Operaciones Django.user int authenticate(username, password): Esta operación autentica en el sistema, si existiera, al usuario con nombre de usuario username y contraseña password. Si el usuario fue autenticado devolverá el valor 1, y cualquier otro valor si no fuera posible la autenticación con los datos proporcionados. Nombre Descripción Operaciones SignUpForm Formulario que muestra cuatro campos para que el usuario introduzca su nombre de usuario, , contraseña y conrmación de la misma void register(username, , password, password_conf): Esta operación trata de registrar un usuario en el sistema cuyos datos personales son los parámetros pasados. Al nalizar la función, se devolverá al usuario un mensaje indicando si se pudo o no realizar el registro. Editar Usuario El diagrama de secuencia de esta funcionalidad puede observarse en la gura 5.22 Login Usuario El diagrama de secuencia de esta funcionalidad puede observarse en la gura 5.23

97 Figura 5.22: Diagrama de comportamiento Editar Usuario

98 Figura 5.23: Diagrama de comportamiento Login Usuario

99 Registrar Usuario El diagrama de secuencia de esta funcionalidad puede observarse en la gura Procesos de Pentaho A continuación se describen los procesos que se han diseñado en Pentaho que permiten extraer los datos referentes a los datasets para almacenarlos en una base de datos relacional, así como calcular datos agregados a partir de los mismos. Assembla Job Assembla Discoverer Este es el proceso de Pentaho de más alto nivel que trabaja con la forja Assembla. Su funcionalidad consiste en llamar a la transformación Assembla Discoverer y enviar un al usuario en caso de que un error ocurriera durante su ejecución. El proceso puede visualizarse en la gura Como parámetros recibe: Identicador del dataset con el que trabajar Correo electrónico del usuario que creó el dataset URL base de la forja Assembla Fichero con los proyectos a descargar de la forja. Transform Assembla Discoverer Esta transformación analizará el chero que contiene los nombres de los proyectos y los almacenará en la base de datos indicando que pertenecen al dataset especicado como parámetro. El proceso puede visualizarse en la gura 5.26 Hay que destacar que no se extraen datos de la forja. No existe en este punto ningún contacto con la API. Job Generic Wrapper Este proceso se ocupa de realizar las peticiones a la API y almacenar los cheros descargados en memoria secundaria. Para ello, en primer lugar, genera todas las peticiones necesarias para cada proyecto. El proceso puede visualizarse en la gura Este proceso sirvió en su momento tanto para Assembla [Assembla, 2012] como para Source- Forge. Sin embargo, ahora mismo sólo se utiliza para Assembla, pues la interacción con Source- Forge se ha descartado temporalmente.

100 Figura 5.24: Diagrama de comportamiento Registrar Usuario

101 Figura 5.25: Job Assembla Discoverer Figura 5.26: Transform Assembla Discoverer Figura 5.27: Job Generic Wrapper

102 Dato obtenido Projects Descripción Con esta petición se obtiene la información general de un determinado proyecto. La apariencia de la petición sería así: GET /spaces/*project_name*/ Users donde *PROJECT_NAME* es el nombre del proyecto que está almacenado en la base de datos y que se le proporcionó al sistema mediante un chero de texto en el proceso Assembla Discoverer Con esta petición se obtienen los usuarios que participan en un determinado proyecto, el cual, como en la petición anterior se le pasa como parámetro en la URI. GET /spaces/*project_name*/users Tickets Con esta petición se obtienen todos los tickets de un determinado proyecto, sea cual sea su estado. Esto se exige mediante la adición de la cadena report/0 al nal de la URL. La apariencia de la petición sería tal que así: GET /spaces/*project_name*/tickets/report/0 Los tickets en Assembla pueden poseer uno y sólo uno de los siguientes estados en un momento determinado: 0. Nuevo 1. Aceptado 2. Inválido 3. Arreglado 4. Test De la misma manera ocurre con la prioridad de lo tickets, que puede ser: 1. Highest 2. High 3. Normal 4. Low 5. Lowest Milestones Mediante esta petición es posible obtener todos los milestones de un determinado proyecto. GET /spaces/milestones/all/*project_name* Documents Con esta petición se obtienen los documentos de un determinado proyecto. Se entiende por documento un recurso que puede ser un audio, una imagen, etc. GET /spaces/*project_name*/documents

103 Figura 5.28: Job Integration Generic Process Job Integration Generic Process Con este proceso se pretende extraer la información de los documentos XML descargados mediante el proceso Generic Wrapper y almacenarlos en la base de datos utilizando el modelo común previamente denido en este documento. El proceso puede visualizarse en la gura Este proceso trabaja con una estructura de carpetas para el tratamiento de los cheros que es como sigue: BASE Harvested: Es la carpeta donde se almacenan los cheros tal y como se descargan de la API. Pre-stored: Los cheros se mueven de la carpeta anterior a esta para ser analizados. Stored: Aquellos que fueron exitosamente analizados serán trasladados a esta carpeta. Non-stored: Si algún error ocurriera en el tratamiento de alguno de los cheros, éste se almacenaría en esta carpeta. Transform Assembla to Database Esta transformación es clave, como su nombre indica, para la forja Assembla. Aunque el proceso tenga por objetivo ser lo más genérico posible, es imposible obviar que cada forja ofrece un determinado XML-Schema en los cheros que proporciona a través de su API y que además, los datos que ofrecen son dispares. Es por ello que es necesario aislar estas peculiaridades de cada forja en una única transformación. De esta manera, para añadir una nueva forja al sistema sólo sería necesario crear una transformación equivalente para la nueva forja e incrustarla en este proceso. El proceso puede visualizarse en la gura Redmine Job Redmine Discoverer Este es el proceso de Pentaho de más alto nivel que trabaja con la forja Redmine. Su funcionalidad consiste en llamar a la transformación Redmine Process y enviar un al usuario en caso de que un error ocurriera durante su ejecución. El proceso puede visualizarse en la gura Como parámetros recibe: Identicador del dataset con el que trabajar Correo electrónico del usuario que creó el dataset URL base de la instancia de Redmine con la que trabajará

104 Figura 5.29: Transform Assembla to Database Figura 5.30: Job Redmine Discoverer

105 Figura 5.31: Transform Redmine Process Transform Redmine Process En este proceso se generan las URIs de todas las peticiones que hay que realizar a la instancia de la forja Redmine que corresponda al dataset. Para entender bien su funcionamiento se explican a continuación algunos detalles de como funciona esta forja. El proceso puede visualizarse en la gura Las peticiones que se van a describir a continuación a la API de Redmine [Redmine, 2013] devuelven como resultado un chero XML. Sea cual sea la petición, el número máximo de elementos que cada documento contiene es 100, ya sean proyectos, tickets o usuarios. Como es posible que en la forja haya más de 100 de algún tipo de elemento, los documentos incluyen en su cabecera el número total de elementos de ese tipo en un atributo llamado total_count así como el oset, el cual se le puede especicar como argumento en la petición a la API. La idea básica entonces es construir tantas peticiones como sean necesarias, lo cual es fácilmente calculable mediante la división por exceso del número total de elementos entre 100 y los osets que deberán pasarse como argumento a cada petición para obtener los elementos adecuados. Para calcular este oset se numerará cada petición empezando en el uno y se multiplicará dicho identicador por el limite máximo establecido, es decir, 100. Esta sería una muestra de las cabeceras que se pueden encontrar en estos documentos XML: <issues type=array total_count=359 limit=100 oset=0> Habría que realizar por tanto cuatro peticiones, cuyos osets serían: Los datos que se obtienen en cada petición no serán descritos nuevamente, pues el lector ya conoce el modelo de datos de la aplicación y sabe que es común y compatible con las dos forjas con las que se trabajan.

106 Redmine ofrece varias posibilidades para la autenticación vía ReST API. En el caso de Abreforjas se ha utilizado la API Key, la cual se pasa en la cabecera de la petición en un campo con el nombre X-Redmine-API-Key. El orden en el que se describen aquí las peticiones es el mismo que el que está almacenado en la base de datos y no es trivial. Un cambio en dicho orden podría conllevar a un fallo en el sistema, pues existen dependencias entre las peticiones. Por ejemplo, no sería posible tratar los tickets y reejar en la base de datos quién es el autor del mismo si dicho autor no está registrado en la tabla de usuarios. Dato obtenido Projects Descripción A diferencia de otras forjas, Redmine permite obtener todos los proyectos alojados en la forja a partir de una única petición (si el oset así lo permitiera). Para obtener todos los proyectos se realizará la siguiente petición: GET /projects.xml?limit=100&oset=*offset* Users Membership Donde *OFFSET* se sustituirá por lo valores anteriormente calculados. Esta petición la maneja Redmine de una manera especial. Se exige que el poseedor de la API Key tenga privilegios de administrador para acceder a la lista de todos los usuarios registrados en la forja. Esto es una desventaja para Abreforjas, pues impide que todas las forjas Redmine con la API activada sean investigables. Además no existe en la interfaz de conguración de permisos ninguna opción que permita un manejo más no de los permisos para no tener que dar privilegios de administrador al usuario determinado. Tras ardua investigación por internet la única propuesta que existe por parte de la comunidad es parchear Redmine para que se salte esta restricción. Por desgracia este parche sale fuera del ámbito de este proyecto y no aportaría valor añadido al mismo. La petición tendría una apariencia tal que así: GET /users.xml?limit=100&oset=*offset* Con las peticiones descritas hasta ahora se pueden conocer qué proyectos y qué usuarios hay registrados en el sistema. Sin embargo no se puede conocer de manera directa qué usuarios pertenecen a qué proyecto. A lo sumo se podrían intuir a partir de los creadores y poseedores de los tickets. Sin embargo sería posible la existencia de usuarios que no hubieran quedado reejados en los tickets, ya fuera por un mal uso de los mismos o porque verdaderamente no hubieran trabajado en el proyecto. Por ello existe la petición de membresía. En ella se indica para cada proyecto qué usuarios son miembros o participan en el mismo. La apariencia de la petición sería la siguiente: GET /projects/*id*/memberships.xml?limit=100&oset=*offset* donde ID tiene el mismo signicado que tenía en la petición de las versiones. Continúa en la siguiente página

107 Dato obtenido Versions Cuadro 5.1 Continuación de la página anterior Descripción Las versiones en Redmine son el equivalente a los milestones en otras forjas. A diferencia de como ocurría con los proyectos, no es posible obtener todas las versiones registradas en la forja, sino que es necesario hacer peticiones por cada proyecto. El formato de la petición es el siguiente: GET /projects/*id*/versions.xml Tickets Siendo *ID* el identicador del proyecto (se corresponde con los campos external_id o name descritos en el modelo de datos). Redmine sí permite obtener todos los issues registrados en el sistema a partir de una única petición. En este caso hay que añadir un parámetro y es el estado del ticket. En el caso de Abreforjas interesan todos los tickets, por lo que se exige que el estado de los mismos sea *. La petición sería así: GET /issues.xml?status_id=*&limit=100&oset=*offset* A diferencia que de Assembla, Redmine es una forja altamente congurable y permite, entre otras cosas, denir qué estados o qué prioridades pueden tener los tickets. Esto diculta mucho la interpretación de los datos por parte de Abreforjas y es por ello que se ha tomado la decisión de contemplar las prioridades y los estados de los tickets como si de una instancia de Redmine recién congurada se tratara. Los estados y prioridades por defecto son: 1. Nueva 2. En curso 3. Resuelta 4. Comentarios 5. Cerrada 1. Baja 2. Normal 3. Alta 4. Urgente 5. Inmediata Tomando los estados y prioridades de Assembla para el modelo común, es necesario realizar un mapeo de estos valores a los de Assembla. El mapeo realizado para los estados y prioridades es el siguiente: Estados Prioridades Nueva ->Nuevo En Curso ->Aceptado Resuelta ->Arreglado Comentarios ->Test Cerrada ->Arreglado Baja ->Lowest Normal ->Low Alta ->Normal Urgente ->High Inmediata ->Highest

108 Figura 5.32: Job Metricas Transform Redmine SubProcess Una vez han sido preparadas las peticiones a realizar, es en esta subtransformación donde se llevan a cabo mediante peticiones HTTP. Al ser pequeño el número de cheros con los que se trata se decidió tratarlos al vuelo y extraer la información de los mismos al vuelo, sin llegar a almacenarlos en memoria secundaria. Rúbrica Job Métricas Este proceso se ejecuta siempre para todos los datasets almacenados en el sistema y calcula, a partir de los datos extraídos de las forjas, una serie de métricas que se denen a continuación: Deadline fulllment: Retraso medio en la entrega de milestones medido en días. Teamwork balance: Desviación típica del número de tickets asignados a cada miembro del proyecto. Número total de tickets por proyecto Número de tickets abiertos por proyecto Número total de tickets por milestone Número de tickets abiertos por milestone Número total de tickets por proyecto y usuario Número de tickets abiertos por proyecto y usuario Como argumento recibe, como el resto de procesos, el correo electrónico del usuario creador del dataset que se está actualizando o creando para informarlo de la situación de la carga de datos. El proceso puede visualizase en la gura Servicios comunes Se contemplan dos de estos servicios: Assembla: Representa a la única instancia de la forja Assembla. Por simplicidad en este apartado se supondrá que sólo existe una única operación llamada obtener_datos en lugar de especicar toda las operaciones que se utilizan de la API.

109 Redmine: Esta clase representa a cualquier instancia de la forja Redmine. Al igual que ocurriera con Assembla, por simplicidad se considera que sólo hay un método llamado obtener datos que proporciona todos los datos que se extraen de la API.

110

111 Capítulo 6 Construcción del Sistema Este apartado trata sobre todos los aspectos relacionados con la implementación del sistema en código fuente y en scripts de base de datos, haciendo uso de un determinado entorno de construcción Entorno tecnológico En esta sección se indica el marco tecnológico utilizado para la construcción del sistema: entorno de desarrollo (IDE), lenguaje de programación, herramientas de ayuda a la construcción y despliegue, control de versiones, repositorio de componentes, integración continua, etc Nivel de presentación HTML El HTML (Hyper Text Markup Language) o, en castellano, lenguaje de marcación de hipertexto, es el lenguaje de marcas de texto utilizado normalmente en World Wide Web (WWW). Fue creado por Tim Berners-Lee en 1986, a partir de dos herramientas preexistentes: el concepto de hipertexto y el SGML. HTML permite denir tanto la estructura y ubicación de los elementos que se muestran en una página Web como las relaciones entre los diversos componentes de un sitio Web gracias al uso de los hipervínculos. La interpretación de los documentos HTML la realizan los navegadores Web, como Mozilla Firefox o Google Chrome entre otros. La interpretación puede hacer que la presentación nal varíe en pequeños detalles. Por ello el desarrollo del HTML se ajustará al máximo a los estándares impuestos por la W3C. CSS El termino CSS, acrónimo de Cascading Style Sheets (hojas de estilo en cascada), hace referencia al lenguaje formal usado para denir la presentación de documentos estructurados escritos en HTML, XML y XHTML por extensión. El World Wide Web Consortium (W3C) es el organismo encargado de formular la especicación de las hojas de estilo que servirán como estándar para los navegadores. Con CSS se pretende separar la estructura de un documento web de su presentación. 97

112 En el caso de Abreforjas no se desarrollaron plantillas CSS desde cero, sino que se aprovecharon las plantillas libres Twitter Bootstrap, las cuales permitieron un desarrollo más rápido sin pérdida de calidad en el diseño y presentación de la web Plantillas Django El lenguaje de plantillas de Django facilita el desarrollo de la capa de presentación en aplicaciones web. En esencia sigue siendo un documento HTML al que se le incrustan variables, que son reemplazadas al ser parseadas por el framework, y etiquetas que dirigen la lógica de la plantilla. Entre estas etiquetas se encuentran los bucles for, sentencias condicionales, agrupamiento de sentencias en bloques e incluso la herencia. Gracias a este lenguaje el desarrollo se facilita, pues permite crear un documento base que incluya la barra de herramientas general, los menús y los detalles de la presentación A partir de este documento base se crean hijos que heredan de éste y en los que sólo se modican pequeños detalles. Además, muchas de las clases disponibles en el framework tienen traducción automática a HTML por medio de estas plantillas. Entre estos elementos se encuentran los formularios. Esta capacidad rearma el inicio de esta sección en la que se deenden la sencillez en el desarrollo de la capa de presentación de aplicaciones web con Django Nivel de aplicación Python Python es un lenguaje de programación interpretado cuya losofía hace hincapié en una sintaxis muy limpia para favorecer un código legible. Es un lenguaje interpretado, usa tipado dinámico y es multiplataforma. La licencia Python Software Foundation que posee dicho lenguaje es compatible con la GPL a partir de la versión Esta última característica es fundamental por el deseo de que Abreforjas sea una aplicación desarrollada con tecnologías compatibles con las directrices de la FSF (Free Software Foundation) Por ser interpretado es más lento que otros lenguajes, pero la facilidad de lectura y la claridad del código fuente que da como resultado compensa con creces dicha lentitud. Django Django es un framework de desarrollo web de código abierto, escrito en Python y liberado bajo licencia BSD en La meta fundamental de Django es facilitar la creación de sitios web complejos. Django pone énfasis en la reutilización de componentes, el desarrollo rápido (heredado de Python) y el principio DRY, del inglés Don't Repeat Yourself). Aunque Django está fuertemente inspirado en el MVC sus desarrolladores preeren no atarse a ningún paradigma al 100 %. Es por ello que existen diferencias con otros frameworks que sí que se rigen por complete a este paradigma. Lo que en cualquier otro framework se llamaría controlador en Django se llama vista y lo que en dichos frameworks llaman vista en Django se denominan plantillas. Otras características que incluye Django y que han sido utilizadas en Abreforjas son: Un mapeador objeto-relacional. Una API de base de datos robusta.

113 Un despachador de URLs basado en expresiones regulares. Muy útil para el paso de parámetros en las URL. Un sistema de gestión de usuarios incorporado. Transformación casi directa de modelo a formulario. Un conjunto de vistas genéricas para la creación, edición o eliminación de instancias de una clase de modelo. Más información en [Django, 2013]. Pentaho Data Integration Pentaho Data Integration en su versión de comunidad es una aplicación escrita en Java y compatible con la licencia GPL que facilita la realización de procesos ETL (Extraction Transform Load) [Pentaho, 2013]. Pentaho provee al desarrollador de una pizarra de trabajo junto con una paleta de herramientas o tareas disponibles para su colocación en la misma. Estas herramientas son conectadas grácamente mediante echas que describen el ujo de la información a través de la pizarra. La organización de los procesos desarrollados tienen una jerarquía denida: 1. Jobs: Son los procesos en el nivel más alto de la jerarquía. Están compuestos por transformaciones y otros procesos. No permiten la inclusión directa de todas las herramientas incluidas en la suite. 2. Transformaciones: Se sitúan en el nivel intermedio de la jerarquía. Están compuestas de otras transformaciones y las herramientas incluidas. 3. Herramientas incluidas en la suite o scripts desarrollados: Pentaho incluye un conjunto de herramientas predenidas típicas en los procesos ETL y que permiten la entrada de algunos parámetros. Cuando las herramientas ofertadas no son sucientes para llevar a cabo los procesos requeridos Pentaho provee al desarrollador de la posibilidad de desarrollar scripts en Java o Javascript e incluirlos como si de una herramienta más se tratara en la pizarra de trabajo. Gracias a la existencia de estas herramientas en Pentaho y a la posibilidad de construir procesos sin apenas tener que escribir una linea de código se pueden desarrollar aplicaciones ETL de una manera mucho más rápida y sencilla, cumpliendo el principio fundamental de la programación DRY y KISS Nivel de persistencia MySQL MySQL es un Sistema de Gestión de Bases de Datos Relacional, licenciado bajo la licencia GPL de GNU. Este gestor de bases de datos es, probablemente, el gestor más usado en el mundo del software libre, debido a su gran rapidez y facilidad de uso. Actualmente es propiedad del grupo Oracle, pues esta absorbió a Sun Microsystems, la anterior propietaria de MySQL. La sencillez de MySQL, su licencia libre y si relativa rapidez lo hacen el sistema ideal para aplicaciones con no demasiada carga de lectura/escritura. Como cualquier sistema, MySQL tiene

114 sus limitaciones y aunque permite aprovechar los procesadores multinúcleo no es un sistema apropiado para sistemas de gran escala como compañías aéreas o sistemas bancarios. Sin embargo las posibilidades que ofrece son más que sucientes para su uso en Abreforjas. XML XML, siglas en inglés de extensible Markup Language, es un lenguaje de marcas desarrollado por el World Wide Web Consortium (W3C) utilizado para almacenar datos en forma legible por un humano. se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. Siguiendo esta recomendación las APIs de las forjas Redmine y Assembla ofrecen su información en formato XML, por lo que Abreforjas tendrá que tratar obligatoriamente con esta tecnología. Por otro lado, Abreforjas también generará de manera indirecta documentos XML, pues la información extraída de las forjas será publicada en formato RDF con la ayuda de D2R-Server Herramientas Todas las herramientas empleadas durante el desarrollo del proyecto, son herramientas gratuitas, de libre acceso que se encuentran disponibles en Internet. Todas ellas se pueden descargar desde sus páginas Web ociales. Muchas de ellas cuentan con una larga y extensa documentación generada por sus respectivas comunidades de usuarios. Apache Tomcat Apache Tomcat es un contenedor de Servlets y JSPs y forma parte de la Apache Software Foundation. En el desarrollo de Abreforjas se ha utilizado para desplegar D2R-Server. Apache Durante el desarrollo de la aplicación EstDV se ha trabajado con la versión Apache 2.2. El servidor Apache es un servidor HTTP de código abierto multiplataforma que implementa el protocolo HTTP/1.1 y la noción de sitio virtual. Apache se desarrolla dentro del proyecto HTTP Server (HTTPD) de la Apache Software Foundation. Tiene amplia aceptación en la red, pues desde 1996, es el servidor HTTP más utilizado. En los últimos años está sufriendo un ligero descenso en dicha cuota por la competencia de otros servidores como NGINX, que aunque no son tan potentes ni congurables son más rápidos a la hora de servir cheros estáticos y permiten una conguración más sencilla. Al ser Abreforjas una aplicación desarrollada con Django, se ha utilizado el módulo WSGI para hacer posible la interactuación con Apache. El funcionamiento es bastante sencillo: En cierto Virtual Host de Apache se añade una linea que cede el control a un chero.wsgi cuando el usuario accede a una determinada URL. El chero WSGI apunta al directorio base de la aplicación Django Mientras el usuario no salga de la ruta indicada en el Virtual Host el control lo llevará Django mediante su despachador de URLs.

115 D2R-Server D2R Server es una herramienta para la publicación de contenido de bases de datos relacionales en la Web Semántica. Los datos en la Web Semántica son representados en RDF. D2R Server permite la personalización de un mapeo de una base de datos a este formato. además de proveer al usuario nal de un endpoint en SPARQL para la realización de consultas sobre los datos publicados. La peticiones web son reescritas en formato SQL mediante en mapeo denido. Esta conversión al vuelo elimina la necesidad de crear un almacén de tripletas con el control de la duplicidad y replicación que ello conlleva. Neologism Se trata de una plataforma para la publicación de vocabularios con un desarrollo enfocado a la facilidad de uso y compatibilidad con las tecnologías Linked Data. Con Neologism es posible crear las clases y propiedades RDF necesarias para publicar la información en la Web de los Datos. Con esta herramienta se ha denido el vocabulario VSPF (Vocabulary for Software Projects in Forges), el cual servirá para publicar los datos extraídos de las forjas. Geany Para la construcción de este proyecto se ha utilizado Geany como editor de texto compatible con UTF-8. Se trata de un editor con licencia libre muy simple al estilo bloc de notas y es independiente de los entornos de escritorio, siendo la librería GTK2 su única dependencia gráca. Algunas de las funcionalidades que incluye son: Coloreado de sintaxis. Cierre automático de etiquetas XML y HTML. Navegación por el código. Autocompleción de nombre de variables o funciones previamente declaradas. LibreOce Calc LibreOce Calc es la aplicación de hojas de cálculo de la suite LibreOce. No es este el lugar para indicar cuantas posibilidades ofrece este software. Su uso se ha limitado al desarrollo del diagrama de Gantt que gura en el apartado de planicación de este mismo documento. Forja RedIRIS RedIRIS es la red española para Interconexión de los Recursos Informáticos de las universidades y centros de investigación. Como tal provee de servicios de conexión a Internet a dichas instituciones. Entre los servicios que ofrece está la Forja de Conocimiento Libre de la Comunidad RedIRIS, que ofrece a toda la comunidad un repositorio para desarrollar iniciativas libres en el entorno académico-cientíco universitario. Esta Forja se usa, por ejemplo, como forja ocial en el Concurso Universitario de Software Libre, en el cual el proyecto Abreforjas obtuvo la primera posición en la fase local del curso 2011/2012.

116 Redmine Cuando Abreforjas pasó a ser un proyecto nal de carrera, se procedió a una mudanza de RedIRIS a una instancia de Redmine administrada por miembros del grupo de investigación. Para acceder al proyecto alojado en esta forja siga el enlace redmine/projects/abreforjas 6.2. Código fuente Organización del código fuente, describiendo la utilidad de los diferentes cheros y su distribución en paquetes o directorios Aplicación Web D2R-Server abreforjas-mapping.ttl Fichero para denir el mapeo de la base de datos relacional al vocabulario VSPF (Vocabulary for Software Projects in Forges). Es interpretado por D2R-Server para la publicación de los datasets. Django bootstrap Este directorio contiene los cheros HTML que contienen las plantillas necesarias de Django para la correcta presentación de la aplicación web. La plantilla base es el chero signin.html, siendo el resto hijas directas de la misma. Fichero Descripción pentaho/api.py En este chero se dene una API para las llamadas a los procesos pentaho. Pentaho Data Integration viene con un script denominado kettle.sh, el cual está diseñado para la ejecución de los procesos alojados en el repositorio desde la terminal. La API sólo consta de dos funciones. Una de ellas para la ejecución de tareas una única vez y otra para la programación de ejecución de tareas. models.py Este chero se corresponde con la capa de modelos de la arquitectura MVC y en él se denen los modelos que serán almacenados en la base de datos. Mediante este chero y la correcta conguración de la conexión a la base de datos, Django es capaz de crear la estructura de la misma, liberando al programador de tener que trasladar este modelo de datos a lenguaje SQL. formus.py En este chero se han denido todos los formularios necesarios para mostrar y captar información del usuario. El framework Django permite la creación automática de formularios a partir de los modelos denidos en models.py. Continúa en la siguiente página

117 projects Cuadro 6.1 Continuación de la página anterior Fichero Descripción views.py En este chero se denen las funciones vista, las cuales serían denominadas controladores si el desarrollo fuera llevado a cabo con un framework que siguiera férreamente el MVC. Todas las funciones vista reciben como parámetro, al menos, una request y siempre debe devolver como resultado una respuesta HTTP. settings.py En este chero se dene la conguración de la aplicación web desarrollada con el framework Django. Son aquí congurables: El nombre de la aplicación. La conexión a la base de datos. Los directorios de cheros de plantilla y multimedia. urls.py Este chero es el despachador de URLs de Django. En él se pueden denir URLs mediante expresiones regulares, parámetros que reciben y función vista responsable de cada una Procesos de Pentaho Assembla Job Assembla Discoverer Este es el proceso de Pentaho de más alto nivel que trabaja con la forja Assembla. Su funcionalidad consiste en llamar a la transformación Assembla Discoverer y enviar un al usuario en caso de que un error ocurriera durante su ejecución. Transform Assembla Discoverer Esta transformación analizará el chero que contiene los nombres de los proyectos y los almacenará en la base de datos indicando que pertenecen al dataset especicado como parámetro. Job Generic Wrapper Este proceso se ocupa de realizar las peticiones a la API y almacenar los cheros descargados en memoria secundaria. Job Integration Generic Process Con este proceso se pretende extraer la información de los documentos XML descargados mediante el proceso "Generic Wrapper almacenarlos en la base de datos. Para ello se ayudará de la transformación Assembla to Database Transform Assembla to Database Esta transformación se encarga de guardar en la base de datos la información obtenida de los diversos cheros descargados de Assembla. Redmine Job Redmine Discoverer Este es el proceso de Pentaho de más alto nivel que trabaja con la forja Redmine. Su funcionalidad consiste en llamar a la transformación Redmine Process y enviar un al usuario en caso de que un error ocurriera durante su ejecución. 2

118 Transform Redmine Process En este proceso se generan las URIs de todas las peticiones que hay que realizar a la instancia de la forja Redmine que corresponda al dataset. Transform Redmine SubProcess las correspondientes APIs. Esta transformación realiza las peticiones HTTP a Rúbrica Job Métricas Este proceso se ejecuta siempre para todos los datasets almacenados en el sistema y calcula, a partir de los datos extraídos de las forjas, una serie de métricas referentes al mismo Scripts de Base de Datos Organización de los scripts para crear de base de datos, describiendo la utilidad de los diferentes cheros y su posible distribución en directorios abreforjas.sql Con la utilización de Django como framework de desarrollo de aplicaciones web se simplica mucho la interacción con la base de datos. Es por ello que en el caso de Abreforjas se ha desarrollado este script con el único n de inicializar la base de datos. Las tablas que se inicializan son: forges: Inicializada con las forjas Assembla y Redmine forge_apis: Con información para la realización de las diferentes peticiones a las diversas forjas. ticket_status: Se inicializa con los estados de tickets contemplados por Assembla. ticket_priorities: Se inicializa con las prioridades de tickets contempladas por Assembla. roles: Se inicializa con los roles de usuario contemplados por Assembla.

119 Capítulo 7 Pruebas del Sistema En este capítulo se documentan los diferentes tipos de pruebas que se han llevado a cabo, ya sean manuales (mediante listas de comprobación) o automatizadas mediante algún software especíco de pruebas Estrategia Para la prueba de Abreforjas se ha seguido una estrategia de pruebas manual, pues la cantidad de funcionalidades no requería la programación de una herramienta que asistiera la fase de pruebas y permitiera automatizarlas. Al coincidir en este proyecto el grupo de testeadores independientes con los clientes, se podría decir que se han realizado pruebas unitarias de aceptación, siendo como el propio nombre indica la aceptación por parte de los clientes la evaluación de los resultados de las pruebas. Para las pruebas de regresión se detectaron las funcionalidades que eran dependientes de los elementos que sufrían cambios de algún tipo. De esta manera, tras la realización de los cambios pertinentes se procedía a probar aquellas funcionalidades que pudieran haber sido afectadas. Por ejemplo, si una transformación de un proceso de Pentaho sufría algún cambio, se procedía al testeo del Job inmediatamente superior en la jerarquía, o si se realizaban cambios en un formulario se procedía a probar aquellas vistas que lo utilizaban. No obstante, cuando el estado de desarrollo de Abreforjas fue lo sucientemente avanzado, era más sencillo realizar directamente las pruebas de sistema en lugar de buscar y detectar las correspondientes dependencias Entorno de pruebas Los requisitos del sistema para la realización de pruebas son los mismos que los descritos en el apartado Roles En las pruebas han participado tres personas correspondientes a dos perles: El desarrollador del software como conductor de las pruebas. Dos testeadores independientes para resolver los conictos de intereses que pudiera tener el propio desarrollador al probar él mismo el producto. 105

120 Desarrollador Es inevitable que el desarrollador pruebe su propio producto. Es evidente que en las pruebas realizadas por su parte existen unos conictos de intereses inherentes. Esto no quiere decir que estas pruebas no sean necesarias, simplemente que no son sucientes como para asegurar la calidad del software. Se podrían entender estas pruebas como las que, como mínimo, debe pasar el software antes de que un grupo externo al desarrollo de testeadores lo probara Testeadores independientes Dos profesores del departamento actuaron como testeadores independientes de Abreforjas. Al estar mayor o totalmente aislados del proceso de desarrollo no existía el conicto de intereses anteriormente mencionado y actuarían como si fueran usuarios nales. De hecho actuaron como clientes en la elicitación de requisitos. Las pruebas realizadas por estos participantes fueron realizadas desde las pruebas unitarias, de manera que los riesgos de desarrollo pudieran ser reducidos. Así el desarrollador recibía feedback del producto en el estado en el que se encontrara y podía adaptar las sugerencias y cambios solicitados en futuras fases del desarrollo Niveles de prueba En este sección se documentan los diferentes tipos de pruebas que se han llevado a cabo. Todas fueron realizadas de manera manual Pruebas Unitarias Aplicación web Las pruebas unitarias en la aplicación web fueron llevadas a cabo en el nivel de vista (controlador en el resto de frameworks). Es decir, para cada URL y vista asociada se comprobaba que la apariencia y funcionalidad de la misma era la esperada. Procesos de Pentaho El correcto funcionamiento de los procesos de Pentaho fueron probados de manera individual en independientemente uno del otro. Siempre a nivel de "Job", pues son los que proveen de datos de entrada a las transformaciones que contienen. Al ser Abreforjas una herramienta que puede ser utilizada para asistir el proceso evaluativo, es importante que los resultados de las métricas que se calculen sean reales. Por ello, en el caso particular de este proceso, se escogieron dos proyectos al azar de cada dataset y se comprobó que, verdaderamente, los resultados de las métricas calculadas por Abreforjas eran idénticos a los calculados manualmente por un humano. D2R-Server Una vez realizado el chero abreforjas-mapping.ttl y con la estructura de la base de datos creada se inició D2R-Server en entorno de desarrollo y en local para comprobar que el mapeo entre la base de datos relacional y el vocabulario se realizaba correctamente.

121 Pruebas Integración Tras el desarrollo del chero pentaho/api.py se comenzaron las pruebas de integración entre la aplicación web y los procesos de Pentaho. Una vez más las pruebas se realizaron manualmente. Al tener conocimiento, por las pruebas unitarias, de que los procesos y la aplicación funcionaban bien por separado sólo fue necesario comprobar que las llamadas al chero kettle.sh se realizaban correctamente. Posteriormente se introdujo en el entorno de pruebas el programador de tareas Celery, el cual se introduce lógicamente entre la aplicación web y los procesos de Pentaho. Para comprobar su correcta integración tanto con la aplicación web como con los procesos de Pentaho se introdujo una frecuencia de actualización de 10 minutos para un dataset y se comprobó que verdaderamente cada 10 minutos se iniciaban los pertinentes procesos de Pentaho. Esta frecuencia de actualización de dataset carece de sentido en un entorno de producción por lo que posteriormente volvió a ser eliminada. Por otro lado también se hicieron pruebas de integración entre la aplicación web y D2R-Server. La integración en este caso fue sencilla, pues únicamente había que añadir un enlace que enlazara la instancia del servidor D2R desde la aplicación web Pruebas Sistema En esta actividad se realizan las pruebas de sistema de modo que se asegure que el sistema cumple con todos los requisitos funcionales establecidos. Pruebas Funcionales Durante las pruebas funcionales se interactuó, por supuesto con las dos forjas, tanto Assembla como Redmine. Para que las pruebas no fueran pesadas y extendidas en el tiempo se tomaron dos decisiones: Escribir en un chero un conjunto de proyectos de Assembla relativamente pequeño. Fueron cuatro en total. Montar una instancia de la forja Redmine en una máquina virtual y realizar las peticiones a dicha instancia en lugar de a cualquier otra que estuviera online. Una vez cargados los datasets varias personas navegaron a través de la aplicación web visualizando los proyectos alojados en cada uno, las grácas generadas con GoogleChartsWrapper de las métricas de cada proyecto así como toda la información textual (fechas, métricas, nombres, descripciones, etc.) Posteriormente se siguió el enlace que conduce a la instancia del servidor D2R y se comprobó que los mismos datos estaban disponibles. Además se realizaron consultas al SPARQL endpoint que el servidor D2R-Server para comprobar su correcto funcionamiento Pruebas Aceptación Para demostrar que el producto estaba listo para el paso a producción se realizaron pruebas parecidas a las descritas en las pruebas funcionales pero con una masa mayor de datos. En concreto se escogieron más de 30 proyectos de Assembla y probó con la instancia de Redmine en la que está alojado este mismo proyecto (

122 dando como resultado dos grandes conjuntos de datos que tres profesores del grupo de investigación consideran de valor para la publicación de artículos cientícos. Uno de estos artículos es [Traverso-Ribón et al., 2013]. En él se publicaron los resultados obtenidos de la exploración anteriormente mencionada en Assembla.

123 Parte III Epílogo 109

124

125

126

127 Capítulo 8 Manual de implantación y explotación Las instrucciones de instalación y explotación del sistema se detallan a continuación Introducción Abreforjas es un software creado para ayudar a docentes o jefes de proyecto en la evaluación del estado de desarrollo de un proyectos software alojados en forjas. Los jefes de proyecto y los docentes suelen tener bajo su revisión una cantidad considerable de proyectos software, cada uno con varios miembros participantes. La utilización de las forjas para su alojamiento hace posible el registro objetivo de la actividad de los diversos miembros en el proceso de desarrollo del proyecto, siendo ahora las contribuciones de los diversos usuarios visibles desde el punto de vista del jefe de proyecto o profesor. El problema es que la comprobación de todos estos datos no es un proceso sostenible cuando la cantidad de proyectos y de usuarios que intervienen en ellos es relativamente grande. Las forjas ofrecen APIs mediante las que recuperar información de interés para los supervisores de los proyectos. Entre ella, se encuentra la división del proyecto en Milestones y la subdivisión de estos a su vez en tickets. Los tickets podrían ser considerados como la unidad de información de más utilidad. De ellos se puede conocer qué usuario lo creó, quién debe resolverlo e incluso el tiempo transcurrido desde su creación hasta su cierre. Abreforjas recopila estos datos de manera desatendida y ofrece al usuario tanto un resumen textual de algunas métricas como los datos en crudo etiquetados con el vocabulario semántico VSPF Requisitos Previos Requisitos hardware y software para la correcta instalación del sistema Requisitos Software Abreforjas ha sido desarrollado, probado y utilizado en una máquina con Ubuntu como sistema operativo, aunque debería ser compatible con cualquier sistema GNU/Linux. Abreforjas mantiene dependencias con las siguientes aplicaciones: Apache Server 2.2 o superior Apache Tomcat 6 o superior 113

128 Celery para Django Django Framework MySQL 5.1 o superior Python Módulo WSGI para Apache Requisitos Hardware Abreforjas tiene requerimientos excesivos en cuanto a capacidad de cómputo. Ha sido probado y utilizado en una máquina con las siguientes características: Procesador de doble núcleo a 2.4 Ghz 4 GB de memoria RAM Conexión a internet de 10 Mb/s 700 MB de espacio en disco Aunque no ha sido probado, no debería haber problemas para ejecutar Abreforjas en un entorno menos potente Inventario de Componentes Lista de los componentes hardware y software que se incluyen en la versión del producto Pentaho Data Integration En el chero de instalación de Abreforjas se incluye la última versión en el momento de la liberación de Pentaho Data Integration en su versión de comunidad y por tanto con licencia libre. La inclusión de esta aplicación es la que hace que el espacio requerido en disco sea más elevado del esperado, pues ocupa 450 MB D2R-Server En el chero de instalación de Abreforjas se incluye un archivo de extensión war que contiene el servidor D2R listo y congurado para ser desplegado por Apache Tomcat Aplicación Web Django Para orquestar los dos componentes y como interfaz de usuario se incluye una aplicación web desarrollada con Django así como un chero de conguración de un virtual host para el servidor Apache.

129 Fichero de instalación Se incluye un script en bash para satisfacer las dependencias software de Abreforjas a partir de paquetes descargados de los repositorios ociales de Ubuntu mediante la herramienta apt-get de este sistema operativo. Este script deberá ser ejecutado con privilegios de superusuario, pues se realizan escrituras en directorios del sistema Procedimiento de Instalación Para la instalación de Abreforjas se deberán seguir los siguientes pasos: 1. Descomprima el tar.gz en cualquier directorio de su equipo 2. Modique el chero abreforjas/settings.py y en el apartado Databases, ponga las credenciales adecuadas para acceder a la base de datos, indicando el nombre de usuario de la base de datos que quiera asignarle a Abreforjas y su contraseña. Dicho usuario deberá tener permisos de creación, modicación, eliminación y acceso a bases de datos. 3. Sitúese en el directorio de instalación 4. Abra el chero abreforjasvh (virtualhost para apache) y modique el parámetro Server- Name y ponga el nombre de dominio que le vaya a dar a su instancia de Abreforjas. 5. Modique /etc/hosts de manera consecuente con respecto al nombre que le ha dado al ServerName del paso anterior. 6. Ejecute el script install.sh incluido en el tar.gz 7. Ejecute ahora sh /var/www/abreforjas/projects/pentaho/data-integration/spoon.sh 8. Pinche sobre el botón verde situado en la esquina superior derecha para crear un nuevo repositorio de procesos en la base de datos. 9. Clique en New para crear una nueva conexión a una base de datos 10. Seleccione MYSQL y establezca los siguientes parámetros: Connection Name: Repo Host Name: localhost Database Name: pentaho Port Number: 3306 User y Password los mismos que se pusieron en el chero settings.py 11. Clique OK y vuelva al formulario de creación de repositorio. Establezca los siguientes parámetros: Como conexión de base de datos la que se acaba de crear Repo ID : REPO Name: Repositorio_Abreforjas 12. Clique en Create or Upgrade y posteriormente en Ok

130 13. Aparecerá un formulario de login en el que se introducirá admin, admin como usuario y contraseña. 14. Seleccione el archivo pentaho/repositorio de la carpeta en la que se descomprimió el tar.gz descargado. 15. Abreforjas requiere almacenar cheros temporales para la extracción de datos de las forjas. Por ello hay que crear una estructura de carpetas determinada en donde el usuario desee. Ella consistirá en una carpeta principal que contendrá las siguientes subcarpetas: harvested pre-stored stored non-stored 16. Una vez ha nalizada la importación se realizarán un par de modicaciones adicionales: Clique en Tools/Repository/Explore y entre en el menú de exploración del repositorio. En el árbol de exploración se accede a la transformación /CUSL/GenericWrapper/Project Data Downloader/ Acceda al paso con nombre Dene target le path Se busca la variable RDF_FILENAME y se cambia la base del PATH para que coincida con la carpeta harvested anteriormente creada. La ruta debe terminar con / o la transformación fallará. 17. El segundo cambio tiene lugar en el paso Set global Variables del proceso CUSL/Integration Generic Process/. En él hay que cambiar la base de los PATH para que se corresponda con la carpeta principal de la jerarquía creada en el paso 15 de este documento. 18. El usuario www-data debe tener permiso de lectura y escritura en los directorios especicados en el paso anterior o de lo contrario la ejecución de los procesos de pentaho no será posible Procedimientos de Operación y Nivel de Servicio Abreforjas envía al usuario de la aplicación que inicia la carga de un dataset un indicando si la carga se realizó correctamente o no y un extracto del log en caso de fallo. El chero log de la última ejecución se encuentra en /var/www/abreforjas/log, por lo que si ocurriera algún problema el administrador del servidor podría consultar lo sucedido. Los datos almacenados por Abreforjas fruto de las cargas de datos de los diversos datasets se encuentran en la base de datos de MySQL con nombre abreforjas. Es, por tanto, la única base de datos a tener en cuenta para realizar los correspondientes backups. Como tarea de mantenimiento, sería recomendable vigilar que la jerarquía de carpetas donde se almacenan los cheros obtenidos de las APIs no se ve alterada, así como borrar periódicamente los cheros almacenados, pues pueden llegar a ocupar una porción importante de memoria secundaria.

131 8.6. Pruebas de Implantación Para comprobar que el sistema se ha implantado correctamente el usuario deberá abrir su navegador web favorito y acceder a la URL que haya indicado en el ServerName correspondiente del virtual host de Apache. Debería aparecer la página principal de abreforjas y el funcionamiento de la aplicación debería ser correcto. Para comprobarlo podría probar con un pequeño conjunto de proyectos de Assembla, por ejemplo Instrucciones para seguir desarrollando Abreforjas La última versión del código fuente se encuentra aloja en redmine/projects/abreforjas. En la carpeta códigofuente se encuentran dos subcarpetas: djcode: En esta carpeta se encuentran todos los cheros relativos a la aplicación web. A partir de aquí, la aplicación sigue una estructura parecida a cualquier otra aplicación web desarrollada con Django. En el apartado 6.2 hay más información acerca de cada chero particular. pentaho: En esta carpeta se encuentra el repositorio de Pentaho Data Integration en formato xml. Toda la comunicación con las APIs se hace mediante los procesos de Pentaho, por lo que las modicaciones o nuevos procesos deberán reejarse en este chero-repositorio. En el apartado 6.2 hay más información acerca de cada proceso particular.

132

133 Capítulo 9 Manual de usuario Las instrucciones de uso del sistema se detallan a continuación Introducción Abreforjas es un software creado para ayudar a docentes o jefes de proyecto en la evaluación del estado de desarrollo de un proyectos software alojados en forjas. Los jefes de proyecto y los docentes suelen tener bajo su revisión una cantidad considerable de proyectos software, cada uno con varios miembros participantes. La utilización de las forjas para su alojamiento hace posible el registro objetivo de la actividad de los diversos miembros en el proceso de desarrollo del proyecto, siendo ahora las contribuciones de los diversos usuarios visibles desde el punto de vista del jefe de proyecto o profesor. El problema es que la comprobación de todos estos datos no es un proceso sostenible cuando la cantidad de proyectos y de usuarios que intervienen en ellos es relativamente grande. Las forjas ofrecen APIs mediante las que recuperar información de interés para los supervisores de los proyectos. Entre ella, se encuentra la división del proyecto en Milestones y la subdivisión de estos a su vez en tickets. Los tickets podrían ser considerados como la unidad de información de más utilidad. De ellos se puede conocer qué usuario lo creó, quién debe resolverlo e incluso el tiempo transcurrido desde su creación hasta su cierre. Abreforjas recopila estos datos de manera desatendida y ofrece al usuario tanto un resumen textual de algunas métricas como los datos en crudo etiquetados con el vocabulario semántico VSPF Características Las principales características del sistema son: La creación de nuevos conjuntos de datos de proyectos software alojados en forjas de tipo Assembla o Redmine. El cálculo de datos agregados y métricas sencillas para dichos proyectos. La visualización de dichos datos mediante una interfaz web (textual o grácamente). La publicación de esos datos mediante el lenguaje VSPF. 119

134 9.3. Requisitos previos Requisitos hardware y software para el correcto uso del sistema Requisitos del cliente El cliente podrá utilizar la aplicación mediante cualquier dispositivo con un navegador web. No hay mayor requisito que este. Abreforjas podría ser utilizado incluso desde un smartphone o un tablet sin ningún tipo de problema Requisitos del servidor Requisitos software Abreforjas ha sido desarrollado, probado y utilizado en una máquina con Ubuntu como sistema operativo, aunque debería ser compatible con cualquier sistema GNU/Linux. Abreforjas mantiene dependencias con las siguientes aplicaciones: Apache Server 2.2 o superior Apache Tomcat 6 o superior Celery para Django Django Framework MySQL 5.1 o superior Python Módulo WSGI para Apache Requisitos hardware Abreforjas tiene requerimientos excesivos en cuanto a capacidad de cómputo. Ha sido probado y utilizado en una máquina con las siguientes características: Procesador de doble núcleo a 2.4 GHz 4 GB de memoria RAM Conexión a internet de 10 Mb/s 700 MB de espacio en disco Aunque no ha sido probado, no debería haber problemas para ejecutar Abreforjas en un entorno menos potente Uso del Sistema Descripción del área de trabajo del sistema y las instrucciones concretas para hacer uso de las funcionalidades del sistema.

135 Figura 9.1: Pantalla de inicio de Abreforjas Registrar Usuario El usuario clicará en el botón verde en la página principal con el texto Sign up in Abreforjas (Figura 9.2). Figura 9.2: Botón de Registro Esto lo redirigirá a una página con un formulario que con los campos necesarios para poder llevar a cabo el registro (Figura 9.3). El usuario introducirá los datos requeridos, atendiendo a los criterios clásicos en cualquier web relacionados con caracteres extraños (acentos, símbolos especiales, letras características de un lenguaje. En cualquier caso, si el usuario introdujera algún campo no válido, la propia aplicación se lo indicaría textualmente.

136 Figura 9.3: Formulario de Registro Login Usuario Si el usuario no está logueado, será posible ver en cualquier página de la aplicación un botón azul en la esquina superior derecha con el texto Sign In (Figura 9.4). Figura 9.4: Botón de Login Esto redirigirá al usuario a una página con un formulario de logueo (Figura 9.5). Una vez insertados ambos campos pulsará "Sign in pasará a estar logueado en el sistema, siempre y cuando los datos fueran los correctos. En caso contrario se informará del error al usuario y se le permitirá que introduzca de nuevo sus datos de logueo Editar Usuario Un usuario logueado tendrá en todo momento disponible en la esquina superior derecha un botón azul cuyo texto es su nombre de usuario. Si clica en él será redirigido a una página con un

137 Figura 9.5: Formulario de Login formulario (Figura 9.6) que permite editar dos campos y a su vez tiene un enlace para acceder al cambio de contraseña. El usuario puede limitarse a cambiar alguno de los dos campos modicados o pinchar en el enlace para cambiar su contraseña. En ese caso será redirigido a un nuevo formulario (Figura 9.7) en el que deberá introducir su contraseña actual y la nueva por dos veces para que el cambio tenga efecto Logout Un usuario logueado tendrá en todo momento disponible un botón en la esquina superior derecha con el texto Logout (Figura 9.8) que le permitirá salir del sistema Crear Dataset Tras loguearse el usuario accede a la pantalla principal de la aplicación (Figura 9.9). En ella podrá clicar en el botón verde con texto Create Dataset. En ese momento será redirigido a una pantalla (Figura 9.10) con un formulario con los campos requeridos para crear un dataset. Si la forja escogida es Assembla, deberá seleccionar un chero local con los proyectos a descargar. Desde la propia web se ofrece un chero de ejemplo para que el usuario no tenga problemas con el formato del mismo. Si la forja escogida es Redmine, el usuario deberá introducir su API Key de la correspondiente instancia de la forja. Esta API Key puede encontrarse bajo el sobrenombre Clave de acceso de

138 Figura 9.6: Formulario de Editar Usuario la API en la barra lateral derecha de la pantalla que se observa al acceder a Mi cuenta en Redmine Actualizar Dataset En la página principal de Abreforjas el usuario seleccionará un dataset mediante un combobox. Posteriormente clicará en el botón verde con el texto Update Dataset, lo que redirigirá al usuario a una página con un formulario para editar diversos campos del dataset (Figura 9.11). Cuando el usuario guarde los cambios, además de quedar registrados los cambios en los campos, se procederá a un refresco de los datos correspondientes a dicho dataset Eliminar Dataset En la pantalla principal de Abreforjas el usuario seleccionará un dataset a partir de un combobox y clicará en un botón rojo con el texto Delete Dataset. Tras esto el sistema pedirá al usuario conrmación de esta acción, reduciendo así los riesgos de eliminar un dataset por accidente Ver Dataset Desde la página principal de Abreforjas el usuario seleccionará un dataset a partir de un combobox y clicará en un botón de color azul con el texto Show Dataset. En este momento el usuario será redirigido a una página donde podrá observar información general del dataset así como una lista de los proyectos que contiene (Figura 9.12).

139 Figura 9.7: Formulario de Cambio de Contraseña Figura 9.8: Botón de Logout Ver Proyecto Desde la página principal de un determinado dataset, el usuario seleccionará un proyecto de la lista que es visualizada y pulsará en el botón gris con el texto "Show Project". Esta acción redirigirá al usuario a una página con información general del proyecto (Figura 9.13) Ver Métricas de Proyecto Desde la página principal de un proyecto determinado el usuario clicará en la pestaña con nombre "Metrics". Esto lo redirigirá a una nueva página con resultados en formato textual de las métricas de dicho proyecto junto con una descripción de las mismas para que el usuario no tenga que consultar documentación adicional para entenderlas (Figura 9.14) Ver Grácas de Proyecto Desde la página principal de un determinado el proyecto el usuario clicará en la pestaña "Graphics", lo cual lo redirigirá a una página como la de la gura Acceder a D2R-Server En cualquier página de la aplicación, en el menú principal situado en la parte superior izquierda de la pantalla podrá visualizarse un botón con el texto "D2R-Server". Si el usuario clica en ese enlace es redirigido a la instancia del servidor D2R, teniendo acceso a los datos de los diferentes datasets en formato RDF con el vocabulario VSPF. Además, en la página principal de cada proyecto el usuario tendrá a su disposición un enlace que le llevará a la página correspondiente de D2R-Server con la información de ese proyecto en formato RDF. Para más información del funcionamiento del servidor D2R se remite al usuario a la documentación de dicho software, disponible en el siguiente enlace

140 Figura 9.9: Página de inicio

141 Figura 9.10: Formulario Crear Dataset

142 Figura 9.11: Formulario Actualizar Dataset Figura 9.12: Página General Dataset

143 Figura 9.13: Página General Proyecto Figura 9.14: Página Métricas de Proyecto

144 Figura 9.15: Página Grácas de Proyecto Figura 9.16: Página de información de proyectos en D2R