ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA

INGENIERÍA TÉCNICA DE INFORMÁTICA DE GESTIÓN

GESTIÓN INTEGRAL DE USUA...
Índice de contenidos
1.Introducción......................................................................................7...
7.Codificación....................................................................................53
7.1.Entorno de progra...
Índice de Tablas
Planificación_del_proyecto..................................................................................
Índice de Figuras
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura...
6
1. Introducción
1.1.

Contexto del proyecto

Drupal es un sistema de administración de contenidos Web
especialmente versát...
 Los mecanismos de actualización de contenidos son realmente
sencillos, permite editar la mayor parte de los contenidos t...
integradas en el software, es posible añadir nuevas funcionalidades a
través de módulos.
Los módulos son aplicaciones adic...
1.3.

Justificación

La tarea de desarrollar este módulo en Drupal parte de la idea
de poder facilitar el trabajo al encar...
2.Metodologías de Desarrollo
Las Metodologías de Desarrollo de Software surgen ante la
necesidad

de

utilizar

una

serie...
Scrum

es

un

marco

de

referencia

para

generar

una

metodología ágil. Es un marco que surgió de la experiencia y se
...
3.Planificación temporal y evaluación de
costes
Para que un proyecto sea exitoso, es importante cumplir los plazos
acordad...
Por tanto, dividimos el ciclo de vida del proyecto en una serie
de tareas a las cuales se les asignará las dos estimacione...
Tarea

Tiempo estimado

Tiempo real

RE

Búsqueda documentación

8h

13h

38.5%

Introducción

15h

10h

-50%

Planificaci...
3.2.

Evaluación de Costes

Para la evaluación de costes, tendremos en cuenta los
diferentes puntos a valorar:
 Coste

de...
800 x 4 / (4 x 12) = 55,67 €
Costes software, utilizaremos los siguientes programas:

Eclipse Helios

0,00 €

Microsoft Of...
4.Elicitación de requisitos
4.1.

Introducción

En este apartado se ofrecerá una visión detallada del módulo
que se va a c...
Participante

Antonio Ruíz Cortes

Organización

Freelance

Rol

Tutor

Es desarrollador

No

Es cliente

No

Es usuario

...
4.3.

Descripción del sistema actual

Actualmente la gestión de usuarios está diseñada por medio de
un directorio LDAP y u...
sea interesante para almacenar información relativamente estática,
pero de muchas lecturas. El protocolo que utiliza el se...
los identifica de forma única y una serie de atributos. Los atributos
están formados por un nombre que ejerce de llave y u...
Figura 4.1 – Estructura de OpenLDAP

•
La

Conexión OpenLDAP con Drupal
conexión

de

OpenLDAP

con

Drupal

se

realiza

...
Figura 4.2 – configuración OpenLDAP en Drupal (Server settings)

24
Figura 4.3 – configuración OpenLDAP en Drupal (Login procedure)

25
Figura 4.4 – configuración OpenLDAP en Drupal (Advanced configuration)

Una vez realizado el proceso, ya se puede comproba...
4.3.2.

“Single Sign On”: CAS

Un “Single Sign On” es un proceso de autenticación unificado,
que permite al usuario introd...
CAS
CAS (Central Authentication Service) es una aplicación java
desarrollada por la universidad de Yale que se compone de ...
Esta información se carga al inicio de la aplicación de Gestión
de Usuarios. Se añaden nuevos atributos consultando a cada...
4.4.1.

Gestión de Usuarios

Un usuario en la Gestión Centralizada de Usuarios constará de
un identificador único de usuar...
Fields

Descripción

app

Identificador de la aplicación a integrar

label

Campo de usuario al que se corresponde.

field...
CRUD de Usuarios: Listado de Usuarios
El listado de usuarios toma la información de la lectura de
usuarios de la función L...
CRUD de Usuarios: Nuevo Usuario
El formulario de nuevo usuario, muestra una sección de
información con la información prop...
Mostraría un formulario con 3 entradas:
 Identificador. Siempre se mostrará en primera posición. En
edición siempre será ...
Figura 4.7 – Ficha de alta de un nuevo usuario

35
CRUD de Usuarios: Edición de Usuario
El formulario de edición de usuario, muestra una sección de
información con la propia...
Figura 4.8 – Detalle de usuario

37
CRUD de Usuarios: Edición de Usuario (no existe)
Cuando se edita un usuario que no existe en una determinada
herramienta (...
4.4.2.

Gestión de Roles

Los roles de cada usuario se mostrarán divididos (en pestañas
o

en

secciones

del

formulario)...
Figura 4.10 – Detalle de perfil

40
Gestión de Roles en Drupal
Drupal

no

tiene

ámbitos

como

tales,

y

tampoco

tiene

modificadores de ámbito.
El formul...
4.4.3.

Consideraciones adicionales

Para preservar la integridad de los datos, lo adecuado sería
que la administración de...
 getRoles
 getScopes
 grantRole
 revokeRole
Para la Gestión de Usuarios:
 listUsers
 getAttributes
 getApps
 creat...
5.Diseño del Sistema
5.1.

Introducción

En el presente apartado de la documentación se describe el
diseño que se ha reali...
explicaremos a continuación, permite ampliar las funcionalidades de
un sistema Drupal de una forma relativamente sencilla....
Figura 5.3 – Estructura de módulos [11]

Así mismo Drupal proporciona “themes” que permiten la
personalización de la apari...
•

Vista: Este presenta el modelo en un formato adecuado
para interactuar, usualmente la interfaz de usuario.

•

Controla...
6.Diseño de datos
Pasamos ahora a la elaboración de la capa de persistencia del
sistema.

Independientemente

del

SGBD

e...
2. Para cada relación, la cardinalidad se expresa mediante el
esquema X:Y, siendo X e Y la multiplicidad mínima y
máxima d...
6.2.

Entidades del Modelo de Datos

Las entidades que utilizaremos en nuestro modelo serán las
siguientes:
GIU_USERS
Atri...
GIU_ENVIRONMENT_PROFILES
Atributo

Tipo

Nulo?

Predet.

PK

Autoinc.

X

id

int(10)

No

profile_id

int(10)

No

moodle...
6.3.

Relaciones del Modelo de Datos

Entidades

Cardinalidad

Descripción

giu_users
1:1

Un usuario tiene un sólo perfil...
7.Codificación
7.1.

Entorno de programación y

Herramientas
Drupal está diseñado para funcionar sobre, prácticamente,
cua...
En nuestro caso haremos uso de las siguientes herramientas:
Elemento

Tipo

Hardware

Detalle

PC

Versión

Sony VAIO

Sis...
Free Software Foundation considera esta licencia como software
libre.
AJAX
Ajax,

acrónimo

de

Asynchronous

JavaScript

...
apariencia de un documento, y puede incluir un script (por ejemplo
Javascript), el cual puede afectar el comportamiento de...
7.3.

Otros aspectos relevantes de la

implementación
A continuación mostraremos lo más reseñable de nuestra
aplicación.
L...
Lo siguiente que vamos a destacar es la creación del listado de
usuarios:

58
...

59
60
Con esta función nos traemos los campos que nos interesan de
cada aplicación, cada una de las aplicaciones con la que quer...
También tenemos una función que valida los campos para que
no haya errores a la hora de trabajar con cada una de las DB de...
8.Conclusiones
Una vez finalizado el proyecto, se puede concluir que el
módulo para la gestión de usuarios cumplirá con la...
funciones, puede resultar del interés de empresas grandes, sobre
todo si ya disponen de estas.

64
9.Glosario de términos
Navegador o navegador web: (del inglés, web browser) es un
programa que permite visualizar la infor...
10. Referencias
[1] PALACIO, Juan. Flexibilidad con Scrum.
http://www.scribd.com/doc/48689944/Flexibilidad-con-Scrum
[2] S...
[13] OPENLDAP
http://www.openldap.org/
[14] XPLORER
http://jxplorer.org/

67
11. Bibliografía
•

FORCONTU
o

•

http://www.forcontu.es/

Estudio de los sistema de gestión de contenidos web (CMS)
o

h...
Upcoming SlideShare
Loading in …5
×

Gestión Integral de Usuarios en Drupal

1,594 views

Published on

Proyecto Fin de Carrera

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,594
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Gestión Integral de Usuarios en Drupal

  1. 1. ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA INGENIERÍA TÉCNICA DE INFORMÁTICA DE GESTIÓN GESTIÓN INTEGRAL DE USUARIOS EN DRUPAL Realizado por ERNESTO ALGAR VALERO 52696992J Dirigido por ANTONIO RUIZ CORTÉS Departamento LENGUAJE Y SISTEMAS INFORMÁTICOS Sevilla, Agosto de 2013
  2. 2. Índice de contenidos 1.Introducción......................................................................................7 1.1.Contexto del proyecto.................................................................7 1.2.Objetivos.....................................................................................9 1.3.Justificación..............................................................................10 1.4.Propuesta detallada..................................................................10 1.4.1.Introducción.....................................................................10 1.4.2.Participantes en el Proyecto............................................10 2.Metodologías de Desarrollo............................................................11 2.1.Scrum........................................................................................11 3.Planificación temporal y evaluación de costes...............................13 3.1.Planificación temporal..............................................................13 3.2.Evaluación de Costes................................................................16 4.Elicitación de requisitos.................................................................18 4.1.Introducción..............................................................................18 4.2.Participantes del proyecto........................................................18 4.3.Descripción del sistema actual.................................................20 4.3.1.OpenLDAP.......................................................................20 4.3.2.“Single Sign On”: CAS.....................................................27 4.4.Objetivos del sistema................................................................28 4.4.1.Gestión de Usuarios.........................................................30 4.4.2.Gestión de Roles..............................................................39 4.4.3.Consideraciones adicionales............................................42 5.Diseño del Sistema.........................................................................44 5.1.Introducción..............................................................................44 5.2.Arquitectura de Drupal.............................................................44 5.2.1.Módulos...........................................................................45 5.2.2.Drupal y MVC..................................................................46 6.Diseño de datos...............................................................................48 6.1.Diagrama Entidad - Relación del Sistema................................48 6.2.Entidades del Modelo de Datos................................................50 6.3.Relaciones del Modelo de Datos...............................................52 2
  3. 3. 7.Codificación....................................................................................53 7.1.Entorno de programación y Herramientas...............................53 7.2.Lenguajes de programación.....................................................54 7.3.Otros aspectos relevantes de la implementación.....................57 8.Conclusiones...................................................................................63 9.Glosario de términos.......................................................................65 10.Referencias...................................................................................66 11.Bibliografía...................................................................................68 3
  4. 4. Índice de Tablas Planificación_del_proyecto......................................................................................15 Costes_de_software................................................................................................. 17 Presupuesto_del_proyecto.......................................................................................17 Participante_del_proyecto:Ernesto_Algar_Valero...................................................18 Participante_del_proyecto:Antonio_Ruíz_Cortes.....................................................19 Organización_LSI.................................................................................................... 19 Objetivos_del_sistema.............................................................................................29 Gestión_de_Usuarios:Atributos...............................................................................30 Gestión_de_Usuarios:Campos.................................................................................31 Gestión_de_Usuarios:Aplicaciones..........................................................................31 CRUD_de_Usuarios:Nuevo_Usuario........................................................................33 Modelo_de_Datos:GIU_USERS................................................................................50 Modelo_de_Datos:GIU_PROFILES..........................................................................50 Modelo_de_Datos:GIU_USERS_PROFILES.............................................................50 Modelo_de_Datos:GIU_ENVIRONMENT_PROFILES..............................................51 Relaciones_del_modelo_de_datos_1........................................................................52 Relaciones_del_modelo_de_datos_2........................................................................52 Relaciones_del_modelo_de_datos_3........................................................................52 Herramientas_usadas.............................................................................................. 54 4
  5. 5. Índice de Figuras Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura 1.1 – Activación del módulo.........................................................................10 4.1 – Estructura de OpenLDAP....................................................................23 4.2 – configuración OpenLDAP en Drupal (Server settings)........................24 4.3 – configuración OpenLDAP en Drupal (Login procedure).....................25 4.4 – configuración OpenLDAP en Drupal (Advanced configuration)..........26 4.5 – Esquema de autenticación con SSO-CAS............................................27 4.6 – Listado de usuarios.............................................................................32 4.7 – Ficha de alta de un nuevo usuario......................................................35 4.8 – Detalle de usuario...............................................................................37 4.9 – Borrado de usuarios............................................................................38 4.10 – Detalle de perfil................................................................................40 5.1 - Esquema de la arquitectura de Drupal...............................................44 5.2 - Inversion of Control............................................................................45 5.3 – Estructura de módulos........................................................................46 5.4 - MVC..................................................................................................... 47 5.5 - Patrón arquitectónico MVC................................................................47 6.1 - Diagrama entidad-relación..................................................................49 7.1 - Entornos.............................................................................................. 53 6.2 – database.config.php............................................................................57 5
  6. 6. 6
  7. 7. 1. Introducción 1.1. Contexto del proyecto Drupal es un sistema de administración de contenidos Web especialmente versátil. En sus orígenes el sistema estaba dirigido a dar soporte a una comunidad de Weblog. Su desarrollo fue iniciado en 2009 por Dries Buytaert en 1999 y no fue hasta 2001 cuando se publico la primera versión del CMS. Hasta el lanzamiento de la versión 4.0.0, Drupal publicaba una versión anualmente, tras ésta, el lanzamiento de cada nueva versión base, se ha ralentizado a una cada 2 o 3 años, publicando entre 10 y 20 versiones menores sobre cada una de las versiones base. Actualmente Drupal se encuentra en la versión 7.23. Drupal no está dirigido a un tipo de escenarios específico. El límite de este CMS lo impone el desarrollador; al igual que ocurre con muchos otros CMS, es necesario disponer de un buen conocimiento y experiencia en dicha solución para sacarle el máximo partido. Son muchas las características que sitúan a Drupal entre los CMS más destacados del mercado:  Dispone de un entorno de personalización robusto, tanto el contenido como la presentación pueden ser tratados de forma individual de acuerdo a unas preferencias definidas por el usuario. La gestión de contenido se realiza como objetos independientes, de forma que puede realizarse un tratamiento individualizado de la información, facilitando su inclusión en cualquier página o permitiendo comentarios específicos sobre cada uno de ellos. 7
  8. 8.  Los mecanismos de actualización de contenidos son realmente sencillos, permite editar la mayor parte de los contenidos tanto desde el frontend como desde el backend.  Ofrece la posibilidad de gestionar las taxonomías y la estructuración de contenidos de forma personalizable, algo indispensable para sitios de complejidad media-alta.  Desde el punto de vista de la seguridad, la gestión de permisos destacaba por encima de cualquier otra característica; ofrece un sistema muy avanzado y completamente personalizable a nivel de rol y páginas.  El rendimiento y la escalabilidad son otras de sus señas de identidad: sistema de cache avanzado, replicación de base de datos, balanceo de cargo, mecanismos de control de congestión configurable para habilitar o deshabilitar módulos, etc.  La comunidad de desarrolladores es otro de los puntos fuertes de Drupal, ofreciendo un desarrollo dinámico y un soporte amplio basado en foros Web.  Dispone de agrupadas cientos según Administración, de extensiones, funcionalidad Controlo de en Acceso, estás se encuentran distintas categorías: Eventos, Comercio, Comunidad, Contenidos, Gestión de usuarios, Búsquedas, etc. Con respecto a las características más técnicas, cabe mencionar que Drupal se encuentra liberado bajo licencia GPL y utiliza PHP como lenguaje de programación, MySQL como motor de base de datos, aunque también puede funcionar con PostgreSQL o SQLite, y Apache o Microsoft IIS como servidor Web. Con Drupal es posible desarrollar cualquier tipo de portal o aplicación web. Además de las funcionalidades básicas que vienen 8
  9. 9. integradas en el software, es posible añadir nuevas funcionalidades a través de módulos. Los módulos son aplicaciones adicionales desarrolladas por miembros de la Comunidad de Drupal, que se distribuyen libremente bajo la misma licencia GPL. Cualquier persona puede crear un nuevo módulo o modificar uno existente. 1.2. Objetivos Nos encontramos con un conjunto de aplicaciones, que a la hora de registrarse en cada una de estas, se tienen que hacer de forma independiente, esto es, que se tiene que dar de alta a un mismo usuario en todas las aplicaciones de forma individual. El objetivo de este proyecto es presentar al administrador que gestiona todas las aplicaciones, un sistema de gestión de usuarios centralizado, donde pueda gestionar toda la logística de los permisos y roles de las diferentes aplicaciones. La idea es que con el alta de un usuario, este pueda acceder a todas las aplicaciones con ese mismo usuario, sin tener que darse de alta en todas, o lo que es lo mismo, realizar un “Single Sign On” para acceder a cada una de la aplicaciones que integremos. Para llevar a cabo esta tarea se va a desarrollar un módulo en Drupal, donde se va a implementar toda la funcionalidad de integración. Figura 1.1 – Activación del módulo 9
  10. 10. 1.3. Justificación La tarea de desarrollar este módulo en Drupal parte de la idea de poder facilitar el trabajo al encargado de administrar el conjunto de las aplicaciones. Con esta herramienta se pretende que no se tenga que dar de alta a un usuario en todas las aplicaciones de forma individual, sino que cuando se realice en registro de un usuario, se pueda dar de alta en todas. 1.4. Propuesta detallada GESTIÓN INTEGRAL DE USUARIOS EN DRUPAL 1.4.1. Introducción El proyecto a realizar consiste en desarrollar un módulo que se integre en el CMS Drupal y que permita tener una zona de administración de usuarios única donde se integren las demás aplicaciones que dependen de él. 1.4.2. Participantes en el Proyecto Los participantes en este proyecto fin de carrera son: Ernesto Algar Valero alumno de Ingeniería Técnico de Informática de Gestión por la Escuela Técnica Superior de Ingeniería Informática de la Universidad de Sevilla, el cual realizará el desarrollo completo del módulo. Antonio Ruíz Cortes profesor titular del Departamento de Lenguajes y Sistemas Informáticos por la Universidad de Sevilla, encargado de la supervisión y control de desarrollo completo del sistema. 10
  11. 11. 2.Metodologías de Desarrollo Las Metodologías de Desarrollo de Software surgen ante la necesidad de utilizar una serie de procedimientos, técnicas, herramientas y soporte documental a la hora de desarrollar un producto software. Dichas metodologías pretenden guiar a los desarrolladores al crear un nuevo software, pero los requisitos de un software a otro son tan variados y cambiantes, que ha dado lugar a que exista una gran variedad de metodologías para la creación del software. Se podrían clasificar en dos grandes grupos: • Las metodologías orientadas al control de los procesos, estableciendo rigurosamente las actividades a desarrollar, herramientas a utilizar y notaciones que se usarán. Estas metodologías son llamadas Metodologías Pesadas. • Las metodologías orientadas a la interactuacción con el cliente y el desarrollo incremental del software, mostrando versiones parcialmente funcionales del software al cliente en intervalos cortos de tiempo, para que pueda evaluar y sugerir cambios en el producto según se va desarrollando. Estas son llamadas Metodologías ligeras/ágiles. 2.1. Scrum La metodología ágil surge en entornos donde las definiciones de productos o servicios cambian con relativa facilidad y la obsolescencia de las tecnologías utilizadas es relativamente rápida. Esto da lugar a que decisiones tomadas durante la planificación inicial de un proyecto sean interesantes modificarlas con la menor trascendencia posible en el proyecto. 11
  12. 12. Scrum es un marco de referencia para generar una metodología ágil. Es un marco que surgió de la experiencia y se mantiene activo y evolucionando. El principal objetivo de Scrum es llevar los proyectos a su realización final cuando están envueltos en entornos cambiantes, como es el mundo del software y especialmente el entorno web. A diferencia de la metodología ágil, Scrum concretiza los pasos a seguir para alcanzar los objetivos propuestos. La metodología de Scrum se sustenta sobre 3 principios: transparencia, inspección y adaptación. Los tres principios de esta metodología tienen la misma importancia. Transparencia hace referencia a que todos los agentes implicados deben estar al corriente de los cambios, contratiempos o impedimentos que surjan. La inspección quedará cubierta por medio de las reuniones y trabajos en equipo que plantea la metodología, para detectar las desviaciones con la mayor brevedad posible. Adaptación es uno de los principios básicos de la metodología ágil y uno de los objetivos por los que se aplica Scrum. Consiste en introducir los cambios que puedan surgir con la menor implicación a los objetivos del proyecto [1-6]. Como se ha llevado a cabo en el proyecto Para el desarrollo de este proyecto se detectó que se necesitaba una metodología ágil que permitiera introducir cambios en el proyecto. Esto era debido a que las especificaciones no eran totalmente cerradas y en la medida que avanzara el proyecto podía ser interesante priorizar tareas o incluso redefinirlas. 12
  13. 13. 3.Planificación temporal y evaluación de costes Para que un proyecto sea exitoso, es importante cumplir los plazos acordados con antelación y no sobrepasar los costes estimados. Para ello una buena planificación temporal y de costes es de suma importancia. 3.1. Planificación temporal Es una actividad que el gestor realiza distribuyendo el esfuerzo estimado a lo largo de la duración prevista del proyecto, asignando el esfuerzo a las tareas específicas de la ingeniería del software. Debemos tener en cuenta varios aspectos fundamentales:  Personal integrante del proyecto, es importante conocer las cualidades y conocimientos de los participantes para delegar en ellos las tareas que más se adapten a cada persona.  Producto, hay que tener claro el producto a desarrollar antes de iniciar la planificación, determinar los objetivos, identificar dificultades técnicas y de gestión, de lo contrario, no sabremos estimar el tiempo de desarrollo.  Proceso, una vez conocido el producto y sus dificultades, es esencial crear un diagrama de dependencias entre las actividades y las tareas que componen cada una de ellas.  Proyecto, no es menos importante identificar los factores de riesgo, con el fin de poder dirigirlos y controlarlos. Una vez explicados los puntos a tener en cuenta en la planificación, procederemos a definir los tiempos estimados en cada labor. 13
  14. 14. Por tanto, dividimos el ciclo de vida del proyecto en una serie de tareas a las cuales se les asignará las dos estimaciones siguientes: Tiempo estimado empleadas en los inicios del desarrollo. Son las menos exactas, pero se emplean como primera aproximación a la viabilidad del proyecto. Tiempo real expresan la duración y el esfuerzo real empleado, cuyos valores se compararán para evaluar la exactitud de la estimación, empleando el Error Relativo de la estimación, RE. Considerando que el proyecto académico consta de 9 créditos y cada cual son 30 horas lectivas por crédito, hacen un total de 270 horas. Por tanto, el reparto de tareas es: 14
  15. 15. Tarea Tiempo estimado Tiempo real RE Búsqueda documentación 8h 13h 38.5% Introducción 15h 10h -50% Planificación temporal 2h 1h -100% Evaluación de costes 3h 2h -50% Elicitación de requisitos 18h 28h 35.7% Análisis del sistema 18h 33h 45.4% Diseño del sistema 20h 25h 20% Codificación 171h 231h 26% Pruebas 8h 8h 0% Manual de Usuario 7h 9h 22.2% TOTAL 270h 360h 25% Tabla 3.1 - Planificación del proyecto La desviación viene provocada por el número de aplicaciones que se quieren controlar desde la gestión de usuarios, se tienen que crear las clases especificas para poder realizar la integración con el módulo a crear y que no haya conflictos entre ellas. 15
  16. 16. 3.2. Evaluación de Costes Para la evaluación de costes, tendremos en cuenta los diferentes puntos a valorar:  Coste de personal, corresponderá al total de horas empleadas por los distintos integrantes del proyecto.  Coste social, es el gasto asociado a la Seguridad Social a cargo de la empresa. Este gasto tiene un porcentaje que oscila entre el 31% al 35% del salario bruto anual.  Coste de hardware, contemplará el precio del equipo usado durante la realización de la aplicación.  Coste de software, valor del conjunto de programas necesarios. Coste de personal, teniendo en cuenta que el salario anual de un técnico medio no doctorado es 15.640,30 €, y que al año se trabajan una media de 50 semanas con 5 días laborables y 8 horas cada jornada, obtenemos que el precio/ hora es 7,82 €. Con este valor, y dado que el número de horas a dedicar en este proyecto académico es 270, llegamos a un total para este apartado de 2.111,4 €. Coste social, como vemos, si el trabajador tiene un salario bruto de 2.111,4 €, la seguridad social que se tiene que pagar por este trabajador oscila entre 654 € a 739 € todos los meses. Coste hardware, aquí incluimos el precio de un ordenador portátil. Dado que el precio del portátil es de 800€ con un coste de amortización de 4años, y suponiendo una duración de proyecto de 4 meses, obtenemos un total de: 16
  17. 17. 800 x 4 / (4 x 12) = 55,67 € Costes software, utilizaremos los siguientes programas: Eclipse Helios 0,00 € Microsoft Office 381,98 € Apache incluido en XAMPP 0,00 € MYSQL 0,00 € Total 381,98 € Tabla 3.2 - Costes de software Al que aplicamos el mismo coste de amortización que para el hardware obtenemos: 381,98 x 4 / (4 x 12) = 31,83 € Presupuesto Concepto Precio Personal 1.759,5 €. Hardware 55,67 € Software 31,83 € Total 1847 € Tabla 3.3 - Presupuesto del proyecto 17
  18. 18. 4.Elicitación de requisitos 4.1. Introducción En este apartado se ofrecerá una visión detallada del módulo que se va a crear. Por ello primeramente describiremos la plataforma en la actualidad. Luego los objetivos que queremos conseguir, y seguidamente los requisitos del sistema, tanto de información, como funcionales (casos de uso) como no funcionales. Por último, presentaremos las matrices de rastreabilidad dividida en subsistemas y presentaremos un glosario de términos. 4.2. Participantes del proyecto Participante Ernesto Algar Valero Organización Freelance Rol Desarrollador Es desarrollador Sí Es cliente No Es usuario No Comentarios Autor del proyecto Tabla 4.1 - Participante del proyecto: Ernesto Algar Valero 18
  19. 19. Participante Antonio Ruíz Cortes Organización Freelance Rol Tutor Es desarrollador No Es cliente No Es usuario No Comentarios Tutor del proyecto Tabla 4.2 - Participante del proyecto: Antonio Ruíz Cortes Organización Departamento de Lenguajes y Sistemas Informáticos Dirección Av/Reina Mercedes s/n CP: 41012 (Sevilla) Teléfono 954555964 Fax 954557139 Comentarios Departamento de Lenguajes y Sistemas Informáticos – L4 Correo: buzon@lsi.us.es Web: www.lsi.us.es Tabla 4.3 - Organización LSI (Departamento de Lenguajes y Sistemas Informáticos) 19
  20. 20. 4.3. Descripción del sistema actual Actualmente la gestión de usuarios está diseñada por medio de un directorio LDAP y un “Single Sign On". Para ayudar en la tarea de la gestión de los usuarios y grupos de ellos se define el uso de OpenLDAP como directorio en red. El uso de esta herramienta no solo aporta una mayor flexibilidad en la gestión de usuarios, sino también un sistema independiente y estándar para compartirlos con otras aplicaciones y servicios. OpenLdap es una implementación del servidor LDAP de código abierto. Un servidor de LDAP ofrece un servicio de directorio en red. Este tipo de servicio es de interés para usos como una guía de contactos, guía telefónica, directorio de correo electrónico, servidor de dns o autenticación de usuarios. Finalmente, se añade un servicio de “Single Sign On” que aporta valor añadido y comodidad de uso. Es altamente valorado por los usuarios puesto que permite unificar la tarea de autenticación para todos los servicios web sobre los que se tenga el control. De esta forma, no es necesario introducir usuario y contraseña constantemente. 4.3.1. OpenLDAP OpenLdap es una implementación del servidor LDAP de código abierto. Un servidor de LDAP ofrece un servicio de directorio en red. Este tipo de servicio es de interés para usos como una guía de contactos, guía telefónica, directorio de correo electrónico, servidor de dns o autenticación de usuarios. Las características que destacan en un servidor LDAP son: la alta velocidad en lectura de datos y la baja velocidad en escritura y modificación. Estas características hacen que este tipo de servidor 20
  21. 21. sea interesante para almacenar información relativamente estática, pero de muchas lecturas. El protocolo que utiliza el servidor LDAP está orientado a trabajar en red y presenta características de entorno distribuido, que facilita la replicación de la información a múltiples servidores al mismo tiempo, es decir, que se pueden actualizar los datos en diversos servidores LDAP al mismo tiempo. LDAP se organiza por medio de una estructura jerárquica orientada a representar y contener objetos y elementos. Este tipo de organización representa de forma adecuada, un gran número de relaciones existentes en la realidad. Esta organización acompañada de los atributos multivalor que describen los objetos, dan unas propiedades adecuadas a LDAP para describir relaciones reales. Con la información expuesta, puede parecer que LDAP no es más que una base de datos pero, su protocolo orientado a funciones de directorio en red y su optimización para lectura unido a la estructura jerárquica, hacen de este sistema, uno de los mas instalados para la gestión de usuarios y agendas de contactos, a la vez que, la convierte en poco eficiente para almacenar otros tipos de datos. Esta estructura jerárquica aumenta notablemente los tiempos de escritura pero, facilita la lectura. Por ese motivo, los datos que se guardan en este tipo de servidor son información que se consulta un gran número de veces pero, se escribe poco. Otra virtud que presenta LDAP es que, para temáticas como la gestión de usuarios, incorpora un mecanismo de autenticación para el cliente que quiere acceder a la información contenida en el servidor LDAP. De esta forma se limita el acceso a los datos que contiene. Un directorio LDAP se compone de un árbol ordenado de entradas pudiendo representar algunas dependencias entre ellos a nivel conceptual. Las entradas del árbol constan de un nombre que 21
  22. 22. los identifica de forma única y una serie de atributos. Los atributos están formados por un nombre que ejerce de llave y uno o varios valores para ese atributo. Los atributos que aplican a cada entrada dependen del esquema que se aplique. Cada entrada del árbol queda definida por un esquema que indica los atributos que esta entrada debe o puede tener, según si son atributos obligatorios o opcionales. Por último, se tiene que recordar que en los directorios LDAP la posición de la entrada en el árbol, seguido del nombre de la entrada, es el “Distinguished Name”, que se utiliza como identificador único de la entrada y no pueden existir 2 iguales [13]. Herramienta para gestionar LDAP En nuestro caso se ha probado JXplorer [14], que está desarrollada en java y permite la conexión con LDAP indicándole el puerto al que acceder. • Esquema OpenLDAP para Drupal En este proyecto se ha desarrollado un esquema para OpenLDAP basándonos en el uso de LDAP como directorio de usuarios y principalmente en su conexión con Drupal. Se ha trabajado primero con los conceptos que emplea Drupal en la gestión de usuarios, para poder definir una buena estructura en LDAP. Dentro del esquema de LDAP, se van a almacenar los usuarios, para que desde Drupal se pueda gestionar con comodidad la adhesión a otras aplicaciones de los usuarios. El esquema empleado muestra la rama de los usuarios existes en un listado. Los atributos que los definen vienen determinados por los esquemas básicos “top, person, inetOrgPerson”. 22
  23. 23. Figura 4.1 – Estructura de OpenLDAP • La Conexión OpenLDAP con Drupal conexión de OpenLDAP con Drupal se realiza completamente por medio de la interfaz gráfica de Drupal. El administrador del portal debe ir a la zona de administración y dentro de Configuración del sitio, seleccionar la modalidad LDAP. Una vez dentro, se deben configurar los parámetros como corresponda para el servidor LDAP que se va a utilizar, en este caso OpenLDAP. Se debe indicar la máquina y puerto de OpenLDAP, y entregar un usuario con permisos suficientes para poder modificar la rama del árbol donde se almacenan los usuarios de Drupal. 23
  24. 24. Figura 4.2 – configuración OpenLDAP en Drupal (Server settings) 24
  25. 25. Figura 4.3 – configuración OpenLDAP en Drupal (Login procedure) 25
  26. 26. Figura 4.4 – configuración OpenLDAP en Drupal (Advanced configuration) Una vez realizado el proceso, ya se puede comprobar si ha funcionado, intentando acceder con un usuario de OpenLDAP que no exista en Drupal. Los usuarios de Drupal se iran exportando a OpenLDAP en la medida que vayan accediendo al portal. ¿Quien autentica los usuarios? En este escenario los usuarios siguen siendo autenticados y gestionados por Drupal. La única diferencia de la del uso normal es que Drupal no consulta sus bases de datos para determinar los usuarios y su contraseña, sino que emplea OpenLDAP para este fin. La ventaja que esto representa, es poder compartir los usuarios de Drupal con otras aplicaciones. 26
  27. 27. 4.3.2. “Single Sign On”: CAS Un “Single Sign On” es un proceso de autenticación unificado, que permite al usuario introducir una única vez el nombre de usuario y contraseña para acceder a varias aplicaciones. El proceso de “Single Sign On” autentifica una vez al usuario para esa sesión, y le dará acceso a todas aquellas aplicaciones donde tenga permisos para acceder, eliminando la tarea de introducir usuario y contraseña cada vez que cambia de aplicación durante la misma sesión [7] [8]. La autenticación del “Single Sign On” para entornos web se realiza por medio de tiquets, que son almacenados en el servidor SSO y en una cookie en el navegador del cliente. Al acceder el usuario a las aplicaciones, estas consultan con el servidor de SSO para verificar que coincide el tiquet almacenado en el servidor SSO con el proporcionado por el navegador en la cookie. Figura 4.5 – Esquema de autenticación con SSO-CAS [8] 27
  28. 28. CAS CAS (Central Authentication Service) es una aplicación java desarrollada por la universidad de Yale que se compone de un servidor de autenticación que implementa el SSO, y de un cliente de autenticación, que actualmente tiene desarrollado conectores para varios lenguajes de programación como son java, php, .NET y perl. Por seguridad, el servidor CAS debe ser accedido por medio de protocolo de capa segura SSL (https), que es el utilizado en entornos web para enviar la información cifrada entre el navegador del cliente y el servidor web. 4.4. Objetivos del sistema Se pretende con la solución propuesta por un lado:  La información está distribuida en cada una de las herramientas. No tener datos propios en la herramienta para evitar problemas de sincronización de datos.  Permitir la escalabilidad de la gestión de usuarios en la aplicación, al añadir nuevas herramientas a la misma.  Preservar la integridad de los datos de usuarios a lo largo de toda la aplicación. La idea es que la Gestión Integral de Usuarios, haga los mantenimientos correspondientes en cada una de las herramientas de forma lo más transparente posible al usuario. La gestión de usuario parte de una información mínima, y añade nuevos atributos en función de los que requiera cada nueva herramienta. Cada nueva herramienta debe proporcionar el listado de atributos que puede manejar y los que necesita para considerar un nuevo usuario. 28
  29. 29. Esta información se carga al inicio de la aplicación de Gestión de Usuarios. Se añaden nuevos atributos consultando a cada herramienta. La gestión de roles, se delega igualmente en cada herramienta, de modo que cada una proporciona el formulario de roles y ámbitos definidos en la misma, así como los que tiene un usuario asignados. Si en una herramienta, no existe el concepto de ámbito, no se mostrará nada como ámbito. Si existen modificadores al ámbito (como la recursividad) lo podrá gestionar adecuadamente el formulario de cada herramienta. Si una herramienta no devuelve ningún rol, no se mostrará su zona de asignación en el formulario (por ejemplo, para el caso del LDAP). Formulario de Edición de Usuario Identificador Atributo 1 Atributo 2 … Botones de Guardar - Borrar App1 App2 App3 Formulario de edición de Roles de App1 29
  30. 30. 4.4.1. Gestión de Usuarios Un usuario en la Gestión Centralizada de Usuarios constará de un identificador único de usuario, que se identifica con el login de usuario que devolverá CAS, y un listado de atributos.  Identificador  Atributos Los atributos dependerán del número de aplicaciones que queramos gestionar, de modo que para cada sistema existirán una serie de atributos, cada uno de los cuales podrá ser obligatorio o no y de un tipo determinado. Los atributos tendrán una etiqueta con la que se identificarán, y para cada aplicación puede tener diferentes nombres. De modo que el atributo con etiqueta “correo electrónico”, tendrá su representación en la aplicación GLPI en el campo email, y en la aplicación Drupal en el campo email. Para mostrar la información de un usuario, los atributos tendrán además un atributo de peso que determinará el orden en que se muestran los mismos. Attributes Descripción label Etiqueta que se mostrará en el formulario de CRUD de Usuarios. weight Orden en que se mostrará el campo en el formulario de CRUD de Usuarios 30
  31. 31. Fields Descripción app Identificador de la aplicación a integrar label Campo de usuario al que se corresponde. field_name Nombre del campo en la aplicación field_widht Ancho del campo en la aplicación mandatory Obligatorio o no El CRUD de usuarios tomará la información de la aplicación predeterminada (de peso menor), y mostrará el resto de información de las demás aplicaciones. No existe información de usuarios local al módulo de Gestión de Usuarios, sino que se toma de las aplicaciones integradas. La única información de la que dispone el módulo es de la de configuración y acceso a las diferentes aplicaciones. Applications Descripción app Acrónimo de la aplicación app_name Nombre de la aplicación app_desc Descripción de la aplicación weight Prioridad de la aplicación 31
  32. 32. CRUD de Usuarios: Listado de Usuarios El listado de usuarios toma la información de la lectura de usuarios de la función ListUsers de la aplicación predeterminada. Esta función devuelve un listado de identificador y atributos, que el formulario de listado formateará para darle el estilo adecuado. Cada entrada de usuario incluirá, para los usuarios con privilegios para ello, una opción de acceso al formulario de edición de ese usuario. El formulario de listado de usuarios incluye, para los usuarios con privilegios para ello, una opción de “nuevo usuario” que da acceso al formulario de edición de usuario sin parámetro de usuario. Figura 4.6 – Listado de usuarios 32
  33. 33. CRUD de Usuarios: Nuevo Usuario El formulario de nuevo usuario, muestra una sección de información con la información propia del usuario. Cada campo del formulario se obtiene de recorrer los atributos en orden de menor a mayor peso y montándolos dinámicamente con el ancho de campo más restrictivo (el menor) de las aplicaciones a las que corresponda. Por ejemplo: Dos aplicaciones: LDAP (peso 1) y GLPI (peso 2). Dos Atributos: Nombre (peso 1) y Correo Electrónico (peso 2) Campos: app label field_name field_width mandatory LDAP Nombre givenname 40 Y GLPI Nombre firstname 60 N GLPI Correo email 80 N Electrónico 33
  34. 34. Mostraría un formulario con 3 entradas:  Identificador. Siempre se mostrará en primera posición. En edición siempre será de sólo lectura.  Nombre: de ancho 40 (el más restrictivo) y además será obligatorio.  Correo electrónico: de ancho 60 (el más restrictivo) y además será opcional, ya que ninguna aplicación lo considera obligatorio. Una vez rellenos los campos obligatorios, y aceptada la creación del usuario, se produce una validación de campos. Como paso previo a guardar los datos se hará una llamada a todas las funciones de getAttributeValidation de cada Label, que a su vez hará una llamada a getFieldValidation de cada aplicación. Si alguna de estas da errror de validación, se vuelve al formulario de edición de usuario con un mensaje de advertencia destacado que corresponda en cada caso al error de validación cometido. Finalmente, la creación del usuario se realiza en cada aplicación mediante la correspondiente llamada a la función CreateUser con los atributos necesarios para cada una de ellas. 34
  35. 35. Figura 4.7 – Ficha de alta de un nuevo usuario 35
  36. 36. CRUD de Usuarios: Edición de Usuario El formulario de edición de usuario, muestra una sección de información con la propia del usuario, y otra con la de los roles por cada aplicación (que se especifica más adelante). El formulario se monta de forma dinámica tal y como se describe en el anterior apartado, pero tomando los datos de cada campo del formulario de la aplicación de mayor peso. De modo que para el ejemplo anterior, en cada caso se llamaría a la función getLabelValue para cada label, y en cada caso se haría la correspondiente llamada al de la aplicación correspondiente. getAttributeValue(“Nombre”) devolvería el valor de getFieldValue(“LDAP”, “givenname”), al tener la aplicación APP más peso que GLPI, y getAttributeValue(“Correo electrónico”) devolvería el valor de getFieldValue(“GLPI”, “email”) al no tener ese campo la aplicación LDAP. A la hora de aprobar los cambios realizados en el formulario, como paso previo a guardar los datos se hará una llamada a todas las funciones de getAttributeValidation de cada Label, que a su vez hará una llamada a getFieldValidation de cada aplicación. Si alguna de estas da errror de validación, se vuelve al formulario de edición de usuario con un mensaje de advertencia destacado que corresponda en cada caso al error de validación cometido. Una vez comprobadas todas las validaciones, se realizará la actualización de cada uno setAttributeValue(attribute,value), de que los atributos, hará las mediante respectivas setFieldValue(field,value) de cada una de las aplicaciones. 36
  37. 37. Figura 4.8 – Detalle de usuario 37
  38. 38. CRUD de Usuarios: Edición de Usuario (no existe) Cuando se edita un usuario que no existe en una determinada herramienta (se puede dar el caso por diversas situaciones), se debe dar de alta el nuevo usuario en la herramienta de forma automática. Si para la herramienta hay campos obligatorios sin valor, se mostrará el mensaje correspondiente y se procederá como si de un usuario nuevo se tratara (para esa herramienta). El formulario no permitiría guardar cambios hasta que la información obligatoria fuera completamente rellena. CRUD de Usuarios: Borrado de Usuario Además, el formulario de edición de usuario incluirá, para los usuarios autorizados, un check para el borrado de los mismos que realizará la llamada a los respectivos deleteUser de cada aplicación, previa confirmación. Figura 4.9 – Borrado de usuarios 38
  39. 39. 4.4.2. Gestión de Roles Los roles de cada usuario se mostrarán divididos (en pestañas o en secciones del formulario) según cada aplicación. La actualización de roles se producirá por aplicación, de modo que cada aplicación montará su propio formulario de gestión de roles. Si una aplicación no devuelve ningún rol en su petición de roles, no tendrá sección en el formulario. En general, el formulario de asignación de roles se compondrá usando tres funciones, una que devuelva los roles disponibles de la herramienta, otra que devuelva los ámbitos, y una última que devuelva las asignaciones de rol y ámbito que ya tiene el usuario. Si la gestión de roles no se ajusta a este sistema (por incluir más características), usará una función que devuelva un formulario propio. 39
  40. 40. Figura 4.10 – Detalle de perfil 40
  41. 41. Gestión de Roles en Drupal Drupal no tiene ámbitos como tales, y tampoco tiene modificadores de ámbito. El formulario de Drupal se realizaría con el mantenimiento genérico. Gestión de Roles en GLPI GLPI tiene ámbitos, que se identifican con las Entidades. También tiene un modificador que es el de la recursividad, así que lo apropiado sería que devolviera su propio formulario de gestión de roles. Gestión de Roles en Alfresco Alfresco tiene ámbitos, que se identifican con los espacios. También tiene un modificador que es el de la recursividad, así que lo apropiado sería que devolviera su propio formulario de gestión de roles. Gestión de Roles en dotProject dotProject no tiene ámbitos como tales, y tampoco tiene modificadores de ámbito. El formulario de dotProject se realizaría con el mantenimiento genérico. Gestión de Roles en Moodle Moodle tiene ámbitos, que se identifican con los cursos. El formulario de Moodle se realizará con el mantenimiento genérico. 41
  42. 42. 4.4.3. Consideraciones adicionales Para preservar la integridad de los datos, lo adecuado sería que la administración de usuarios de cada herramienta estuviera reservada únicamente para los usuarios de perfil super- administrador, o directamente anulada. Como esto no será posible en todas las circunstancias, por eliminar funcionalidades deseadas, siempre habrá que contemplar la prioridad de la propia herramienta de Gestión Integral de Usuarios sobre las demás, y que los datos que prevalecerán siempre serán los de las herramientas configuradas como tal. Una posible configuración sería con LDAP, DRUPAL, GLPI y Alfresco, configurados en la herramienta de Gestión Integral de Usuarios, en la que un usuario con privilegios modificara una información directamente en la aplicación de GLPI. Cuando se cargara el formulario de edición de datos, los atributos coincidentes entre las herramientas LDAP, DRUPAL y GLPI, siempre prevalecerían los de las dos primeras sobre la última. Por cada Aplicación:  listUsers  getAttributes  createUser  deleteUser  getFieldValue  getFieldValidation  setFieldValue 42
  43. 43.  getRoles  getScopes  grantRole  revokeRole Para la Gestión de Usuarios:  listUsers  getAttributes  getApps  createUser  deleteUser  getAttributeValue  getAttributeValidation  setAttributeValue  showRoleForm 43
  44. 44. 5.Diseño del Sistema 5.1. Introducción En el presente apartado de la documentación se describe el diseño que se ha realizado de los módulos del sistema, así como la arquitectura que el sistema de gestión de contenidos Drupal proporciona. 5.2. Arquitectura de Drupal Drupal es un Sistema de Gestión de Contenidos (CMS) cuya lógica está programada en PHP, siguiendo un modelo de programación estructurada, y que hace uso de un sistema de bases de datos relacional. Figura 5.1 - Esquema de la arquitectura de Drupal [9] El código que constituye el núcleo de Drupal está formado por un conjunto de librerías que permiten gestionar los procesos de arranque del sistema. Estas librerías ofrecen además un conjunto de servicios que permiten integrar las funcionalidades adicionales de los módulos, servicios como conexión y administración de la base de datos, gestión de procesos de mailing, tratamiento de imágenes, internacionalización, soporte para la codificación y un potente entorno de integración de utilidades. Este último servicio, que 44
  45. 45. explicaremos a continuación, permite ampliar las funcionalidades de un sistema Drupal de una forma relativamente sencilla. Drupal es, por tanto, un sistema con una arquitectura modular que permite ampliar sus funcionalidades a través de unos métodos uniformes de desarrollo e integración de nuevos módulos. En última instancia un módulo consiste en un conjunto de archivos con código PHP, que utiliza la arquitectura y las APIs de Drupal para incorporar nuevas características funcionales al sitio web [9]. 5.2.1. Módulos Drupal proporciona los módulos para extender su funcionalidad. La funcionalidad que proporcionan los módulos puede ser habilitada o deshabilitada a través de la correspondiente página de administración. Drupal consigue proveer esta funcionalidad gracias a la implementación que realiza del patrón de diseño “Inversion of Control”, este patrón de diseño consiste en un cambio en el flujo de ejecución de un programa en el que en vez de especificar el flujo de la información se especifica la respuesta esperada de una operación. Figura 5.2 - Inversion of Control [10] De esta forma los nuevos módulos que se añaden a Drupal se disponen de la siguiente forma dentro del core de Drupal. 45
  46. 46. Figura 5.3 – Estructura de módulos [11] Así mismo Drupal proporciona “themes” que permiten la personalización de la apariencia del sitio web para adaptarlo a la entidad corporativa de la empresa con la que se está trabajando, de esta forma se consigue obtener un portal totalmente adecuado y personalizado a las necesidades del cliente. 5.2.2. El Drupal y MVC modelo-vista-controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página. El modelo es el SGBD y el controlador es el responsable de recibir los eventos de entrada desde la vista. • Modelo: Esta es la representación específica de la información con la cual el sistema opera. La lógica de datos asegura la integridad de estos y permite derivar nuevos datos. 46
  47. 47. • Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario. • Controlador: Este responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista. Figura 5.4 – MVC [12] En Drupal este patrón arquitectónico está implementado de la siguiente forma: Figura 5.5 - Patrón arquitectónico MVC Como se puede observar en la utilización que Drupal hace del patrón arquitectónico MVC no existe interacción entre la vista y el modelo, esto se debe a que dichas interacciones siempre se realizan a través de la lógica de negocio, el controlador. 47
  48. 48. 6.Diseño de datos Pasamos ahora a la elaboración de la capa de persistencia del sistema. Independientemente del SGBD empleado finalmente, necesitamos un Modelo de Datos que represente los aspectos estáticos y dinámicos del Modelo del Dominio de uestro Portal Web. Existen muchos tipos de Modelos de Datos, pero el de más alto nivel y mayor facilidad de comprensión son los modelos conceptuales, con conceptos muy cercanos al Modelo del Dominio (y al modelo de clases obtenido en el análisis). Uno de los modelos de alto nivel más empleados es el denominado Diagrama Entidad - Relación, el cual usaremos para describir nuesta Base de Datos final de una forma más general y expresiva. La razón de utilizar un modelo de tan alto nivel nos permite independizarnos de la implementación final escogida. 6.1. Diagrama Entidad - Relación del Sistema En los diagramas Entidad - Relación, las clases del Modelo del Dominio se convierten en entidades, las cuales se relacionan mediante una serie de asociaciones que definen una serie de información relevante para el sistema. De la información extraida del diagrama de clases del análisis, obtenemos el siguiente esquema conceptual de datos, considerando los siguientes aspectos: 1. Para cada entidad indicaremos la clave primaria (PK) de la tabla final que representará dicha entidad. 48
  49. 49. 2. Para cada relación, la cardinalidad se expresa mediante el esquema X:Y, siendo X e Y la multiplicidad mínima y máxima de cada entidad que participe en la relación. A continuación vemos el diagrama de nuestro sistema: Diagrama entidad-relación Figura 6.1 - Diagrama entidad-relación 49
  50. 50. 6.2. Entidades del Modelo de Datos Las entidades que utilizaremos en nuestro modelo serán las siguientes: GIU_USERS Atributo Tipo Nulo? Predet. PK Autoinc. X Nulo? Predet. PK Autoinc. X id tinyint(4) No name varchar(100) No email varchar(255) FK No Tabla 6.1 - GIU_USERS GIU_PROFILES Atributo Tipo id int(10) No name varchar(255) No description varchar(255) FK Si Tabla 6.2 - GIU_PROFILES GIU_USERS_PROFILES Atributo Tipo Nulo? Predet. PK Autoinc. FK X id int(10) No user_id int(10) No X profile_id int(10) No X Tabla 6.3 - GIU_USERS_PROFILES 50
  51. 51. GIU_ENVIRONMENT_PROFILES Atributo Tipo Nulo? Predet. PK Autoinc. X id int(10) No profile_id int(10) No moodle text No glpi text No Ocs text No dotproject text No alfresco text No drupal text FK No X Cuadro 6.4 – GIU_ENVIRONMENT_PROFILES 51
  52. 52. 6.3. Relaciones del Modelo de Datos Entidades Cardinalidad Descripción giu_users 1:1 Un usuario tiene un sólo perfil giu_users_profiles Tabla 6.5 – Relaciones del modelo de datos Entidades Cardinalidad giu_profiles 1:N giu_users_profiles Descripción Un perfil puede estar asociado a más de un usuario Tabla 6.6 - Relaciones del modelo de datos Entidades Card. giu_profiles 1:1 gui_environment_profiles Descripción Un perfil tiene una sola configuración de permisos Tabla 6.7 - Relaciones del modelo de datos 52
  53. 53. 7.Codificación 7.1. Entorno de programación y Herramientas Drupal está diseñado para funcionar sobre, prácticamente, cualquier entorno independientemente del sistema operativo, servidor web o sistema de gestión de base de datos. Figura 7.1 – Entornos Además Drupal proporciona un framework responsable de proveer las funcionalidades básicas necesarias en las otras partes del sistema, así como de servir de soporte para las nuevas funcionalidades. 53
  54. 54. En nuestro caso haremos uso de las siguientes herramientas: Elemento Tipo Hardware Detalle PC Versión Sony VAIO Sistema Operativo Entorno de desarrollo Ubuntu 12.04 NetBeans 7.3 Apache 2.2.22 extensión PHP mysqli SGBD MySQL 5.5.31 Gestión Web BD phpMyAdmin Servidor Web Software 3.4.10.1deb1 Firefox 21.0 Navegadores Chromium 25.0.1364.16 Tabla 7.1 – Herramientas usadas 7.2. Lenguajes de programación PHP PHP es un lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web dinámicas. Es usado principalmente en interpretación del lado del servidor, pero actualmente puede ser utilizado desde una interfaz de línea de comandos o en la creación de otros tipos de programas incluyendo aplicaciones con interfaz gráfica. PHP es un acrónimo recursivo que significa PHP Hypertext Pre-processor (inicialmente PHP Tools, o, Personal Home Page Tools). Fue creado originalmente por Rasmus Lerdorf en 1994; sin embargo la implementación principal de PHP es producida ahora por The PHP Group y sirve como el estándar de facto para PHP al no haber una especificación formal. Publicado bajo la PHP License, la 54
  55. 55. Free Software Foundation considera esta licencia como software libre. AJAX Ajax, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones. Ajax es una tecnología asíncrona, en el sentido de que los datos adicionales se requieren al servidor y se cargan en segundo plano sin interferir con la visualización ni el comportamiento de la página. JavaScript es el lenguaje interpretado (scripting language) en el que normalmente se efectúan las funciones de llamada de Ajax mientras que el acceso a los datos se realiza mediante XMLHttpRequest, objeto disponible en los navegadores actuales. En cualquier caso, no es necesario que el contenido asíncrono esté formateado en XML.AJAX HTML HTML, siglas de HyperText Markup Language (Lenguaje de Marcado de Hipertexto), es el lenguaje de marcado predominante para la elaboración de páginas web. Es usado para describir la estructura y el contenido en forma de texto, así como para complementar el texto con objetos tales como imágenes. HTML se escribe en forma de "etiquetas", rodeadas por corchetes angulares (<,>). HTML también puede describir, hasta un cierto punto, la 55
  56. 56. apariencia de un documento, y puede incluir un script (por ejemplo Javascript), el cual puede afectar el comportamiento de navegadores web y otros procesadores de HTML. HTML también es usado para referirse al contenido del tipo de MIME text/html o todavía más ampliamente como un término genérico para el HTML, ya sea en forma descendida del XML (como XHTML 1.0 y posteriores) o en forma descendida directamente de SGML (como HTML 4.01 y anteriores). JAVASCRIPT JavaScript es un lenguaje de scripting basado en objetos, utilizado para acceder a objetos en aplicaciones. Principalmente, se utiliza integrado en un navegador web permitiendo el desarrollo de interfaces de usuario mejoradas y páginas web dinámicas. JavaScript es un dialecto de ECMAScript y se caracteriza por ser un lenguaje basado en prototipos, con entrada dinámica y con funciones de primera clase. JavaScript ha tenido influencia de múltiples lenguajes y se diseñó con una sintaxis similar al lenguaje de programación Java, aunque más fácil de utilizar para personas que no programan. Todos los navegadores modernos interpretan el código JavaScript integrado dentro de las páginas web. JavaScript se ejecuta en el agente de usuario, al mismo tiempo que las sentencias van descargándose junto con el código HTML. 56
  57. 57. 7.3. Otros aspectos relevantes de la implementación A continuación mostraremos lo más reseñable de nuestra aplicación. Lo primero que vamos a destacar es la conexión a las aplicaciones, donde todas las acciones que hacemos en el sistema deben crear una conexión. Para ello usaremos esta sentencia por cada una de las aplicaciones que queremos conectarnos: Guardamos la conexión en una variable de Drupal. 57
  58. 58. Lo siguiente que vamos a destacar es la creación del listado de usuarios: 58
  59. 59. ... 59
  60. 60. 60
  61. 61. Con esta función nos traemos los campos que nos interesan de cada aplicación, cada una de las aplicaciones con la que queramos interactuar tiene su propia función init: 61
  62. 62. También tenemos una función que valida los campos para que no haya errores a la hora de trabajar con cada una de las DB de cada aplicación: 62
  63. 63. 8.Conclusiones Una vez finalizado el proyecto, se puede concluir que el módulo para la gestión de usuarios cumplirá con las expectativas, reduciendo el coste que supone dar de alta a un mismo usuario en todas las aplicaciones de forma individual. La solución de integración de las diferentes aplicaciones en un módulo para realizar la gestión en Drupal supone una facilidad para las futuras altas de usuarios por parte del administrador. La gestión de usurios ha sido el tema en este proyecto pero ha quedado bien resuelta con la solución planteada e implementada. Delegar el almacenamiento de los usuarios a un directorio LDAP, facilita notablemente la gestión de estos, ya que este tipo de directorio está muy extendido para este uso. También el uso de un “Single Sign On” como CAS es acertado, por disponer de conectores en casi todos los lenguajes de programación en entorno web existente. Pese a existir alternativas como la autenticación por medio de OpenID o Facebook, creo firmemente que es mucho mejor esta solución al no perder el control de los usuarios en ningún momento, mientras que si se delega a ese tipo de herramientas, se deja de controlar. La filosofía de este proyecto, en que todas las aplicaciones tienen un origen OpenSource, es un modelo que me parece también acertado. No solo por estar imponiéndose y resultar más económico para las empresas, sino por el resultado final de los proyectos. Este proyecto finaliza en un punto donde la plataforma puede ser suficiente para un gran número de empresas. Pero la posibilidad de integrar herramientas más específicas para determinadas 63
  64. 64. funciones, puede resultar del interés de empresas grandes, sobre todo si ya disponen de estas. 64
  65. 65. 9.Glosario de términos Navegador o navegador web: (del inglés, web browser) es un programa que permite visualizar la información que contiene una página web (ya esté está alojada en un servidor dentro de la World Wide Web o en uno local). Base de datos: es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. En la actualidad, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital (electrónico), que ofrece un amplio rango de soluciones al problema de almacenar datos. Login: es el acto de establecimiento o confirmación de algo (o alguien) como auténtico, es decir que reclama hecho por, o sobre la cosa son verdadero. La autenticación de un objeto puede significar (pensar) la confirmación de su procedencia, mientras que la autenticación de una persona a menudo consiste en verificar su identidad. Scrum: Es una metodología de trabajo ágil para la gestión de proyectos. Directorio LDAP: Directorio para almacenar información en red, como usuarios o listín telefónico. Single Sign On: Sistema de autenticación unificado para varias aplicaciones. OpenLDAP: Producto OpenSource que implementa un directorio LDAP. 65
  66. 66. 10. Referencias [1] PALACIO, Juan. Flexibilidad con Scrum. http://www.scribd.com/doc/48689944/Flexibilidad-con-Scrum [2] SCRUM, Org. La guía de Scrum http://www.scrum.org/ [3] ALBALADEJO, Xavier. Que es Scrum? http://wpww.royectosagiles.org/que-es-scrum [4] SCRUMALLIANCE http://www.scrumalliance.org/pages/who_uses_scrum [5] SCRUM, Org. La guía de Scrum http://www.scrum.org/storage/scrumguides/Gua%20sobre %20Scrum.pdf#view=fit [6] SCRUMALLIANCE – What is scrum? http://www.scrumalliance.org/pages/what_is_scrum [7] CAS – Universidad de yale CAS http://www.jasig.org/cas [8] DONNELLY, Brian – CAS https://confluence.ucdavis.edu/confluence/display/IETP/About+CA S [9] Libros Aprende Drupal http://www.forcontu.com/libros-drupal7 [10] http://en.wikipedia.org/wiki/File:Inversion_of_Control.svg [11] koala-soft http://www.koala-soft.com/drupal [12] Programación Cocoa http://luisrey.wordpress.com/2008/01/13/modelo-vistacontrolador/ 66
  67. 67. [13] OPENLDAP http://www.openldap.org/ [14] XPLORER http://jxplorer.org/ 67
  68. 68. 11. Bibliografía • FORCONTU o • http://www.forcontu.es/ Estudio de los sistema de gestión de contenidos web (CMS) o http://www.opencmshispano.com/nav/noticias/noticia_01 05.html • BUTCHER, Matt - Learning Drupal 6 Module Development • TIMOTHY, A Howes - Understanding and Deploying LDAP directory Services • APACHE, httpd – Servidor web apache2 o • PHP5 o • http://httpd.apache.org/ http://www.php.net/ APACHE, tomcat – Servidor Java http://tomcat.apache.org/ • DRUPAL http://drupal.org/ 68

×