facultad de informática informatika fakultateaadimen.si.ehu.es/~rigau/teaching/ehu/pfcs... ·...

Facultad de Informática Informatika Fakultatea

Proyecto de fin de carrera, abril de 2010

INTEGRACIÓN DE APLICACIONES GESTORAS DE PROYECTOS

Alumno/a: D./Dña. Lorea Ustarroz Leandro

Director/a: D./Dña. German Rigau i Claramunt

Integración de aplicaciones gestoras de proyectos: Memoria

Facultad de Informática Informatika Fakultatea

Proyecto de fin de carrera, abril de 2010

~ 2 ~

INTEGRACIÓN DE APLICACIONES GESTORAS DE PROYECTOS

Alumno/a: D./Dña. Lorea Ustarroz Leandro

Director/a: D./Dña. Germán Rigau


~ 3 ~


RESUMEN

Los primeros sistemas de administración de contenidos fueron desarrollados por

organizaciones que publicaban una gran cantidad de información en internet, que necesitaban

de continuas actualizaciones. La alta participación de los usuarios en redes sociales, blogs…

ha convertido a los gestores de contenidos una herramienta esencial en Internet. Una

herramienta que actualmente se utiliza para gestionar los datos de grupos de investigación,

trabajos en grupo…. Independientemente de los CMS se encuentran los gestores de proyectos,

principalmente utilizados en grupos de investigación, encargados de administrar los

componentes del grupo que realizaran el proyecto, cada uno de que parte se hará cargo,

presupuestos del material a utilizar, tiempo empleado para cada apartado del proyecto…

Este proyecto de fin de carrera, tiene como objetivo la integración de un gestor de proyecto y

un CMS (Gestor de Contenidos de Proyecto), creando una herramienta para obtener una

administración completa de un proyecto en grupo. Para poder integrarlas, se han tenido en

cuenta la forma de implementación, el gestor de base de datos que ambas utilizan y el

servidor. Partiendo de ahí, se han obtenido dos aplicaciones las cuales se han estudiado para

conocer cuál era la manera más conveniente para poder complementarlas.

Al ser unas aplicaciones igualmente implementadas en PHP, la base de datos gestionada por

MySQL y Apache de servidor web, su integración ha sido más fácil. Para analizar las

aplicaciones, en cuanto a la implementación se refiere, hemos utilizado NetBeans IDE, y

WampServer para comprender la estructura y almacenamiento de lo datos. Con la ayuda de

estas herramientas el desarrollo de este proyecto ha sido mas sencillo.

~ 4 ~


INDICE

INDICE DE TABLAS.........................................................................................................................6

INDICE DE ILUSTRACIONES.........................................................................................................7

INDICE DE PANTALLAS.................................................................................................................8

INDICE DE GRAFICAS..................................................................................................................10

1. INTRODUCCIÓN.........................................................................................................................10

2. DOCUMENTO DE OBJETIVOS DEL PROYECTO...................................................................12

3. OBJETIVOS ..................................................................................................................................25

4. ANÁLISIS DEL ENTORNO.........................................................................................................26

5. ELECCIÓN DE LAS APLICACIONES .......................................................................................36

ELECCIÓN TECNOLOGICA..........................................................................................................38

6. CAPTURA DE REQUISITOS.......................................................................................................42

7. ANÁLISIS......................................................................................................................................46

8. DISEÑO.........................................................................................................................................54

9. IMPLEMENTACION.................................................................................................................68

10. PRUEBAS................................................................................................................................84

11. GESTION DEL PROYECTO...................................................................................................92

12. CONCLUSIONES......................................................................................................................97

13. BIBLIOGRAFIA..........................................................................................................................99

~ 5 ~


INDICE DE TABLAS

Tabla 1: CMS, Content Management System....................................................................................28

Tabla 2: Gestores de proyectos...........................................................................................................33

Tabla 3: Horas planificadas/horas reales (procesos tácticos).............................................................92

Tabla 4: Horas planificadas/horas reales (procesos operativos).........................................................93

Tabla 5: Horas planificadas/horas reales (procesos formativos)........................................................94

Tabla 6: Horas planificadas/horas reales divididas por procesos.......................................................95

~ 6 ~


INDICE DE ILUSTRACIONES

Ilustración 1: Diagrama EDT.............................................................................................................15

Ilustración 2: Diagrama de Gantt.......................................................................................................21

Ilustración 3: Tablas de información de usuarios de Dotproject (1)..................................................42

Ilustración 4: Tablas de información de usuarios de Dotproject (2)..................................................43

Ilustración 5: Tablas de información de usuarios de Drupal..............................................................44

Ilustración 6: Alternativa 1: Sincronización de las bases de datos.....................................................47

Ilustración 7: Alternativa 2: Utilización de triggers...........................................................................49

Ilustración 8: Alternativa 3: Modificación de llamadas a las tablas users.........................................51

Ilustración 9: Alternativa 4: Utilización de triggers, procedimientos y vistas (únicamente de la tabla

users)...................................................................................................................................................53

Ilustración 10: Creación de la tabla my_users....................................................................................55

Ilustración 11: Estructura de tablas de Dotproject..............................................................................61

Ilustración 12: Alternativa 5: Alternativa final, utilización de triggers, procedimientos y vistas......71

Ilustración 13: Estructura de la nueva base de datos, mi_proyecto....................................................72

Ilustración 14: Operaciones que genera el trigger insert_user_drupal (1)..........................................77

Ilustración 15: Operaciones que genera el trigger insert_user_drupal (2)..........................................78

Ilustración 16: Operaciones que genera el trigger drop_user_drupal ................................................83

~ 7 ~


INDICE DE PANTALLAS

Pantalla 1: Pagina principal de WampServer....................................................................................39

Pantalla 2: Páginaprincipal de PHPMyAdmin...................................................................................39

Pantalla 3: Configuración MySQL.....................................................................................................41

............................................................................................................................................................60

Pantalla 4: Tabla de roles de Dotproject.............................................................................................60

............................................................................................................................................................74

Pantalla 5: Tabla de usuarios antes de la insercion de uno de ellos...................................................74

............................................................................................................................................................74

Pantalla 6: Formulario de insercion de usuarios en Drupal. ..............................................................74

Pantalla 7: Tabla de usuarios antes de la eliminacion de uno de ellos...............................................79

Pantalla 8: Formulario de eliminacion de usuarios en Drupal. ..........................................................79

............................................................................................................................................................84

Pantalla 9: Resultado de la ejcucion del procedimiento obt_id_users................................................84

............................................................................................................................................................85

Pantalla 10: Resultado de la ejcucion del procedimiento obt_id_cont...............................................85

............................................................................................................................................................86

Pantalla 11: Tabla de almacenamiento de los campos auto_increment..............................................86

............................................................................................................................................................86

Pantalla 12: Resultado de la ejcucion del procedimiento obt_id_gacl_seq........................................86

............................................................................................................................................................87

Pantalla 13: Resultado de la ejecución del procedimiento_id_apli_del.............................................87

Pantalla 14: Creación de usuario en Drupal.......................................................................................89

............................................................................................................................................................89

Pantalla 15: Creación de un usuario en Drupal, exitosamente...........................................................89

~ 8 ~


............................................................................................................................................................89

Pantalla 16: Identificacion de usuario Drupal en DotProject.............................................................89

............................................................................................................................................................90

Pantalla 17: Identificacion de usuario Drupal en DotProject, exitosamente......................................90

............................................................................................................................................................90

Pantalla 18: Creación de usuario en DotProject.................................................................................90

............................................................................................................................................................91

Pantalla 19: Identificación de usuario DotProject en Drupal.............................................................91

............................................................................................................................................................91

Pantalla 20: Identificación de usuario DotProject en Drupal, exitosamente......................................91

~ 9 ~


INDICE DE GRAFICAS

...........................................................................................................................................................92

Gráfica 1: Horas planificadas/horas reales (procesos tácticos).........................................................92

..........................................................................................................................................................94

Gráfica 2: Horas planificadas/horas reales (procesos operativos).....................................................94

..........................................................................................................................................................95

Gráfica 3: Horas planificadas/horas reales (procesos formativos)....................................................95

...........................................................................................................................................................96

Gráfica 4: Horas planificadas/horas reales divididas por procesos...................................................96

1. INTRODUCCIÓN

1.1 MOTIVACION

La idea inicial que motivó este proyecto es un tanto curiosa. Surge de una conversación con una

Profesora de Investigación, especialista en esponjas marinas, del Consejo Superior de

Investigaciones Científicas, en un Centro de Investigación de Gerona. La bióloga me comentó la

conveniencia de disponer de un programa para gestionar los proyectos que dirigía. Se trataba de un

programa en el que no sólo se incluyeran aspectos relacionados con la administración de la parte

económica, sino del estado en tiempo real de las actividades-científicas en cada uno de los

proyectos: investigadores que participaban y estado de las tareas que se le habían atribuido,

principales resultados obtenidos, planificación para los próximos meses, rentabilidad del proyecto

en cuanto a publicaciones generadas, participación en congresos, contactos con laboratorios

extranjeros, etc. Partiendo de dicha idea, el tutor del proyecto me informó de que ya existían

aplicaciones de este tipo, pero que probablemente, no satisfacían todas las necesidades formuladas

con anterioridad y que un buen proyecto a llevar a cabo seria precisamente hacer una revisión e

investigación de las distintas aplicaciones existentes. Después de una exhaustiva búsqueda, la

conclusión de esta investigación fue que para una gestión completa de los aspectos comprendidos

en un proyecto de investigación, lo más adecuado sería la utilización de dos programas

complementarios, por una parte un gestor de contenidos de los proyectos, conocido como CMS

(Content Management System) y por otra un gestor de los aspectos financieros, tareas, resultados y

~ 10 ~


contribución de los participantes a dichos proyectos. El presente estudio de fin de carrera

comprende el análisis, diseño e implementación de las bases de datos de dos aplicaciones que se

combinan para la gestión integrada de proyectos de investigación. Los usuarios creados podrán

acceder a ambas aplicaciones con el mismo nombre de usuario y contraseña.

A vista de los usuarios, las aplicaciones no tienen ningún cambio, son transparentes, ya que la

instalación de ambas será de forma convencional. Los cambios introducidos en este proyecto se

realizarán mediante la ejecución de un script en la base de datos global. A lo largo de la memoria se

describen todos los detalles y bases teóricas de la implementación de este proyecto.

~ 11 ~


2. DOCUMENTO DE OBJETIVOS DEL PROYECTO

1.1 INTRODUCCION

Descripción

El proyecto a realizar es una aplicación que integra dos programas ya implementados destinados

para gestión científica y económica de proyectos de investigación, cuya finalidad es el acceso a

ambas utilizando los mismos usuarios. Las bases de datos tienen funciones separadas: una gestiona

el contenido de uno o varios proyectos, en la cual se puede publicar documentación de los mismos

(tanto pública como privada) de distintos usuarios, y la otra, gestiona los proyectos, es decir,

gestiona los proyectos en que participa cada usuario, las tareas que tiene asignadas en cada uno de

ellos, los archivos asociados a cada tarea, presupuesto adscrito a cada proyecto.

Objetivos

El objetivo principal del proyecto es desarrollar una nueva aplicación basada en dos programas

distintos creados para el desarrollo de proyectos de investigación, pudiendo identificarse con los

mismos usuarios desde ambas, así como crear nuevos usuarios y borrar usuarios.

Para poder lograr el objetivo principal planeamos realizar diversas actividades exploratorias que

constituyen en si subobjetivos específicos:

1.-Consultar distintos gestores de proyectos y de contenidos de proyectos y analizar sus

características más importantes, para seleccionar los más adecuados en el desarrollo del proyecto

final. Una característica que se tendrá en cuenta es que estén implementados en el mismo lenguaje.

2.-Analizar el código de los dos programas seleccionados, para estudiar dos formas diferentes de

implementarla aplicación, a pesar de que los programas de los que se parte estén implementados en

el mismo lenguaje.

3.-Analizar las bases de datos de ambos programas, y en particular la forma en que cada uno de

ellos gestiona los usuarios y nuevamente buscar las llamadas a las tablas correspondientes a los

usuarios en el código de cada aplicación.

~ 12 ~


4.-Conocer los programas en profundidad, para encontrar distintas alternativas para poder gestionar

los usuarios desde ambas aplicaciones:

5.-Modificar el código para identificarse, crear usuarios y borrar usuarios desde ambas aplicaciones,

de manera que se puedan utilizar los mismos usuarios en cada una de ellas, sin tocar apenas la base

de datos.

6.-Crear una nueva base de datos que contenga las tablas de usuarios de ambos programas y

modificar las llamadas a las tablas de users, es decir, a las tablas de usuarios de la nueva base de

datos.

7.-Crear una nueva base de datos con una tabla que contenga los atributos de los usuarios de las dos

aplicaciones, y sin tocar el codigo, crear una vista en cada base de datos de las aplicaciones con el

nombre users, y cambiar el nombre de la tabla users de cada una de ellas.

1.2 ALCANCE

El alcance del proyecto está dividido en tres partes:

Por un lado están los procesos tácticos como gestión del proyecto, reuniones, gestión del

archivo, redacción de DOP y memoria y realización de la presentación.

Por otro lado están los procesos operativos donde se encuentran la captura de requisitos,

análisis, elección de la tecnología adecuada para el desarrollo del proyecto, diseño,

implementación y pruebas.

Por último encontramos los procesos formativos.

Recursos

Los recursos con los que cuento a la hora de realizar el proyecto son de dos tipos, recursos

personales y recursos materiales.

~ 13 ~


Recursos personales:

1 persona

Recursos materiales:

Ordenador portátil.

~ 14 ~


Diagrama EDT

Ilustración 1: Diagrama EDT

~ 15 ~

Tácticos

Gestión Proyecto

Descripción del proyecto

Objetivos del proyecto

Alcance

Planificación temporal

Plan de contingencia

Método de Trabajo

Gestión Archivos

Reuniones tácticas

Parte de trabajo

Copias de seguridad

Redacción de Memoria

Presentación

PROYECTO

Cierre de Proyecto

Valoración

Cumplimientos de objetivos

Operativos

Fase de Pruebas

Estudio de código

Elección de aplicaciones

Búsqueda de aplicaciones existentes

Modo de integración

Implementación

Estudio de la BD

Gestión de tablas

Formativos

NetBeans IDE 6.5 (PHP)

WAMP

Servidor Apache

PHP

MySQL

Implementación en PHP

Implementación MySQL


Lista de Subtareas

Procesos tácticos

• Subtarea Gestión del Proyecto:

Descripción del proyecto: texto descriptivo, sus antecedentes y

motivación.

Objetivos del proyecto: resultados (productos y servicios) que

se prevé obtener.

Alcance: diagrama EDT, asignación de recursos.

Planificación temporal: diagrama de Gantt.

Plan de contingencia : lista de riesgos y posibles soluciones.

Método de trabajo: texto descriptivo de la gestión y desarrollo.

• Subtarea Gestión de Archivos: se realizarán reuniones con el tutor para

evaluar diferentes aspectos y decisiones sobre el proyecto. Se

contabilizaran el número de reuniones realizadas y las horas invertidas

en estas, aunque no será necesaria la realización de actas de cada

reunión. Se efectuará también un parte de trabajo para la gestión de

horas reales. Y por último también se realizarán copias de seguridad

semanales para el mantenimiento de la información.

• Subtarea de redacción de memoria: la memoria será redactada durante

todo el desarrollo del proyecto. De esta manera evitaremos el olvido de

problemas y datos elaborados durante este periodo.

~ 16 ~


• Subtarea de presentación: una vez que se haya comprobado que el

proyecto funciona correctamente se hará una presentación de su vida de

desarrollo.

• Subtarea de cierre: se realizará un análisis general del proyecto como

es el cumplimiento de objetivos y problemas surgidos, una vez

entregada la memoria.

Procesos Operativos

• Subtarea búsqueda de aplicaciones existentes: búsqueda de

información sobre las distintas aplicaciones existentes, bien de los

gestores de proyectos, bien de los gestores de contenidos de proyectos.

• Subtarea elección de aplicaciones: la elección de un gestor de

contenido de proyecto y un gestor de proyectos entre los distintos

existentes.

• Subtarea estudio de código: un estudio previo del código de las

aplicaciones a integrar, para conocer distintos tipos de implementación

y posibles formas de integración.

• Subtarea estudio de la BD:

Gestión de tablas: el estudio de las tablas de ambas bases de

datos. Se prevé que pueda ser necesaria una reorganización de

las tablas con posterioridad al estudio.

• Subtarea modo de integración: una vez analizada la base de datos y el

código de ambas aplicaciones buscar distintas alternativas para una

correcta integración de las aplicaciones.

~ 17 ~


• Subtarea implementación: dependiendo de la alternativa elegida,

implementar o modificar el código, base de datos y aquellos otros

aspectos que sean necesarios para llegar al objetivo final.

• Subtarea de pruebas: se diseñaran y probaran una serie de casos de

prueba, tanto durante el desarrollo del proyecto como una vez

finalizado el mismo, para probar que la aplicación funciona

correctamente y cumple los objetivos requeridos.

Procesos Formativos

Subtareas formativas: aprendizaje de las herramientas necesarias para

el desarrollo del sistema. Será una subtarea importante en el desarrollo

del proyecto, ya que es un proyecto que requiere de distintas

herramientas que previamente no eran conocidas, y se necesita

formación e investigación de distintas opciones para llegar al objetivo

final. Posible aprendizaje de distintos lenguajes de programación.

Reflexión sobre los componentes a seleccionar para llevar a cabo el

proyecto.

1.3 PLANIFICACION TEMPORAL

La estimación total de tiempo es de: 216h, distribuidas de la siguiente manera:

Tácticas (96h.) :

Gestión del proyecto: 15h.

Creación del DOP: 15h (descripción, objetivos, alcance,

planificación temporal, plan de contingencia, método de

trabajo)

Gestión de Archivos:

Reuniones: 15h.

~ 18 ~


Copias de seguridad: 3h.

Redacción de memoria: 55h.

Presentación: 7h.

Cierre: 1h.

Operativos (108h.):

Búsqueda de aplicaciones existentes: 5h.

Selección de aplicaciones: 18h.

Estudio del código: 10h.

Estudio de la base de datos: 10h.

Modo de integración: 15h.

Implementación: 40h.

Fases de prueba: 10h.

Formativos (12h.)

Netbeans: 2h.

WAMP: 2h.

PHP: 4h.

MySQL: 4h.

~ 19 ~


Diagrama de Gantt

~ 20 ~


Ilustración 2: Diagrama de Gantt

~ 21 ~

1.4 PLAN DE CONTINGENCIA

A continuación se enumeran los posibles riesgos e inconvenientes que pudieran surgir a lo

largo de la elaboración del proyecto. Con cada riesgo también se mencionan las posibles

soluciones o medidas de prevención que se aplicaran para paliar su efecto.

Problema: Perdida de parte o la totalidad de los datos.

Solución: realizar copias de seguridad periódicamente.

Problema: dudas respecto a decidir con que aplicaciones trabajar.

Solución: analizar las ventajas y desventajas de cada una de ellas para poder

seleccionar las más convenientes. En caso de que la duda persistiese se consultaría

al tutor del proyecto.

Problema: dificultades a la hora de integrar las aplicaciones elegidas para

trabajar::

- dificultad en la interpretación del código.

-incompatibilidad de las aplicaciones, bien por sus formas de

implementación, bien por una gestión muy distinta de los datos de la base

de datos.

Solución: buscar otras dos aplicaciones más compatibles a nivel de implementación

y a nivel de gestión de la base de datos.

Problema: incumplimiento de los plazos por una mala planificación.


Solución: se realizará una planificación con holgura para evitar que la entrega de las

diferentes fases se retrase. Se podrán realizar re-planificaciones, se organizara mejor

el trabajo y se empleara más tiempo en su realización para evitar que ocurra

nuevamente. Como última medida se contempla modificar la fecha final de entrega.

~ 23 ~


1.5 METODO DE TRABAJO

Los métodos de trabajo que se llevaran a cabo en el desarrollo de este proyecto son los

siguientes:

Procesos tácticos y operativos:

Se mantendrán reuniones periódicas con el tutor del proyecto de manera que cualquier posible

cambio sugerido por éste, se conozca lo más rápidamente posible para que la planificación

realizada no tenga que modificarse en exceso. Respecto a las reuniones, no hará falta la

realización de actas pero se llevará un recuento de las mismas, así como del número de horas

invertidas en ellas. Se llevará una rigurosa organización de los archivos generados durante el

desarrollo del proyecto.

Gestión de archivos: se tendrán dos formatos para guardar los archivos generados:

-Formato digital: se guardarán todos los entregables, manuales que se vayan

generando, así como el código y el software de la aplicación.

-Formato impreso: se guardan los entregables aprobados, información relacionada

con el proyecto y la memoria final.

~ 24 ~


3. OBJETIVOS

El objetivo principal de este proyecto es conseguir que creando un usuario bien en un gestor

de contenidos de proyecto (CMS) o en un gestor de proyectos, se pueda acceder a cualquiera

de los dos sin tener que registrarse en el otro. Una vez logrado esto, se adquirirán las

siguientes funcionalidades en una misma plataforma:

Gestionar los usuarios tanto de una aplicación como de otra.

Gestionar roles para poder dar permisos a un grupo de usuarios.

Compartir contenidos de proyecto públicamente, entre un grupo de usuarios

concretos o únicamente el creador del contenido.

Administrar los recursos, las tareas, el presupuesto… de un proyecto entre varios

usuarios, para llevar un control exhaustivo.

Creación de diagramas de Gantt.

Utilización de plantillas para cambiar la imagen de la aplicación, pudiendo así

implantar la misma plantilla a ambas aplicaciones.

~ 25 ~


4. ANÁLISIS DEL ENTORNO

Una investigación previa de las aplicaciones existentes en el mercado, es decir, de los

distintos gestores de proyectos y de contenidos de proyectos es fundamental para conseguir el

objetivo planteado. La diferencia entre un gestor de contenidos de proyecto y un gestor de

proyecto es muy sencilla.

Un gestor de contenidos de proyecto, también llamado como CMS (Content Management

System), sirve para que cada usuario pueda publicar sus informes, documentos etc. de manera

que el resto de los compañeros que están desarrollando el proyecto estén informados en todo

momento. El usuario puede hacer accesible sus datos a un grupo de usuarios, a unos usuarios

concretos o bien hacerlos públicos. Por el contrario que un gestor de proyectos principalmente

se utiliza para gestionar las tareas, los eventos, los participantes etc. de cada proyecto.

Concluyendo, dado que una aplicación es complementaria a la otra, la integración de ambas

representa una buena herramienta nueva.

En el análisis de las distintas alternativas con las que trabajar, la fuente de información más

importante ha sido Internet, ya que en la web hemos encontrado las diversas páginas web de

las aplicaciones, el software, los manuales, e incluso una valoración de las mismas por los

usuarios. Por tanto, está ha resultado la forma más adecuada para llevar a cabo la elección de

las aplicaciones con las que se trabajaría.

A continuación se detallaran las características de los distintos gestores de contenidos de

proyectos (CMS) y los distintos gestores de proyectos analizados, remarcando cuáles son sus

diferencias. En primer lugar, analizaremos los gestores de contenidos de proyectos y a

continuación los gestores de contenido.

~ 26 ~


4.1 GESTORES DE CONTENIDOS DE PROYECTO o CMS (Content Management System)

Nombre Plataforma compatible Lenguaje y soporte Tiempo aprox. de

instalación y

configuración

Funcionalidades y características

generales

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

Configurable en

algo más de 15 min

Unidad compartida.

Integración con Microsoft

Office.

OpenSearch.

Arquitectura REST.

(Representational State

Transfer).

Disponible en diversas

lenguas.

Drupal • Unix/Linux

• Windows

• Desarrollado en PHP

• Soporte para MySQL y

PostgreSQL

• Servidor Web: Apache 1.3

Configurable en

poco más de 45 min

Diversos módulos para

distintas funcionalidades.

Asignación de permisos a

usuarios basados en roles.

Control de versiones de

~ 27 ~


o superior. contenidos.

Utilización de plantillas.

Libro colaborativo

Sistema de control de

congestión.


lenguas.

Joomla • Unix/Linux

• Windows

• Desarrollado en PHP

• Soporte para MySQL y

PostgreSQL

• Servidor Web: Apache 6 o

superior.

Configurable en 35

min

Anteriormente conocido

como Mambo.


lenguas.

Posibilidad de ampliación de

Joomla.

DotCMS

Core

• Unix/Linux

• Windows

• Hecho con J2EE/Java

• soporte para MySQL,

PostgreSQL, MS-SQL y

Oracle

• Servidor Web: Apache

Tomcat

Configurable en más

de 1 hora

Aplicación OpenSource, y

para empresas.


lenguas.

Gestión de permisos de

usuarios basad en roles.

Tabla 1: CMS, Content Management System

~ 28 ~


Todas las aplicaciones nombradas en la Tabla 1 son de código abierto (opensource), lo cual es

muy importante para poder tocar o analizar sus respectivos códigos. A pesar de ello, también

existen aplicaciones de pago, las cuales solo nombraremos ya que para el desarrollo del proyecto

no son interesantes: B-kin Project Monitor, Microsoft Office Project 2007 etc.

A continuación, se realizan en detalle cada una de las aplicaciones, añadiendo algunas

características de interés, a las ya mencionadas en la Tabla 1.

ALFRESCO

Alfresco es un buen gestor de contenidos empresariales de código abierto que tiene un gran

soporte en castellano. Utiliza unidad compartida, es decir, todo el contenido es accesible a través

de una interfaz de unidad compartida. Puede accederse al contenido desde Office, y trabajar con él

sin ninguna instalación y formación adicional. En cuanto a la búsqueda de información, es tan

sencilla como la de Amazon o Google. Utiliza arquitectura REST (Representational State

Transfer), permite fusionar herramientas de Alfresco y otras aplicaciones web a través de una

URL.

Hay dos versiones, o ediciones, a disposición de los usuarios:

• Alfresco Community Edition (Edición comunitaria de Alfresco): 100% código abierto,

de descarga y uso gratuitos.

• Alfresco Enterprise Edition (Edición empresarial de Alfresco): de código abierto con

asistencia comercial y ampliaciones empresariales.

Esta aplicación es compatible con Red Hat Enterprice, Sun Solaris 10 y Windows Server 2003,

pero cualquier sistema con soporte JSP debería soportarla (Linux, Unix, MacOS y Windows).

Esta hecha en JSP y soporta MySQL y Oracle 10. Su tiempo aproximado de instalación y

configuración es de 15 min., lo que es relativamente poco en comparación con el resto de las

aplicaciones.

~ 29 ~


Para mas información sobre este gestor de contenidos, se puede visitar su sitio web,

http://www.alfresco.com/es/.

4.1.1 DRUPAL

Drupal es uno de los CMS más conocidos y completos del mercado, modular y muy configurable,

el cual podrá instalarse en 20 idiomas diferentes. Tiene una versión hispana, Drupal Hispano, con

su propio sitio web (http://drupal.org.es/) creado por una comunidad de usuarios en castellano, en

la cual se podrán encontrar artículos, documentación y foros, partiendo de su sitio web principal

(http://drupal.org/).

Una de las características importantes es, que los administradores de Drupal no tienen que

establecer permisos para cada usuario. En lugar de eso, pueden asignar permisos a un 'rol' y

agrupar los usuarios por roles. También hay la v de utilizar platillas, las cuales podrán ser

sustituidas por otras en cualquier momento independizando el contenido del aspecto de la pagina,

dando la posibilidad de exporta el contenido en formato RDF/RSS para ser utilizado por otros

sitios web. En cuanto a la administración y configuración del sistema, se puede realizar

enteramente con un navegador y no precisa de ningún software adicional.

La cantidad de módulos que proporcionan distintas funcionalidades es muy amplia. También

contiene, un sistema de control de versiones de Drupal permite seguir y auditar totalmente las

sucesivas actualizaciones del contenido: qué se ha cambiado, hora y fecha, de los cambios, etc.

También permite mantener comentarios sobre los sucesivos cambios o deshacer los cambios

recuperando una versión anterior. A su vez es un libro colaborativo, una característica única de

Drupal, que permite crear un proyecto o "libro" escrito y que otros usuarios contribuyan en el

contenido.

En el aspecto de rendimiento, Drupal incorpora un mecanismo de control de congestión que

permite habilitar y deshabilitar determinados módulos o bloques dependiendo de la carga del

servidor.

~ 30 ~

http://drupal.org/

http://drupal.org.es/


Ha sido diseñado desde el principio para ser multi-plataforma. Puede funcionar con Apache o

Microsoft IIS como servidor web y en sistemas como Linux, BSD, Solaris, Windows y Mac OS

X. Por otro lado, al estar implementado en PHP, es totalmente portable. Sobre la base de datos

podemos destacar que incorpora una 'capa de abstracción de base de datos' que actualmente está

implementada y mantenida para MySQL y PostgresSQL, aunque permite incorporar fácilmente

soporte para otras bases de datos.

Es de gran interés comentar que se ha creado un modulo para poder integrar Drupal y Alfresco.

JOOMLA

Joomla, antiguamente conocida como Mambo, es un sistema de administración de contenidos y

entre sus principales virtudes permite editar el contenido de un sitio web de manera sencilla. En

cuanto a su traducción a nuestro idioma es una de las mejores y de las más completas que hay

disponibles. Tiene su sitio web, http://www.joomla.org/, en el que se pueden encontrar manuales,

foro etc. y del que se puede acceder a la pagina en castellano, creada por una comunidad de

usuario en castellano, http://www.joomlaspanish.org/

Es una aplicación de código abierto construida mayoritariamente en PHP bajo una licencia GPL.

Este administrador de contenidos puede trabajar en Internet o intranets y requiere de una base de

datos MySQL, así como preferiblemente, de un servidor HTTP Apache.

Muchas empresas u organizaciones tienen más necesidades de las que dispone el paquete de

Joomla básico, en esos casos Joomla facilita a los desarrolladores crear sofisticadas extensiones

que amplían la capacidad de Joomla.

A pesar de tener varias virtudes también tiene varios inconvenientes. En cuanto a la seguridad,

surgen diversos problemas, al igual que su correcta actualización es algo complicada sin que tenga

ningún problema irresoluble.

DOTCMS CORE

DotCMS, es uno de los más completos software libre, adaptable a casi cualquier necesidad CMS.

Es una aplicación disponible en diversas lenguas, como la mayoría de los CMS que encontramos

~ 31 ~

http://es.wikipedia.org/wiki/Servidor_HTTP_Apache

http://es.wikipedia.org/wiki/MySQL

http://es.wikipedia.org/wiki/Base_de_datos

http://es.wikipedia.org/wiki/Base_de_datos

http://es.wikipedia.org/wiki/Intranet

http://es.wikipedia.org/wiki/Internet

http://es.wikipedia.org/wiki/Licencia_p%C3%BAblica_general_de_GNU

http://es.wikipedia.org/wiki/PHP

http://es.wikipedia.org/wiki/C%C3%B3digo_abierto

http://www.joomlaspanish.org/

http://www.joomla.org/

http://es.wikipedia.org/wiki/Sistema_de_administraci%C3%B3n_de_contenidos


en el mercado. Disponemos de dos versiones, una orientada para usuarios, versión gratuita, y otra

destinada para empresas (versión de pago).

A pesar de esto, sus manuales, foros, noticias…, los que se podrán encontrar en su sitio web

(http://www.dotcms.org/), son algo escasos, y su instalación es algo prolongada, de un tiempo

aproximado de 1h.

Es compatible con Unix/Linux y Windows. Esta hecho con J2EE/Java, y requiere de una base de

datos MySQL, PostgreSQL, MS-SQL u Oracle.

~ 32 ~

4.2 GESTORES DE PROYECTOS

Requisitos previos

Características generalesNombre de

aplicación

Servidor Lenguaje Gestor de

base de

datos

Dotproject Servidor

web: Apache

1.3.27 o

superior

PHP 4.1.x o

superior.

MySQL

3.23.51 o

superior.

Utilización de plantillas.

Creación de graficas de Gantt.

Repositorio de fichero.

Disponibilidad de diversos módulos.

Aplicación multiusuario.

Multi-idiomas.

Archievo Servidor

web: apache

2

PHP 5 MySQL Utilización de módulos.

Multi-idiomas.

Tabla 2: Gestores de proyectos

Como podemos ver gestores de proyectos no hay muchos lo suficientemente completos y

fáciles de manejar. Lo cierto es que a pesar de llamarlos gestores de proyectos son

aplicaciones que se suelen utilizar entre otras funciones también para la gestión de las

empresa. Hay dos aplicaciones aparentemente con la misma funcionalidad, DotProject y

Achievo. Ambas pueden usarse para la gestión de un proyecto como para la gestión de una

empresa, pero cada una de ellas es aconsejada para una funcionalidad diferente.

DOTPROJECT

DotProject es una solución potente y completa, que nos brindara las herramientas necesarias

para gestionar un proyecto en sus distintas fases y tareas. Para ello ofrece una gran cantidad

de módulos que permiten realizar la correcta planificación y gestión de las múltiples

actividades que surgirán. Estos módulos se denominan: empresa, contactos, proyecto,

calendario, tareas, ficheros, foros e informes.

Permite la creación de graficas de Gantt, como el repositorio de ficheros, pudiendo asociar

una o varias tareas a un fichero. También ofrece la posibilidad de aplicar plantillas para

cambiar el aspecto de la aplicación. Es una aplicación multiusuario, es decir, pueden trabajar

varios usuarios concurrentemente.

DotProject precisa de un servidor web Apache 1.3.27 o superior, PHP 4.1.x o superior y un

gestor de bases de datos MySQL 3.23.51 o superior.

ACHIEVO

Achievo es una aplicación que se encarga de gestionar áreas y actividades claves en la

empresa, tales como: gestión de proyectos, proveedores, clientes, y gestión del personal, entre

otros. Se conoce mas como gestor de actividades y áreas de empresa pero tiene dos módulos

muy destacados: “Gestión de Proyectos” que nos permite gestionar los proyectos, las fases,

tareas, notas, estadísticas, informes, planificación y colaboradores del proyecto, y el modulo

de “Personal” permite gestionar los recursos humanos, sus contratos y muchas otras tareas.

Como tiene un sistema modular permite posteriores ampliaciones.

Achievo exige servidor web Apache 2, PHP 5 y MySQL.

5. ELECCIÓN DE LAS APLICACIONES

La elección del software con el que trabajar ha sido rigurosa. Las aplicaciones mencionadas

anteriormente, los CMS Joomla, Drupal, DotCMS y Alfresco, y los gestores de proyectos

DotProject y Achievo son la selección previa a la decisión final.

Los puntos a tener en cuenta principalmente para la elección de un CMS y un gestor de

proyectos compatibles han sido los siguientes:

•Lenguaje en que han sido implementadas.

•Tipo de bases de datos soportadas.

•Funcionalidades de la aplicación.

• Instalación de la aplicación.

ELECCIÓN DEL GESTOR DE PROYECTOS

La elección comenzó por un gestor de proyecto, ya que entre los existentes en el mercado

fueron elegidos dos: Achievo y DotProject. Ambos fueron puestos en marcha en un

equipo para poder probar sus funcionalidades y así poder compararlas. Achievo no llego

a manejarse por su complicada instalación, la multitud de errores es la razón principal.

Sin embargo, DotProject es un software fácil de instalar y sencillo de manejar.

Por otro lado, a pesar de que Achievo es más completo no se centra únicamente en los

proyectos que es la idea principal de este estudio, principalmente esa es la razón de la

elección de la aplicación Dotproject, además de la multitud de manuales que se pueden

encontrar para su correcto manejo, y de una interfaz intuitiva, simple, clara y consistente.

En la tabla anterior apreciamos los requisitos previos para que cada unas de estas

aplicaciones sea instalada correctamente. De ahí observamos que Achievo requiere

mejores prestaciones para su funcionamiento que Dotproject. Concluimos que Dotproject

será una aplicación instalable en equipos relativamente antiguos como modernos, ya que

soporta versiones anteriores a las que soporta Achievo.

Por tanto, la elección final de gestor de proyectos fue DotProject.

ELECCIÓN DE GESTOR DE CONTENIDO DE PROYECTOS

La elección del CMS fue bastante complicada, porque observando las características de

cada una de ellas no tienen diferencias destacables, pero para poder profundizar en ellas

hubo que también instalarlas y utilizarlas detenidamente una por una. Para su elección

principalmente fueron tomados en cuenta las características de DotProject tanto técnicas

como funcionales.

Partiendo de que los requisitos previos para la instalación de DotProject son un servidor

web Apache 1.3.27 o superior, PHP 4.1.x o superior y un gestor de bases de datos

MySQL 3.23.51 o superior. Podemos descartar el software Alfresco y DotCMS ya que no

son implementados en PHP como DotProject y se prevé que no facilitara la tarea de

integrar las aplicaciones.

Por tanto, la elección se resume entre Drupal y Joomla. Ambas son aplicaciones

completas, con versión en lengua española, implementadas en PHP, requieren de servidor

web Apache y de base de datos de MySQL. En ese aspecto ambas son buenas candidatas.

Sin embargo, tras la instalación de Joomla y Drupal, hemos observado que a pesar de

que la instalación de Drupal ha sido más costosa, en cuanto a tiempo se refiere, su

funcionamiento ha sido más fácil gracias a su clara interfaz y a su multitud de manuales

existentes on-line para poder consultar.

ELECCIÓN TECNOLOGICA

Para poder llevar a cabo este estudio es necesaria la utilización de otras herramientas y así poder

instalar, analizar… las distintas aplicaciones para su posterior manejo.

Partiendo de que las aplicaciones seleccionadas son implementadas en Java y PHP, se necesita

una herramienta útil para analizar el código que interprete los dos lenguajes. La herramienta que

se ha utilizado es NetBeans IDE 6.5, un entorno de desarrollo implementado en java pero que

sirve para cualquier otro lenguaje de programación. Una herramienta para que los programadores

puedan escribir, compilar, depurar y ejecutar programas.

Otra herramienta que se ha utilizado es WampServer, una plataforma formada por MySQL, PHP

y Apache para entorno Windows. Permite crear aplicaciones web con Apache, PHP y la base de

datos MySQL. Contiene también PHPMyAdmin para administrar fácilmente las bases de datos.

Se instala automáticamente y su uso es muy intuitivo. También tiene una opción para poder

gestionar el servidor y su configuración.

Pantalla 1: Pagina principal de WampServer.

Pantalla 2: Páginaprincipal de PHPMyAdmin.

Windows Grep, es otra herramienta que se ha utilizado para poder buscar las llamadas a la base de

datos en el código de las aplicaciones.

Otro instrumento utilizado para la esquematización de la base de datos ha sido Workbench.

Para saber más sobre estas dos últimas herramientas nombradas, Véase Anexo 1.

No se han utilizado únicamente las herramientas anteriormente mencionadas, también ha sido

muy útil la configuración de una de ellas, MySQL, en WAMP. Con ella se ha analizado más

intensamente las bases de datos de las aplicaciones seleccionadas, así como las sentencias que se

lanzan en cada movimiento que un usuario pueda provocar en cada una de las aplicaciones.

Principalmente, es necesario poder ver dónde y en qué orden se ejecutan las operaciones cuando

se crea o borra un usuario tanto en Drupal como en DotProject. Para conseguir esto, únicamente

se ha configurado el fichero “my.ini”, ubicado en la ruta

“C:\wamp\bin\mysql\mysql5.0.51b\my.ini”. Se ha añadido una nueva línea y modificado otra, de

la siguiente manera:

Antes: los errores que se producían se almacenaban en el fichero mysql.log.

#log filelog-error=c:/wamp/logs/mysql.log

Ahora: los errores que se producen se almacenaran en el fichero mysql-error.log y las sentencias

que se ejecutan se guardan en el fichero mysql.log.

#log filelog-error=c:/wamp/logs/mysql-error.log

#loglog=c:/wamp/logs/mysql.log

Para comprobar que los cambios se han efectuado, se han consultado las variables del sistema

MySQL:

Pantalla 3: Configuración MySQL.

Pan

talla 4: Comprobacion de la nueva configuracion MySQL.

Una vez hecho esto, para poder ver las sentencias ejecutadas cuando se crea un usuario en ambas

aplicaciones, eliminaremos todo el contenido en mysql.log y se creara un usuario en una

aplicación para posteriormente guardar ese fichero, analizar las sentencias y ver las tablas que son

modificadas. Después de la misma manera se realizara con la otra aplicación.

Esto es solo para llevar a cabo este proyecto, una vez que este hecho no será necesario para su

funcionamiento.

6. CAPTURA DE REQUISITOS

Con la ayuda las herramientas nombradas con anterioridad, se ha empezado a profundizar en las

aplicaciones DotProject y Drupal. Con ello se ha conseguido estudiar a fondo la distribución de

las bases de datos y las sentencias ejecutadas en la creación de usuarios en ambas aplicaciones, así

como el código de cada una de ellas.

BASE DE DATOS DOTPROJECT

Comenzamos conociendo detalladamente la base de datos de DotProject. Está formada por varias

tablas entre ellas las relacionadas con la información de los usuarios: users, user_access_log,

user_events, user_preferences, user_roles, user_tasks, user_task_pin… entre otras. Estos son los

atributos de alguna de ellas y la relación entre ellas:

Ilustración 3: Tablas de información de usuarios de Dotproject (1)

A continuación se explicara el contenido de cada una de ellas:

•Users: contiene los usuarios con la información correspondiente a cada uno de ellos.

•User_access_log: contiene la información sobre cada usuario que se ha identificado en el

sistema: la fecha y hora en la que se ha identificado y a salido del sistema, la fecha y hora de

la última acción realizada en la aplicación y la ip de la maquina desde donde se ha

conectado.

•User_roles: contiene cada usuario a que rol está asociado.

•User_tasks: tareas relacionadas a los proyectos relacionados a usuarios.

•User_events: los eventos relacionados a cada usuario.

Sin embargo, las tablas a tener en cuenta que repercuten a la hora de crear o borra un

usuario son las siguientes: users, contacts, gacl_aro, gacl_aro_seq y gacl_groups_aro_map.

Por tanto, estas son las tablas en las que hay que centrarse para lograr el objetivo de este

proyecto. Estos son los atributos de cada una de ellas y como están relacionadas:

Ilustración 4: Tablas de información de usuarios de Dotproject (2)

En cuanto a su contenido no se puede comentar mucho, en la tabla contacts contiene información

ampliada y personalizada sobre cada usuario qué se complementa con la tabla de users. Sin

embargo, la funcionalidad de gacl_aro, gacl_aro_seq y gacl_groups_aro_map son muy confusas,

únicamente se ha analizado que cuando un usuario es creado en DotProject se crean y modifican

tuplas en estas tablas, esto permitirá que realizando estos cambios para los usuarios creados en

Drupal, podrán acceder desde Dotproject sin ningún problema.

BASE DE DATOS DRUPAL

Continuamos analizando la base de datos de Drupal. Las tablas relacionadas con la información de

los usuarios son pocas: users, users_roles y role entre otras. A continuación veremos los atributos

de cada una de ellas y la relación que tienen entre sí:

Ilustración 5: Tablas de información de usuarios de Drupal

A continuación se explicara su contenido:

•Users: contiene la información sobre los usuarios registrados en la aplicación.

•Users_roles: contiene cada usuario a que rol está asociado.

•Role: contiene los tipos de roles con sus respectivos números de identificación.

CÓDIGO EN PHP DE DOTPROJECT Y DRUPAL

En cuanto a la implementación, es muy grande la diferencia de la Dotproject y de la Drupal. Por

lo que el análisis del código de cada una de ellas se centra básicamente en las llamadas a las tablas

de usuarios, ya que el resto del código no es relevante para el objetivo de este proyecto. Por

ejemplo, aquí podemos ver una llamada a la tabla users de DotProject para insertar datos de un

usuario:

…$q = new DBQuery;$q->addTable('users');$q->addQuery('user_id, user_password, user_contact');$q->addWhere("user_username = '$username'");…

Observamos como DotProject utiliza funciones adicionales para crear las consultas a la base de

datos, creando previamente un objeto DBQuery.

Sin embargo, Drupal realiza las operaciones a la base de datos de la siguiente manera, vemos

como inserta una tupla en la tabla user_roles:

db_query('INSERT INTO {users_roles} (uid, rid) VALUES (%d, %d)', $array['uid'], $rid);

Vemos como Drupal directamente hace la consulta a la base de datos, sin necesidad de crear

ninguna clase adicional.

Por tanto, descartamos tocar código como opción para conseguir el objetivo, centrándose en las

bases de datos de las aplicaciones para buscar distintas alternativas, sencillas y claras, con el fin

de cumplir con el propósito del proyecto.

7. ANÁLISIS

Una vez profundizado en ambas aplicaciones, para poder crear una plataforma con dos

aplicaciones complementarias, hubo que hacer un estudio de las distintas opciones que se podrían

poner en práctica para lograr el objetivo de este proyecto. Intentamos buscar una alternativa

efectiva, sin redundancias, de fácil modificación y que cuando una aplicación sea modificada o

actualizada no repercuta al funcionamiento de la plataforma. Las alternativas deberían solucionar

el problema de la creación y eliminación de los usuarios de una forma sencilla y optima. Para ello

se han estudiado distintas alternativas que se detallan a continuación, de las cuales se elegirán las

aparentemente menos costosas:

•Alternativa 1: Sincronizar las bases de datos de las dos aplicaciones, únicamente las tablas

relacionadas con los usuarios, para que cuando se cree un usuario en una de ellas, se generen

las entradas necesarias en las tablas de la otra aplicación y viceversa.

Esta alternativa no es la óptima para realizar este proyecto, porque no es necesaria la

sincronización de toda la base de datos, sino únicamente de las tablas relacionadas con los

usuarios. Para ello habrá que adaptar las tablas de los usuarios para que tengan los mismos

campos, y por tanto poder guardar los mismos datos en ambas. Con esta alternativa se

genera una redundancia en cuanto a parte de la información de los usuarios, problema que

se intentara evitar con el planteamiento de otras alternativas.

Ilustración 6: Alternativa 1: Sincronización de las bases de datos.

APLICACIÓN BASE DE DATOS

DOTPROJECT

DRUPAL

DOTPROJECT

users

tabla_dot_1

tabla_dot_2

tabla_dot_n

BD_DRUPAL

users

tabla_dru_1

tabla_dru_2

tabla_dru_m

SINCRONIZACIÓN

•Crear una nueva base de datos y, en ella, generar una tabla que contenga los datos de los

usuarios de las dos aplicaciones, teniendo en cuenta que deberá contener campos que

coincidan en ambas aplicaciones. Para ello se podrían sustituir las tablas originales de los

usuarios de cada aplicación por vistas que hagan referencia a la nueva tabla de users de la

nueva base de datos. Partiendo de este punto surgen otras alternativas:

Alternativa 2: Utilizar triggers cambiando las tablas que sean necesarias en cada base de

datos para poder utilizar en ambas aplicaciones los usuarios creados en DotProject y los

usuarios creados en Drupal.

En este caso el problema de la redundancia está solucionado, ya que con el uso de los

triggers se conseguirá actualizar o añadir tuplas en las tablas de ambas bases de datos en la

medida que sea necesario. Con esta alternativa, sin embargo, surge otro problema que es la

creación de un número elevado de triggers. Por tanto, en el momento que una de las

aplicaciones haga modificaciones notables en la base de datos, habrá que analizar de nuevo

los triggers y crear o modificar algunos de ellos.

Ilustración 7: Alternativa 2: Utilización de triggers.


DOTPROJECT

DRUPAL

TRIGGERS

DOTPROJECT

users

dru_userstabla_dot_1

tabla_dot_2

tabla_dot_n

BD_DRUPAL

users

tabla_dru_1

tabla_dru_2

tabla_dru_m

Alternativa 3: Analizar todas las llamadas a la tabla users de ambas aplicaciones

cambiando el nombre de la tabla users, por el nombre de la tabla nueva de usuarios creada

en la nueva base de datos. En este caso, como el código de las aplicaciones es muy extenso,

el número de llamadas a la tabla users es muy elevado.

Llevar a cabo esta alternativa es muy costoso, en cuanto a tiempo se refiere, y habría que

analizar a fondo todo el código, archivo por archivo, línea por línea, llamada por llamada y

modificar cada una de las invocaciones a la tabla de users tanto de DotProject como de

Drupal. Otro de los problemas que surge con esta alternativa, al igual que la alternativa 2,

es la necesidad de actualizar las aplicaciones continuamente. Este trabajo es largo y pesado

de realizar, por lo que no resulta una alternativa efectiva y práctica.

Ilustración 8: Alternativa 3: Modificación de llamadas a las tablas users.


bd_drupal.users

DRUPAL

MIPROYECTO

my_users

dotproject.users

DOTPROJECT

DOTPROJECT

users (vista)

dot_users

BD_DRUPAL

users (vista)

dru_users

miproyecto.my_users

Alternativa 4: Cambiar los datos necesarios de una base de datos y de otra cada vez que

se cree un usuario en una de las dos. Es decir, si se crea en DotProject cambiar las tablas que

sean necesarias en Drupal y viceversa. Si se analizan las tablas que se modifican cuando se

crea un usuario en una u otra aplicación observamos que Dotproject modifica las siguientes

tablas: contacts, gacl_aro, gacl_aro_seq y gacl_groups_aro_map. Mientras que Drupal

únicamente modifica la tabla users. Al analizar a fondo la creación de los usuarios y su

utilización en cada una de las aplicaciones, hemos averiguado que únicamente dan

problemas los usuarios creados en Drupal ya que no pueden ser utilizados en DotProject.

Para solucionar este problema se hará uso de triggers y procedimientos.

Esta alternativa parece efectiva, y se ha considerado una buena opción para conseguir el

objetivo de la nueva aplicación objeto de este proyecto. Sus ventajas e inconvenientes se

analizaran una vez puesta en práctica.

Ilustración 9: Alternativa 4: Utilización de triggers, procedimientos y vistas (únicamente de la tabla users).

PROCEDIMIENTOS

TRIGGERSPROCEDIMIENTOS

MIPROYECTO

my_users

TRIGGERS

DOTPROJECT

DRUPAL

APLICACION BASE DE DATOS

BD_DRUPAL

users (vista)

dru_users

DOTPROJECT

users (vista)

dot_users

contacts

gacl_aro

gacl_aro_seq

gacl_groups_aro_map

8. DISEÑO

Una vez realizado el análisis teórico de las distintas alternativas, procederemos a ponerlas en

práctica para estudiar sus ventajas e inconvenientes y así poder elegir la más efectiva y menos

compleja.

• Alternativa 1: Sincronización de las bases de datos:

Esta alternativa no se ha puesto en práctica ya que como se ha comentado anteriormente no

es necesaria la sincronización de toda la base de datos, únicamente de las tablas necesarias.

Al no haber aplicaciones que realicen esta función, esta alternativa ha sido descartada.

• Alternativa 2: Utilización de triggers para la modificación de tablas de las distintas

aplicaciones:

Para llevar a cabo esta alternativa es necesario analizar las tablas que modifican cada

aplicación para que cuando se cree o borre un usuario en DotProject, se añadan las tablas

necesarias en Drupal y viceversa. Para analizar las sentencias que se ejecutan se consultó el

archivo “mysql.log”, que almacena todas las operaciones que se realizan en la base de datos.

La implementación de los triggers para sincronizar las tablas de users de ambas aplicaciones

junto con las tablas necesarias para que creado un usuario en una aplicación o en otra

funcione correctamente en ambas, es una operación muy costosa. Esta alternativa tampoco

se ha desarrollado debido a su complejidad.

• Alternativa 3: Modificación de las llamadas a las tablas users en la

implementación:

La alternativa 3 consiste en modificar las llamadas a las tablas users, para que en vez de

llamar a la tabla users de DotProject o Drupal, llame directamente a la my_users de la nueva

base de datos miproyecto. A continuación se apreciaran los pasos que se han seguido para

implementar esta alternativa:

1. Crear una base de datos nueva, cuyo nombre será miproyecto.

2. Crear una tabla con todos los atributos de las tablas de users de ambas

aplicaciones en esta nueva base de datos, aquí podemos ver los atributos de cada

una de ellas:

Ilustración 10: Creación de la tabla my_users.

Los campos anidados son los campos en común, por tanto la nueva tabla my_user

de la base de datos miproyecto quedara de la siguiente manera:

CREATE VIEW users AS

SELECT u.id AS uid, u.user_name AS name, u.passwrd AS pass, mail, mode, sort, threshold, theme, signature, created, access, login, status, timezone, language, picture, init, data, signature_formatFROM miproyecto.my_users AS u;

CREATE VIEW users AS

SELECT u.id AS user_id, u.user_name AS user_username, u.passwrd AS user_password, u.user_contact, u.user_parent, u.user_type, u.user_company, u.user_department, u.user_owner, u.user_signatureFROM miproyecto.my_users AS u

Pantalla 3: Nueva tabla de usuarios, my_users.

3. Modificar el nombre de las tablas de users de Drupal y Dotproject cuyos nombres

serán dru_users y dot_users respectivamente.

4. Crear las vistas users, que contendran los campos de la tabla base my_users los

cuales seran necesarios para cada aplicación. El código utilizado para crear las

vistas es el siguiente:

Codigo para crear la vista users de Drupal:

Codigo para crear la vista users de DotProject:

5. Una vez creada la nueva base de datos, creada la tabla my_users y creadas las

vistas necesarias, se buscaran todas las llamadas de las dos aplicaciones a las

tablas users, con las ayuda de Windows Grep, para que se modifiquen por la tabla

my_users. A continuación podemos ver un ejemplo del codigo de Drupal, de

como deberian ser las llamas antes y después de modificarlas:

Antes:

…$sql = 'SELECT DISTINCT u.uid, u.name, u.status, u.created, u.access FROM {users} u LEFT JOIN {users_roles} ur ON u.uid = ur.uid '. $filter['join'] .' WHERE u.uid != 0 '. $filter['where'];

…

$query_count = 'SELECT COUNT(DISTINCT u.uid) FROM {users} u LEFT JOIN {users_roles} ur ON u.uid = ur.uid '. $filter['join'] .' WHERE u.uid != 0 '. $filter['where'];…

Despues:

…$sql = 'SELECT DISTINCT u.uid, u.name, u.status, u.created, u.access FROM {my_users} u LEFT JOIN {users_roles} ur ON u.uid = ur.uid '. $filter['join'] .' WHERE u.uid != 0 '. $filter['where'];

…

$query_count = 'SELECT COUNT(DISTINCT u.uid) FROM { my_users} u LEFT JOIN {users_roles} ur ON u.uid = ur.uid '. $filter['join'] .' WHERE u.uid != 0 '. $filter['where'];…

Lo mismo se debería hacer con las llamadas del código de Dotproject.

Esta alternativa no se ha desarrollado completamente puesto que se han planteado otras más

fáciles. Cada aplicación tiene mucho código, y por tanto es un trabajo muy costoso y

engorroso. Hay que destacar que al actualizar las aplicaciones, esta alternativa va a provocar

muchos problemas. Cada vez que se actualice una aplicación, habrá que modificar el código

actualizado, lo que es un proceso muy laborioso y poco práctico.

• Alternativa 4: Actualización de tablas de aplicaciones en la creación y eliminación

de usuarios mediante herramientas de la base de datos:

Para llevar a cabo esta alternativa se han utilizado los pasos 1, 2, 3 y 4 realizados en la

alternativa anterior. A modo de ensayo preliminar, se ha creado un usuario en DotProject

que después se ha utilizado en Drupal y se ha visto que no se produce ningún problema. Sin

embargo, cuando un usuario ha sido creado por Drupal y se ha intentado acceder con él a

Dotproject, este no lo ha permitido. Por tanto, como el problema proviene de la creación de

los usuarios en Drupal para la posterior utilización en Dotproject.

Para analizar las operaciones que Dotproject genera en las diversas tablas cuando crea un

usuario, se han seguido los siguientes pasos:

1. Creado un usuario en DotProject y posteriormente las operaciones que realiza

consultando el fichero mysq.log que almacena todas las operación que se realizan en las

bases de datos. Por ejemplo, se insertara el usuario “pru11” con contraseña

“prueba11” y el resto de campos destacados en la siguiente pantalla:

Pantalla 4: creacion de un usuario en Dotproject.

2. oCon la creacion de este usuario, analizando las operaciones, observando el fichero

“mysql.log”configurado con anterioridad en MySQL, se han realzado las siguientes

sentencias:

INSERT INTO `contacts` (contact_id,contact_first_name,contact_last_name,contact_company,contact_email,contact_owner) VALUES ('0','prueba11','p11','0','[email protected]','1')

Esta sentencia inserta una tupla en la tabla contacts de la bases de datos de Dotproject.

Esta tabla contiene información adicional de los usuarios, de la que contiene users.

INSERT INTO `users` (user_id,user_username,user_password,user_type,user_contact) VALUES ('0','pru11','a07481e5e9b57e03d85c5595da4e11df','1','34')

Inserta una tupla en la tabla users de la base de datos de DotProject.

UPDATE gacl_aro_seq set id=LAST_INSERT_ID(id+1)

La tabla gacl_aro_seq tiene únicamente un campo con un único valor que realiza la

función de una variable, la cual se incrementa cada vez que se inserta una tupla en la

tabla gacl_aro.

INSERT INTO `gacl_aro` (id, section_value, value, order_value, name, hidden) VALUES(18,'user','34','1','pru11',0)

La tabla gacl_aro es la relacional entre un usuario y el rol que tiene establecido.

INSERT INTO `gacl_groups_aro_map` (group_id, aro_id VALUES (11,18)

La tabla gacl_gropus_aro_map, almacena cada usuario al rol al que esta asignado ya

que el campo groups_id es el id del rol. Como podemos ver en la pantalla de la parte

inferior los roles existentes, que estan almacenados en la tabla cuyo nombre es

gacl_aro_groups. Y el campo aro_id esta relacionado con las entradas del campos id de

la tabla gacl_aro.

Pantalla 4: Tabla de roles de Dotproject.

En cuanto al orden de ejecucion, se enfatiza en que primero se inserta una tupla en la

tabla contact y luego en la de users, y no viceversa. Posteriormente el orden de

ejecución del resto de las sentecias no es de gran importancia.

A continución, se comprenderá la relacion de las tablas nombradas anteriormente:

Ilustración 11: Estructura de tablas de Dotproject.

gacl_aro

contacts

gacl_aro_groups

gacl_aro_seq

gacl_groups_aro_map

Para simular las inserciones y actualizaciones que genera DotProject cuando crea o

borra un usuario, se han implementado triggers y procedimientos en la base de datos

“miproyecto”. Se han creado triggers que se lanzan después de que se ha insertado una

tupla en la tabla my_users. Para que cada triggers sepa si deben de ser modificadas las

tablas mencionadas anteriormente, se ha observado, como cuando un usuario se crea

desde Drupal el valor del campo user_contact es cero, de lo contrario, DotProject le

asigna el id correspondiente a la tabla de contacts.

a) El primer trigger implementado, una vez insertada una tupla en la tabla

my_users, primero comprueba si ha sido insertado por Drupal o Dotproject, es

decir, si el valor user_contact es cero o no. En caso de que sea cero, se inserta una

tupla en la tabla contacts, obteniendo algunos valores de la tabla my_users. El

trigger ha sido creado en la base de datos miproyecto junto con los procedimientos

que se mostraran a continuación.

DELIMITER $$CREATE TRIGGER insert_contacts AFTER INSERT ON my_usersFOR EACH ROW BEGIN

CALL obt_max_id (@max_id);CALL comp_user_contact_max (@cont);CALL obt_max_id_contacts (@max_id_con);IF @cont=1 THEN

INSERT INTO dotproject.contacts (contact_id, contact_first_name, contact_email)SELECT @max_id_con+1, my_users.user_name, my_users.mail FROM my_users WHERE my_users.id=@max_id;

END IF;END $$DELIMITER ;

Para ejecutar este trigger, se han creado varios procedimientos a los que llama para

obtener ciertos valores:

CREATE PROCEDURE obt_max_id (OUT max_id INT)SELECT MAX(id) INTO max_id FROM my_users;

El procedimiento obt_max_id, obtiene el id máximo de la tabla my_users y lo

devuelve como parámetro de salida.

DELIMITER $$

CREATE PROCEDURE comp_user_contact_max (OUT user_cont INT)BEGIN

CALL obt_max_id (maxi);SELECT COUNT(*) INTO user_cont FROM my_users WHERE user_contact=0 AND id=maxi;END $$DELIMITER ;

El procedimiento comp_user_contact_max obtiene mediante la llamada al

procedimiento obt_max_id el id máximo de la tabla my_users el cual utiliza para

obtener el valor del campo user_contact correspondiente a dicho usuario, y lo

devuelve como parámetro de salida.

CREATE PROCEDURE obt_max_id_contacts (OUT max_id INT)SELECT MAX(contact_id) INTO max_id FROM dotproject.contacts;

Este ultimo procedimiento al que llama el trigger insert_contacts, obtiene el id

máximo de la tabla contacts.

b) Despues de que se inserte ua tupla en la tabla dotproject.contacts, se lanzará

el siguiente trigger que comprobara mediante el procedimiento

comp_user_contact_max, si el valor de user_contact del usuario con id máximo, es

decir el ultimo usuario creado, es cero o no. Si es cero, comprueba que la entraba

con id máximo de la tabla gacl_aro coincide con el id de la tabla gacl_aro_seq. En

caso de que coincida el trigger incrementa mediante el procedimiento

incre_id_seq, el id de la tabla gacl_aro seq, e inserta en la tabla gacl_aro una

nueva tupla, obteniendo los valores de necesarios de my_users y de otras entradas

de gacl_aro. Este trigger ha sido creado en la base de datos Dotproject, y

procedimientos en la base de datos miproyecto.

DELIMITER $$CREATE TRIGGER insert_gacl_aro AFTER INSERT ON contactsFOR EACH ROWBEGIN CALL miproyecto.obt_max_id_gacl (@maxidgacl);CALL miproyecto.obt_max_id (@maxid);CALL miproyecto.comp_user_contact_max (@cont);CALL miproyecto.obt_id_gacl_seq (@idseq);IF @cont=1 THEN

IF @maxidgacl=@idseq THENCALL incre_id_seq ();

INSERT INTO gacl_aro(id, section_value, value, order_value, name, hidden)

SELECT @idseq+1, g.section_value, m.id, g.order_value, m.user_name, hiddenFROM miproyecto.my_users AS m, dotproject.gacl_aro AS g

WHERE m.id=@maxid AND g.id=@maxidgacl;END IF;


Estos son los procedimientos a los que llama este trigger para obtener ciertos

valores, aunque también utiliza parte de los mencionados anteriormente:

CREATE PROCEDURE obt_max_id_gacl (OUT id_max_gacl INT)SELECT MAX(id) INTO id_max_gacl FROM dotproject.gacl_aro;

El procedimiento obt_max_id_gacl obtiene el valor del id máximo de la tabla

gacl_aro, y lo devuelve como parámetro de salida.

CREATE PROCEDURE obt_id_gacl_seq (OUT mid INT)SELECT MAX(id) INTO mid FROM dotproject.gacl_aro_seq;

El procedimiento obt_id_gacl_seq obtiene el id que contiene la tabla

gacl_aro_seq, y lo devuelve como parámetro de salida.

CREATE PROCEDURE incre_id_seq ()UPDATE gacl_aro_seqSET id=id+1;

El procedimiento incre_id_seq, incrementa en una unidad el valor de id de la tabla

gacl_aro_seq.

c) A continuación, después de lanzarse el trigger insert_gacl_aro, se lanzara

un tercer trigger cuando se inserte una tupla en gacl_aro, el cual insertara una

nueva tupla en la tabla gacl_groups_aro_map, después de comprobar si el valor del

campo user_contact del usuario con máximo id, y después de comprobar que el

valor máximo del campo id de la tabla gacl_aro es igual que el id de la tabla

gacl_aro_seq coinciden, con el valor de group_id por defecto 13 (usuario invitado,

el cual podrá ser modificado por el administrador) ,y el aro_id correspondiente al

usuario recién insertado.

mailto:g.id%3D@maxidgacl

mailto:m.id%3D@maxid

DELIMITER $$CREATE TRIGGER insert_gacl_groups AFTER INSERT ON gacl_aroFOR EACH ROWBEGIN

CALL miproyecto.obt_max_id_gacl (@maxidgacl);CALL miproyecto.obt_id_gacl_seq (@idseq);CALL miproyecto.comp_user_contact_max (@cont);IF @cont=1 THENIF @maxidgacl=@idseq THEN

INSERT INTO gacl_groups_aro_map (group_id, aro_id)VALUES (13, @maxidgacl);

END IF;END IF;END $$

DELIMITER ;

Los procedimientos que utiliza este trigger ya se han explicado arriba.

d) Finalmente, se lanzara el trigger update_user_contact, después de insertar

una tupla en la tabla gacl_group_aro_map. Una vez comprobado que el valor del

campo user_contact cuyo id es el máximo de la tabla my_users es cero, se

modificara el valor de user_contact por el máximo id de la tabla contacts.

DELIMITER $$CREATE TRIGGER update_user_contact AFTER INSERT ON gacl_groups_aro_mapFOR EACH ROWBEGINCALL miproyecto.comp_user_contact_max (@cont);CALL miproyecto.obt_max_id (@maxid);CALL miproyecto.obt_max_id_contacts (@maxcont);IF @cont=1 THENUPDATE miproyecto.my_users SET user_contact=@maxcont WHERE id=@maxid;


Una vez creados todos los procedimientos y triggers, se hicieron diversas pruebas,

empezando por probar el trigger insert_contacts creando un usuario y comprobando que

realmente llevaba a cabo las operaciones definidas consultando las tablas que debían ser

modificadas. A continuación, el trigger insert_gacl_aro lanzado junto con el primero,

tampoco provocó ningún problema, se modificaron las tablas correspondientes sin surgir

ningún problema. Seguidamente, se probó el trigger insert_gacl_groups a continuación de

los dos anteriores, y tampoco generó ningún problema. Finalmente, al probar el último

trigger, update_user_contact, al crear un usuario en Drupal, se generó el siguiente error:

• user warning: Can't update table 'my_users' in stored function/trigger because it is already used by statement which invoked this stored function/trigger. query: INSERT INTO users (name, mail, pass, status, language, timezone, init, created, access) VALUES ('trig26', '[email protected]', '24c8a1473ac5c932e6add3e8d9502cee', 1, 'es', 7200, '[email protected]', 1249124256, 1249124256) in C:\wamp\www\drupal-6.6\modules\user\user.module on line 327.

• Error al guardar la cuenta de usuario

Ante este problema se probo a crear el trigger update_insert_contact que no comprueba si

el valor del campo user_contact es cero, intuyendo que no se podría modificar la tupla de la

que se está consultando su valor, en este caso de user_contact. De la siguiente manera:

DELIMITER $$CREATE TRIGGER update_user_contact AFTER INSERT ON gacl_groups_aro_mapFOR EACH ROWBEGIN

CALL miproyecto.comp_user_contact_max (@cont);CALL miproyecto.obt_max_id (@maxid);CALL miproyecto.obt_max_id_contacts (@maxcont);IF @cont=1 THEN

UPDATE miproyecto.my_users SET user_contact=@maxcont WHERE id=@maxid;

END IF;END $$

DELIMITER ;

Pero el resultado fué el mismo. El error no proviene únicamente de la consulta del valor

user_contact, sino que también del procedimiento obt_max_id que también obtiene el id de

la tupla que será modificada posteriormente.

Por tanto, se ha deducido quese trata de, un error circular, ya que el último disparador que

se lanza afecta al primero. Se lanzan los triggers en cascada volviendo el ultimo trigger a

basarse en la tabla del primero, con lo que se produce el error. Se puede ver el orden de

ejecución en la siguiente secuencia una vez que se ha insertado un usuario en la tabla

my_users:

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);

Se ha probado ejecutar el código del último trigger manualmente, es decir, una vez

ejecutados los tres primeros triggers, insertando el código manualmente y funciona

correctamente, con lo que confirmamos que el error está localizado.

Hay que matizar que ha sido necesario un estudio previo de la sintaxis de las operaciones

por falta de conocimientos en la implementación en MySQL. En la creación de los triggers y

procedimientos se han generado varios errores por problemas de implementación en

MySQL que han sido solucionados con la ayuda del manual on-line de MySQL.

1

2

3

4

9. IMPLEMENTACION

En este apartado se expondrá en detalle la implementación final del proyecto, subrayando entre

otras cosas la alternativa final llevada a cabo y la explicación del funcionamiento del código

implementado.

La implementación final de la aplicación se basa en la alternativa 4, que, como hemos explicado,

generó un error circular con el último trigger. Por ello, se modificó para que las modificaciones e

inserciones necesarias al crear un nuevo usuario mediante se realizaran mediante un solo trigger.

De igual manera, la modificación y supresión de las tuplas necesarias al eliminará un usuario

también se implementó con un solo trigger. Este procedimiento evitó el error generado por el

funcionamiento circular.

Para que la base de datos tenga el aspecto que ilustra la imagen posterior se han seguido los

siguientes pasos:

1) Partimos de la alternativa desarrollada anteriormente.

2) Al igual que con la tabla users se ha creado una vista en cada aplicación, se crearan

otras vistas de las tablas contacts, gacl_aro, gacl_aro_seq y gacl_groups_aro_map en la

base de datos de Dotproject, y crear tablas nuevas en miproyecto, de la siguiente manera:

a. Modificar el nombre de las tablas contacts, gacl_aro, gacl_aro_seq y

gacl_groups_aro_map, por los nombres dot_contacts, dot_gacl_aro,

dot_gacl_aro_seq y dot_gacl_groups_aro_map respectivamente.

b. Crear las tablas my_contacts, my_gacl_aro, my_gacl_aro_seq y

my_gacl_groups_aro_map en la base de datos nuevo, mi poryecto.

c. Crear las vistas a las tablas de la base de datos miproyecto con los nombres

iniciales de las tablas originales en la base de datos de DotProject, con el siguiente

código:

CREATE VIEW contacts AS

SELECT `contact_id`, `contact_first_name`, `contact_last_name`, `contact_order_by`, `contact_title`, `contact_birthday`, `contact_job`, `contact_company`, `contact_department`, `contact_type`, `contact_email`, `contact_email2`, `contact_url`, `contact_phone`, `contact_phone2`, `contact_fax`, `contact_mobile`, `contact_address1`, `contact_address2`, `contact_city`, `contact_state`, `contact_zip`, `contact_country`, `contact_jabber`, `contact_icq`, `contact_msn`, `contact_yahoo`, `contact_aol`, `contact_notes`, `contact_project`, `contact_icon`, `contact_owner`, `contact_private`FROM miproyecto.my_contacts;

CREATE VIEW gacl_aro ASSELECT ìd`, `section_value`, `value`, òrder_value`, `name`, `hidden`FROM miproyecto.my_gacl_aro;

CREATE VIEW gacl_aro_seq ASSELECT ìd`FROM miproyecto.my_gacl_aro_seq;

CREATE VIEW gacl_groups_aro_map ASSELECT `group_id`, àro_id`FROM miproyecto.my_gacl_groups_aro_map;

3) A parte de las tablas creadas anteriormente, será necesaria una nueva tabla

my_aplic para poder almacenar la información de cada usuario por quien ha sido creado.

Esta tabla guardará el id_usu, el id del usuario al que corresponde, y el id_aplic que tiene

el valor 0 si el usuario ha sido creado por Drupal y 1 si lo ha creado DotProject. Esta

nueva tabla principalmente servirá para identificar que un usuario identificar que va a ser

eliminando por Drupal y así lanzar el trigger que eliminará o modificará las tuplas

necesarias (como veremos a continuación).

4) Una vez modificadas las bases de datos para un manejo más adecuado, se han

creado dos triggers para que simulen en Drupal las modificaciones, inserciones y

eliminaciones necesarias que se generan cuando se crea o se borra un usuario en

Dotproject, y así posteriormente utilizar los usuarios en ambas aplicaciones por igual. A

continuación una breve explicación de cada uno de ellos:

a. insert_user_drupal: se dispara al insetar un usuario nuevo, detecta si el

que lo ha insertado ha sido Drupal y en ese caso inserta y modifica diversas tablas

de la base de datos miproyecto.

b. drop_user_drupal: se dispara al eliminar un usuario, detecta si la

aplicación que ha eliminado dicho usuario ha sido Drupal, en tal caso borrando y

modificando diversas tablas de la base de datos miproyecto.

Ilustración 12: Alternativa 5: Alternativa final, utilización de triggers, procedimientos y vistas

BD_DRUPAL

users (vista)

dru_users

DOTPROJECT

users (vista)dot_users

dot_contacts

dot_gacl_aro

dot_gacl_aro_seq

dot_gacl_groups_aro_map

contacts (vista)

gacl_aro (vista)

gacl_groups_aro_map (vista)

gacl_aro_seq (vista)

DOTPROJECT

DRUPAL

APLICACION BASE DE DATOS

MIPROYECTO

my_users

TRIGGERS

PROCEDIMIENTOS

my_contacts

my_gacl_aro

my_gacl_aro_seq

my_gacl_groups_aro_map

my_aplic

Ilustración 13: Estructura de la nueva base de datos, mi_proyecto.

MIPROYECTO

PROCEDIMIENTOS

obt_id_cont

obt_id_users

obt_id_gacl_seq

TRIGGERS

insert_user_drupal

drop_user_drupal

BASE DE DATOS

id_aplic_del

A continuación se expone el funcionamiento de los triggers detalladamente.

insert_user_drupal (trigger)

El trigger insert_user_drupal está programado para que se dispare antes de que una nueva

tupla sea insertara en la tabla my_user de la base de datos mipryecto. Para poder entender

más detalladamente las modificaciones e inserciones que realiza, se insertará, por ejemplo,

el usuario user1. A continuación podremos considerarlo detenidamente:

La tabla my_users inicialmente esta de la siguiente manera.

Pantalla 5: Tabla de usuarios antes de la insercion de uno de ellos.

Insertamos en Drupal un usuario, user1 con contraseña user1, para que se lance el

trigger. Insertamos los datos necesarios y pulsamos el boton “Crear cuenta nueva”:

Pantalla 6: Formulario de insercion de usuarios en Drupal.

Analizando el codigo poco a poco añade o modifica los siguientes campos:

A continuacion veremos como ha sido implementado el trigger insert_user_drupal y paso por

paso las operaciones que realiza:

DELIMITER $$CREATE TRIGGER insert_user_drupal BEFORE INSERT ON my_usersFOR EACH ROW

BEGIN

CALL obt_id_users (@max_id);

IF NEW.user_contact=0 THEN

CALL obt_id_gacl_seq (@id_seq);CALL obt_id_cont (@max_cont);

INSERT INTO my_contacts (contact_id, contact_first_name, contact_email)VALUES (@max_cont, NEW.user_name, NEW.mail);

INSERT INTO my_gacl_aro (id, section_value, value, order_value, name, hidden)SELECT @id_seq+1, g.section_value, @max_id,g.order_value, NEW.user_name, g.hiddenFROM my_gacl_aro AS g WHERE g.id=1;

INSERT INTO my_gacl_groups_aro_map (group_id, aro_id)VALUES (13, @id_seq+1);

UPDATE my_gacl_aro_seqSET id=@id_seq+1;

SET NEW.user_contact=@max_cont;

INSERT INTO my_aplic (id_usu, id_aplic)VALUES (@max_id, 0);

ELSEINSERT INTO my_aplic (id_usu, id_aplic)VALUES (@max_id, 1);


Como se puede ver en el código al comienzo del trigger se llama a tres procedimientos

obt_id_users, obt_id_gacl_seq y obt_id_cont, lo cuales ayudaran a obtener algunos

valores que despues se necesitan para ejecutar otras sentencias.

Este procedimiento ha sido creado para obtener el valor del campo, valor autoincremental,

de la tabla users almacenado en las tablas de la información del esquema, id que devolverá

por medio del parámetro max_id. Este valor auto_increment almacenado, es el valor que se

le asignará a la siguiente tupla insertada.

CREATE PROCEDURE obt_id_users (OUT max_id INT)SELECT auto_increment INTO max_id FROM information_schema.tables WHERE table_schema = 'miproyecto' AND table_name = 'my_users';

1) INSERT INTO my_contacts (contact_id, contact_first_name, contact_email) VALUES (@max_cont, NEW.user_name, NEW.mail);

4)UPDATE my_gacl_aro_seqSET id=id+1;

�

Este otro procedimiento obtiene el valor del campo id de la tabla my_gacl_aro_se.

CREATE PROCEDURE obt_id_gacl_seq (OUT max_seq INT)SELECT id INTO max_seq FROM my_gacl_aro_seq;

Finalmente, este tercer procedimiento, similar al obt_id_users, obtiene el valor

autoincremental que se le asignará a la siguiente tupla insertada en la tabla my_contacts.

CREATE PROCEDURE obt_id_cont (OUT max_cont INT)SELECT auto_increment INTO max_cont FROM information_schema.tables WHERE table_schema = 'miproyecto' AND table_name = 'my_contacts';



�

Ilustración 14: Operaciones que genera el trigger insert_user_drupal (1)


Inserta una tupla en la tabla my_contacts.

Insertar una tupla en la tabla my_gacl_aro.

2) INSERT INTO my_gacl_aro (id, section_value, value, order_value, name, hidden)

SELECT @id_seq+1, g.section_value, @max_id,g.order_value, NEW.user_name, g.hiddenFROM my_gacl_aro AS g WHERE g.id=1;

Inserta una tupla en la tabla my_gacl_groups_aro_map, por defecto group_id=13, como usuario invitado. Este valor solo afectara a Dotproject.

3) INSERT INTO my_gacl_groups_aro_map (group_id, aro_id)VALUES (13,@id_seq+1);

Incrementar en una unidad el valor anterior a insertar la tupla en my_user.


�

Ilustración 15: Operaciones que genera el trigger insert_user_drupal (2)

Modifica el valor de user_contact, como por defecto es cero, se modifica con el máximo valor de contact_id de la tabla contacts. Modificando la tabla my_user como se puede observar en la siguiente tabla.

5) SET NEW. user_contact=@max_cont;

Antes:

Después:

6.1) INSERT INTO my_aplic (id_usu, id_aplic) VALUES (@max_id, 0);

Si el usuario ha sido creado por Drupal, (como es en este caso) inserta una tupla en la tabla my_aplic con el id_aplic cero.

Sino, si el usuario ha sido creado por DotProject, inserta una tupla en la tabla my_aplic con el id_aplic uno (este no es el caso).

6.2) INSERT INTO my_aplic (id_usu, id_aplic)VALUES (@max_id, 1);

Nota: esta última modificación es necesario para que el usuario insertado por Drupal sea admitido para identificarse en la aplicación DotProject.

drop_user_drupal (trigger)

Otra operación, que es muy común en la gestión de los usuarios es borrar uno de ellos. Por

eso se ha creado este trigger, drop_user_drupal, para que modifique o borre las tuplas que

no sean necesarias, el cual se dispara antes de que la tupla con la información de un usuario

almacenada en my_users sea borrada.

Para entender más detalladamente las modificaciones y eliminaciones que realiza

analizaremos paso por paso el código, y para ello borraremos un usuario existente, por

ejemplo, user1 (creado anteriormente). A continuación podremos considerarlo

detenidamente:

La tabla my_users inicialmente esta de la siguiente manera.

Pantalla 7: Tabla de usuarios antes de la eliminacion de uno de ellos.

Eliminamos desde Drupal un usuario, user1 con contraseña user1, para que se

lance el trigger. Insertamos la direccion de correo y la contraseña y pulsamos el boton

“Borrar”:

Pantalla 8: Formulario de eliminacion de usuarios en Drupal.

A continuacion veremos como ha sido implementado el trigger drop_user_drupal y paso

por paso las operaciones que realiza, y apreciamos como ejecuta los pasos inversos que el

trigger insert_user_drupal:

DELIMITER $$CREATE TRIGGER drop_user_drupal BEFORE DELETE ON my_usersFOR EACH ROWBEGIN

CALL id_aplic_del (OLD.id, @aplic);

IF @aplic=0 THEN

CALL obt_id_gacl_seq (@id_seq);CALL obt_id_usu_gacl (OLD.id, @group_id);

DELETE FROM my_contacts WHERE contact_id=OLD.id;

DELETE FROM my_gacl_aro WHERE value=OLD.id;

DELETE FROM my_gacl_groups_aro_map WHERE aro_id=@group_id;

UPDATE my_gacl_aro_seqSET id=@id_seq-1;

END IF;

DELETE FROM my_aplic WHERE id_usu=OLD.id;

END $$DELIMITER ;

Como se puede ver en el código, al comienzo del trigger se llama a dos procedimientos

id_aplic_del y obt_id_gacl_seq, los cuales ayudaran a obtener algunos valores que después

se necesitan para ejecutar otras sentencias. El procedimiento obt_id_gacl_seq ya se ha

explicado anteriormente ya que se utiliza tambien en el trigger insert_user_drupal.

Este procedimiento, pasandole como parametro de entrada el id del usuario que se va a

borrar, devuelve un cero si dicho usuario lo ha creado Drupal y uno si lo ha creado

DotProject, ya que se ha decidido identificar de esta forma a las aplicaciones.

CREATE PROCEDURE id_aplic_del (IN id INTEGER, OUT aplic INTEGER)SELECT id_aplic INTO aplic FROM my_aplic WHERE id_usu=id;

Estas operaciones únicamente se ejecutaran si el valor que devuelva el procedimiento id_aplic_del es cero, es decir si el programa que

elimina el usuario es Drupal.

Esta última operación se ejecuta siempre, bien el usuario lo borre Drupal o bien lo borre DotProject.

1) DELETE FROM my_contacts WHERE contact_id=OLD.id;

Elimina de la tabla my_contacts la tupla cuyo id coincide con el user_contact de la tabla my_users.

2) DELETE FROM my_gacl_aro WHERE id=OLD.ID;

Elimina de la tabla my_gacl_aro la tupla cuyo campo name coincide con el campo contact_first_name de la tabla my_contacts.

3) DELETE FROM my_gacl_groups_aro_map WHERE aro_id=@group_id;

Elimina de la tabla my_gacl_groups_aro_map la tupla cuyo campo aro_ id coincide con el campo id de la tabla my_gacl_aro.

4) UPDATE my_gacl_aro_seqSET id=@id_seq-1;

Modifica el id de la tabla my_gacl_aro_seq, incrementándolo en una unidad.

5) UPDATE my_gacl_aro_seqSET id=@id_seq-1;

Modifica el id de la tabla my_gacl_aro_seq, incrementándolo en una unidad.

Ilustración 16: Operaciones que genera el trigger drop_user_drupal

10. PRUEBAS

A continuación exponemos una serie pruebas para verificar el correcto funcionamiento del

proyecto un vez finalizado.

Pruebas unitarias

Para ver el correcto funcionamiento de cada módulo de código generado, en este proyecto los

distintos procedimientos y triggers, se ejecutará cada uno de ellos independientemente analizando

el efecto que surge en la base de datos.

Para probar el procedimiento obt_id_users, se ejecutara de siguiente manera:

CALL obt_id_users(@max_id);SELECT @max_id;

Obteniendo el siguiente resultado:

Pantalla 9: Resultado de la ejcucion del procedimiento obt_id_users.

Así podemos observar como el id del siguiente usuario que se insertará en la tabla

my_users será el 3, ya que esta tabla almacena el siguiente valor a asignar, porque es un

campo auto_incremental y está almacenado en el esquema de información.

Para probar el procedimiento obt_id_cont, se ejecutará de siguiente manera:

CALL obt_id_cont(@max_id_cont);SELECT @max_id_cont;


Pantalla 10: Resultado de la ejcucion del procedimiento obt_id_cont.

Se puede observar como el id del siguiente usuario que se insertara en la tabla my_contacts

será el 3, ya que esta tabla almacena el siguiente valor a asignar porque es un campo

auto_incremental y está almacenado en el esquema de información.

Los valores obtenidos con obt_id_users y obt_id_cont, se han consultado de la siguiente

tabla:

Pantalla 11: Tabla de almacenamiento de los campos auto_increment.

Para probar el procedimiento obt_id_gacl_seq, se ejecutará de la siguiente manera:

CALL obt_id_gacl_seq (@id_seq);

SELECT @id_seq;


Pantalla 12: Resultado de la ejcucion del procedimiento obt_id_gacl_seq.

Así observamos que el id de la tabla gacl_aro del último usuario insertado es el 2,

porque el id de la tabla gacl_aro_seq se incrementa una ver que se ha insertado una

tupla en la tabla gacl_aro, por tanto almacena el id del último usuario insertado.

Para probar el procedimiento id_aplic_del, hay que tener en cuenta que este

procedimiento requiere de un parámetro de entrada y uno de salida. Por tanto, el

parámetro de entrada, que será el id de un usuario existente en la tabla my_user, se

insertará manualmente para obtener un resultado correcto, por ejemplo, id=2, que

corresponde al usuario cuyo user_name=user1:

CALL id_aplic_del (2,@id_aplic);

SELECT @id_aplic;


Pantalla 13: Resultado de la ejecución del procedimiento_id_apli_del.

Vemos que el id de aplicación que le corresponde al usuario con id=2 es cero, por tanto,

sabemos que la aplicación que ha creado este usuario a sido Drupal.

En cuanto a la prueba de ejecución de los triggers, en el apartado de implementación del proyecto

podemos ver paso por paso la ejecución de cada uno de ellos, independientemente, y los cambios

que generan en las diferentes tablas de la base de datos mi_proyecto.

Pruebas de integración

Las pruebas de integración consisten en probar todos los elementos unitarios que componen un

proceso. En este proyecto, una prueba de integración será la ejecución de los triggers, ya que cada

uno de ellos llama a procedimientos, y por tanto, un trigger y los procedimientos a los que llama

componen un proceso. Las pruebas de integración son dos, una por cada trigger creado.

Como se ha ilustrado anteriormente, los pasos a seguir de la ejecución de los triggers están

incluidos en el apartado de implementación del proyecto final (Véase página 73 y página 78).

Pruebas de validación

Se utilizan para verificar que el objetivo de este proyecto se ha cumplido. Es decir, que la creación

de un usuario en una aplicación o en otra se podrá utilizar indistintamente en cualquiera de las

dos.

Principalmente, probaremos a crear un usuario en Drupal y acceder con el mismo en DotProject.

Creamos el usuario “dru1” con contraseña “drupal1”, en Drupal y podemos ver como se ha

creado satisfactoriamente:

Pantalla 14: Creación de usuario en Drupal.

Pantalla 15: Creación de un usuario en Drupal, exitosamente.

Identificarse con “dru1” en DotProject:

Pantalla 16: Identificacion de usuario Drupal en DotProject.

El usuario accede sin ningún problema, como podemos ver en la siguiente pantalla,

pudiendo realizar distintas operaciones.

Pantalla 17: Identificacion de usuario Drupal en DotProject, exitosamente.

Por último, crear un usuario en DotProject y acceder con el mismo en Drupal.

Crear el usuario “dot1” con contraseña “dotproject1”, en DotProject:

Pantalla 18: Creación de usuario en DotProject.

Identificarse con “dot1” en Drupal:

Pantalla 19: Identificación de usuario DotProject en Drupal.

El usuario accede sin ningún problema, como podemos ver en la siguiente pantalla,

pudiendo realizar distintas operaciones.

Pantalla 20: Identificación de usuario DotProject en Drupal, exitosamente.

Pruebas de carga

Para probar si la base de datos soporta una gran carga de operaciones y si las transacciones de los

triggers funcionan correctamente en la creación y eliminación de los usuarios, se ha creado un

programa en java que inserta y elimina un grupo masivo de usuarios concurrentemente. El código

de la prueba de carga está recogido en el Véase Anexo 2 .

11. GESTION DEL PROYECTO

En este apartado, se muestran gráficos con las horas estimadas para cada tarea y las horas

reales que finalmente se han necesitado para llevarlas a cabo.

Las horas planificadas y reales se muestran divididas por procesos y tareas:

Horas planificadas Horas invertidas

Creación del DOP 15 h. 8 h.

Gestión de archivos 18 h. 25 h.

Memoria 55 h. 75 h.

Presentación 8 h. 7 h.

Tabla 3: Horas planificadas/horas reales (procesos tácticos)

Gráfica 1: Horas planificadas/horas reales (procesos tácticos)

Como se puede observar en la gráfica de los procesos tácticos, la redacción de la memoria

es la tarea que mas diferencia de horas ha tenido respecto a la planificación inicial, seguida

por la gestión de archivos, principalmente por las horas invertidas en las reuniones con el

tutor del proyecto. Sin embargo, la creación del DOP se ha realizado en bastantes menos

horas de las estimadas.

Horas

planificadas

Horas invertidas

Búsqueda de aplicaciones existentes 5 h. 8,5 h.

Selección de aplicaciones 18 h. 12 h.

Estudio de código 10 h. 10,9 h.

Estudio de la base de datos 10 h. 5 h.

Modo de integración 15 h. 8 h.

Implementación 40 h. 42,5 h.

Fase de pruebas 10 h. 8 h.

Tabla 4: Horas planificadas/horas reales (procesos operativos)

Gráfica 2: Horas planificadas/horas reales (procesos operativos)

En cuanto a los procesos operativos, las únicas tareas que se han excedido de las horas

planificadas son la búsqueda de aplicaciones, la fase de implementación y el estudio de código. En

la tarea de estudio de código es muy difícil estimar las horas que se invertirán, pues dependiendo

de las aplicaciones escogidas, el código varia considerablemente. Sin embargo, a diferencia del

estudio de las bases de datos, ha sido más sencillo, puesto que las tablas de los usuarios, que son

las más importantes, no son muchas.

Horas

planificadas

Horas

invertidas

NetBeans 2 h. 3 h.

WAMP 2 h. 1 h.

PHP 4 h. 2 h.

MySQL 4 h. 10 h.

Tabla 5: Horas planificadas/horas reales (procesos formativos)

Gráfica 3: Horas planificadas/horas reales (procesos formativos)

Los procesos formativos, son las tareas que mas difieren en horas entre las horas planificadas y las

horas invertidas. A pesar de conocer teóricamente la implementación en MySQL, ha originado

varios problemas imprevistos por falta de formación en pequeños pero importantes detalles. Sin

embargo, el desconocimiento de WAMP y PHP indujo a prever más horas de las necesarias,

puesto que WAMP es una aplicación de manejo sencillo, y la implementación en PHP no ha sido

necesaria, ya que el proyecto se ha centrado finalmente en las bases de datos de las aplicaciones,

obviando la implementación de las mismas.

Horas planificadas Horas invertidas

Procesos tácticos 96 h. 115 h.

Procesos

operativos 108 h. 94,9 h.

Procesos

formativos 12 h. 16 h.

Tabla 6: Horas planificadas/horas reales divididas por procesos

Gráfica 4: Horas planificadas/horas reales divididas por procesos

Finalmente, en la ultima gráfica, observamos como las horas planificadas en los procesos tácticos

y los formativos se han quedado por denajo de las invertidas. Sin embargo, en los procesos

operativos las horas planificadas has excedido a las horas invertidas.

12. CONCLUSIONES

El proyecto ha requerido un gran esfuerzo de exploración, adecuación y y optimización de las

herramientas existentes para crear una aplicación que cumplira los objetivos del mismo. Este

esfuerzo de ha traducido en un elevado numero de horas de trabajo. La metodologia seguida se

basa en la practicada en la asignatura de Ingenieria del Software, en la cual adquirí los

conocimientos para llevar a cabo este proyecto.

Para llevar a cabo un proyecto de estas características, hay que tener una buena planificación

inicial. Sin embargo, los inconvenientes que van surgiendo durante el desarrollo del proyecto,

hacen que la planificación inicial no se cumpla debidamente. Es cierto que es necesaria una gran

experiencia para hacer estas planificaciones y en mi caso la única experiencia es la adquirida

durante el último año de carrera. Por lo que creo que con más práctica, se puede llegar a conseguir

planificaciones que se adapten mejor a las horas reales necesarias en las diferentes fases, para

elaborar un proyecto como este.

La estructuración necesaria para el correcto desarrollo del proyecto ha seguido el proceso

unificado de desarrollo software que divide el proyecto en diversas fases.

En algunas de estas fases han surgido complicaciones. Algunas de debieron al desconocimiento

previo de las aplicaciones a analizar y de las técnicas de las bases de datos MySQL. El

aprendizaje teorico de las bases de datos, vistas, procedimientos, triggers, transacciones… en la

univerdidad no conlleva las practicas necesarias para analizar realmente las dificultades, y errores

que pueden generarse en cada concepto aprendido, asi como las posibles soluciones aplicables en

casa caso. Algo comun a la mayoria de los estudios universitarios.

Otra complicacion encontrada es en el análisis encontrar una alternativa optima y sencilla para

llevar a cabo este proyecto. Al no conocer bien las aplicaciones escogidas y su funcionamiento, se

han tenido que hacer diversas prueba hasta conseguir la solución idónea. En esta fase ha sido

donde mas complicaciones ha surgido.

A pesar de costar mas horas de las esperadas por los inconvenientes nombrados anteriormente, se

ha conseguido el objetivo final exitosamente.

Este proyecto,ha pretendido producir una utilidad práctica pero además, me ha servido para

conocer distintos gestores de proyectos, conocer mas detalladamente las bases de datos MySQL y

distintas maneras de implementar en PHP.

13.BIBLIOGRAFIA

[1] 2009 Alfresco Software, Inc., Productos de Alfresco, Consulta: durante el año 2009,

<http://www.alfresco.com/es/>

[2] En línea desde 11 abril 2005, Theme provided by Acquia, Inc. under GPL license from

TopNotchThemes Drupal themes, Consulta: durante el año 2009, <http://drupal.org.es/>

(http://drupal.org/)

[3] Joomla Spanish 2009 (C), Manual de usuario on-line, Consulta: durante el año 2009

< http://www.joomlaspanish.org/ > (http://www.joomla.org/)

[4] © 2009 DM Web, Produscts: DotCMS 1.7, Consulta: durante el año 2009,

<http://www.dotcms.org/>

[5] Copyright 2005, Slackhat, Consulta: durante el año 2009, < http://www.dotproject.net/ >

[6] © 1999 - 2009 Ibuildings B.V., Product, Consulta: durante el año 2009,

< http://www.achievo.org/ >

[7] Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., List of content

management systems, Consulta: durante el año 2009,

< http://en.wikipedia.org/wiki/List_of_content_management_systems >

[8] © 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc., Consulta: durante el año

2009,

+Manual referencia MySQL 5.0: < http://dev.mysql.com/doc/refman/5.0/es >

+Manual MySQL workbench: <http://dev.mysql.com/doc/workbench/en/index.html>

http://dev.mysql.com/doc/refman/5.0/es

http://en.wikipedia.org/wiki/List_of_content_management_systems

http://www.wikimediafoundation.org/

http://www.achievo.org/

http://www.dotproject.net/

http://www.joomla.org/

http://www.joomlaspanish.org/

http://www.topnotchthemes.com/

http://www.acquia.com/

facultad de informática informatika fakultateaadimen.si.ehu.es/~rigau/teaching/ehu/pfcs... ·...

Documents