I NTEGRACIÓN DE APLICACIONES GESTORAS DE PROYECTOS Ingeniería Técnica en Informática de Sistemas Proyecto de fin de carrera, Junio 2010 Director: German Rigau i Claramunt Alumno: Lorea Ustarroz Leandro 1

ÍNDICE Introducción. Método de trabajo. Elección de las aplicaciones. Elección tecnológica. Captura de requisitos. Desarrollo técnico. Pruebas. Gestión del proyecto. Conclusiones. Demo. 2

INTRODUCCIÓN Origen del proyecto. Conveniencia de una herramienta de gestión de proyectos para un centro de investigación: Gestionar el contenido de proyectos. Gestionar los aspectos financieros, tareas, resultados y contribución de los participantes. Objetivo. Alternativas para lograr un sistemas formado por un gestor de proyectos y un gestor de contenidos. Gestores de proyectos: DotProject, Achievo… Gestores de contenidos de proyectos: Drupal, Joomla,… No existen aplicaciones que reúnan las funcionalidades de ambas. Creación de una aplicación integrando ambas. 3 3

MÉTODO DE TRABAJO Métodos de desarrollo de software: El Proceso Unificado de Desarrollo (PUD). Organización de trabajo: Se ha seguido el Documento de Objetivos del Proyecto (DOP). Reuniones con el director del proyecto. Seguir plan de contingencia y planificación temporal para evitar problemas. Pasos a seguir para el desarrollo del proyecto: Búsqueda de información de las aplicaciones existentes. Elección de dos aplicaciones. Alternativas de integración. 4

ELECCIÓN DE LAS APLICACIONES (1) Estudio previo de las aplicaciones existentes: Gestor de contenidos o CMS (Content Management System). Gestor de proyectos. Aplicaciones opensource, para poder estudiar: Código (implementación). Base de datos. 5

Gestores de contenidos de proyectos (CMS) Nombre Plataforma compatibleLenguaje y soporte Alfresco  Red Hat Enterprise  Sun Solaris 10  Windows Server 2003  Cualquier sistema con soporte JSP debería soportarlo (MacOS, Linux, Unix)  Desarrollado en JSP  Soporta cualquier base de datos apoyada por Hibernate, incluidas: MySQL 5 y Oracle 10  Servidor Web: Apache Tomcat Drupal  Unix/Linux  Windows  Desarrollado en PHP  Soporte para MySQL y PostgreSQL  Servidor Web: Apache 1.3 o superior. Joomla  Unix/Linux  Windows  Desarrollado en PHP  Soporte para MySQL y PostgreSQL  Servidor Web: Apache 6 o superior. DotCMS Core  Unix/Linux  Windows  Desarrollado en J2EE/Java  soporte para MySQL, PostgreSQL, MS-SQL y Oracle  Servidor Web: Apache Tomcat 6

Gestores de proyectos Requisitos previos Características generales Nombre de aplicación ServidorLenguaje Gestor de base de datos Dotproject Servidor web: Apache o superior PHP 4.1.x ó superior. MySQL ó superior.  Utilización de plantillas.  Creación de graficas de Gantt.  Repositorio de fichero.  Disponibilidad de diversos módulos.  Aplicación multiusuario.  Multi-idiomas. Achievo Servidor web: apache 2 PHP 5MySQL  Utilización de módulos.  Multi-idiomas. 7

ELECCIÓN DE LAS APLICACIONES (2) Criterios para la elección de las aplicaciones:: Lenguaje en que han sido implementadas. Tipo de bases de datos soportadas. Funcionalidades de la aplicación. Dificultad de la instalación. 8

ELECCIÓN DE LAS APLICACIONES (3) 9 AplicacionesServidorLenguajeGestor de bases de datos Instalación DotProject Servidor web: Apache o superior Desarrollado en PHP 4.1.x o superior. Soporte para MySQL o superior. Rápida instalación. Instalable en equipos antiguos y modernos. Drupal Servidor Web: Apache 1.3 Desarrollado en PHP Soporte para MySQL y PostgreSQL Rápida instalación.

ELECCIÓN TECNOLÓGICA WAMP Plataforma para Windows que incorpora PHP, MySQL y Apache. Para el correcto funcionamiento de las aplicaciones seleccionadas. Análisis de las bases de datos. NetBeans IDE 6.5 Entorno de desarrollo implementado en java pero que sirve para cualquier otro lenguaje de programación. Análisis de la implementación de las aplicaciones. 10

CAPTURA DE REQUISITOS (1) ¿Qué vamos a integrar? Muchas alternativas. Decisión: integración únicamente a nivel de usuarios. Criterios de integración: Minima intervención en la aplicaciones. Manera sencilla para el desarrollador. ¿Cómo? Manera menos invasiva. Integrando las BD  modificando las BD. 11

CAPTURA DE REQUISITOS (2) Base de datos de DotProject: Cuando un usuarios es creado en DotProject se modifican las siguientes tablas. 12 Contiene información complementaria a la contenida en la tabla users. Relaciona cada usuario al rol correspondiente. Usuarios existentes.

CAPTURA DE REQUISITOS (3) Base de datos de Drupal: en estas tablas se almacena la información principal de los usuarios. 13 Contiene cada usuario al rol que está asociado. Roles existentes. Usuarios existentes.

CAPTURA DE REQUISITOS (4) DotProject: utiliza una clase DBQuery y sus funciones para crear las consultas a la base de datos. … $q = new DBQuery; $q->addTable('users'); $q->addQuery('user_id, user_password, user_contact'); $q->addWhere("user_username = '$username'"); … Drupal: directamente hace la consulta, mediante una única función. db_query('INSERT INTO {users_roles} (uid, rid) VALUES (%d, %d)', $array['uid'], $rid); Implementación DotProject y Drupal: 14

DESARROLLO TÉCNICO (1) Alternativa 1: sincronización de las BD. Alternativa 2: sincronizar los usuarios mediante triggers. Alternativa 3: Creación de una nueva BD para los usuarios. Alternativa 4: Creación de vistas, procedimientos y triggers. Alternativa 5: variante de la Alternativa 4. 15

DESARROLLO TÉCNICO (2) Alternativa 1: Sincronización de las BD. Solo se necesita sincronizar las tablas de los usuarios, no la BD entera. Problemas: Redundancia en la información de los usuarios. Inconsistencia de datos. APLICACIÓN BASE DE DATOS DRUPAL DOTPROJECT users tabla_dot_1 tabla_dot_2 tabla_dot_n BD_DRUPAL users tabla_dru_1 tabla_dru_2 tabla_dru_p SINCRONIZACIÓNSINCRONIZACIÓN DOTPROJECT 16

DESARROLLO TÉCNICO (3) Alternativa 2: sincronizar los usuarios mediante triggers. Replica de la misma tabla en las dos aplicaciones. Alternativa 5 similar a esta alternativa. Problemas: Continuamos con redundancia de la información. Dificultad para mantenerla consistente. APLICACIÓN BASE DE DATOS DOTPROJECT DRUPAL TRIGGERSTRIGGERS DOTPROJECT users tabla_dot_1 tabla_dot_2 tabla_dot_n BD_DRUPAL users tabla_dru_1 tabla_dru_2 tabla_dru_p 17

DESARROLLO TÉCNICO (4) Alternativa 3: creación de una nueva BD para los usuarios. No se modifican las BD originales. Problemas: Dificultad en las actualizaciones  modificar todas las llamadas. 18 DotProject.users MIPROYECTO my_users DOTPROJECT users APLICACIÓNBASE DE DATOS bd_drupal.users DRUPAL DOTPROJECT BD_DRUPAL users miproyecto.my_users

DESARROLLO TÉCNICO (5) Alternativa 4: Creación de vistas, procedimientos y triggers. Se ha averiguado: Crear usuario en Drupal  utilizarlo en DotProject. NO funciona. Crear usuario en DotProject  utilizarlo en Drupal. SI funciona. 19 DRUPAL PROCEDIMIENTOS MIPROYECTO my_users TRIGGERS DOTPROJECT APLICACIÓN BASE DE DATOS BD_DRUPAL users (vista) DOTPROJECT contacts gacl_aro gacl_aro_seq gacl_groups_aro_map users (vista)

DESARROLLO TÉCNICO (6) Para ponerla en práctica: Crear nueva BD  miproyecto. Crear tabla de usuarios en miproyecto  my_users. Crear las vistas users en cada BD. Crear los triggers y procedimientos. 20 DotProject bd_ drupal

DESARROLLO TÉCNICO (7) Se ejecutan los triggers en cascada: Problema : ERROR CIRCULAR. MySQL no permite modificar una tabla que se esta consultando por el mismo trigger. insert_contacts AFTER my_users (insert in contacts ); insert_gacl_aro AFTER contacts (insert in gacl_aro ); insert_gacl_groups AFTER gacl_aro (insert in gacl_group_aro_map ); update_user_contact AFTER gacl_groups_aro_map (update in my_users );

DESARROLLO TÉCNICO (7) Alternativa 5: variante de la Alternativa 4. DOTPROJECT DRUPAL APLICACION BASE DE DATOS MIPROYECTO my_users PROCEDIMIENTOS my_contacts my_gacl_aro my_gacl_aro_seq my_gacl_groups_a ro_map my_aplic TRIGGERS DOTPROJECT users (vista) contacts (vista) gacl_aro (vista) gacl_groups_aro_ map (vista) gacl_aro_seq (vista) BD_DRUPAL users (vista) 22

DESARROLLO TÉCNICO (8) Suma de las anteriores alternativas. Crear una replica de las tablas de DotProject, en la BD miproyecto. Crear las vistas en DotProject, de las tablas de miproyecto. Crear 2 triggers: Crear usuarios: trigger insert_user_drupal. Eliminar usuarios: trigger drop_user_drupal. 23

PRUEBAS Pruebas unitarias: Funcionamiento de los procedimientos y triggers generados en este proyecto Pruebas de integración: Probar todos los elementos unitarios (triggers y procedimientos) que componen un proceso. Pruebas de validación: ¿se ha cumplido el objetivo? Pruebas de carga: Probar múltiplas operaciones concurrentemente y correcto funcionamiento de las transacciones. 24

GESTIÓN DEL PROYECTO (1) Planificado: 216 h. Real: 225,9 h. Desajuste de horas total: 4,58% 25

GESTIÓN DEL PROYECTO (2) Gráfica de procesos tácticos, operativos y formativos. 26

CONCLUSIONES Gestión del proyecto: Se han cumplido los objetivos de forma satisfactoria y a tiempo. Desarrollo de la aplicación: Gran importancia del análisis y el diseño para facilitar la implementación. Objetivos logrados: únicamente modificando la BD y utilizando las capacidades triggers, procedimientos… Valoraciones personales: Demostrar lo aprendido en diversas asignaturas. Experiencia enriquecedora y satisfactoria. Conocer aplicaciones existentes. Se han aprendido y utilizado nuevas tecnologías. 27

I NTEGRACIÓN DE APLICACIONES GESTORAS DE PROYECTOS Ingeniería Técnica en Informática de Sistemas Proyecto de fin de carrera, Junio 2010 Director: German Rigau i Claramunt Alumno: Lorea Ustarroz Leandro 1 28