INTEGRACIÓN DE APLICACIONES GESTORAS DE PROYECTOS
Ingeniería Técnica en Informática de Sistemas
Proyecto de fin de carrera, Junio 2010
Director: German Rigau i Claramunt Alumno: Lorea Ustarroz Leandro
1
ÍNDICE
Introducción. Método de trabajo. Elección de las aplicaciones. Elección tecnológica. Captura de requisitos. Desarrollo técnico. Pruebas. Gestión del proyecto. Conclusiones. Demo.
2
INTRODUCCIÓN
Origen del proyecto. Conveniencia de una herramienta de gestión de
proyectos para un centro de investigación: Gestionar el contenido de proyectos. Gestionar los aspectos financieros, tareas, resultados y
contribución de los participantes.
Objetivo. Alternativas para lograr un sistemas formado por un
gestor de proyectos y un gestor de contenidos. Gestores de proyectos: DotProject, Achievo… Gestores de contenidos de proyectos: Drupal, Joomla,… No existen aplicaciones que reúnan las funcionalidades de
ambas. Creación de una aplicación integrando ambas.
3
3
MÉTODO DE TRABAJO
Métodos de desarrollo de software: El Proceso Unificado de Desarrollo (PUD).
Organización de trabajo: Se ha seguido el Documento de Objetivos del
Proyecto (DOP). Reuniones con el director del proyecto. Seguir plan de contingencia y planificación temporal
para evitar problemas. Pasos a seguir para el desarrollo del proyecto:
Búsqueda de información de las aplicaciones existentes.
Elección de dos aplicaciones. Alternativas de integración.
4
ELECCIÓN DE LAS APLICACIONES (1)
Estudio previo de las aplicaciones existentes: Gestor de contenidos o CMS (Content
Management System). Gestor de proyectos.
Aplicaciones opensource, para poder estudiar: Código (implementación). Base de datos.
5
Gestores de contenidos de proyectos (CMS)
Nombre Plataforma compatible Lenguaje y soporte
Alfresco
Red Hat Enterprise
Sun Solaris 10
Windows Server 2003
Cualquier sistema con soporte JSP
debería soportarlo (MacOS, Linux, Unix)
Desarrollado en JSP
Soporta cualquier base de datos apoyada por
Hibernate, incluidas: MySQL 5 y Oracle 10
Servidor Web: Apache Tomcat
DrupalUnix/Linux
Windows
Desarrollado en PHP
Soporte para MySQL y PostgreSQL
Servidor Web: Apache 1.3 o superior.
JoomlaUnix/Linux
Windows
Desarrollado en PHP
Soporte para MySQL y PostgreSQL
Servidor Web: Apache 6 o superior.
DotCMS CoreUnix/Linux
Windows
Desarrollado en J2EE/Java
soporte para MySQL, PostgreSQL, MS-SQL y
Oracle
Servidor Web: Apache Tomcat
6
Gestores de proyectos
Requisitos previosCaracterísticas generalesNombre de
aplicaciónServidor Lenguaje
Gestor de base de datos
Dotproject
Servidor web:
Apache 1.3.27 o
superior
PHP 4.1.x ó
superior.
MySQL
3.23.51 ó
superior.
Utilización de plantillas.
Creación de graficas de Gantt.
Repositorio de fichero.
Disponibilidad de diversos
módulos.
Aplicación multiusuario.
Multi-idiomas.
AchievoServidor web:
apache 2PHP 5 MySQL
Utilización de módulos.
Multi-idiomas.
7
ELECCIÓN DE LAS APLICACIONES (2)
Criterios para la elección de las aplicaciones::
Lenguaje en que han sido implementadas. Tipo de bases de datos soportadas. Funcionalidades de la aplicación. Dificultad de la instalación.
8
ELECCIÓN DE LAS APLICACIONES (3)
9
Aplicaciones
Servidor Lenguaje Gestor de bases de
datos
Instalación
DotProjectServidor web: Apache 1.3.27 o superior
Desarrollado en PHP 4.1.x o superior.
Soporte para MySQL 3.23.51 o superior.
•Rápida instalación.
•Instalable en equipos antiguos y modernos.
DrupalServidor Web: Apache 1.3
Desarrollado en PHP
Soporte para MySQL y PostgreSQL
•Rápida instalación.
ELECCIÓN TECNOLÓGICA
WAMP Plataforma para Windows que incorpora PHP,
MySQL y Apache. Para el correcto funcionamiento de las
aplicaciones seleccionadas. Análisis de las bases de datos.
NetBeans IDE 6.5 Entorno de desarrollo implementado en java pero
que sirve para cualquier otro lenguaje de programación.
Análisis de la implementación de las aplicaciones.
10
CAPTURA DE REQUISITOS (1)
¿Qué vamos a integrar? Muchas alternativas. Decisión: integración únicamente a nivel de
usuarios. Criterios de integración:
Minima intervención en la aplicaciones. Manera sencilla para el desarrollador.
¿Cómo? Manera menos invasiva. Integrando las BD modificando las BD.
11
CAPTURA DE REQUISITOS (2) Base de datos de DotProject:
Cuando un usuarios es creado en DotProject se modifican las siguientes tablas.
12
Contiene información complementaria a la
contenida en la tabla users.
Relaciona cada usuario al rol correspondiente.
Usuarios existentes.
CAPTURA DE REQUISITOS (3) Base de datos de Drupal: en estas tablas se almacena
la información principal de los usuarios.
13
Contiene cada usuario al rol que está asociado.
Roles existentes.
Usuarios existentes.
CAPTURA DE REQUISITOS (4)
DotProject: utiliza una clase DBQuery y sus funciones para crear las consultas a la base de datos.
…$q = new DBQuery;$q->addTable('users');$q->addQuery('user_id, user_password, user_contact');$q->addWhere("user_username = '$username'");…
Drupal: directamente hace la consulta, mediante una única función.
db_query('INSERT INTO {users_roles} (uid, rid) VALUES (%d, %d)', $array['uid'], $rid);
Implementación DotProject y Drupal:
14
DESARROLLO TÉCNICO (1)
Alternativa 1: sincronización de las BD. Alternativa 2: sincronizar los usuarios mediante
triggers. Alternativa 3: Creación de una nueva BD para los
usuarios. Alternativa 4: Creación de vistas, procedimientos
y triggers. Alternativa 5: variante de la Alternativa 4.
15
DESARROLLO TÉCNICO (2) Alternativa 1: Sincronización de las BD.
Solo se necesita sincronizar las tablas de los usuarios, no la BD entera.
Problemas: Redundancia en la información de los usuarios. Inconsistencia de datos.
APLICACIÓN BASE DE DATOS
DRUPAL
DOTPROJECT
users
tabla_dot_1
tabla_dot_2
tabla_dot_n
BD_DRUPAL
users
tabla_dru_1
tabla_dru_2
tabla_dru_p
SINCRONIZACIÓN
DOTPROJECT
16
DESARROLLO TÉCNICO (3) Alternativa 2: sincronizar los usuarios mediante triggers.
Replica de la misma tabla en las dos aplicaciones. Alternativa 5 similar a esta alternativa. Problemas:
Continuamos con redundancia de la información. Dificultad para mantenerla consistente.
APLICACIÓN BASE DE DATOS
DOTPROJECT
DRUPAL
TRIGGERS
DOTPROJECT
users
tabla_dot_1
tabla_dot_2
tabla_dot_n
BD_DRUPAL
users
tabla_dru_1
tabla_dru_2
tabla_dru_p
17
DESARROLLO TÉCNICO (4) Alternativa 3: creación de una nueva BD para los usuarios.
No se modifican las BD originales. Problemas:
Dificultad en las actualizaciones modificar todas las llamadas.
18
DotProject.users
MIPROYECTO
my_users
DOTPROJECT
users
APLICACIÓN BASE DE DATOS
bd_drupal.users
DRUPAL
DOTPROJECT
BD_DRUPAL
users
miproyecto.my_users
DESARROLLO TÉCNICO (5) Alternativa 4: Creación de vistas, procedimientos y triggers.
Se ha averiguado: Crear usuario en Drupal utilizarlo en DotProject. NO funciona. Crear usuario en DotProject utilizarlo en Drupal. SI funciona.
19
DRUPAL
PROCEDIMIENTOS
MIPROYECTO
my_users
TRIGGERS
DOTPROJECT
APLICACIÓN BASE DE DATOS
BD_DRUPAL
users (vista)
DOTPROJECT
contacts
gacl_aro
gacl_aro_seq
gacl_groups_aro_map
users (vista)
DESARROLLO TÉCNICO (6) Para ponerla en práctica:
Crear nueva BD miproyecto. Crear tabla de usuarios en miproyecto my_users. Crear las vistas users en cada BD. Crear los triggers y procedimientos.
20
DotProjectbd_ drupal
DESARROLLO TÉCNICO (7)
Se ejecutan los triggers en cascada: Problema: ERROR CIRCULAR. MySQL no permite modificar una tabla que se esta
consultando por el mismo trigger.
insert_contacts AFTER my_users (insert in contacts);
insert_gacl_aro AFTER contacts (insert in gacl_aro);
insert_gacl_groups AFTER gacl_aro (insert in gacl_group_aro_map);
update_user_contact AFTER gacl_groups_aro_map (update in my_users); 21
1
2
3
4
DESARROLLO TÉCNICO (7) Alternativa 5: variante de la Alternativa 4.
DOTPROJECT
DRUPAL
APLICACION BASE DE DATOS
MIPROYECTO
my_users
PROCEDIMIENTOS
my_contacts
my_gacl_aro
my_gacl_aro_seq
my_gacl_groups_aro_map
my_aplic
TRIGGERS
DOTPROJECT
users (vista)
contacts (vista)
gacl_aro (vista)
gacl_groups_aro_map (vista)
gacl_aro_seq (vista)
BD_DRUPAL
users (vista) 22
DESARROLLO TÉCNICO (8)
Suma de las anteriores alternativas. Crear una replica de las tablas de DotProject, en la
BD miproyecto. Crear las vistas en DotProject, de las tablas de miproyecto.
Crear 2 triggers: Crear usuarios: trigger insert_user_drupal. Eliminar usuarios: trigger drop_user_drupal.
23
PRUEBAS
Pruebas unitarias: Funcionamiento de los procedimientos y triggers
generados en este proyecto Pruebas de integración:
Probar todos los elementos unitarios (triggers y procedimientos) que componen un proceso.
Pruebas de validación: ¿se ha cumplido el objetivo?
Pruebas de carga: Probar múltiplas operaciones concurrentemente
y correcto funcionamiento de las transacciones.24
GESTIÓN DEL PROYECTO (1)
Planificado: 216 h. Real: 225,9 h. Desajuste de horas total: 4,58%
25
0
50
100
150
200
250
Cre
ació
n de
lD
OP
Ges
tión
Mem
oria
Pre
sent
acio
n
Bus
qued
a de
aplic
acio
nes
Sel
ecci
ón d
eap
licac
ione
s
Est
udio
de
códi
go
Est
udio
de
las
BD
Mod
o de
inte
grac
ión
Impl
emen
taci
ón
Pru
ebas
Net
Bea
ns
WA
MP
PH
P
MyS
QL
Tot
al
Horas planificadas
Horas reales
GESTIÓN DEL PROYECTO (2)
Gráfica de procesos tácticos, operativos y formativos.26
CONCLUSIONES Gestión del proyecto:
Se han cumplido los objetivos de forma satisfactoria y a tiempo.
Desarrollo de la aplicación: Gran importancia del análisis y el diseño para
facilitar la implementación. Objetivos logrados: únicamente modificando la BD y
utilizando las capacidades triggers, procedimientos… Valoraciones personales:
Demostrar lo aprendido en diversas asignaturas. Experiencia enriquecedora y satisfactoria. Conocer aplicaciones existentes. Se han aprendido y utilizado nuevas tecnologías. 27
INTEGRACIÓN DE APLICACIONES GESTORAS DE
PROYECTOS
Ingeniería Técnica en Informática de Sistemas
Proyecto de fin de carrera, Junio 2010
Director: German Rigau i Claramunt Alumno: Lorea Ustarroz Leandro
1
28