Repositorio Institucional de Documentos

Proyecto Final de Carrera Ingeniería en Informática Desarrollo de una plataforma para la realización de experimentos participativos de índole sociológica Julio Alberto Arenere Mendoza Director: Francisco Sanz García Ponente: Javier Campos Laclaustra Escuela de Ingeniería y Arquitectura Universidad de Zaragoza Septiembre de 2014 Resumen Cada día está mas en auge la ciencia ciudadana, ya no solo ofreciendo ciclos de CPU de nuestras máquinas, sino pudiendo ser partícipes de forma directa en la investigación científica. Por ello desde dentro de la Fundación Ibercivis y en colaboración con investigadores de de otras universidades se decidió lanzar un experimento que aúna la ciencia ciudadana y las ciencias sociales. Este experimento consta de tres partes, una primera parte que trata sobre distintos aspectos de la personalidad, y otras dos partes representan diversos escenarios en los que se tendrá que tomar decisiones, algunas solo dependen del propio usuario, mientras que otras dependerán del resultado de otro participante. Estos escenarios basados en distintos juegos como el del dictador se plantean en términos de ganancias económicas, pudiendo el usuario obtener una compensación económica basada en una de sus decisiones. Además cada usuario tiene la posibilidad de recibir un feedback basado en sus decisiones y las de los demás. El objetivo del presente proyecto ha sido desarrollar una plataforma web de encuestas que permita a los usuarios de manera fácil, la creación, modificación y publicación de encuestas así como la obtención de los resultados de esta. Además se ha modificado esta plataforma para el experimento anteriormente resumido, así como a las necesidades de los investigadores. Para ello se han analizado las plataformas web actuales para la realización de encuestas y se ha observado que tienen un gran problema para ser reutilizables y adaptables a las necesidades del experimento. Por ello la plataforma de encuestas ha sido desarrollada siempre pensando en la reusabilidad y la facilidad para adaptarse a nuevos requisitos y añadir nuevas características, por estas razones se ha puesto especial interés a a la hora de explicar el funcionamiento de la plataforma, así como la documentación de esta y la elaboración de una serie de manuales para la administración y el desarrollo de esta, desde como añadir nuevos tipo de preguntas a la plataforma o como desplegar nuestra plataforma en la nube. La implementación se ha realizado siempre usando tecnologías de software libre, además se ha desarrollado la plataforma siempre de una manera transparente y libre, usando el repositorio de datos GitHub en su modalidad pública, albergando tanto documentación como el código desarrollado. Como balance general del proyecto, se ha desarrollado una plataforma web de encuestas que cumple con todos los requisitos marcados inicialmente, además se ha probado con éxito en la realización del experimento anteriormente descrito. i Agradecimientos A mi padres, a cada uno de ellos por la comprensión, confianza, paciencia y apoyo incondicional que me habéis demostrado siempre. A mis hermanas por estar siempre ahí acogiéndome cuando ha sido necesario. A todo el equipo del BIFI, la Fundación Ibercivis, en especial a Fermín, Francisco, Mari Carmen y a los investigadores Antonio, Pablo y Anxo, sin vosotros esto no hubiese sido posible. Y por supuesto a todos mis amigos, que siempre habéis estado ahí aguantandome tanto en los buenos como en los malos momentos. iii iv Índice general 1. Introducción 1 1.1. Contexto.................................. 1 1.2. Objetivos ................................. 2 1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Estado del Arte 5 2.1. Análisis de requerimientos . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Herramientas actuales . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Contexto Tecnológico 11 3.1. Modelo-vista-controlador . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Mapeo objeto-relacional . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Motordeplantillas ............................ 12 3.4. Diseñowebadaptable........................... 13 3.5. OpenID .................................. 13 3.6. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Desarrollo de la plataforma 15 4.1. Análisis de los requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Modelo Vista Controlador implantado . . . . . . . . . . . . . . . . . . 16 4.3. DiagramadeClases............................ 16 4.4. Clasesdelsistema............................. 18 4.5. Clases del sistema del proyecto Project Q ................ 21 4.6. EsquemaRelacional............................ 22 4.7. Módulos de la plataforma . . . . . . . . . . . . . . . . . . . . . . . . 22 4.8. Prototipado de las ventanas y cuestiones de usabilidad . . . . . . . . 27 4.9. Cuestiones sobre la implementación . . . . . . . . . . . . . . . . . . . 29 v ÍNDICE GENERAL 5. Pruebas 31 5.1. Tests unitarios y cobertura de código . . . . . . . . . . . . . . . . . . 31 5.2. Pruebasdecarga ............................. 32 5.3. PruebasdeSistema............................ 32 6. Lanzamiento 33 6.1. Despliegue................................. 33 6.2. Soporte .................................. 33 6.3. Comunicación y redes sociales . . . . . . . . . . . . . . . . . . . . . . 34 7. Conclusiones 35 7.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.2. Trabajofuturo .............................. 36 7.3. Conclusiónpersonal............................ 37 A. Gestión del proyecto 41 A.1. Ciclo de vida del desarrollo. . . . . . . . . . . . . . . . . . . . . . . . 41 A.2.Gestióndeltiempo ............................ 41 B. Herramientas 45 B.1.Flask ................................... 45 B.2.WTForms ................................. 46 B.3.Jinja2 ................................... 46 B.4.SQLAlchemy ............................... 46 B.5.Python................................... 47 B.6.Otroslenguajes.............................. 47 B.7.Bootstrap ................................. 48 B.8.GitHub .................................. 48 B.9.Gunicorn.................................. 48 B.10.Softwaredeapoyo............................. 48 C. Manual del administrador 51 C.1.Consideraciones.............................. 51 C.2.Requisitoshardware ........................... 51 C.3.Requisitossoftware............................ 52 C.4.Instalación................................. 52 C.5.Configuración............................... 53 C.6.Basededatos............................... 54 vi ÍNDICE GENERAL C.7.Iniciodelprograma............................ 55 C.8. Asignación del rol investigador a un usuario . . . . . . . . . . . . . . 55 C.9.Actualización ............................... 55 C.10.Log..................................... 56 D. Manual de investigador 57 D.1.Iniciodesesión .............................. 57 D.2. Creación de encuestas . . . . . . . . . . . . . . . . . . . . . . . . . . 59 E. Guía de desarrollo 79 E.1. Preguntas de tipo fecha . . . . . . . . . . . . . . . . . . . . . . . . . . 79 E.2. Preguntas de tipo casillas de verificación . . . . . . . . . . . . . . . . 82 E.3. Encuestas en varios lenguajes . . . . . . . . . . . . . . . . . . . . . . 85 E.4. Encuestas con preguntas que saltan a distintas secciones . . . . . . . 85 E.5. Plataforma en la nube . . . . . . . . . . . . . . . . . . . . . . . . . . 88 E.6. Consideraciones en el desarrollo de la plataforma . . . . . . . . . . . 90 F. Análisis de requisitos de la aplicación 91 F.1. Especificación de Requisitos Software . . . . . . . . . . . . . . . . . . 91 G. Enrutamiento 99 G.1. Resolución de rutas en Flask . . . . . . . . . . . . . . . . . . . . . . . 99 G.2. Rutas de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 100 H. Esqueleto 103 H.1.Flask.................................... 103 H.2.MVCimplantado............................. 106 H.3.PlataformaModular ........................... 106 I. Seguridad 107 I.1. Autenticación de usuarios . . . . . . . . . . . . . . . . . . . . . . . . 107 I.2. Controldeacceso............................. 108 J. Controlador 111 J.1. Estructura. ................................ 111 J.2. Formularios ................................ 112 vii 1. INTRODUCCIÓN Ibercivis es una iniciativa internacional de ciencia ciudadana, compuesta por una plataforma de computación voluntaria y por una serie de experimentos que permiten a la sociedad participar en la investigación científica de forma directa y en tiempo real. Dentro de la computación voluntaria, Ibercivis es una plataforma de computación distribuida, basada en BOINC, que permite a usuarios de internet a participar en proyectos científicos donando ciclos de computación que se emplean para realizar simulaciones y otras tareas. Los experimentos están basados en Ciencia Ciudadana, que es un tipo de ciencia basada en la participación, consciente y voluntaria, de miles de ciudadanos que generan grandes cantidades de datos. Cualquier persona puede aportar su inteligencia para poder encontrar resultados de utilidad social. Hacemos notar que debido a la distancia geográfica de los investigadores y del equipo de Ibercivis, se usó principalmente el correo electrónico como medio medio principal de comunicación entre las dos partes del proyecto. También se realizó una reunión presencial en Madrid con el investigador Anxo para perfilar algunos detalles del experimento y mostrar el estado de esta. 1.2. Objetivos Los objetivos del presente proyecto hacen referencia a lo establecido en la propuesta de PFC. Dichos objetivos son: Desarrollar una plataforma de encuestas, así como las herramientas necesarias para la creación de encuestas y obtención de los resultados. Dicha plataforma se debe acceder vía portal web, teniendo este un diseño web adaptable. Adaptar la plataforma al experimento Project Q, descrito en el apéndice M, cuyo objeto de estudio son los voluntarios de Ibercivis que toman parte en los proyectos de Ciencia Ciudadana. Dentro del experimento Project Q, hay algunas decisiones que se plantean en términos de una ganancia económica. En casos elegidos de forma aleatoria, el voluntario recibe un pago asociado a una de sus decisiones. Ofrecer soporte a los investigadores durante el desarrollo del experimento Project Q. 2 1.3 Estructura de la memoria El objetivo final del experimento es permitir a los investigadores comparar a los voluntarios de Ibercivis con la muestra de población general del trabajo Experimental subjects are not different[12]y caracterizar a una población amplia de voluntarios para después solicitar su colaboración en futuros proyectos seleccionándolos conforme a su perfil. Documentar, gestionar y asegurar toda la ingeniería que hay detrás de la plataforma de encuestas y del experimento Project Q, con el objetivo de ser reutilizable y fácilmente modificable y ampliable. 1.3. Estructura de la memoria En la presente memoria se describe el proceso llevado a cabo para el desarrollo de la plataforma. Su contenido se ha distribuido en los siguientes capítulos: Capítulo 1, este capítulo de introducción. Capítulo 2, análisis de las herramientas existentes relacionadas con el proyecto. Capítulo 3, muestra algunos conceptos referente al uso de tecnologías asociadas al proyecto. Capítulo 4, descripción del proceso de desarrollo de la plataforma de encuestas y del experimento Project Q. Capítulo 5, detalle de los distintos tests realizados a la plataforma creada. Capítulo 6, reseña de las tareas realizadas durante el experimento Project Q y la visibilidad de este. Capítulo 7, exposición de los resultados obtenidos, así como posibilidades de ampliación de la plataforma desarrollada y la valoración personal del trabajo realizado. 3 1. INTRODUCCIÓN 4 Capítulo 2 Estado del Arte Antes de la realización de la aplicación se estudió los requerimientos que debía cumplir la plataforma, además se estudió las distintas alternativas libres que existen para la elaboración de cuestionarios y si estas se adaptaban a los requerimientos. 2.1. Análisis de requerimientos Para ser capaces de evaluar las distintas alternativas existentes, antes debemos realizar en primer lugar un análisis de los requerimientos necesarios para la realización de nuestra plataforma de encuestas. Estos requerimientos han sido fruto del estudio del documento ¿Cómo son nuestros voluntarios? descrito en el anexo M, así como las distintas conversaciones con los investigadores para saber las características deseables en una plataforma de encuestas on-line para el desarrollo de sus investigaciones, Los requerimientos que debía cumplir la plataforma de encuestas son los siguientes: Poder evaluar y calcular el tiempo empleado de cada usuario al contestar cada pregunta. El orden de las distintas secciones debía seguir una pauta muy específica, existiendo secciones con un orden fijo y las otras secciones siguiendo una pauta semialeatoria, ya que hay secciones que deben ir contiguas. Hay secciones excluyentes entre si. Los usuarios tienen un tiempo limite para la realización del cuestionario. El cuestionario solo debe estar presente para su realización en un rango de tiempo predefinido. 5 2. ESTADO DEL ARTE Existe un numero máximo de participantes. Hay preguntas que deben ser contestada según la respuesta dada a otra anterior. Existen preguntas de validación, en la que se comprueba que el usuario ha contestado bien y se le notifica si la respuesta es correcta o no, con un número máximo de intentos. Disponibilidad de una interfaz gráfica. Acceso mediante un portal web. 2.2. Herramientas actuales La importancia de la web ha ido creciendo de manera exponencial conforme han ido pasado los años. Por lo que se han ido creando multitud de herramientas para ir resolviendo los distintas necesidades que se han ido creando y repitiendo a lo largo de los años. En el caso de las encuestas no es distinto al de los otros, pero debido a nuestras necesidades concretas que hemos expuesto anteriormente nos hemos centrado en las alternativas libres o que expusiesen un API (Interfaz de programación de aplicaciones) para su integración con la plataforma. Surveyor Surveyor[42] es una herramienta para crear encuestas, cuestionarios y premios e integrarlos en una aplicación escrita en Ruby en Rails. Usa una licencia MIT, compatible con GPL (Licencia Pública General de GNU). En un principio fue diseñado para ofrecer estudios de investigación clínicos en grandes poblaciones. Para la elaboración de encuestas hace uso de un Lenguaje especifico del dominio, permitiendo una escritura fácil y rápida de encuestas. Además permite la personalización del modelo, vista y controlador, así como las rutas. Como parte negativas, no tiene un soporte consistente para HTML, así como un código poco documentado y ninguna guía de desarrollo. LimeSurvey LimeSurvey[28] una herramienta escrita en PHP bajo la licencia GPL. Entre sus usuarios se encuentra proyectos como OpenOffice, Ubuntu o GNOME. 6 2.2 Herramientas actuales En si es una plataforma muy completa, con un potente editor WYSIWYG (lo que ves es lo que obtienes), así como numerosas opciones en la elaboración de encuestas, como puede ser el restringir el numero máximo de participantes según sus característica, pudiendo ser estas el rango de edad, población, sexo... Su gran inconveniente es que está pensado para usarla en si misma, ya que trae todo integrado, haciendo difícil la modificación fuera de las opciones predeterminadas. Es mas su modelo de negocio es el ofrecer alojamiento web de LimeSurvey a cambio de una tarifa que depende del número de encuestados. Survey Project Survey Project[37] Es una herramienta bajo GPL2 escrita en C# y soporte único para máquinas con un sistema operativo windows. Tanto a nivel de características como de modelo de negocio, es muy parecido a LimeSurvey. Google Forms Google posee una herramienta para la elaboración de formularios, Google Forms[16], así como una API[6] para poder acceder ella, tanto para la elaboración de formularios como para obtener los resultados de ella. Además de esta herramienta, también posee un servicio de pago para la elaboración de encuestas, Google Surveys[43]. En la elaboración de formularios, posiblemente la solución de Google sea la más accesible de todas, sobre todo por su cuidado en el aspecto y las funcionalidades a la hora de crear formularios. A parte de tener todo integrado, exportándose automáticamente los resultados a GoogleDrive[11] y pudiendo obtener un análisis de estadísticas sencillo. Por otra parte es la más limitada a la hora de crear formularios complejos y sin la posibilidad de modificación. Comparativa Del estudio de las herramientas actuales se obtuvo bastante información interesante, sobre todo las características deseables para la elaboración de una plataforma para la elaboración de encuestas, esta información recogida así como los requisitos necesarios para nuestra plataforma fueron los usados para definir los requerimientos finales. Observando las tablas de la figuras 2.1, 2.2, 2.3 y 2.4 se puede comparar el grado de cumplimiento de nuestra plataforma respecto a las otras. Swarm Survey es el nombre de la plataforma creada. 7 2. ESTADO DEL ARTE Tipo de respuesta Surveyor LimeSurvey Survey Google Swarm esperada Proyect Forms Survey Numérica Si Si Si Si Si Decimal Si Si Si Si Si Texto Si Si Si Si Si Expresión regular No Si Si Si Si Escala likert No Si Si Si Si Selección Si Si Si Si Si Preguntas obligatorias No Si Si Si Si Preguntas dependientes Si Si Si No Si de la respuesta de otra Preguntas de validación No No No No Si Figura 2.1: Tabla comparativa entre las herramientas Lógica del programa Surveyor LimeSurvey Survey Google Swarm Proyect Forms Survey Secciones aleatorias No No No No Si Secciones excluyentes No No No No Si Cálculo de tiempos No No No No Si Tiempo limite No No No No Si Fecha limite No Si Si No Si Número máximo de No Si Si No Si participantes Figura 2.2: Tabla comparativa entre las herramientas La tabla 2.1, hace referencia al tipo de respuesta que puede tener una pregunta Mirando únicamente la tabla, Surveyor puede parecer que sea de las peores elecciones, sobre todo si solo se comparan funcionalidades, pero analizando un poco más la plataforma sería la mejor opción para adaptarla, debido a su tamaño y a que ofrece un núcleo básico para usarse de base, pero debido a su nula documentación, se estimo que el tiempo necesario para comprender en profundidad el funcionamiento de esta, así como para adaptar todas las características necesarias para nuestra plataforma y elaboración del experimento iba a ser mayor que el necesario para crear una desde cero. Para no caer en el error de Surveyor se ha intentado documentar lo mejor posible la plataforma, además de la elaboración de una guía rápida de desarrollo en el que se incluyen ejemplos de como ampliar la plataforma con una serie de características que no posee, incluido las encuestas multilenguaje, o usar la plataforma en la nube. Todo ello y más se detalla en el apéndice E. 8 2.2 Herramientas actuales Ampliación de la Surveyor LimeSurvey Survey Google Swarm Plataforma Proyect Forms Survey Facilidad de ampliación Media Baja Baja No Alta Facilidad de desarrollo Media Baja Baja Media, Altausando la API Sistema de No No No No Si migración de BBDD Shell No No No No Si Manual de desarrollo No No No Si Si Figura 2.3: Tabla comparativa entre las herramientas Otras cuestiones Surveyor LimeSurvey Survey Google Swarm Proyect Forms Survey Interfaz gráfica No Si Si Si Si Lenguaje Si No No No No específico del dominio Exportar Si Si Si No Si importar a fichero Multilenguaje Si Si Si Si No Editor No, uso No No No Si, uso de de texto parcial sintaxis amigable de html Markdown Plantillas Si Si Si No Si Uso de direcciones Si No No No Si web amigables Multiplataforma Si Si No No Si Uso de nube No No No No No Figura 2.4: Tabla comparativa entre las herramientas 9 2. ESTADO DEL ARTE 10 Capítulo 3 Contexto Tecnológico En este capítulo se estudia algunos conceptos referentes a las tecnologías usadas, además se realiza una valoración personal de las distintas tecnologías utilizadas. 3.1. Modelo-vista-controlador El modelo-vista-controlador o MVC es un patrón de diseño de las aplicaciones software, según la definición de Christopher Alexander [3]cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, así como la solución a ese problema, de tal modo que se pueda aplicar esta solución un millón de veces, sin hacer lo mismo dos veces. El patrón MVC consiste en tres tipos de objetos: El Modelo es la representación de la información con la cual es sistema opera. La Vista que es su representación del modelo (información y lógica del negocio), en un formato adecuado para interaccionar con él. El Controlador que define el modo en que la interfaz reacciona a la entrada del usuario e invoca peticiones al modelo. La figura 3.1 muestra la relación entre el modelo, la vista y el controlador. Las lineas solidas indicas una asociación directa, las punteadas indirectas. En otras palabras, el flujo de control sería: El usuario realiza una acción en la interfaz. El controlador trata el evento de entrada. El controlador notifica al modelo la acción del usuario, lo que puede implicar un cambio en el estado del modelo. 11 4. DESARROLLO DE LA PLATAFORMA Figura 4.3: Diagrama de clases de Question Observando con mas detenimiento la clase Pregunta, cada tipo de pregunta desciende de esta clase, en la figura 4.3 se puede ver con mas detalle. Por otra parte, para el experimento Project Q se creo una serie de clases para los distintos juegos y sorteos, como se puede ver en la figura 4.4.En la figura 4.5 se puede ver con mas detenimiento la clase Juego_dos_participantes. Como hemos dicho anteriormente estos diagramas solo hacen referencia al modelo estático del sistema, no así a las demás clases que interactúan con estas, como puede ser los distintos formularios y validadores web usados para la representación del modelo. En el apéndice L.1 se encuentra una versión completa de los diagramas anteriormente citados. 4.4. Clases del sistema A continuación vamos a describir las distintas clases que conforman los diagramas de las figuras 4.2, 4.3: Usuario Un usuario es una persona que se registra en la plataforma para poder hacer uso de ella, ya sea creando encuestas o contestándolas. Entre los atributos del usuario están el correo, un hash de la contraseña, así como el rol que tiene en el sistema. 18 4.4 Clases del sistema Figura 4.4: Diagrama de clases de Games Figura 4.5: Diagrama detallado de la clase de Game 19 4. DESARROLLO DE LA PLATAFORMA Los métodos de la clases permiten verificar la contraseña del usuario, así como el rol que posee. Encuesta Representa la cabecera de la encuesta, en la que están definidas los atributos y las limitaciones de está, como puede ser la fecha durante la que estará activa la encuesta, la duración de esta, o simplemente el título y la descripción de esta. Además se implementan los métodos para importar y exportar encuestas en formato XML propio. Por último el método orden_secciones, genera el orden en el que el usuario realizará el cuestionario. Consentimiento Contiene los consentimientos que debe aceptar un usuario para realizar una encuesta. Sección Sirven para definir los distintas secciones organizativas que posee una encuesta, a su vez una sección puede contener mas secciones. Además en cada sección se puede definir si son secciones exclusivas respecto a las secciones del mismo nivel, así como definir el nombre y la probabilidad de realizar dicha sección de la encuesta. Al final las secciones generan un árbol que cuelga de una encuesta. El método duplicar, sirve para duplicar una sección dada, así como todas las preguntas que contiene. Pregunta Contiene una pregunta de una encuesta. Las preguntas pueden ser de distinto tipo, cada una tiene su propia clase que hereda de ella. Las preguntas puedes ser obligatorias o no, además pueden ser preguntas de validación, esperando una respuesta esperada, así como el número máximo de intentos.Además una pregunta puede depender de la respuesta dada a otra pregunta. Pregunta de texto Contiene preguntas cuya respuesta es texto, almacena también las limitaciones que pueda tener la respuesta, como puede ser si es un número entero, decimal o viene limitado por una expresión regular. Pregunta YN Hace referencia a las preguntas cuya respuesta es si o no. 20 4.5 Clases del sistema del proyecto Project Q Preguntas de elección Contiene las distintas opciones posibles en las preguntas cuyo rango de respuestas está predeterminado. También guarda información de como representar gráficamente estas opciones al usuario. El método opciones genera una lista con todas las elecciones posibles. Preguntas de escala likert Almacena la información necesaria para las preguntas likert, como puede ser los valores mínimos y máximos, así como el valor de las etiquetas. Condición Hace referencia a las preguntas dependientes de la respuesta de otra pregunta. Guardando que pregunta depende de quién así como las condiciones necesarias para mostrar dicha pregunta. Respuesta Guarda la respuesta que ha dado un usuario a una pregunta, así como el tiempo empleada en ella. Estado de la encuesta Contiene la información relativa del estado en el que se encuentra una encuesta por parte de un usuario, guardando entre otras cosas la sección por la que va, el tiempo empleado o el estado de la encuesta. 4.5. Clases del sistema del proyecto Project Q A continuación vamos a describir las entidades creadas para el proyecto Project Q. Rifa En el sorteo que hay dentro del proyecto, se encarga de decidir si el usuario es premiado o no y guarda la cantidad ganada. Juego de la impaciencia Hace referencia a los resultados de las decisiones tomadas en el juego de la impaciencia, que depende únicamente solo de un usuario, descrita en el apéndice M.4. Además se encarga de decidir si el jugador es premiado o no. 21 4. DESARROLLO DE LA PLATAFORMA Juego de dos participantes Dentro del proyecto existen varios juegos que involucran a dos usuarios, cada juego depende de las decisiones tomadas en las respuestas de la encuesta. Cada juego hereda de esta entidad e implementa dicho juego. GameLottery1, juego de la lotería 1: descrito en el apéndice M.4 GameLottery2, juego de la lotería 2: descrito en el apéndice M.4 GameRent1, juego de la renta 1: descrito en el apéndice M.4 GameRent2, juego de la renta 2: descrito en el apéndice M.4 GameUltimatum, juego del ultimatum: descrito en el apéndice M.4 GameDictador, juego del dictador: descrito en el apéndice M.4 4.6. Esquema Relacional A pesar de usar un ORM, en nuestro caso SQLAlchemy, se tuvo que tomar la decisión de como implementar las clases heredadas, si todas iban a ir en la misma tabla, en distintas o o algunas compartiendo tabla y otras no. Se decidió que todas las preguntas compartirían la misma tabla, sobre todo ya que no se espera una gran cantidad de entradas en esta tabla, y a nivel de funcionamiento siempre se piden todas las preguntas de una sección dada, independientemente del tipo de preguntas, por lo que se optó por esta solución. Una solución similar se adoptó para los juegos. En el apéndice L.2 se muestra con detalle el esquema relacional, así como algunas de las restricciones existentes en el sistema. 4.7. Módulos de la plataforma Como se puede ver en la figura 4.6, se ha dividido la plataforma en distintos módulos, agrupando estas a nivel de funcionalidades, además de tener en cuenta las recomendaciones dadas por los desarrolladores de Flask [14][44]. Módulo del Modelo Implementa el diagrama de clases descrito anteriormente en la sección 4.3, usando SQLAlchemy como ORM, gestionando todos los accesos a la información del sistema 22 4.7 Módulos de la plataforma Figura 4.6: Módulos del sistema Módulo de decoradores Este módulo contiene los decoradores usados para proteger las vistas (direcciones web) de los distintos módulos que se pueden acceder vía petición HTML, así se evita que cualquier usuario pueda ejecutar una vista a la que no tiene acceso, ya sea porque no ha ingresado el usuario en la plataforma o no tenga privilegios suficientes. En el apéndice I se describe el funcionamiento y la implementación de los decoradores. Módulo Planificador de tareas. Este módulo se encarga de ejecutar tareas periódicas. Concretamente tiene definidas dos: Envía periódicamente al investigador los resultados de la encuesta. En la adaptación del experimento Project Q, se barajó la posibilidad de automatizar el envío de cheques regalos con los premios usando Tango Card [9], aunque finalmente se desechó debido a la pequeña cantidad de cheques regalos que se enviarían, así que se decidió realizar los pagos manualmente, por lo que se envía un correo electrónico al responsable de los pagos, con el dinero y usuario al que debe realizar el pago. El responsable envía al usuario un cheque regalo al correo del usuario a través de Amazon [4]. 23 4. DESARROLLO DE LA PLATAFORMA Figura 4.7: Diagrama de clases del sistema de configuración Módulo de configuración Este módulo se encarga de leer la configuración de la plataforma una vez que se inicia está. Aunque no se ha señalado explícitamente, los demás módulos interaccionan con él si tienen que leer alguna configuración de la plataforma. Teniendo en cuenta las recomendaciones dadas por los autores de la plataforma [20], se decidió crear un sistema de clases y herencia para la configuración del sistema, pudiendo cambiar el modo de funcionamiento de la aplicación simplemente cambiando una variable de entorno del sistema. En la figura 4.7 se puede ver un esquema del diagrama de clases, siendo la descripción de las clases usada la siguiente: Config: Configuración básica de la plataforma. DevelopmentConfig: Configuración de la plataforma en modo desarrollo. TestingConfig: Configuración de la plataforma para test unitarios. JmeterConfig: Configuración de la plataforma para la realización de pruebas de sobrecarga y aceptación. ProductionConfig: Configuración de la plataforma en modo producción. Hay que indicar cual es el servidor de correos a usar. Usa un sistema de logs propio. HerokuConfig: Configuración para la ejecución de la plataforma en la nube Heroku, usa el sistema de logs de Heroku [21]. UnixConfig: Configuración de la plataforma en modo producción en una máquina de tipo Unix, haciendo uso del sistema de logs de la máquina. En el apéndice C se trata mas a fondo la configuración del sistema y las distintas opciones. 24 4.7 Módulos de la plataforma Módulo shell Este módulo se accede mediante la consola de la plataforma, dando acceso a un interprete Python, el cual puede acceder a cualquier módulo definido en el sistema y ejecutar los distintos métodos y funciones. Además proporciona el acceso a una serie de herramientas para la administración del sistema. 1( venv )$ ./ manage . py shell 2// shell interactively of swarm - surveys , " import utiles " to access the administration tools 3In [1]: from current_app import utiles Módulo de selección de jugadores Este módulo es el encargado de decidir en los juegos del experimento Project Q que usuarios se enfrentan con quién. Además de buscar las respuestas dadas por los voluntarios. A la hora de decidir que usuarios van a enfrentarse, se busca a todos los usuarios que no han realizado ningún enfrentamiento. Si este llega a un número mínimo necesario para que no existan enfrentamientos repetidos se continua, sino se selecciona las decisiones tomadas de otros voluntarios que ya se han enfrentado, pero sin posibilidad de que estos últimos vuelvan a salir premiados. Módulo de resultados Este módulo es el encargado de generar el fichero de resultados para los investigadores. Concretamente existen dos funciones, una para encuestas genéricas y otra para el experimento Project Q, ya que se adapto los resultados a las necesidades de los investigadores en cuanto al formato de salida del fichero. Módulo de autentificación Este módulo da acceso a las siguientes funcionalidades las cuales se puede acceder a través del portal web de la plataforma: Registranos en la plataforma. Validarnos mediante el uso de un correo y contraseña o mediante el uso de un servidor OpenID. Cierre de la sesión actual. 25 4. DESARROLLO DE LA PLATAFORMA Módulo del investigador Este módulo permite a los usuarios de la plataforma que tengan el rol de investigadores la creación de encuestas usando el portal web de la plataforma. Las opciones dadas son las siguientes: Listar las encuestas del investigador que ha iniciado sesión. Crear, modificar o eliminar una encuesta. Exportar e importar una encuesta. Crear, modificar o eliminar consentimientos de una encuesta. Crear, modificar, eliminar o duplicar una sección de una encuesta. Crear, modificar, eliminar o duplicar una subsección de una encuesta. Crear, modificar o eliminar una pregunta. Estas acciones solo están disponibles para investigadores, además no se permite editar o eliminar encuestas de otros investigadores. Módulo del encuestado Este módulo permite a los usuarios que sean voluntarios realizar encuestas. Las acciones disponibles son las siguientes: Listar todas las encuestas disponibles, así como el estado de esta, ya sea sin empezar, empezada o finalizada. Empezar o continuar una encuesta. Internamente la aplicación decidirá cual es el siguiente paso a realizar en una encuesta, pudiendo ser: •Mostrar los consentimientos que el usuario debe aceptar para empezar a contestar a la encuesta. •Mostrar una sección con las distintas preguntas para que el usuario las responda. Las respuestas así como los tiempos empleados son almacenados en la base de datos del sistema. •Dar paso al módulo de feedback en el caso del experimento Project Q A este módulo solo pueden acceder usuarios que hayan autentificado en la plataforma. 26 4.8 Prototipado de las ventanas y cuestiones de usabilidad Módulo de feedback Este módulo permite dar feedback sobre las decisiones tomadas en el proyecto Project Q. Cada página corresponde con una decisión concreta del experimento. El orden en el que se muestra al usuario el feedback es el mismo que el realizado durante el experimento, ya que el orden en el que se realiza el experimento es generado al azar. Este módulo está protegido de modo que solo pueden acceder los usuarios que hayan terminado la encuesta y hayan decidido que desear recibir feedback. Módulo de visualización de estadísticas y juegos Este módulo permite la visualización de los resultados de las encuestas, además también permite la visualización de los resultados de los juegos del experimento Project Q, también da información de utilidad, como puede ser la cantidad de dinero repartido en el experimento o los usuarios premiados. Las funciones anteriores solo están disponibles para investigadores, además solo se puede acceder a las encuestas creadas por el propio investigador. 4.8. Prototipado de las ventanas y cuestiones de usabilidad Después del análisis y el diseño de las distintas partes de la aplicación, se continuo con un diseño preliminar de la interfaz para el usuario. Se tomaron distintas ideas de las plataformas estudiadas para la elaboración de encuestas, así como las guías de usabilidad del proyecto KDE [18]. Para facilitar al investigador la navegación entre las distintas secciones, se decidió mostrar el árbol de secciones por completo en un lateral de la ventana. Además de mostrar en la parte superior un menú de tipo migas de pan, que presenta en forma textual todos los enlaces que describen la ruta de una sección a partir de la raíz, siendo esta la propia encuesta. Por otra parte para mejorar la usabilidad de la aplicación, se ha añadido código JavaScript en distintas páginas para ofrecer ciertas funcionalidades al usuario, sin tener que realizar peticiones a la plataforma web, añadiendo velocidad y fluidez a la plataforma. 27 6. LANZAMIENTO Se comprobó que la evolución de los premios monetarios dados, estaba dentro del rango esperable. Durante el experimento se comprobó que más de un tercio de los participantes no terminaban este. Se realizó una serie de scripts para comprobar cuales podían ser las causas para no finalizarlo, comprobando en que partes el usuario decidía abandonar el experimento y si intentaba retomarlo mas tarde. En base a los resultados obtenidos los investigadores decidieron notificar al usuario que en las preguntas de control recibiría ayuda en caso de no saber responder a la pregunta, además de poder continuar con el cuestionario. 6.3. Comunicación y redes sociales Figura 6.1: Fragmento del artículo del heraldo.es Durante el lanzamiento del experimento se envió una nota de prensa a diferentes periódicos así como a las distintas universidades a los que pertenecen el equipo de investigadores del experimento. Por otra parte también se informo a los usuarios que ya habían participado en otros experimentos dentro del BIFI y la Fundación Ibercivis, a través del correo electrónico. Además de informar del lanzamiento del experimento, a través de la página de la Fundación Ibercivis [22], también se realizo una serie de entradas en FaceBook [23] y Twitter [24] de Ibercivis, a parte de hacerser eco en otros medios web como Aragón investiga [7]o la sección de blogs del Heraldo de Aragón [35]. 34 Capítulo 7 Conclusiones Este capítulo contiene las conclusiones extraídas tras la realización de este Proyecto Final de Carrera y se apuntan algunas posibilidades de mejora y trabajo futuro. Se termina con una pequeña conclusión a nivel personal. 7.1. Conclusiones generales Una vez finalizado el proyecto, se puede concluir que los resultados obtenidos son satisfactorios, habiéndose cubierto el listado de los requisitos. Dichos requisitos se han ido ampliando a lo largo del proyecto, conforme iba evolucionando la plataforma, y el experimento Project Q, adaptando las necesidades de los investigadores a la plataforma. Respecto al experimento Project Q, se llevó a cabo durante el mes de julio, durante ese mes se sirvieron mas de 36.000 páginas, siendo los primeros días los que mas carga soporto la plataforma como se puede ver en la figura 7.1. Durante todo este tiempo la plataforma desarrollada funcionó correctamente, por lo que se puede considerar un éxito. Figura 7.1: Información de Google Analytics 35 7. CONCLUSIONES Además del desarrollo de la plataforma, se ha buscado la reutilización y ampliación de está, objetivo cumplido como se puede ver en el anexo E y la facilidad que tiene la plataforma para su ampliación. 7.2. Trabajo futuro Durante la elaboración del proyecto siempre se ha tenido presente crear un núcleo de la plataforma versátil y potente, el cual se pueda adaptar a las necesidades de otros proyectos. A continuación se proponen unas posibles mejoras, algunas de ellas completamente desarrolladas en el anexo E: Añadir nuevos tipos de preguntas predeterminadas, que puedan servir para la elaboración de nuevas encuestas. Debido a la imposibilidad de llegar a todas las opciones posibles, durante el proyecto se decidió implementar solo el tipo de preguntas que aparecen en la encuesta del experimento Project Q, pero no por ello se quería dejar cerrada la plataforma a ese tipo de preguntas. Está fue una de las razones para escribir dos manuales en el apéndice E, de como incluir preguntas de tipo fecha y multitest. Aunque la interfaz de la plataforma esta traducida al Español e Ingles, y se puede ampliar fácilmente los idiomas soportados, no tiene soporte multiidioma, por lo que puede ser un inconveniente si se quiere acceder a poblaciones con distinto idioma. En el apéndice E, se dan las pautas necesarias para la implementar esta función. Crear un lenguaje específico del dominio. Durante el desarrollo del experimento Project Q, se observó que la creación de encuestas largas y complejas es una tarea tediosa y que consume bastante tiempo. Observando las soluciones de otras plataformas de encuestas se puede observar que ninguna es capaz de resolver este problema mediante el uso de una interfaz visual, ya sean mas o menos elaboradas y complejas. Por lo que se propone crear un lenguaje específico del dominio, como hace la plataforma Surveyor. Una solución intermedia, pasa por la creación y modificación de la encuesta mediante ficheros XML, que ya soporta la plataforma o ficheros JSON, que también sería muy fácil de implementar. Esta última solución se ha probado con éxito en el experimento Project Q, sobre todo a la hora de modificar la encuesta. 36 7.3 Conclusión personal Creación de una API para extender la funcionalidad de la plataforma a otros dispositivos distintos del navegador web. Para la elaboración de esta tarea puede uno observar que funciones son las que tienen una vista para el navegador, y enviar y recibir los datos serializando estos mediante JSONS. Desarrollo de un sistema de extensiones, para facilitar la ampliación de la plataforma, abstrayendo el núcleo de esta a la incorporación de nuevas funcionalidades. 7.3. Conclusión personal La realización de este proyecto me ha servido entre otras cosas para ampliar mi conocimiento, trabajando en áreas en las que no se tenía conocimiento previo, como es el mundo de las aplicaciones web, y todas las tecnologías asociadas a ella. Aprendiendo y disfrutando mientras se realizaba el proyecto y pensando en lo que puede ser una nueva versión de la plataforma desarrollada. Por otra parte se agradece la posibilidad de haber trabajado con algunos de los investigadores más importantes en su campo de investigación y de todo el feedback recibido por ellos, además del ambiente y la forma de trabajar en el BIFI, dentro de Ibercivis ha sido excelente. También se ha valorado positivamente la libertada dada en cuanto al uso de tecnologías y el haber podido desarrollar la plataforma siempre de manera transparente y libre, mediante el uso de GitHub, pudiendo devolver algo a la comunidad de software libre de la que tanto se ha tomado de ella. 37 7. CONCLUSIONES 38 Apéndices 39 Apéndice A Gestión del proyecto En este apéndice se va a detallar la metodología usada para la gestión del proyecto. A.1. Ciclo de vida del desarrollo. A pesar de tener claro desde el principio cual era la meta del proyecto y del experimento Project Q, estos dos han ido evolucionado a la par durante el desarrollo del proyecto. Esto se ha debido sobretodo a las diferencias que hay a la hora de realizar una encuesta con apoyo presencial y a otra telemática. Por eso el ciclo de vida que ha seguido el proyecto ha sido el prototipado evolutivo, como se puede ver en la figura A.1, teniendo desde el primer mes una versión básica con los requisitos sacados del documento del experimento Project Q, incluido en el apéndice M y a partir de esta primera versión, con la información recibida por los investigadores, se han ido añadiendo características y refinando el funcionamiento de esta, así sucesivamente durante el desarrollo de la plataforma y la adaptación del experimento a esta. Para facilitar esta retroalimentación de información, se ha intentado tener siempre una versión actualizada de la plataforma disponible para los investigadores y recibiendo los comentarios de estos a través del correo electrónico. A.2. Gestión del tiempo Debido al ciclo de vida desarrollado usado, una vez finalizado el primer prototipo, se ha vuelto constantemente a las etapas anteriores, añadiendo nuevos requisitos. Los grupos de tareas son los siguientes: 41 A. GESTIÓN DEL PROYECTO Figura A.1: Esquema del prototipado evolutivo Análisis: Se realizó un análisis previo al documento del experimento Project Q y a partir de este y después de las sucesivas evaluaciones por parte de los investigadores de los distintos prototipos, se fueron añadiendo mas características. Estudio de alternativas: En este grupo se engloba el estudio de las distintas plataformas para la elaboración de encuestas, y su posible uso. Estudio y familiarización de las herramientas: Esto incluye el estudio de las diferentes tecnologías usadas para la elaboración del proyecto. A pesar de dedicar un tiempo en exclusiva para él, a lo largo del desarrollo se han ido adquiriendo nuevos conocimientos, que aveces ha implicado la reimplementación de ciertas funcionalidades a favor de un código y una solución mas clara. Diseño: Este grupo incluye desde la estructuración de la aplicación en una jerarquía de módulos y funcionalidades según el ámbito, hasta el diseño de los datos, así como el diseño del interfaz. En el diagrama de Gantt de la figura A.2 solo se hace referencia explícita al primer diseño previo, pero después de cada evaluación se volvía al diseño. 42 A.2 Gestión del tiempo Figura A.2: diagrama de Gantt Implementación: Este grupo comprende en la escritura del código necesario para la elaboración de la plataforma. Pruebas: Esto incluye las pruebas tanto unitarias, aceptación y de sobrecarga realizadas a la plataforma. Documentación: En esta parte solo se engloba la generación de la documentación para la elaboración de la memoria, aunque durante todas las fases se han ido generando distintos diagramas, y ficheros. Evaluación: En este grupo se incluye las distintas revisiones que han realizado los investigadores a la plataforma y al experimento Project Q. A lo largo de la vida del proyecto se ha ido recibiendo de manera constante retroalimentación por parte de los investigadores, que han ido refinando el experimento. Aun así se podría destacarse tres grandes revisiones en las siguientes fechas: •4 de marzo, se enseño por primera vez en Madrid una primera versión de la plataforma y del experimento. Además se decidió que el usuario podría recibir un feedback por parte del experimento. •11 de abril, se reviso por completo el experimento, se recibió las pautas para modificarlo, además de indicar el formato de los ficheros de estadísticas para los investigadores. •19 de mayo, se realizó la evaluación final de las características de la plataforma. Lanzamiento: Esto grupo además de incluir el soporte dado a los investigadores mientras se lanzó el experimento Project Q, incluye el trabajo previo para 43 B. HERRAMIENTAS 50 Apéndice C Manual del administrador En este apéndice vamos a explicar como un administrador puede instalar la aplicación y ponerla en marcha. C.1. Consideraciones Aunque este manual intenta ser autoexplicativo en cuanto a la instalación de la plataforma, no es un manual de las distintas herramientas usadas en la plataforma, por lo que para ello se remite a la documentación oficial de estas. Por otra parte se espera que el administrador de la aplicación tenga nociones en la administración de servidores web, así como unas nociones muy básicas de Python. C.2. Requisitos hardware Los requisitos hardware dependerán del número de usuarios que van a acceder a la plataforma simultaneamente. Si se quiere medir como se comporta la plataforma ante un número elevado de usuarios, en la carpeta jmeter se incluye una configuración para JMeter, así como un generador de usuarios y una encuesta compleja. Esta aplicación genera todas los peticiones que realizaría un usuario al contestar a una encuesta. Para ejecutar la plataforma en este modo, debe cambiar la variable de entorno FLASK_CONFIG ajmeterProduction o en el fichero config.py cambiar la configuración default por jmeterProduction, ver figura C.1. También existe la posibilidad de ejecutar la plataforma en la nube. Dependiendo de la elección llevará mas o menos cambio. En el anexo E se incluyen las modificaciones y los pasos necesarios para ejecutar la aplicación en Heroku. 51 C. MANUAL DEL ADMINISTRADOR 1config = { 2’development ’: DevelopmentConfig , 3’testing’: TestingConfig , 4’production ’: ProductionConfig , 5’heroku’: HerokuConfig , 6’unix ’: UnixConfig , 7’jmeter’: Jmeter , 8’jmeterProduction’ : JmeterProduction , 9 10 ’default’: DevelopmentConfig } 11 \ end { listing } Figura C.1: Parte del fichero config.py C.3. Requisitos software Los requistos software son los siguientes: Virtualenv: Para la creación de un entorno virtual de Python para la instalación de todas los módulos necesarios. Git: Para poder descargarse la aplicación. Servidor web compatible con WSGI, en la documentación de Flask puedes encontrar una guía rápida para la puesta en marcha del servidor, http://flask. pocoo.org/docs/deploying/. Base de datos a usar, está debe ser compatible con SQLAlchemy, las posibilidades son las siguientes: •Postgresql •MySQL y su fork MariaDB •Oracle •Microsoft SQL Server •SQLite C.4. Instalación Empezaremos clonando el repositorio git donde se encuentra la aplicación: 1$ git clone git:// github . com / nu_kru / swarm - survey . git 2$ cd swarm - survey Una vez clonado el repositorio procederemos a crear un entorno virtual para poder instalar todas las dependencias necesarias en la aplicación: 52 C.5 Configuración 1$ mkdir swarm - surveys 2$ virtualenv venv 3New python executable in venv / bin / python 4Installing distribute ............ done . Después de instalar el entorno virtual, lo activamos: 1$ . venv / bin / activate Dentro del entorno virtual procederemos a instalar todas las dependencias de la aplicación. Todas ellas, así como la versión usada se encuentran en el fichero requeriments.txt. Para instalarla haremos uso de pip, el cual se ha instalado dentro de virtualenv: 1( venv )$ pip install -r requeriments . txt Con esto ya tendremos instalada la aplicación así como todos los módulos necesarios para hacerla funcionar. C.5. Configuración La configuración de la plataforma está localizada en los ficheros escritos en Python, config.py ysettings. En el fichero config.py se puede observar los distintos modos en los que se puede arrancar la aplicación, estos son los siguientes: Development: para el desarrollo de la plataforma. Testing: para ejecutar los test unitarios de la plataforma. Production: configuración base para el modo producción Heroku: para ejecutar la aplicación en modo producción en la nube Heroku. Unix: para ejecutar la aplicación en modo producción en una máquina de tipo Unix. Jmeter: para ejecutar el test de sobrecargar y aceptación. Para cambiar de modo, puede hacerlo mediante la variable de entorno CONFIG_FLASK o sino está definida modificando la configuración por defecto en el fichero config.py. En el fichero settings se encuentra una plantilla con las variables a cambiar. La plataforma espera encontrar la localización del fichero usando la variable de entorno 53 C. MANUAL DEL ADMINISTRADOR SWARMS_SURVEY_SETTINGS o sino por defecto el fichero settings.cfg el cual se genera automáticamente si no se encuentra. Tanto el fichero settings como config.py son autoexplicativos, estando documentado el significado de cada opción. En el fichero settings básicamente hay que indicar cual es el servidor de correo y los usuarios a los cuales se le va a enviar los correos con las distintas alertas que puede generar la plataforma, así como el usuario administrador y la contraseña de este. C.6. Base de datos Configuración de la base de datos a usar La plataforma hace uso de la variable de entorno DEV_DATABASE_URL en la cual espera que se encuentre la URI de la conexión de la base de datos, así como el usuario y contraseña. Si la variable no está definida usa por defecto SQLite. El formato es el siguiente: 1driver:// username : password@host : port / database Por ejemplo para MySQL: 1driver:// username : password@host : port / database Mas información para la configuración de la base de datos consulte la documentación oficial de SQLAlchemy http://docs.sqlalchemy.org/en/rel_0_9/core/engines. html. Creación de la base de datos Una vez definida la base de datos a usar entre las soportadas por SQLALchemy, debemos de crear la base de datos, para ello ejecutaremos los siguientes comandos: 1( venv )$ ./ manage . py db init 2( venv )$ ./ manage . py db migrate 3( venv )$ ./ manage . py db upgrade Con esto generamos la base de datos, además se hace uso de flask-migrate, una extensión que hace uso de Alembic para poder migrar la base de datos a nuevas actualizaciones del sistema. Para obtener mas información de como migrar o volver a una revisión anterior de la base de datos, consulte la documentación oficial: http: //flask-migrate.readthedocs.org/en/latest/. 54 C.7 Inicio del programa 1# Inicio de la shell : 2( venv )$ manage . py shell 3#Dar permisos de investigador al usuario foo@foo .com : 4>>> add_researcher ( foo@foo . com ) 5# Quitar permisos de investigador al usuario foo@foo . com 6>>> delete_researcher ( foo@foo . com ) 7# Listar usuarios disponibles : 8>>> list_user () Figura C.2: Ejemplos de comandos disponibles en la shell C.7. Inicio del programa Dependiendo del servidor web usado, deberá arrancar la aplicación de una manera u otra, para ello diríjase a la documentación oficial de su servidor web o consulte como guía rápida http://flask.pocoo.org/docs/deploying/. 1# Usando el servidor Gunicorn : 2( venv )$ gunicorn manage . py runserver : app 3# Usando el servidor de desarrollo de Flask : 4( venv )$ manage . py runserver Una vez puesta en marcha la plataforma, se crea automáticamente en la base de datos el usuario administrador indicado en el fichero de configuración, además también se le otorgan roles de investigador para poder crear encuestas. C.8. Asignación del rol investigador a un usuario Para asignar el rol de investigador a un usuario, inicie la shell del programa. Esto abrirá un interprete Python de la plataforma web. Entre las funciones disponibles están la de add_researcher ydelete_researcher, que sirven para dar y quitar permisos de investigador a un usuario dado. En la figura C.2, hay una muestra de comandos disponibles. C.9. Actualización Antes de actualizar la plataforma se recomienda hacer una copia de seguridad de la base de datos y del entorno virtualizado donde se ha instalado la plataforma. Los pasos para actualizar son los siguientes: Haga una copia de la configuración de la plataforma, config.py ysettings.cfg. Descargue la última versión de la plataforma mediante git: 1(venv )$ git pull 55 C. MANUAL DEL ADMINISTRADOR Instale los nuevos módulos requeridos: 1( venv ) $pip install -r requeriments . txt Compruebe si ha habido algún cambio en los ficheros de configuración. Actualice la base de datos si es necesario: 1( venv )$ ./ manage . py db migrate 2( venv )$ ./ manage . py db upgrade C.10. Log La plataforma por defecto guarda todos los mensajes con un nivel warning o superior en el fichero temp/swarms.log esta configuración se puede cambiar en el fichero config.py, también se puede elegir usar SysLogHandler para comunicarse remotamente con una maquina Unix, quién almacenará la información. Además también se enviará por correo al usuario indicado los mensajes con un nivel error o superior. El nivel de los mensajes se puede cambiar, los disponibles son los siguientes: critical. error. warning. info. debug. Mas información disponible en https://docs.python.org/2/library/logging.html. 56 Apéndice D Manual de investigador En este manual vamos a tratar las opciones que tiene un investigador para crear una encuesta. D.1. Inicio de sesión Existen dos posibilidades para iniciar la sesión, mediante el uso de una cuenta OpenID para lo cual puedes usar su cuenta de Google, Yahoo, Steam o cualquier otro servicio que haga uso de OpenID. O mediante el uso de un usuario y contraseña. Para ello previamente debe registrase en la plataforma y se le enviará un correo con la contraseña. OpenID Haciendo uso de un navegador entre en el portal web donde se encuentra alojada la plataforma y entre en el enlace Account, ver figura D.1, escriba la dirección del servidor OpenID el cual va usar para autentificarse o haga click sobre uno de los servidores predeterminados. Para entrar en la plataforma aprieta al botón Sign In, ver figura D.2. Correo Para registrarse en la plataforma, vaya a la dirección http://servidor/auth/ register, ver figura D.3, e introduzca el correo que quiere usar de registro. Una ver registrado, se le enviara un correo con la contraseña. Para iniciar sesión, vaya a la dirección http://servidor/auth/loginEmail e introduzca el correo con la que se registró y la contraseña que se le envió al correo, ver figura D.4: 57 D. MANUAL DE INVESTIGADOR Figura D.1: Página principal de la aplicación Figura D.2: Página de inicio de sesión mediante OpenID Figura D.3: Página de registro mediante correo 58 D.2 Creación de encuestas Figura D.4: Página de inicio mediante correo/contraseña Figura D.5: Barra de navegación D.2. Creación de encuestas Crear o editar una encuesta Una vez iniciado sesión en la plataforma, en la barra de navegación de la plataforma verá dos enlaces, figura D.5: Logout: para salir de la sesión. Researcher: para entrar en el módulo de creación de encuestas. Una vez dentro del modulo de creación de encuestas observara una página similar a la figura D.6, las opciones disponibles son las siguientes: 1. Botón New survey: Opción para crear una nueva encuesta. 2. Opción para modificar una encuesta ya creada, en este caso la encuesta ¿Cómo son nuestros voluntarios? 3. Botón export stats: Opción para exportar los resultados de una encuesta en formato CSV. 59 D. MANUAL DE INVESTIGADOR Figura D.12: Página de nueva sección 66 D.2 Creación de encuestas para cada usuario que empiece una encuesta. Por lo que un usuario puede realizar la encuesta con un orden distinto a otro usuario. Las secciones del mismo nivel con misma secuencia y porcentaje distinto de 1 son excluyentes. Esto quieres decir que si tienes tres secciones: Sección 1 con 0.3, Sección 2con 0.2 y Sección 3 con 0.5. El 30 % de usuarios realizarán la Sección 1, el 20% realizarán la Sección 2 y el 50 % realizarán la Sección 3. Una vez creada una sección, ver figura D.13, se le mostrarán las opciones para eliminar una sección, añadir una subsección a la sección dada, añadir/editar preguntas y duplicar la sección. Añadir nuevas preguntas Si realiza click en el botón de Add/Edit question dentro de una sección, D.13, ira a la página para añadir/editar preguntas. Preguntas cuya respuesta es Si o No Las opciones para las preguntas Si o No, ver figura D.14, son las siguientes: 1. Text: Texto de la pregunta, esta descripción soporta sintaxis Markdown. 2. Required: Si es una pregunta obligatoria o no. 3. Answer: La respuesta correcta de la pregunta si es que la tiene. “Yes”, si la respuesta correcta es si, "No" si la respuesta correcta es no. Este campo es opcional. 4. Number of attempt: Número de intentos para responder a la pregunta, en caso que la pregunta tenga una respuesta correcta. Nada, para infinitos intentos. El apartado SubQuestion yOptions game se explicará mas adelante. Preguntas cuya respuesta es un texto Las opciones para las preguntas cuya respuesta es un texto, ver figura D.15, son las siguientes: 1. Number: Si se desea validar que el texto introducido por el usuario en un número entero. 2. Number Float: Si se desea validar que el texto introducido por el usuario en un número flotante. 67 D. MANUAL DE INVESTIGADOR Figura D.13: Sección ya creada 68 D.2 Creación de encuestas Figura D.14: Creación de preguntas de tipo Si y No 69 D. MANUAL DE INVESTIGADOR Figura D.15: Creación de preguntas de tipo texto 70 D.2 Creación de encuestas 3. Regular Expression: Si se desea validar que el texto introducido por el usuario corresponde a una expresión regular, para ello se usa la sintaxis de Python de expresiones regulares. 4. Error Message: Mensaje de error personalizado ante el fallo a la hora de introducir la respuesta el usuario. 5. Answer: La respuesta correcta de la pregunta si es que la tiene. Se comprueba si es correcta después de validar que la respuesta tenga el formato apropiado. A la hora de comprobar la respuesta se ignora la coincidencia de mayúsculas/- minúsculas. 6. Number of attempt: Número de intentos para responder a la pregunta, en caso que la pregunta tenga una respuesta correcta. Nada, para infinitos intentos. Preguntas cuya respuesta es una opción posible Las opciones para las preguntas cuya respuesta es una opción posible, ver figura D.16, son las siguientes: 1. Answer: Respuesta correcta a la pregunta. 2. Number of attempt: Número de intentos para responder a la pregunta. 3. Render: Formato a la hora de mostrar las opciones posibles al usuario. Son tres: Vertical: Se muestran todas las opciones en vertical Horizontal: Se muestran todas las opciones en horizontal. Select: Se muestran todas las opciones en un formulario de selección como el elegido para mostrar las opciones de Render . 4. Range step: Si la respuesta esta formado por un rango de números, indica el salto entre un número y el siguiente. 5. Range min: Rango de inicio, si la respuesta está formado por un rango de números. 6. Range max: Rango máximo, si la respuesta está formado por un rango de números. 71 D. MANUAL DE INVESTIGADOR Figura D.16: Creación de preguntas de tipo selección 72 D.2 Creación de encuestas Figura D.17: Creación de preguntas de tipo escala likert 7. Answer 1: Respuesta posible. 8. Add other answer: Añadir otra respuesta posible. Preguntas cuya respuesta es una escala likert Las opciones para las preguntas cuya respuesta es una escala likert, ver figura D.17, son las siguientes: 1. Scale: Número inicial de la escala likert, puede ser 0 o 1. 2. to: Número final de la escala likert. 3. min: Etiqueta opcional para indicar el significado del valor mínimo de la escala. 4. max: Etiqueta opcional para indicar el valor máximo de la escala. 73 D. MANUAL DE INVESTIGADOR Figura D.18: Creación de preguntas dependientes de otras preguntas Preguntas dependientes de la respuesta a otra pregunta Todas las preguntas anteriores se pueden mostrar o no dependiendo de la respuesta dada a una pregunta. En la figura D.2 podemos ver las siguientes opciones: 1. SubQuestion: Menú desplegable que muestra las opciones para las subpreguntas 2. Type of operation: Operación con la que realizaremos la comparación, esta puede ser: Mayor, > Menor, < Igual, = Distinto, != 3. Value: Valor a comparar según la operación anterior indicada. 74 D.2 Creación de encuestas Figura D.19: Ejemplo de pregunta dependiente Figura D.20: Ejemplo de pregunta dependiente 4. Question: Pregunta de la que depende la respuesta. En las preguntas de Si o No, las respuestas posibles son "Yes" y"No" y solo tiene sentido las operaciones igual y distinto. En las preguntas cuya respuesta es un texto, todas las operaciones son posibles. En las preguntas de selección se muestra en Value todas las opciones posibles. En las preguntas de escala likert, se muestra en Value todas las opciones posibles. Las preguntas que dependen de otra respuesta solo se mostrará al usuario dependiendo de la respuesta dada, como se puede ver en las figuras D.19 y D.20. 75 E. GUÍA DE DESARROLLO 4’’’ 5for question in questions : 6if isinstance (question , QuestionDate ): 7if question . required : 8setattr ( AnswerForm ,"c"+ str ( question . id ), DateField ( ’Answer’,validators = [ Required () ]) ) 9else: 10 setattr ( AnswerForm ,"c"+ str ( question . id ), DateField ( ’Answer’,validators = [ Optional () ]) ) En el fichero útiles deberemos de modificar la función new_answer() el cual genera un objeto de tipo Answer dependiendo del tipo de pregunta: 1def new_answer ( question , form , user ): 2if isinstance (question , QuestionDate ): 3answer = Answer ( answerDate = form["c"+ str ( question .id)]. data , user = user , question = question ) 4answer . answerText = str ( answer . answerDate ) En el atributo answer.answerText siempre guardamos una representación del texto de la respuesta. Esto también se puede implementar con un atributo híbrido en el ORM. Con esto ya hemos terminado una implementación básica de una pregunta de tipo fecha. E.2. Preguntas de tipo casillas de verificación En está sección vamos a tratar brevemente de como incluir una pregunta, en la que puede haber múltiples respuestas. Modificación de la base de datos Lo primero que debemos de decidir es como almacenar todas las respuestas posibles a la pregunta, ya sea creando una clase nueva con todas las respuestas posibles a una pregunta, o almacenar en la pregunta todas las respuestas posibles, ya sea usando una lista (PickleType), JSON, o cualquier formato que se nos ocurra. En este caso hemos decidido implementarlo en una tabla nueva, para ello creamos primero la clase nueva, a la cual hemos añadido un nuevo atributo con el mínimo numero de opciones a marcar en la respuesta. 1class QuestionMultipleChoices(Question): 2’’’ Question with multiple choices 3’’’ 4__mapper_args__ = { ’polymorphic_identity’:’multipleChoices’} 5#: Minimum number of options 6min_choices = Column ( Integer , default = 0) 7choices = relationship ( ’Choice ’, 8cascade=" all , delete - orphan " , 9backref = ’question ’, lazy = ’dynamic’) 82 E.2 Preguntas de tipo casillas de verificación Después creamos una nueva clase con todas las opciones posibles para una pregunta: 1class Choice ( db . Model ): 2’’’A table with Choices to a Question with multiple Choices 3’’’ 4__tablename__ = ’choice’ 5#: unique id ( automatically generated ) 6id = Column ( Integer , primary_key = True ) 7#: Text for this choice 8text = Column ( String , nullable = False ) 9question_id = Column ( Integer , ForeignKey ( ’question . id ’)) Entre la clase Answer y la clase Choice tendremos una relación muchos a muchos, por lo que deberemos crear una tabla para ella, hacemos notar que creamos una tabla y no una clase nueva, ya que solo lo usaremos para crear una relación entre Answer yChoice, sin ningún atributo nuevo. 1class Answer ( db . Model ): 2’’’A table with answers 3’’’ 4__tablename__ = ’answer’ 5... 6choices = relationship (" Choice " , 7secondary = association_answer_choices , 8backref=backref(’answers’, remote_side = id), 9lazy = ’dynamic’, uselist = True ) Para añadir los cambios en la base de datos, debemos de migrar la base de datos y actualizarla, con los siguientes comandos: 1( venv )$ ./ manage . py db migrate 2( venv )$ ./ manage . py db upgrade Modificación del módulo Researcher Para modificar el módulo Researcher habrá que hacer una modificación análoga a la realizada en la modificación de añadir una pregunta de tipo fecha. Por otro parte se podría modificar el validador del formulario para comprobar que el número de respuestas mínimas necesario es correcto, ya que no podemos pedir mas opciones de las que hay. 1def validate ( self ): 2if self . questionType . data == ’multiplChoices’: 3l = get_choices () # return list with choices 4if len(l) ==0: 5self . errors . append ( " There should be a choice " ) 6if self . min_choices . data is not None : 7if self . min_choices .data >= len ( get_choices () ): 8self . min_choices . errors . append (" minimum of choices must be less than the maximum ") Además deberemos de añadir estas opciones a la base de datos: 83 E. GUÍA DE DESARROLLO 1def selectType ( form , section ): 2if form . questionType . data == ’multiple_choices’: 3question = QuestionMultipleChoices ( min_choices = form . min_choices . data ) 4for i in get_choices () : # return list with choices 5choice = Choice ( text = i, question = question ) 6db . session . add ( choice ) Modificación del módulo Answer Esta parte es análoga a la implementación de una pregunta de tipo fecha, solo que además añadiremos un validador para comprobar que el número marcado de opciones se corresponde con el mínimo exigido: 1class CheckMinChoices ( object ): 2’’’ check if the answer is the expected 3’’’ 4def __init__ ( self , n , message = None ): 5if not message: 6self.message = gettext(" minimum of choices must be %i" %n) 7else: # pragma : no cover 8self.message = message 9self . min_choices =n 10 11 def __call__ ( self , form , field ): 12 if len (form .data ) <self . min_choices : 13 raise ValidationError ( self . message ) Además cuando creemos el formulario añadiremos el validador: 1validators = [ Required () , CheckMinChoices ( question . min_choices )] También crearemos una lista con las opciones disponibles, cuyo índice será el identificador de cada opción, esta lista se la pasaremos al constructor de wtforms. fields.SelectMultipleField: 1choices = [( str ( choice . id ) ,choice . text ) for choice in question . choices ] Por último en el fichero útiles deberemos de modificar la función new_answer() el cual genera un objeto de tipo Answer dependiendo del tipo de pregunta: 1def new_answer ( question , form , user ): 2if isinstance ( question , QuestionMultipleChoice ): 3answer = Answer ( user = user , question = question ) 4// obtenemos la lista de elementos marcados : 5list_aux =[] 6for i in form ["c"+ str ( question . id)]. data : 7// obtenmos la opción marcada 8choice = Choice . query . get (i) 9// añadimos la opcion a la respuesta 10 answer . choices . append ( choice ) 11 // guardamos en una lista auxiliar la respuesta para guardarla también como texto 12 // pero no sería necesario 13 list_aux . append ( choice . text ) 14 answer . text = ’, ’. join ( list_aux ) 84 E.3 Encuestas en varios lenguajes E.3. Encuestas en varios lenguajes Puede ser muy útil tener una encuesta en múltiples idiomas, para ello la solución mas fácil y de las mas cómodas para el investigador es la de crear la encuesta en un idioma predeterminado y luego traducir esta a otros idiomas. La traducción se podría hacer con un simple editor de texto o integrando esta en la aplicación, para lo que bastaría crear una página con todos los textos de una encuesta e ir traduciendo. La forma mas sencilla sería almacenar en un formato como JSON o XML el texto y el idioma al que pertenece. Todo ello guardado en el mismo atributo. Esta podría ser una representación de un texto guardado: 1{ 2{" language ":"eng", 3"text ":" Hello wolrd "}, 4{" language ":"es", 5"text ":" Hola Mundo "}, 6} Para no cambiar todos los accesos a los textos, podemos hacer uso de @hybrid_property, para devolver solo el texto en el idioma deseado o en su defecto en el predeterminado. La plataforma ya hace uso de Babel, que es una colección de herramientas que sirve para la internacionalización de las aplicaciones escritas en Python, entre las funciones que tiene hay una que nos devuelve el idioma deseado por el usuario/navegador: 1request . accept_languages . best_match ( LANGUAGES . keys () ) Por lo que una clase como Survey quedaría de la siguiente manera: 1class Survey ( db . Model ): 2..... 3text_json = Column ( String , nullable = False ) 4@hybrid_property 5def survey (self , language = request . accept_languages . best_match ( LANGUAGES . keys () )): 6return get_text ( self . text_json , language ) E.4. Encuestas con preguntas que saltan a distintas secciones Otra mejora interesante para la plataforma, es saltar a alguna sección en concreto dependiendo de la respuesta dada a una pregunta. 85 E. GUÍA DE DESARROLLO Modificación de la base de datos: Para ello primero deberemos de crear un identificador único para cada sección especial. Podemos pensar en usar el identificador de cada sección, pero esto no es buena idea, ya que es la base de datos quien se encarga de administrarlo y puede ser poco amigable, por lo que decidimos que el nombre de la sección sea único. 1class Section ( db . Model ): 2... 3title = Column ( String (128) , nullable = False ) 4#: nos aseguramos que el titulo de la sección sea único en la encuesta 5__table_args__ = (UniqueConstraint(’title ’,’ survey_id ’) ,) Además modificaremos las preguntas de tipo test, QuestionChoice, para que dependiendo de la respuesta dada saltemos a una sección u otra, para facilitar el diseño usaremos la implementación realizada para las preguntas con casillas de verificación, en vez de guardar los posibles resultados en una lista. 1class QuestionChoice ( Question ): 2... 3choices = relationship ( ’Choice ’, 4cascade=" all , delete - orphan " , 5backref = ’question ’, lazy = ’dynamic’) 6 7class Choice ( db . Model ): 8’’’A table with Choices to a Question with multiple Choices 9’’’ 10 __tablename__ = ’choice’ 11 #: unique id ( automatically generated ) 12 id = Column ( Integer , primary_key = True ) 13 #: Text for this choice 14 text = Column ( String , nullable = False ) 15 question_id = Column ( Integer , ForeignKey ( ’question . id ’)) 16 #: id de la sección a la cual se realizará el salto . 17 section_id = Column ( Integer , ForeignKey ( ’ section . id ’)) 18 ## Relationships 19 section = relationship ("Section") 20 answer = relationship ("Answer") Por último modificamos la clase Answer, para que pueda tener una relación con la clase Choice: 1class Answer ( db . Model ): 2choice = Column ( Integer , ForeignKey ( ’ choice . id ’)) Modificación del módulo Researcher: Deberemos de modificar los formularios de añadir/editar sección, añadiendo la posibilidad de definir un identificador, por otra parte también se modificara la plantilla, /templetes/resarcher/addEditSection.html y la vista. Por otra parte también habrá que modificar las opciones dadas en las preguntas de tipo test, permitiendo asociar a cada respuesta un salto a una sección dada. 86 E.4 Encuestas con preguntas que saltan a distintas secciones Para ello podemos usar el campo definido por la clase wtforms.ext.sqlalchemy.fields. QuerySelectField : 1section = QuerySelectField (’Section’, get_label = ’text ’,validators =[ Optional () ]) Para rellenar el formulario, que estará formado por la tupla Section.id ytitle, título de la sección: 1form . section . query = Question . query . filter ( 2Survey . id == id_survey , 3Section . root == Survey , 4Section . title != id_section // evitamos poder saltar a la misma sección 5) Modificación de la clase StateSurvey Por último habrá que cambiar algo de la lógica de control de la encuesta, para poder realizar saltos a la sección indicada dependiendo de la respuesta dada. Cada usuario cuando empieza una encuesta, se le asocia una objeto a esa encuesta StateSurvey, que guarda la información relativa del usuario a esta encuesta, como puede ser si ha terminado la encuesta, cuanto tiempo lleva empleada en ella o por que sección va. La clase tiene un método llamado finishedSection, el cual se llama cuando se termina una sección y decide cual es la siguiente sección a realizar. Por lo que este sería un buen lugar para comprobar las respuestas dadas en la sección para comprobar cual es la siguiente sección a realizar. Primero buscamos la respuesta dada a la pregunta de la cual dependerá la próxima sección, para simplificar el proceso hemos supuesto que solo existe una pregunta de este tipo por sección y que será obligatoria. 1answer = Answer.query.filter( 2// obtenmos las preguntas de tipo Choice de la sección en la que estamos 3QuestionChoice . section_id == self . get_section , 4// obtenemos las posibles respuestas a la pregunta de tipo choice 5Choice . question == QuestionChoice , 6// Las posibles elecciones deben tener asociada un salto 7Choice . section != None , 8// buscamos todas las respuestas del usuario 9Answer . user_id == Self . user_id , 10 // y cogemos solo la que coincide con la pregunta 11 Answer . question == QuestionChoice 12 ). first () Por lo que en answer tenemos la respuesta dada por el usuario de la que dependerá la siguiente sección. 1self . nexSection == answer . choice . section 87 E. GUÍA DE DESARROLLO E.5. Plataforma en la nube Aquí vamos a tratar de como desplegar nuestra plataforma en la nube. Hemos elegido Heroku, no sólo porque es uno de los mas populares de la red, sino porque además ofrece también un nivel de servicio gratuito. Para implementar la plataforma web en Heroku, es tan fácil como subir la aplicación usando Git. Para las aplicaciones desarrolladas en Python se espera un fichero requirements.txt en la que se encuentran todos los módulos que deben instalarse. Primero nos crearemos una cuenta en Heroku y nos bajaremos el "cliente Heroku", una vez instalado el cliente, accederemos a nuestra cuenta y clonaremos nuestra plataforma desde GitHub y crearemos la plataforma en Heroku: 1$ heroku login 2$ git clone git:// github . com / nu_kru / swarm - survey . git 3$ cd swarm - survey 4$ heroku create swarm - survey Creating swarm - survey ... done , stack is cedar http : // swarm - survey . herokuapp . com / | git@heroku . com : swarm - survey . git Con esto ya tendríamos nuestra plataforma en la nube. Pero aun no hemos terminado, ya que Heroku impone unas cuantas restricciones: Las aplicaciones que se ejecutan en Heroku no escriben archivos permanentemente en el disco. La base de datos a usar debe ser PostgreSQL. No proporciona un servidor web. Migración del log Debido a que las aplicaciones que se ejecutan en Heroku no pueden escribir permanentemente en el disco, el log de la plataforma lo perderíamos cada cierto tiempo, para ello lo solucionaremos usando el log que nos proporciona Heroku, es mas si se observa el fichero config.py, ya tenemos escrita una configuración por si se lanza la plataforma en Heroku, que se encarga de modificar el log a los requisitos de la nube 1// log to stderr 2import logging 3from logging import StreamHandler 4file_handler = StreamHandler() 5file_handler . setLevel ( logging . WARNING ) 6app . logger . addHandler ( file_handler ) Para ver el log simplemente desde el cliente escribimos: 1$ heroku logs 88 E.5 Plataforma en la nube Esto nos mostrara todos los logs, tanto de la nube como de nuestra aplicación, si solo queremos ver la de la aplicación: 1$ heroku logs --source app Migración a PostgreSQL La plataforma de Heroku nos proporciona una URI por la cual podemos acceder a nuestra base de datos, como durante el desarrollo hemos usado SQLAlchemy, y no hemos usado características únicas solo disponible en ciertas bases de datos, la migración a PostgreSQL es transparente, sin tener que realizar ninguna modificación en el código. Por otra parte si se observa el fichero de configuración, la base de datos la obtenemos de una variable de entorno si está definida o sino de la ruta indicada por nosotros. Esta variable de entorno es la misma que usa Heroku para darnos la dirección de la bbdd por lo que no tendremos que realizar ningún cambio. 1class ProductionConfig(Config): 2SQLALCHEMY_DATABASE_URI = os . environ . get (’DATABASE_URL’) or \ 3’sqlite :/// ’ + os.path . join (basedir , ’data . sqlite ’) Servidor web Ya que Heroku no nos proporciona ningún servidor web, en su lugar espera que la aplicación ejecute su propio servidor en el puerto indicado por la variable de entorno $PORT. El servidor web proporcionado por Flask para el desarrollo no es conveniente usarlo en producción, ya que no es multihilo, en la documentación proporcionada por Heroku en las aplicaciones Python sugieren la instalación de Gunicorn, que es un servidor web escrito en Python, para hacer uso de él, lo podemos instalar vía pip, para ejecutar el servidor con la aplicación tan solo debemos escribir: 1gunicorn manage . py runserver : app Con esto ya tendríamos todo lo necesario para ejecutar nuestra aplicación en Heroku. Si se observa detenidamente las modificaciones a hacer en la plataforma son nulas, sobre todo gracias a la buena definición del fichero config.py, en el que hemos tenido en cuenta las distintas configuraciones de la aplicación, pasando por el modo de desarrollo al modo producción, con tres variantes posibles dependiendo de si la máquina contiene un sistema tipo UNIX, está en la nube o ninguno de estos casos. 89 E. GUÍA DE DESARROLLO E.6. Consideraciones en el desarrollo de la plataforma Durante el desarrollo de aplicaciones en Python se recomienda instalar todos los módulos a usar en entornos virtuales, además en nuestro caso como hemos hecho uso de pip para la instalación de cada módulo, podemos obtener una lista de todos los módulos instalados usando: 1( venv )$ pip freeze > requirements . txt 90 Apéndice F Análisis de requisitos de la aplicación En este anexo se presenta una descripción del análisis de requisitos que se llevo a cabo antes de realizar la implementación de la plataforma y durante las revisiones de esta. A lo largo del anexo se mostrará el documento de especificaciones de requisitos. Este documento no ha sido creado con el fin de ser completamente riguroso a las convenciones, aunque más de una vez se sigan, sino que el fin último es que el lector comprenda este documento. F.1. Especificación de Requisitos Software En este apartado vamos a hablar de los requisitos software que debe cumplir nuestra plataforma. Estos requisitos se elaboraron después del estudio de las herramientas actuales y el documento del experimento Project Q, por otra parte se ha intentado seguir las recomendaciones dadas en la Especificación de Requisitos según el estándar IEEE 830. Introducción Propósito El propósito es definir cuáles son los requerimientos que debe tener la plataforma para elaboración de encuestas, así como la adaptación de está al experimento Project Q. La aplicación se desarrollara como proyecto final de carrera y permitirá el desarrollo del experimento anteriormente citado, así como ayudar a la comunidad científica en la elaboración de encuestas mas o menos complejas, en los que se quiera aleatorizar el orden de las secciones, así como la existencia de secciones excluyentes. 91 F. ANÁLISIS DE REQUISITOS DE LA APLICACIÓN 98 Apéndice G Enrutamiento El diseño de rutas de la plataforma, nos permite tener una visión clara de la funcionalidad de la aplicación. Como ya hemos explicado anteriormente en el apéndice H, la plataforma está subdividida en varios módulos, a cada módulo se accede mediante una ruta distinta. A la hora de elegir las rutas siempre se ha tenido en cuenta el requisito de que sean amigables y fácilmente recordables. A continuación veremos como Flask resuelve las rutas, así como un resumen del mapa de rutas de la aplicación. G.1. Resolución de rutas en Flask Las rutas son las URL o localizador de recursos uniforme que nos permite acceder a las distintas funcionalidades de la plataforma. Flask posee tres formas de definir las reglas de las rutas en el sistema: Usando el decorador flask.Flask.route(). Usando la función flask.Flask.add_url_rule(). Accediendo directamente al sistema de rutas de Werkzeug, el cual está expuesto mediante flask.Flask.url_map. Para el desarrollo de la plataforma se ha elegido la opción del decorador, debido a la sencillez de uso y a la abstracción de la función y la ruta usada para esta. La ruta se define mediante una cadena que simboliza la regla de una URL, la cual puede contener variables, de tal manera que la variable de la URL se le pasará a la función de Python que está decorando. Además en estas rutas se puede limitar el método de petición HTTP (GET, POST, PUT...). 99 G. ENRUTAMIENTO En el siguiente ejemplo vemos que para acceder a la vista que nos permite modificar una encuesta, debemos usar la ruta /survey/N, siendo N el número de la encuesta, además podemos acceder mediante los métodos GET y POST. También se puede acceder mediante la cadena "titulo_de_la_encuesta_id_survey", para facilitar el acceso. 1@blueprint . route ( ’/ survey /< int : id_survey > ’, methods = [’ GET ’,’POST ’]) 2@blueprint . route ( ’/survey/<string:title_survey >’, methods = [’GET ’,’POST ’]) 3... 4def editSurvey ( id_survey ): G.2. Rutas de la aplicación Como se explica en el apéndice H.3, la plataforma creada tiene distintos módulos, cada una registrada en un prefijo URL distinto, gracias al uso de blueprints, a continuación vamos a detallar las distintas rutas de la aplicación dividida en módulos. Módulo main Todas las direcciones de este módulo están bajo la raíz de la dirección web y están disponibles para todos los usuarios. /- Autentificación mediante OpenId /login - Autentificación mediante OpenId /loginEmail - Autentificación mediante correo/contraseña /register - Registro de cuenta de usuario /logount - Cierre de la sesión actual Módulo de investigador Todas las direcciones de este módulo están bajo la ruta /researcher y solo pueden acceder aquellos usuarios que sean investigadores. /- Listado de las encuestas de un investigador /index - Listado de las encuestas de un investigador /new - Creación de una nueva encuesta /survey/<survey> - Modificación de una encuesta /survey/deleteSurvey/<survey> - Eliminación de una encuesta /survey/exportSurvey/<survey> - Exportación de una encuesta /survey/<survey>/consent/add - Creación de un consentimiento 100 G.2 Rutas de la aplicación /survey/<survey>/consent/<consent>/delete - Eliminación un consentimiento /survey/<survey>/consent/<consent> - Modificación de un consentimiento /survey/<survey>/section/new - Creación de una sección nueva /survey/<survey>/section/<section> - Modificación de una sección /survey/<survey>/deleteSection/<section> - Eliminación de una sección /survey/<survey>/duplicateSection/<section>/section/<section2> - Duplicación de una sección /survey/<survey>/duplicateSection/<section>/survey/ - Duplicar una sección /survey/<survey>/section/<section>/new - Creación de una subsección /survey/<survey>/section/<section>/addQuestion - Creación de una pregunta /survey/<survey>/section/<section>/question/<question> - Modificación de una pregunta /survey/<survey>/Section/<section>/deleteQuestion/<question> - Eliminación de una pregunta /survey/exportStats/<survey> - Exportación de las estadísticas de una encuesta Módulo del encuestado Todas las direcciones de este módulo están bajo la ruta /survey y está disponible para todos los usuarios que hayan iniciado sesión. /- Listado de las encuestas /index - Listado de las encuestas /<survey> - Inicio de una encuesta /<survey>/consent - Muestra el consentimiento de una encuesta /<survey>/consent/<consent> - Muestra el consentimiento de una encuesta /<survey>/section/<section> - Muestra una sección de una encuesta para que el encuestado la responda Módulo de feedback Todas las direcciones de este módulo se encuentran bajo la ruta /feedback y está disponible para todos los usuarios que hayan iniciado sesión. 101 G. ENRUTAMIENTO /<survey> - Muestra feedback sobre las decisiones tomadas en la encuesta /<survey>/<feedback> - Muestra feedback sobre las decisiones tomadas en la encuesta Módulo de visualización de estadísticas Todas las direcciones de visualización de estadísticas se encuentran bajo la ruta /stats y está disponible para todos los usuarios que sean investigadores. /- Listado de las encuestas disponibles /index - Listado de las encuestas disponibles /<survey> - Listado de los resultados de una encuesta /<survey>/games - Listado de los juegos disponibles de una encuesta /<survey>/games/<game> - Listados de los resultados de los juegos de una encuesta 102 Apéndice H Esqueleto En este apartado vamos a indicar el esqueleto sobre el que hemos construido la aplicación, haciendo uso de las distintas tecnologías mencionadas en el contexto tecnológico. H.1. Flask Siguiendo los distintos consejos dados en la documentación de Flask, así como las recomendaciones de patrones para Flask, la estructura de nuestra plataforma de encuestas es la siguiente: SwarmSurvey - Directorio raíz de la aplicación manage.py - Se encarga de la gestión de la aplicación, ya sea ejecutar el servidor, migrar la base de datos, o entrar en la interfaz de linea de comandos de la aplicación config.py - Fichero de configuración base, usando un modelo de herencia de clases para la configuración, así como el uso de variables de entorno para cambiar de configuración app auth - Módulo para el registro y autentificación de los usuarios __init__.py - Fichero de inicialización del módulo forms.py - Formularios que se mostrarán en las plantillas para el registro y autentificación de usuarios validators.py - Fichero con los distintos validadores creados para comprobar los formularios 103 H. ESQUELETO views.py - Fichero con la resolución de rutas y las funciones expuestas a través de estas rutas (eg: /login, /register...) feedback - Módulo que da soporte de feedback al experimento ProjectQ ... funtion_jinja - Módulo que contiene distintas funciones creadas para el generador de plantillas jinja2 __init__.py functions.py game - Módulo que contiene la lógica a la hora de seleccionar los usuarios para los juegos del experimento ProjectQ __init__.py game.py - Juegos del apartado 3 del experimento ProjectQ game_impatience.py -Juegos del apartado 2 del experimento ProjectQ raffle.py - Rifa del experimento Project Q main -Módulo que contiene la información básica de la plataforma __init__.py errors.py - Personalización de los distintos errores que puede lanzar la plataforma, ya sean por parte del cliente(4xx) o del servidor(5xx) views.py - Vistas del la ruta raiz (/), así como el selector de idioma. researcher - Módulo para la creación de encuestas por parte de los investigadores ... scheduler - Módulo para la planificación de tareas en el tiempo ... surveys - Módulo para visualizar y contestar encuestas por parte de los usuarios. ... static - Directorio que contiene los elementos estáticos de la plataforma web, como puede ser el uso de imágenes, css... css - Directorio que contiene los ficheros CSS de la aplicación 104 H.1 Flask img -Directorio que contiene las imagenes de la apliacación js - Directorio que contiene los ficheros JavaScript de la aplicación text - Directorio que contiene ficheros de texto de la aplicación stats - Módulo que contiene la generación y visualización de estadísticas y resultados de las encuestas así como del experimento Project Q ... templates - Directorio con las distintas plantillas usadas para la generación de las distintas páginas web auth - Directorio con las plantillas del módulo auth login.html - Plantilla de inicio de sesión a través de OpenID register.html - Plantilla de registro loginEmail.html - Plantilla de inicio a través de correo/contraseña feedback - Directorio con las plantillas de modulo de feedback ... ... translations - Directorio con los distintos idiomas que soporta la plataforma es - Traducción al español en - Traducción al ingles __init__.py - Fichero de inicialización de la plataforma web decorators.py - Fichero con las funciones para la protección de las distintas vistas de la plataforma models.py - Declaración del modelo de clases que hace uso de la base de datos. ... migrations - Directorio que contiene la información necesaria para la migración de la base de datos, este directorio se genera automáticamente. ... tests - Directorio que contiene los distintos tests unitarios del sistema test_models.py - Fichero con los test del modelo ... logs - Directorio con los logs de la aplicación 105 H. ESQUELETO H.2. MVC implantado A continuación se va a explicar brevemente como se trabaja con el MVC implantado en la plataforma. El motor de Flask recoge todas las peticiones http que llegan al servidor y busca si existe alguna función para la ruta recibida (ficheros views.py). Si el patrón encaja con una ruta reconocida, ejecuta la función del "Controlador" correspondiente a esa ruta. El controlador es una función en Python que al final termina devolviendo una respuesta HTTP a la petición recibida. La respuesta suele ser una página web, la cual se genera a través de una plantilla (ficheros del directorio templates), normalmente para la generación de esta "Vista", se necesita información de la base de datos (fichero models.py), esto sería el "Modelo". H.3. Plataforma Modular Como se ha vista en el esqueleto de la aplicación, existen varios módulos en la aplicación, cada uno con sus ficheros views.py, que contienen las rutas y los controladores. Para facilitar esta modulación se utiliza el concepto de blueprints en Flask, simplificando en gran medida permite la creación de grandes aplicaciones, al poder extender la aplicación a través de módulos. Aparte de lo anteriormente citado, el uso de blueprints nos permite: Registrar un módulo en un subdominio o prefijo URL, incluyendo de manera transparente las rutas del fichero views, al subdominio o prefijo URL. También permite registrar varias veces el mismo módulo en diferentes subdominios o prefijos URL. Los blueprints se registran al inicio de la aplicación, por lo que se puede implementar distintas funcionalidades como extensiones de la plataforma principal Por ejemplo, para registrar el módulo auth bajo la ruta /auth y/autentificación, simplemente hace falta añadir al fichero de inicialización de la plataforma las siguientes lineas: 1from .auth import auth as auth_blueprint 2app . register_blueprint ( auth_blueprint , url_prefix =’/ auth ’) 3app . register_blueprint ( auth_blueprint , url_prefix =’/ autentificacion ’) 106 Apéndice I Seguridad En el capítulo G pudimos ver el listado de todas las rutas de acceso disponibles. Alguna de estas rutas son algo especiales, ya que solo están disponibles para una serie de usuarios con ciertos permisos . En este capítulo vamos a tratar como se gestiona la autenticación y los permisos de acceso a las distintas rutas web del programa. I.1. Autenticación de usuarios Para la autenticación de usuarios se ha hecho uso de la extensión Flask-Login, el cual proporciona una gestión básica de sesiones de usuarios para Flask, manejando tareas tan comunes como inicio, cierre e identificación automática de sesiones. Existen dos formas de autenticación: Mediante correo y contraseña, como se puede ver en la figura I.1, se lee de un formulario, el correo y la contraseña introducida por el usuario, primero se verifica que el usuario existe, y luego se comprueba que el hash de la contraseña es correcta. 1@blueprint . route ( ’/ loginEmail ’, methods=[’GET ’,’POST ’]) 2def loginEmail () : 3form = LoginFormEmail() 4if form . validate_on_submit (): 5user = User . query . filter_by ( email = form . email . data ). first () 6if user is not None and user . verify_password ( form . password . data ): 7login_user ( user , form . remember_me . data ) 8return redirect ( request . args . get ( ’next ’) or url_for(’ main . index ’)) 9flash ( gettext ( ’Invalid email or password . ’)) 10 return render_template(’ auth / loginEmail . html ’, form=form) Figura I.1: Autenticación mediante correo y contraseña 107 J. CONTROLADOR 1class LikertField ( RadioField ): 2’’’my implement of likert field ’’’ 3def __init__ ( self , label =’’, validators = None , labelMin ="", labelMax ="", ** kwargs ) : 4self . labelMin = labelMin 5self . labelMax = labelMax 6super ( LikertField , self ). __init__ ( label, validators , ** kwargs ) 7 8def __call__ ( self , ** kwargs ) : 9’’’ render likert as table 10 ’’’ 11 from wtforms . widgets . core import html_params , HTMLString 12 kwargs . setdefault ( ’id ’, self.id) 13 kwargs . setdefault ( ’class_’," table table - condensed likert ") 14 html = [ ’< %s %s >’ % (" table " , html_params (** kwargs ) )] 15 html . append ( ’<tr >’) 16 html . append ( ’<td ></td > ’) 17 for subfield in self : 18 html . append ( ’<td > %s </ td > ’ % ( subfield . label )) 19 html . append ( ’ </tr > ’) 20 html . append ( ’<tr >’) 21 html . append ( ’<td class =" type - info"> %s </td >’ % ( self . labelMin )) 22 for subfield in self : 23 html . append ( ’<td > %s </ td > ’ % ( subfield () )) 24 html . append ( ’<td class =" type - info"> %s </td >’ % ( self . labelMax )) 25 html . append ( ’ </tr > ’) 26 27 html . append ( ’</ %s>’ %" table ") 28 return HTMLString ( ’’. join ( html )) Figura J.5: Campo likert Figura J.6: Visualización de la escala likert 114 J.2 Formularios 1class CheckSubquestion(object): 2’’’ check whether to answer the question or not 3’’’ 4def __call__ ( self , form , field ): 5question = Question . query . get ( field . name [1:]) 6# get answer of the question that depend 7data = form["c"+ str ( question . parent . id )]. data 8if question . check_subquestion ( data ): 9pass 10 else: 11 # nothing to check 12 field . errors [:] = [] 13 raise StopValidation() Figura J.7: Validador personalizado un sistema sencillo y flexible que permite añadir a cualquier campo una cadena de validadores. Además de unos validadores básicos, WTForms permite la creación de validadores personalizados, que se adapten a las necesidades del sistema. Al igual que WTForms provee una serie de validadores básicos, como puede ser Lenght, para comprobar la longitud de un campo introducido, también permite crear validadores personalizados, como se puede ver en la figura J.7, se ha creado un validador para comprobar si una subpregunta hay que validarla o no, en función de la respuesta de la pregunta de la que depende. Trabajo con formularios Al principio de este capítulo hemos explicado el funcionamiento de un controlador, y durante el resto del capítulo se ha explicado la creación y personalización de formularios. En la figura J.8 se muestra un fragmento del controlador para editar encuestas, para ejemplificar como trabajan juntos el controlador y los formularios. Cuando se recibe una petición para editar una encuesta, se busca dicha encuesta en el modelo Survey.query.get(id_survey), y se utiliza los datos de la encuesta para crear una instancia del formulario, form.title.data = survey.title, esto permitirá que el formulario aparezca relleno con los valores actuales de la encuesta que se pretende editar. Una vez que el investigador modifica el formulario y guarda los cambios, vuelve a entrar en juego el controlador, esta vez atendiendo a la petición POST. Se comprueba que los datos del formulario son validos mediante el metodo form.validate_on_submit(), si son validos se modifica el modelo y se guarda los cambios realizados, survey.title 115 J. CONTROLADOR 1@blueprint . route ( ’/ survey /< int : id_survey > ’, methods = [’ GET ’,’POST ’]) 2@login_required 3@researcher_required 4@belong_researcher(’ survey ’) 5def editSurvey ( id_survey ): 6survey = Survey . query . get ( id_survey ) 7form = SurveyForm () 8if form . validate_on_submit (): 9survey . title = form . title . data 10 ... 11 db . session . add ( survey ) 12 db . session . commit () 13 flash ( ’Your changes have been saved . ’) 14 elif request . method != " POST ": 15 form . title . data = survey . title 16 ... 17 return render_template(’/ researcher / editSurvey . html ’, 18 title = survey . title , 19 form = form , 20 survey = survey) Figura J.8: Controlador para editar encuestas = form.title.data,db.session.commit. Si existiera algún error, al volver a generar la vista, se mostraría estos errores, render_template. 116 Apéndice K Plantillas En este capítulo se tratará de explicar como se generan las plantillas, que es la parte encargada de generar la vista en el patrón modelo vista controlador. K.1. Motor de plantillas Jinja2 Jinja2 es un motor de plantillas, es decir un software que está diseñado para combinar una o mas plantillas con un modelo de datos para producir un documento resultado, en nuestro caso una página web. Por otra parte cada plantilla contiene un esqueleto de la vista y una serie de variables y expresiones que son remplazadas con los valores obtenidos del modelo cuando se evalúa la plantilla para así poder generar una vista de manera dinámica. En Jinja2 existen dos tipos de delimitadores: { % ... %}es usado para ejecutar sentencias como puede ser bucles o la asignación de valores {{..}} se utiliza para imprimir variables o el resultado de una expresión. Por ejemplo en el controlador index del modulo Researcher, se encarga de recoger de la base de datos todas las encuestas creadas por un investigador, estas encuestas son pasadas junto con una plantilla a la función render_templete que se encarga de generar la vista. Esto se puede observar en la figura K.1. Desde la plantilla podremos crear un listado con enlaces a las distintas encuestas del investigador, como se aprecia en la figura K.2. 117 K. PLANTILLAS 1def index (): 2surveys = Survey . query . filter ( Survey . researcher == g. user ). order_by ( Survey . created . desc ()) 3return render_template(’/ researcher / index . html ’ , 4tittle = ’Survey’, 5surveys = surveys) Figura K.1: Controlador researcher.index 1{ % extends "base.html" %} 2{ % block content %} 3<h1 > Researcher ! </h1 > 4<div > 5<a class =" btn btn - primary btn " href=" {{ url_for (’ researcher . new ’) }} " >{{ (’ New survey ’) }} </a > 6</div > 7<ul > 8{ % for survey in surveys %} 9<li ><a href ="{{ url_for (’ researcher . editSurvey ’, id_survey = survey . id ) }} " >{{ survey . title }} </a > </li > 10 { % endfor %} 11 </ul > 12 { % endblock %} Figura K.2: Plantilla de listado de encuestas K.2. Estructura El motor Jinja2, entre sus distintas características permite la herencia de plantillas, esto permite crear una plantilla base, que contiene todos los elementos comunes del sitio web y define los bloque que las plantillas descendientes pueden sustituir. Como se puede ver en la figura K.2, se ha optado por una plantilla base, { % extends "base.html" %}, que contiene los elementos básicos que se repiten a lo largo de las paginas web, como puede ser la barra de navegación o los ficheros de estilo y JavaScript. Además para simplificar el uso de formularios en la página web se ha creado una serie de macros, que facilitan la generación del código de los formularios. Además se encargan de mostrar los errores si los ha habido a la hora de rellenar el formulario. Por ejemplo en la figura K.3, se observa que se usa la macro render_field, para renderizar los distintos campos del formulario, así como indicar el tamaño que deben tener, o alguna miga de pan, con la información que debe incluir el investigador. En las figura K.4 podemos ver el aspecto final una vez generado la plantilla. La figura K.5 muestra un error producido a la hora de validar la plantilla. 118 K.2 Estructura 1{ % from " formHelpers . html " import render_field %} 2... 3<form method = "post " class ="form - horizontal "> 4{{ form . hidden_tag () }} 5{{ render_field ( form .title , size = 64) }} 6{{ render_field ( form . description , rows = 10 , style = ’ width :100 % ’) }} 7{{ render_field ( form . startDate , size = 128 , placeholder =" %Y- %m- %d %H: %M: %S") }} 8{{ render_field ( form . endDate , size = 128 , placeholder =" %Y- %m- %d %H: %M: %S")}} 9{{ render_field ( form . maxNumberRespondents ) }} 10 {{ render_field ( form . duration )}} 11 {{ render_field ( form . surveyXml )}} 12 <div class =" btn - group " > 13 <input class=" btn" type="submit" value ="Create Survey"> 14 <a class=" btn " href=" {{ url_for (’ researcher . index ’) }} " >{{ (’Cancel’) }} </ a> 15 </div > 16 </form > Figura K.3: Plantilla nueva encuesta Figura K.4: Vista generada de una nueva encuesta 119 K. PLANTILLAS Figura K.5: Vista generada de una nueva encuesta en la que hay un error 1LANGUAGES = { 2’en ’:’English’, 3’es ’:’Español’ 4} Figura K.6: Lenguajes disponibles K.3. Traducción Para hacer que nuestra aplicación sea accesible a usuarios con distintos idiomas, se ha utilizado la extensión Flask-Babel, que proporciona una herramienta fácil de usar para traducir las distintas partes de la aplicación ya sea en el lado de las plantillas o ficheros escritos en python, todo ello usando la interfaz de internacionalización gettext de GNU. Selección de idioma La figura K.6 contiene parte del fichero de configuración, donde están definidos los lenguajes disponibles. Luengo en cada petición que se realiza a la plataforma, Babel se encarga de decidir cual es el idioma a mostrar al usuario, como se puede ver en la figura K.7. Traducción de ficheros Una vez que se tiene seleccionado el idioma, Babel se encarga de buscar una traducción a aquellos textos que se hayan señalado previamente. En los ficheros python se usa la función gettext para extraer el texto a traducir, como se puede observar en el siguiente ejemplo: 1password = PasswordField ( gettext (’Password ’), validators =[ Required () ]) 1from config import LANGUAGES [email protected] 3def get_locale () : 4return request . accept_languages . best_match ( LANGUAGES . keys () ) Figura K.7: Selección de idioma 120 K.3 Traducción Figura K.8: Captura de la herramienta Lokalize Para la traducción de plantillas se realiza algo similiar, pero en vez de getttext, se usa _(). Por ejemplo para traducir el enlace Logout de nuestra plantilla base: 1<a href =" {{ url_for (’ auth . logout ’) }} " >{{ _( ’Logout’) }} </a > Una vez que tenemos seleccionado todos los textos a traducir de nuestras plantillas y ficheros python, se extraen todos ellos mediante el siguiente comando: 1pybabel init -i messages . pot -d app / translations -l es esto genera un catálogo con los textos a traducir, luego con una herramienta externa como puede ser Lokalize, ver figura K.8, se traducen los textos a los distintos idiomas disponibles en la plataforma. Por último, una vez traducido todos los textos hay que generar un fichero con los textos traducidos en un formato optimizado, para ello se utiliza el siguiente comando: 1pybabel compile -d app / translations 121 K. PLANTILLAS K.4. Funcionalidades en el lado del navegador JavaScripts es un lenguaje de programación interpretado que se usa principalmente en el lado del cliente, implementado como una parte del navegador web, permitiendo entre otras cosas mejoras en la interfaz del usuario, comunicación asíncrona con el servidor o el añadir ciertas funcionalidades en el lado del cliente. En las diferentes plantillas que generan código html, se ha incluido un bloque para los distintos códigos JavaScripts embebidos, que añaden distintas funcionalidades en la página web servida al usuario. Alguna de estas funcionalidades son las siguientes: En las vistas que muestran las distintas tablas con los resultados obtenidos en la encuesta así como en los distintos juegos, se puede ordenar la tabla por cualquier columna, evitando el tener que recargar la página y sobrecargar al servidor con esta operación. A la hora de crear o modificar encuestas y preguntas, la interfaz de usuario se ha mejorado y simplificado mostrando únicamente las distintas opciones posibles, así como ocultando las opciones menos comunes. Renderizado en tiempo real de los textos escritos en sintaxis Markdown. Generación de gráficos. Cálculo de tiempos empleados a la hora de contestar cada pregunta. Ocultar o mostrar las distintas preguntas dependiendo de las respuestas anteriores dadas. 122 Apéndice L Diseño En este apéndice se muestra con mas detalle algunos de los diagramas, omitidos en el capítulo 4. L.1. Diagrama de clases Las figuras L.1 y L.2 muestran el diagrama de clases final implementado que hace uso de la base de datos, representando únicamente el modelo estático del sistema. Las figuras L.3 y L.4 muestran las clases añadidas para el experimento Project Q. Este esquema se ha obtenido directamente del modelo creado usando la herramienta Sadisplay [39]. L.2. Esquema Relacional En la figura L.5 mostramos el esquema relacional, generado automáticamente por el ORM SQLAlchemy. Aunque no se aprecia en el esquema, existen las siguientes restricciones en la declaración del modelo que se trasladan a la base de datos: Tabla stateSurvey, la tupla user_id ysurvey_id es única. Tabla condition, la tupla subquestion_id yparent_id es única. Tabla answer, la tupla user_id yquestion_id es única. Tabla user, el valor de email es único. En la figura L.2 se muestra el esquema relacional, donde se guardan los resultados de los distintos juegos y sorteos Las restricciones de estas tablas son las siguientes: 123 L. DISEÑO Figura L.8: Diagrama de casos de uso de un investigador Figura L.9: Diagrama de casos del administrador 130 L.4 Capturas Figura L.10: Página de inicio Figura L.11: Consentimiento del experimento L.4. Capturas Las figuras L.10, L.11, L.12 y L.4 muestran distintas capturas de pantalla del experimento Project Q. 131 L. DISEÑO Figura L.12: Aspecto del cuestionario Figura L.13: Feedback al usuario 132 Apéndice M ¿Cómo son nuestros voluntarios? Este anexo incluye parcialmente el documento de partida que se uso para realizar el experimento y la plataforma. En las decisiones 1, 2 y 3 de la parte 3 solo se ha incluido el texto de los distintos juegos y las preguntas de la decisión 1 debido a su similitud. M.1. Proyecto "¿Cómo son nuestros voluntarios?" Antonio Espín (Universidad de Granada) Pablo Brañas-Garza (Middlesex University) Anxo Sánchez (Universidad Carlos III) Equipo Ibercivis M.2. Introducción y motivación El proyecto se propone caracterizar de manera detallada el perfil de los voluntarios que toman parte en los proyectos de ciencia ciudadana de Ibercivis. El punto de partida es el trabajo "Experimental subjects are not different" [F. Exadaktylos, A. M. Espín & P. Brañas-Garza, Sci. Rep. 3, 1213 (2013)], donde se comparó a los sujetos experimentales típicos de los laboratorios de economía con la población general. Los resultados de la acción en Ibercivis permitirían: Comparar a los voluntarios de Ibercivis con la muestra de población general del trabajo citado y analizar su representatividad Caracterizar a una población amplia de voluntarios para después solicitar su colaboración en futuros proyectos seleccionándolos conforme a su perfil 133 M. ¿CÓMO SON NUESTROS VOLUNTARIOS? M.3. Ejecución del proyecto Nos ocupamos aquí de la implementación de la primera fase, la realización de una encuesta con incentivos económicos para que las decisiones tomadas se correspondan con las que se esperan de la teoría económica. De cara a la segunda fase, sería necesario almacenar las respuestas de los voluntarios de manera que fuera compatible con la preservación de su anonimidad y con la ley de protección de datos. La encuesta que deben realizar los voluntarios se presenta en detalle a continuación, junto con las correspondientes observaciones sobre implementación. Por supuesto, todos aquellos puntos que no queden claros los resolveremos en conjunto, incluyendo posibles dificultades técnicas. M.4. Encuesta Instrucciones Nota de los investigadores: Estas instrucciones deben presentarse a los voluntarios al acceder a la aplicación. Deben terminar con una pregunta sobre si las han comprendido y sobre si aceptan las condiciones de participación. En particular, hay que asegurarse de que entienden que algunas cosas se pagarán y otras no, y si se les paga con qué probabilidad. Aquí como a lo largo del documento hay partes que deben aparecer en dos versiones; cada voluntario al llegar a cada uno de esos puntos es asignado a una de las dos versiones al azar, pero se debe registrar por cuales ha ido pasando. Gracias por participar en este proyecto de investigación. Nuestro objetivo es entender cómo se toman las decisiones, y no esperamos ningún comportamiento en concreto por tu parte. Tus respuestas serán guardadas respetando en todo momento tu anonimato; los investigadores no tendrán acceso a tus datos personales ni podrán conectar sus respuestas con ellos de ninguna manera. Además, se te incluirá en la base de datos de Ibercivis para, llegado el caso, solicitar tu colaboración voluntaria en futuras investigaciones. A continuación se te pasará a una encuesta, que consta de tres partes: una primera consistente en una batería de preguntas sobre distintos aspectos de tu personalidad, y dos partes en las que se te presentarán diversos escenarios en los que tendrás que tomar decisiones; en un caso serán decisiones que sólo dependen de ti, mientras que 134 M.4 Encuesta en el otro dependerán también de lo que haga otro participante anónimo escogido al azar, que no te conoce y al que tú no conoces (y nunca se os revelarán vuestras identidades), y que puede haber escogido sus respuestas antes o después que tú. En la segunda y tercera partes, las cuestiones se plantean en términos de una ganancia económica. En algunos casos, esa ganancia económica es meramente hipotética; sin embargo, para el objetivo del proyecto, es importante que tomes tus decisiones como si realmente fueras a recibir ese dinero. En otros, uno de cada diez participantes en el proyecto, elegidos al azar, recibirá el pago asociado a una de sus decisiones, también escogida al azar. Al final de la encuesta se te comunicará si has sido seleccionado y en tal caso se te informará del procedimiento para el pago. Tu participación en el proyecto te llevará entre media hora y una hora. Es deseable que participes sin interrupción, realizando la encuesta de principio a fin. Sin embargo, si no te fuera posible, podrás guardar tus respuestas hasta el punto al que hubieras llegado y terminarla después. ¿Aceptas las condiciones de participación? Sí (S), No (N) ¿Eres consciente de que no todas las decisiones de las partes segunda y tercera se pagarán con dinero real, y de que cuando lo vaya a ser se pagarán sólo a uno de cada diez participantes elegidos al azar? Sí (S), No (N) Nota de los investigadores: Esto exige el asignar un login al voluntario e implementar una manera de guardar las respuestas. El login puede ser también la manera de referirse a los voluntarios para futuras solicitudes de colaboración; los datos pueden estar asociados al login y podríamos tener una base de datos aparte donde los logins estén asociados a la persona, y a la que nosotros no tendríamos acceso. Tenemos que implementar además una manera de pagar. No son muchos, en principio se podría hacer manualmente, pero tenemos que verlo. Además de las respuestas, hay que guardar el momento en que van pinchando en cada opción, para luego analizar los tiempos que emplean en cada decisión, y poder identificar posibles respuestas al azar. Primera parte Bloque 1 1. Año de nacimiento 2. Localidad de nacimiento (y país si no es España) 135 M. ¿CÓMO SON NUESTROS VOLUNTARIOS? 3. ¿Hombre?: Sí (S), No (N) 4. Estado civil: soltero (1), casado (2), divorciado/separado (3), viudo (4), convive en pareja (5) 5. ¿Cuántos hijos has tenido? 5.1 ¿Viven todos actualmente?: Sí (S), No (N) 6. Consideras que tu estado de salud es: muy malo (1), malo (2), regular (3), bueno (4), muy bueno (5) 7. ¿Eres fumador/a?: Sí (S), No (N) 7.1 (Si fuma)Número medio de cigarros diarios 7.2 (Si fuma)¿Has intentado alguna vez de dejar de fumar? 7.3 (Si lo ha intentado) ¿Cuántas veces? 8. ¿Tienes algún tipo de discapacidad reconocida?: no (0), entre 33 % y 65 % (1), más de 65 % (2) ... 16. ¿Has cambiado tu denominación religiosa a lo largo de tu vida?: Sí (S), No (N) 16.1 (Si ha cambiado) Antes te denominabas: (ídem 15) 16.2 (Si ha cambiado) ¿A qué edad te cambiaste? 17. Crees que el éxito en la vida se debe principalmente a (sólo una opción): a) La suerte b) El esfuerzo 136 M.4 Encuesta Bloque 2 Ahora tienes que responder si estás de acuerdo o no con las siguientes afirmaciones en una escala de 1 a 7. 1 significa totalmente en desacuerdo y 7 totalmente de acuerdo, el punto neutral es el 4. Nota de los investigadores: Para esto tenemos que acordar una forma visual para las likert (las escalas de 1 a 7) que nos guste y que sea cómoda para los voluntarios. Cada pregunta lleva una escala para contestar. 18. Estoy dispuesto a hacer un trabajo aburrido para devolver una ayuda previa. 19. Estoy dispuesto a dedicar tiempo y esfuerzo para devolver una injusticia que me hayan hecho 20. No me preocupa cuánto dinero tengo, lo que me preocupa es que otros tienen menos que yo ... 34. Ayudaría a un conocido que sé que no lo haría por mí Bloque 3 Las siguientes preguntas tienen sólo dos posibles respuestas, hay que elegir una. 37. En general, ¿crees que se puede tener confianza en la mayoría de la gente, o que se debe ser muy prudente al relacionarse con la gente? a) Se puede tener confianza en la mayoría de la gente. b) Se debe ser muy prudente al relacionarse con la gente 38. ¿Crees que la mayoría de la gente intentaría aprovecharse de ti, si tuvieran la oportunidad, o tratarían de ser justos? a) La mayoría de la gente intentaría aprovecharse de ti. b) La mayoría de la gente tratarían de ser justos ... 137 M. ¿CÓMO SON NUESTROS VOLUNTARIOS? Bloque 4 Las siguientes 4 preguntas, a diferencia de las demás, SÍ tienen una única respuesta correcta: 40. Si la probabilidad de contraer una enfermedad es de un 10 por ciento, ¿cuántas personas de 1.000 contraerían la enfermedad? (N si no puede/quiere responder) 41. Si 5 personas tienen el número premiado de la lotería y el premio a repartir es de dos millones de euros, ¿cuánto recibiría cada una?: (N si no puede/quiere responder) ... Bloque 5 45. Lanzamos una moneda al aire. Elige, de entre estas dos opciones, la que prefieres: a) Recibir 1.000 euros independientemente de si sale cara o sale cruz b) Recibir 2.000 euros si sale cara y nada si sale cruz 46. Elige, de entre estas dos opciones, la que prefieres: a) Recibir un billete de lotería con un 80 % de probabilidad de ganar 45 euros y un 20 % de probabilidad de no ganar nada b) Recibir 30 euros 47. ¿Aceptarías el siguiente acuerdo? Lanzamos una moneda al aire y si sale cara ganas 1.500 euros, y si sale cruz pierdes 1.000 euros: Sí (S), No (N) Segunda parte Nota de los investigadores: Queremos aleatorizar la presentación de las partes dos y tres. La mitad de los voluntarios hacen primero la segunda parte, detallada en esta sección y luego la tercera parte, detallada en la sección M.4, y la otra mitad al revés. A su vez, la mitad de los encuestados realizaran esta parte con dinero real, y la otra mitad con dinero ficticio. 138 M.4 Encuesta Además en esta parte queremos que en cada subtratamiento (2-3/3-2) la mitad hagan las cuestiones en orden 1-10, 11-20, y la otra mitad en el otro orden, 11-20, 1-10. La probabilidad de que se te presente un orden u otro es el 50 % y debe ser independiente de que hagas 2-3 o 3-2. Además, la mitad tienen que hacer versión 1 (pago real) y la mitad versión 2 (pago hipotético). Cogiendo el ejemplo de los que hacen primero la parte 2 y después la 3 (igual para los que hacen 3-2), tendríamos 4 subgrupos: un 25 % de gente haciendo la versión 1 en el orden 1-10, 11-20; otro 25 % haciendo la versión 1 en orden 11-20, 1-10; otro 25 % haciendo la versión 2 en orden 1-10, 11-20; y el 25% restante haciendo la versión 2 en orden 11-20, 1-10. Así que al final tendríamos 8 subgrupos (estos 4 más los 4 de los que hacen la parte 3 y luego la 2) con el mismo número de participantes aproximadamente. Bloque 1 1. Recibir 30€hoy o recibir 30€dentro de un mes 2. Recibir 30€hoy o recibir 32€dentro de un mes 3. Recibir 30€hoy o recibir 34€dentro de un mes 4. Recibir 30€hoy o recibir 36€dentro de un mes 5. Recibir 30€hoy o recibir 38€dentro de un mes 6. Recibir 30€hoy o recibir 40€dentro de un mes 7. Recibir 30€hoy o recibir 42€dentro de un mes 8. Recibir 30€hoy o recibir 44€dentro de un mes 9. Recibir 30€hoy o recibir 46€dentro de un mes 10. Recibir 30€hoy o recibir 48€dentro de un mes Bloque 2 11. Recibir 30€dentro de un mes o recibir 30€dentro de 7 meses 12. Recibir 30€dentro de un mes o recibir 32€dentro de 7 meses 13. Recibir 30€dentro de un mes o recibir 34€dentro de 7 meses 139