facultad de informática informatika fakultateaadimen.si.ehu.es/~rigau/teaching/ehu/pfcs... ·...
TRANSCRIPT
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
Integración de aplicaciones gestoras de proyectos: Memoria
~ 3 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
............................................................................................................................................................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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
Recursos personales:
1 persona
Recursos materiales:
Ordenador portátil.
~ 14 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
• 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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
• 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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
Diagrama de Gantt
~ 20 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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.
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
o superior. contenidos.
Utilización de plantillas.
Libro colaborativo
Sistema de control de
congestión.
Disponible en diversas
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.
Disponible en diversas
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.
Disponible en diversas
lenguas.
Gestión de permisos de
usuarios basad en roles.
Tabla 1: CMS, Content Management System
~ 28 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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 ~
Integración de aplicaciones gestoras de proyectos: Memoria
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.
APLICACIÓN BASE DE DATOS
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.
APLICACIÓN BASE DE DATOS
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;
END IF;END $$DELIMITER ;
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.
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;
END IF;END $$DELIMITER ;
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 `id`, `section_value`, `value`, `order_value`, `name`, `hidden`FROM miproyecto.my_gacl_aro;
CREATE VIEW gacl_aro_seq ASSELECT `id`FROM miproyecto.my_gacl_aro_seq;
CREATE VIEW gacl_groups_aro_map ASSELECT `group_id`, `aro_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);
END IF;END $$DELIMITER ;
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';
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;
�
Ilustración 14: Operaciones que genera el trigger insert_user_drupal (1)
1) INSERT INTO my_contacts (contact_id, contact_first_name, contact_email) VALUES (@max_cont, NEW.user_name, NEW.mail);
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.
4)UPDATE my_gacl_aro_seqSET id=id+1;
�
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;
Obteniendo el siguiente resultado:
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;
Obteniendo el siguiente resultado:
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;
Obteniendo el siguiente resultado:
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>
[9] © 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc., Forums, Consulta: durante el año 2009, <http://forums.mysql.com/list.php?71>