Emtec V700H Manual do Utilizador

UNIVERSIDAD DE CASTILLA-LA MANCHAESCUELA SUPERIOR DE INFORMÁTICAINGENIERÍAEN INFORMÁTICAPROYECTO FIN DE CARRERAQuQuSI: Plataforma para la Gestión Inte

3.2.1. Procesos de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . 273.2.2. Patrones de diseño . . . . . . . . . . . . . . . . . . . . . .

5.3. SERVIDOR QUQUSI CAPÍTULO 5. ARQUITECTURAalgún cambio en alguno de los descriptores de archivo, llama a la función correspondientede la clase que

CAPÍTULO 5. ARQUITECTURA 5.3. SERVIDOR QUQUSIA partir de estas dos clases se implementan las partes del servidor QuQuSI. La funciónde cada parte es:QE

5.3. SERVIDOR QUQUSI CAPÍTULO 5. ARQUITECTURAFigura 5.5: Diagrama de clases de la interacción entre el módulo de comunicación y el mó-dulo de concurso

CAPÍTULO 5. ARQUITECTURA 5.3. SERVIDOR QUQUSILa comunicación con las partes del módulo de comunicación se lleva a cabo median-te el patrón observer. P

5.3. SERVIDOR QUQUSI CAPÍTULO 5. ARQUITECTURAFigura 5.6: Diagrama de clases del módulo de concurso.82

CAPÍTULO 5. ARQUITECTURA 5.3. SERVIDOR QUQUSIA continuación se describe brevemente el propósito de cada estado:QStartState: Es el estado inicial del c

5.3. SERVIDOR QUQUSI CAPÍTULO 5. ARQUITECTURAQRoundEndState: Es un estado de transición durante el cual se muestra la puntua-ción de los equipos.QWinn

CAPÍTULO 5. ARQUITECTURA 5.3. SERVIDOR QUQUSIFigura 5.7: Diagrama de clases del módulo de preguntas.85

5.3. SERVIDOR QUQUSI CAPÍTULO 5. ARQUITECTURA// Obtiene una preguntaboolQuizMgr::popQuestion() {QuestRequest questRequest;double val;// RondaquestRequ

CAPÍTULO 5. ARQUITECTURA 5.3. SERVIDOR QUQUSIdoubleQuestionMgr::valQuestion(Question*pQuestion,QuestRequest questRequest) {double cat, sub, typ, dif;/

5.3.3. Módulo de concurso . . . . . . . . . . . . . . . . . . . . . . . . . 795.3.4. Módulo de preguntas . . . . . . . . . . . . . . . . . . . . . . .

5.4. APLICACIÓN PARA EL CHROMA CAPÍTULO 5. ARQUITECTURAPairQuestion: Se asocia con la pregunta de tipo emparejar elementos. Cuenta conla pregunta y lo

CAPÍTULO 5. ARQUITECTURA 5.4. APLICACIÓN PARA EL CHROMALa interfaz debe ofrecer un feedback ante las acciones de los usuarios, de forma quesea fácil s

5.4. APLICACIÓN PARA EL CHROMA CAPÍTULO 5. ARQUITECTURAFigura 5.8: Captura de la interfaz de la aplicación para el chroma.Observer: Se utiliza para la

CAPÍTULO 5. ARQUITECTURA 5.4. APLICACIÓN PARA EL CHROMA• Panel de preguntas: Este overlay muestra la pregunta. Cambia en función deltipo de pregunta q

5.4. APLICACIÓN PARA EL CHROMA CAPÍTULO 5. ARQUITECTURA5.4.1. Módulo de configuraciónSe trata exactamente del mismo módulo descrito en la sección 5.3.1

CAPÍTULO 5. ARQUITECTURA 5.4. APLICACIÓN PARA EL CHROMAEl protocolo de comunicación se implementa en la clase QChromaMsg. El mensaje quese recibe del

5.4. APLICACIÓN PARA EL CHROMA CAPÍTULO 5. ARQUITECTURAFigura 5.10: Diagrama de clases del módulo de overlays.94

CAPÍTULO 5. ARQUITECTURA 5.4. APLICACIÓN PARA EL CHROMAPanel de puntuaciónEs el gestor que se encarga de los overlays en los que se muestran los nombr

5.4. APLICACIÓN PARA EL CHROMA CAPÍTULO 5. ARQUITECTURAstd::string makeTextAreaText(std::string text,Ogre::OverlayElement*pTextArea) {// Cast de Overl

CAPÍTULO 5. ARQUITECTURA 5.4. APLICACIÓN PARA EL CHROMAstd::string textNewLine(std::string text,Ogre::OverlayElement*pTextArea) {// Strings de entrada

A. Manual de usuario 139A.1. Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139A.1.1. Aplicación Web para las pregu

5.4. APLICACIÓN PARA EL CHROMA CAPÍTULO 5. ARQUITECTURAdouble textWidth(std::string text, Ogre::OverlayElement*pTextArea) {// Convertir texto a cadena

CAPÍTULO 5. ARQUITECTURA 5.4. APLICACIÓN PARA EL CHROMAnuevos tipos de preguntas sin tener que realizar grandes cambios en el módulo.Nodo multimediaEs

5.4. APLICACIÓN PARA EL CHROMA CAPÍTULO 5. ARQUITECTURAdo 5.6). La clase proporciona funciones para cargar, reproducir y pausar el contenido, yse enca

CAPÍTULO 5. ARQUITECTURA 5.4. APLICACIÓN PARA EL CHROMA// Inicializar GStreamergst_init(0, 0);// Inicializar soporte para hilosif (!g_thread_supported

5.4. APLICACIÓN PARA EL CHROMA CAPÍTULO 5. ARQUITECTURAFigura 5.12: Diagrama de clases del módulo chroma.102

CAPÍTULO 5. ARQUITECTURA 5.5. APLICACIÓN PARA LOS MARCADORESoverlays, el cual se encarga de representar el estado del concurso.5.5. APLICACIÓN PARA LO

5.5. APLICACIÓN PARA LOS MARCADORES CAPÍTULO 5. ARQUITECTURAPara ello, utiliza el motor gráfico OGRE 3D (capítulo 3). Mediante el uso de overlaysy fuen

CAPÍTULO 5. ARQUITECTURA 5.5. APLICACIÓN PARA LOS MARCADORESFigura 5.14: Diagrama de clases del módulo de comunicación de la aplicación para los mar-c

5.6. APLICACIÓN PARA LOS PULSADORES CAPÍTULO 5. ARQUITECTURAFigura 5.15: Diagrama de clases del módulo de marcadores.La función initOIS inicializa los

CAPÍTULO 5. ARQUITECTURA 5.6. APLICACIÓN PARA LOS PULSADORESGestionar la conexión con el servidor, reconectándose en caso de fallo.Comunicarse con el

ÍNDICE DE FIGURAS1.1. Precio por spot de 20 segundos en función de la franja horaria [2]. . . . . . 33.1. Mapa conceptual de antecedentes de QuQuSI. .

5.6. APLICACIÓN PARA LOS PULSADORES CAPÍTULO 5. ARQUITECTURALas pulsaciones se transmiten en el orden correcto gracias al código cargado en el micro-p

CAPÍTULO 5. ARQUITECTURA 5.7. APLICACIÓN WEB DE CONTROLeste descriptor al conjunto de lectura de QSelectMgr y, cuando se recibe un carácter desdeel mi

5.7. APLICACIÓN WEB DE CONTROL CAPÍTULO 5. ARQUITECTURA#define BUTTONS 3int buttons[] = {2, 3, 4}; // Pulsadoresint pressed[] = {0, 0, 0}; // Presiona

CAPÍTULO 5. ARQUITECTURA 5.7. APLICACIÓN WEB DE CONTROLEsta interfaz debe reaccionar ante los cambios de estado y los eventos que ocurran du-rante el

5.7. APLICACIÓN WEB DE CONTROL CAPÍTULO 5. ARQUITECTURAEstá aplicación, implementada en HTML, PHP, JavaScript y AJAX, permite enviar lasseñales de con

CAPÍTULO 5. ARQUITECTURA 5.8. APLICACIÓN WEB PARA EL PÚBLICOla caché de APC (3b, 4b). Si está abierto, lo cierra y realiza la consulta al servidorQuQu

5.8. APLICACIÓN WEB PARA EL PÚBLICO CAPÍTULO 5. ARQUITECTURAPermitir que el usuario realice un login que lo identifique de forma inequívoca.Ofrecer la

CAPÍTULO 5. ARQUITECTURA 5.8. APLICACIÓN WEB PARA EL PÚBLICOCategoría: La categoría a la que pertenece el participante. Hay un ganador por cadacategor

5.9. REPRODUCTOR DE EVENTOS CAPÍTULO 5. ARQUITECTURA7. Cuando el usuario contesta a una pregunta, se marca ésta en la interfaz y se activa unavariable

CAPÍTULO 5. ARQUITECTURA 5.9. REPRODUCTOR DE EVENTOSEsta aplicación, implementada en C++, carga el historial de eventos y simula ser el ser-vidor del

5.12. Diagrama de clases del módulo chroma. . . . . . . . . . . . . . . . . . . . 1025.13. Captura de la interfaz de la aplicación para los marcadores

CAPÍTULO 6. EVOLUCIÓN Y COSTESEn este capítulo se describe la evolución sufrida por el proyecto bajo el Proceso Unificadode Desarrollo, como se indicó

6.1. EVOLUCIÓN DEL PROYECTO CAPÍTULO 6. EVOLUCIÓN Y COSTESIteración Fecha de entrega1 22-12-20122 10-1-20133 23-2-20134 30-3-20135 10-4-20136 15-4-201

CAPÍTULO 6. EVOLUCIÓN Y COSTES 6.1. EVOLUCIÓN DEL PROYECTOimplicado en las VII Olimpiadas Informáticas para introducir las preguntas del concurso enla

6.1. EVOLUCIÓN DEL PROYECTO CAPÍTULO 6. EVOLUCIÓN Y COSTESPruebas: Se realizaron pruebas unitarias para el módulo de gestión de preguntas im-plementad

CAPÍTULO 6. EVOLUCIÓN Y COSTES 6.1. EVOLUCIÓN DEL PROYECTOAnálisis: Se llevó a cabo el análisis de la mecánica de juego para incorporar las reglasal m

6.1. EVOLUCIÓN DEL PROYECTO CAPÍTULO 6. EVOLUCIÓN Y COSTESlas aplicaciones clientes. Se diseñó también una forma de comunicación con el puertoserie a

CAPÍTULO 6. EVOLUCIÓN Y COSTES 6.1. EVOLUCIÓN DEL PROYECTOIteración 8Durante la octava iteración se implementó la aplicación de marcadores, ampliando

6.1. EVOLUCIÓN DEL PROYECTO CAPÍTULO 6. EVOLUCIÓN Y COSTESImplementación: Se llevó a cabo la implementación de la aplicación para el chromareutilizand

CAPÍTULO 6. EVOLUCIÓN Y COSTES 6.2. RECURSOS Y COSTESDiseño: Se diseño la aplicación para la reproducción del historial de eventos, teniendoen cuenta

D.4. a) Vista desde los atriles de los concursantes. b) Proceso de montaje de ladecoración impresa para cubrir los atriles. c) Mesa de mezcla de audio

6.2. RECURSOS Y COSTES CAPÍTULO 6. EVOLUCIÓN Y COSTESla Escuela Superior de Informática de Ciudad Real. Para simplificar los cálculos, no se hatenido e

CAPÍTULO 6. EVOLUCIÓN Y COSTES 6.2. RECURSOS Y COSTESEl número de líneas de código de cada lenguaje empleado en la elaboración de QuQuSIpuede consulta

6.2. RECURSOS Y COSTES CAPÍTULO 6. EVOLUCIÓN Y COSTESMayo 2013Abril2013Marzo2013Commits realizados876543210Figura 6.2: Commits realizados al servidor

CAPÍTULO 7. CONCLUSIONES Y PROPUESTASEn este capítulo se describen los objetivos alcanzados y se proponen una serie de líneasde trabajo futuro para me

7.2. TRABAJO FUTURO CAPÍTULO 7. CONCLUSIONES Y PROPUESTAStres validadores que las revisaron. Se generaron un total de 192 preguntas, de las cuales 139

CAPÍTULO 7. CONCLUSIONES Y PROPUESTAS 7.2. TRABAJO FUTUROA continuación se enumeran las líneas de trabajo futuro que permitirían mejorar y exten-der l

7.2. TRABAJO FUTURO CAPÍTULO 7. CONCLUSIONES Y PROPUESTASSería interesante aprovechar la capacidad de visualizar y animar modelos 3D para di-señar una

CAPÍTULO 7. CONCLUSIONES Y PROPUESTAS 7.2. TRABAJO FUTURObiblioteca de serialización como Boost [20] o bien mediante la creación de un lenguajede espe

7.3. CONCLUSIÓN PERSONAL CAPÍTULO 7. CONCLUSIONES Y PROPUESTAScompatible con Javascript. Esta solución benefició la heterogeneidad de la platafor-ma, p

CAPÍTULO 7. CONCLUSIONES Y PROPUESTAS 7.3. CONCLUSIÓN PERSONALEn definitiva, estoy satisfecho de haber elegido la titulación de Ingeniería Informáticac

E.6. a) El equipo Coldass piensa la solución a una pregunta de sistemas operati-vos. b) El equipo Fbr contesta correctamente a una pregunta test de si

APÉNDICE A. MANUAL DE USUARIOEn este apéndice se incluyen las instrucciones a seguir para la instalación, despliegue ymaniobra de QuQuSI.A.1. INSTALAC

A.1. INSTALACIÓN APÉNDICE A. MANUAL DE USUARIOA.1.2. Aplicación Web de control y para el públicoEstas dos aplicaciones requieren un servidor Web con P

APÉNDICE A. MANUAL DE USUARIO A.2. DESPLIEGUElibgstreamer0.10-devlibgstreamer-plugins-base0.10-devcolorgcclibstdc++6-4.3-devUna vez instalado OGRE 3D

A.2. DESPLIEGUE APÉNDICE A. MANUAL DE USUARIOA.2.2. Aplicación Web de control y para el públicoEstas dos aplicaciones requieren que la máquina donde s

APÉNDICE A. MANUAL DE USUARIO A.2. DESPLIEGUEchromaPort (3002): Puerto utilizado para la comunicación con la aplicación parael chroma.statePort (3003)

A.2. DESPLIEGUE APÉNDICE A. MANUAL DE USUARIOcyclTeamA: Nombre del primer equipo de ciclos formativos.cyclTeamB: Nombre del segundo equipo de ciclos f

APÉNDICE A. MANUAL DE USUARIO A.3. ARRANQUEscoreServerPort (3000): Puerto del servidor para atender a la aplicación para losmarcadores (configurado en

A.3. ARRANQUE APÉNDICE A. MANUAL DE USUARIO4. Probar el circuito eléctrico de los pulsadores viendo los mensajes lanzados por la apli-cación Web para

APÉNDICE B. MECÁNICA DE JUEGOEn este anexo se describe la mecánica de juego del concurso al que da soporte la plata-forma QuQuSI en su fase de demostr

ÍNDICE DE TABLAS6.1. Fechas de entrega según iteración. . . . . . . . . . . . . . . . . . . . . . . 1206.2. Coste estimado del desarrollo de QuQuSI. .

B.2. TIPOS DE RONDA APÉNDICE B. MECÁNICA DE JUEGOB.2. TIPOS DE RONDAEl concurso tiene tres tipos de rondas diferentes que tienen lugar en el orden que

APÉNDICE B. MECÁNICA DE JUEGO B.3. TIPOS DE PREGUNTAEmparejar elementos: Se muestra una pista y tres parejas de elementos desordena-dos. El objetivo e

APÉNDICE C. INVENTARIOEn esta sección se detallan las especificaciones del material empleado en el desplieguede QuQuSI durante la fase final de las VII

APÉNDICE C. INVENTARIO• Tensión de entrada12 V CC (10,8 a 13,2 V CC)• Consumo de corriente0,2 A máx. (a 12 V CC), 2,4 W• Temperatura de funcionamiento

APÉNDICE C. INVENTARIO• Relación de aspecto4:3• Entrada de vídeo1.0 Vp-p, 75 Ohm• Sistema de vídeoNTSC/PAL automático• AlimentaciónCC 12 V 50 W6 x Mon

APÉNDICE C. INVENTARIO• Formato de vídeo para las grabacionesTSMPG(MPEG2, MP2)3 x Micrófono AKG WMS 40 FLEXX• Frecuencia portadora 660 - 865 MHz• Modu

APÉNDICE C. INVENTARIO1 x Arduino Diecimila3 x Pulsadores artesanales2 x Puntos de acceso Wifi4 x Conversores de señal155

APÉNDICE D. FOTOS DEL MONTAJEEn este apéndice se muestran las fotografías tomadas durante el montaje del escenariodel concurso realizado para las VII

APÉNDICE D. FOTOS DEL MONTAJEa bdcFigura D.1: a) Equipos empleados durante el despliegue (un equipo de reserva). b) Conmu-tador y servidor principal c

APÉNDICE D. FOTOS DEL MONTAJEa bdcFigura D.2: a) Vista trasera de un atril de los concursantes a falta de la decoración frontal.b) Vista frontal de un

APÉNDICE D. FOTOS DEL MONTAJEa bdcFigura D.3: a) Pulsador artesanal elaborado por José Antonio Fernández, miembro del equi-po técnico de la escuela. b

APÉNDICE D. FOTOS DEL MONTAJEa bdcFigura D.4: a) Vista desde los atriles de los concursantes. b) Proceso de montaje de la decora-ción impresa para cub

APÉNDICE D. FOTOS DEL MONTAJEa bdcFigura D.5: a) Vista frontal del montaje provisional de la decoración de los atriles. b) Vistadesde el portátil táct

APÉNDICE D. FOTOS DEL MONTAJEa bdcFigura D.6: a) Miembros de la Escuela Superior de Informática prueban el sistema. b) Mesade mezcla de vídeo con las

APÉNDICE D. FOTOS DEL MONTAJEa bFigura D.7: a) Vista trasera de los atriles de los concursantes con los micrófonos y los pulsa-dores fijados y la decor

APÉNDICE E. FOTOS DEL CONCURSOEn este capítulo se recogen capturas del video final editado en la fase de postproduccióntras la grabación del concurso,

APÉNDICE E. FOTOS DEL CONCURSOacbFigura E.1: a) Los equipos de bachillerato preparados para empezar. b) El equipo Fbr03se enfrenta a una pregunta test

APÉNDICE E. FOTOS DEL CONCURSOacbFigura E.2: a) El equipo Desmagnetizar solicita el turno para responder a una pregunta deemparejar elementos.b) Se mu

ÍNDICE DE LISTADOS5.1. Código fuente de la función popQuestion. . . . . . . . . . . . . . . . . 865.2. Código de la función valQuestion. . . . . . . .

APÉNDICE E. FOTOS DEL CONCURSOacbFigura E.3: a) El equipo Fbr03 se piensa la respuesta a la pregunta test de informática básica.b) El equipo Error404

APÉNDICE E. FOTOS DEL CONCURSOacbFigura E.4: a) Clasificación parcial de los equipos tras finalizar una ronda. b) Los equipostratan de encontrar la solu

APÉNDICE E. FOTOS DEL CONCURSOacbFigura E.5: a) Deportividad entre equipos tras la finalización de la categoría de bachillerato.b) Presentación de los

APÉNDICE E. FOTOS DEL CONCURSOacbFigura E.6: a) El equipo Coldass piensa la solución a una pregunta de sistemas operativos.b) El equipo Fbr contesta c

APÉNDICE E. FOTOS DEL CONCURSOacbFigura E.7: a) Clasificación parcial de los equipos de ciclos formativos tras finalizar unaronda. b) Clasificación final

APÉNDICE F. CARTAS DE RECOMENDACIÓNEn este apéndice se recogen las cartas de recomendación recibidas hasta el momentotras la grabación del concurso. S

APÉNDICE F. CARTAS DE RECOMENDACIÓNFigura F.1: Carta de Cesar A. Guerra García, Profesor-Investigador de la Universidad Poli-técnica de San Luis Potos

APÉNDICE F. CARTAS DE RECOMENDACIÓNFigura F.2: Carta de Miguel Ángel Bajo Cabezas, Jefe Técnico de Televisión Ciudad Real.175

APÉNDICE F. CARTAS DE RECOMENDACIÓNFigura F.3: Carta de D. Julián Camacho Morejudo, Consejero Delegado de Imás TV.176

APÉNDICE G. DOWNGRADE CONTROLADOR NVIDIADurante el desarrollo del proyecto el controlador de tarjetas gráficas NVIDIA del reposi-torio de Debian Wheezy

APÉNDICE G. DOWNGRADE CONTROLADOR NVIDIA7. A continuación, instalar el siguiente paquete mediante el gestor de paquetes:# aptitude install nvidia-glx8

APÉNDICE G. DOWNGRADE CONTROLADOR NVIDIAlibgl1-nvidia-glx \libglx-nvidia-alternatives \nvidia-alternative \nvidia-installer-cleanup \nvidia-support \n

APÉNDICE H. CÓDIGO CLASES PATRÓNEn esta sección se muestra el código de las clases plantilla con las que se implementanlos patrones singleton, observe

H.3. CÓDIGO PATRÓN STATE APÉNDICE H. CÓDIGO CLASES PATRÓN#ifndef QSINGLETON_H#define QSINGLETON_Htemplate<class T> class QSingleton {public:// R

APÉNDICE H. CÓDIGO CLASES PATRÓN H.3. CÓDIGO PATRÓN STATE#ifndef QSUBJECT_H#define QSUBJECT_H#include "QObserver.h"#include <list>temp

H.3. CÓDIGO PATRÓN STATE APÉNDICE H. CÓDIGO CLASES PATRÓN#ifndef QSTATE_H#define QSTATE_H#include <string>class QStateMachine;class QState {publ

APÉNDICE H. CÓDIGO CLASES PATRÓN H.3. CÓDIGO PATRÓN STATE#ifndef QSTATEMACHINE_H#define QSTATEMACHINE_H#include <string>#include <stack>cl

H.3. CÓDIGO PATRÓN STATE APÉNDICE H. CÓDIGO CLASES PATRÓN#include "QStateMachine.h"#include "QState.h"// Constructor y destructor

APÉNDICE I. CÓDIGO FUENTEDada la extensión del código fuente de la plataforma, en total más de 10.000 líneas,éste no se ha incluido impreso en ningún

AGRADECIMIENTOSSon muchas las personas a las que quiero agradecer su apoyo y ayuda.En primer lugar a mi familia, especialmente a mi madre, sin quien n

BIBLIOGRAFÍA[1] Kantar Mediahttp://www.kantarmedia1.es/[2] Obliqua Medioshttp://www.obliqua.es/[3] Antena 3http://www.antena3.com/[4] Telecincohttp://

[12] OpenLogichttp://www.openlogic.com/[13] GStreamerhttp://gstreamer.freedesktop.org/[14] Ogre3Dhttp://www.ogre3d.org/[15] Buzz!http://www.buzzthegam

[25] ISO/IEC 9241. ISO/IEC 9241-11: Ergonomic requirements for office work with visualdisplay terminals (VDTs) – Part 11: Guidance on usability. ISO, 1

CAPÍTULO 1. INTRODUCCIÓNEn los últimos años, los concursos han proliferado en la parrilla televisiva, ocupando lasfranjas de emisión con mayor audienc

1.2. IMPACTO SOCIO-ECONÓMICO CAPÍTULO 1. INTRODUCCIÓNLos concursos, al igual que los juegos educativos, favorecen el aprendizaje. Juegos edu-cativos c

CAPÍTULO 1. INTRODUCCIÓN 1.2. IMPACTO SOCIO-ECONÓMICO12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:0002000400060008000100001200014000

1.3. PROBLEMÁTICA CAPÍTULO 1. INTRODUCCIÓNson «Atrapa un millón», que se emite en Antena 3 de 20:00 a 21:00 con un precio por spotque va desde los 7.2

CAPÍTULO 1. INTRODUCCIÓN 1.4. ESTRUCTURA DEL DOCUMENTOPermitir el despliegue de elementos gráficos 2D y 3D, soportando la reproducción deimagen y vídeo

1.4. ESTRUCTURA DEL DOCUMENTO CAPÍTULO 1. INTRODUCCIÓNCapítulo 5. Arquitectura: En este capítulo se describen las aplicaciones que formanla plataforma

CAPÍTULO 2. OBJETIVOSEn este capítulo se enumeran y describen los objetivos y subobjetivos planteados para elpresente Proyecto Fin de Carrera.2.1. OBJ

UNIVERSIDAD DE CASTILLA-LA MANCHAESCUELA SUPERIOR DE INFORMÁTICAPROYECTO FIN DE CARRERAQuQuSI: Plataforma para la Gestión Integral de ConcursosTelevis

2.2. OBJETIVOS ESPECÍFICOS CAPÍTULO 2. OBJETIVOSReproducción de música y efectos de sonido con posibilidad de controlar el volumende forma gradual en

CAPÍTULO 2. OBJETIVOS 2.2. OBJETIVOS ESPECÍFICOSUn mecanismo que permita que las preguntas sean validadas antes de su explotación.Un diseño basado en

2.2. OBJETIVOS ESPECÍFICOS CAPÍTULO 2. OBJETIVOSMostrar información suficiente para entender el estado del concurso y poder presen-tarlo de forma senci

CAPÍTULO 2. OBJETIVOS 2.2. OBJETIVOS ESPECÍFICOSUtilizar patrones de diseño que mejoren la calidad del código y solucionen problemasrecurrentes.Favore

CAPÍTULO 3. ANTECEDENTESAlcanzar los objetivos propuestos en QuQuSI requiere un amplio abanico de conoci-mientos en numerosos campos de la informática

3.1. GAMEPLAY CAPÍTULO 3. ANTECEDENTESGameplayAntecedentesQuQuSIAlmacenamientode datosFrameworksInformáticagráficaNetworkingIngenieríadel softwareConc

CAPÍTULO 3. ANTECEDENTES 3.1. GAMEPLAYy satisfacción en un contexto de uso. Así, la usabilidad de un sistema se mide en función desus propiedades de e

3.1. GAMEPLAY CAPÍTULO 3. ANTECEDENTESun millón» (Antena 3). La prueba de su éxito son las elevadas audiencias que logran [1].Aunque los concursos atr

CAPÍTULO 3. ANTECEDENTES 3.1. GAMEPLAYspot de publicidad de 20 segundos va desde los 7.270 e hasta los 13.000 e [2]. Su versiónoriginal, «The Money Dr

3.1. GAMEPLAY CAPÍTULO 3. ANTECEDENTESFigura 3.3: Imagen de «Pasapalabra» obtenida de [4].participan en una prueba final (“El rosco”) en la que han de

CAPÍTULO 3. ANTECEDENTES 3.1. GAMEPLAYFigura 3.4: Imagen de «¡Ahora caigo!» obtenida de [3].al concursante central, gana la cantidad de dinero oculta

3.1. GAMEPLAY CAPÍTULO 3. ANTECEDENTESFigura 3.5: Imagen de «La ruleta de la suerte» obtenida de [3].turnos hasta llegar a la final, en donde el concur

CAPÍTULO 3. ANTECEDENTES 3.1. GAMEPLAYIntegración de efectos de sonido que se puedan mezclar en tiempo real.Soporte de diferentes tipos de pruebas y d

3.1. GAMEPLAY CAPÍTULO 3. ANTECEDENTESFigura 3.6: Captura de «Buzz!» obtenida de [15].2006, el segundo juego de la serie, «Buzz!: The Big Quiz», recib

CAPÍTULO 3. ANTECEDENTES 3.1. GAMEPLAYtation Eye. Además, durante la partida, la cámara puede tomar fotos de los jugadores, mos-trando sus reacciones

3.1. GAMEPLAY CAPÍTULO 3. ANTECEDENTESCaracterísticas deseables de los videojuegosDe las características y la mecánica de los videojuegos se obtienen

CAPÍTULO 3. ANTECEDENTES 3.1. GAMEPLAYFigura 3.8: Captura de «Brain Training» obtenida de [16].«Brain Training»«Brain Training» («Brain Age» en region

3.1. GAMEPLAY CAPÍTULO 3. ANTECEDENTESFigura 3.9: Captura de «Aprende con Pipo» obtenida de [8].la temática del juego. Algunos ejemplos son pruebas mu

CAPÍTULO 3. ANTECEDENTES 3.2. INGENIERÍA DEL SOFTWAREEn las anteriores secciones se ha definido el concepto de gameplay y se han analizadolas caracterí

TRIBUNAL:Presidente:Vocal:Secretario:FECHA DE DEFENSA:CALIFICACIÓN:PRESIDENTE VOCAL SECRETARIOFdo.: Fdo.: Fdo.:

3.2. INGENIERÍA DEL SOFTWARE CAPÍTULO 3. ANTECEDENTESEstablece a todas sus actividades principales.Utiliza recursos, está sujeto a restricciones y gen

CAPÍTULO 3. ANTECEDENTES 3.2. INGENIERÍA DEL SOFTWARE• Dirigido por casos de uso: El sistema software resultante del proceso se originaa partir de las

3.2. INGENIERÍA DEL SOFTWARE CAPÍTULO 3. ANTECEDENTESInicio Elaboración Construcción TransiciónFLUJOS DE TRABAJORequisitosAnálisisDiseñoImplementación

CAPÍTULO 3. ANTECEDENTES 3.2. INGENIERÍA DEL SOFTWAREson aspectos metodológicos del proceso. Gracias a estas prácticas el producto softwareque se desa

3.2. INGENIERÍA DEL SOFTWARE CAPÍTULO 3. ANTECEDENTESCrear casosde pruebaProgramaren parejasEjecutarpruebasIntegraciónFomarparejasPlanificariteraciónD

CAPÍTULO 3. ANTECEDENTES 3.2. INGENIERÍA DEL SOFTWARELos procesos ligeros se descartaron principalmente por estar optimizados para equiposde desarroll

3.2. INGENIERÍA DEL SOFTWARE CAPÍTULO 3. ANTECEDENTESCreación: Estos patrones proporcionan soluciones relacionadas con la construcciónde clases, objet

CAPÍTULO 3. ANTECEDENTES 3.2. INGENIERÍA DEL SOFTWARE3.2.3. AlgoritmiaUn algoritmo es un conjunto ordenado y finito de normas u órdenes que permiten ef

3.2. INGENIERÍA DEL SOFTWARE CAPÍTULO 3. ANTECEDENTESExploración de grafos: Se trata de algoritmos que permiten resolver problemas quese representan m

CAPÍTULO 3. ANTECEDENTES 3.2. INGENIERÍA DEL SOFTWAREMayor cohesión: Al contener todo el código fuente y las variables necesarias parasatisfacer la fu

3.2. INGENIERÍA DEL SOFTWARE CAPÍTULO 3. ANTECEDENTESPermiten detectar errores en el código durante todas las fases del desarrollo.Es posible dirigir

CAPÍTULO 3. ANTECEDENTES 3.2. INGENIERÍA DEL SOFTWARE• Clases de equivalencia: Con este método se dividen los posibles valores de en-trada en clases d

3.3. NETWORKING CAPÍTULO 3. ANTECEDENTESSe han llevado a cabo pruebas de integración para combinar los módulos en cada apli-cación.Las pruebas de sist

CAPÍTULO 3. ANTECEDENTES 3.3. NETWORKINGSon capaces de interpretar lenguajes de script del lado del servidor, generando asídocumentos dinámicos.Existe

3.3. NETWORKING CAPÍTULO 3. ANTECEDENTESOfrecen una interfaz de comunicación abstrayéndose de los detalles de las capas infe-riores.Permiten el direcc

CAPÍTULO 3. ANTECEDENTES 3.4. ALMACENAMIENTO DE DATOS3.4. ALMACENAMIENTO DE DATOSPara gestionar de forma integral un concurso televisivo se ha de alma

3.4. ALMACENAMIENTO DE DATOS CAPÍTULO 3. ANTECEDENTESManipulación de datos: Gracias al uso de un lenguaje de manipulación de datos,permiten la inserci

CAPÍTULO 3. ANTECEDENTES 3.4. ALMACENAMIENTO DE DATOS3.4.2. Sistemas de archivosUn sistema de archivos consiste en una estructura de directorios o car

3.5. INFORMÁTICA GRÁFICA CAPÍTULO 3. ANTECEDENTESEn las anteriores secciones se han analizado las soluciones disponibles para el almacena-miento de da

CAPÍTULO 3. ANTECEDENTES 3.5. INFORMÁTICA GRÁFICALos colores de fondo más utilizados para la utilización de la técnica son el verde y el azul.Esto se

RESUMENLos concursos son un fenómeno televisivo y social en alza que despierta un gran interéspor parte de los espectadores. La variedad de concursos

3.6. FRAMEWORKS CAPÍTULO 3. ANTECEDENTESPre-rendering: Es el que se usa en las películas de animación por computador. Enlugar de generar las imágenes

CAPÍTULO 3. ANTECEDENTES 3.6. FRAMEWORKSOfrecen formas de gestionar la escena tridimensional, pudiendo aplicar varias trans-formaciones a los elemento

3.6. FRAMEWORKS CAPÍTULO 3. ANTECEDENTESEl motor gráfico utilizado en el presente Proyecto Fin de Carrera es OGRE 3D.Se ha elegido este framework por s

CAPÍTULO 3. ANTECEDENTES 3.6. FRAMEWORKSpropios. Arduino puede ampliarse mediante placas oficiales que aportan nuevas fun-cionalidades (shields) o con

3.6. FRAMEWORKS CAPÍTULO 3. ANTECEDENTESCakePHP: Es otro framework libre para el desarrollo de aplicaciones Web con unaarquitectura Modelo Vista Contr

CAPÍTULO 3. ANTECEDENTES 3.6. FRAMEWORKSGStreamer: Es un framework de desarrollo de aplicaciones multimedia [13]. Permitela creación de aplicaciones m

CAPÍTULO 4. MÉTODO DE TRABAJOEl desarrollo de QuQuSI se ha llevado a cabo siguiendo una metodología y utilizandouna serie de herramientas. En el capít

4.2. HERRAMIENTAS CAPÍTULO 4. MÉTODO DE TRABAJO4.2.1. LenguajesPara la elaboración de QuQuSI se han utilizado lenguajes de diferente nivel y propósito

CAPÍTULO 4. MÉTODO DE TRABAJO 4.2. HERRAMIENTASSistema operativoTanto el desarrollo como en el despliegue y la ejecución del proyecto se han llevado a

4.2. HERRAMIENTAS CAPÍTULO 4. MÉTODO DE TRABAJOMercurial 2.2.2: Es el software de control de versiones utilizado durante el desarrollodel proyecto. Co

CAPÍTULO 4. MÉTODO DE TRABAJO 4.2. HERRAMIENTASBlender 2.49a: Es un programa para la creación y animación de modelos tridimensio-nales, aunque también

4.2. HERRAMIENTAS CAPÍTULO 4. MÉTODO DE TRABAJOComputadoresPara el desarrollo y el despliegue de QuQuSI se usaron varios computadores:Cuatro equipos d

CAPÍTULO 4. MÉTODO DE TRABAJO 4.2. HERRAMIENTASOtrosAdemás de lo anterior, se utilizó el siguiente material para comunicación, conexión yconversión:Un

CAPÍTULO 5. ARQUITECTURAEn el capítulo actual se describe la arquitectura de la plataforma QuQuSI a través de unenfoque top-down, comenzando con una d

CAPÍTULO 5. ARQUITECTURAMóduloconfiguraciónMódulo overlaysPanel preguntasPanel vídeoPanel puntuaciónPanel contadoresMódulo preguntasLista preguntas Pr

CAPÍTULO 5. ARQUITECTURA 5.1. DESCRIPCIÓN GENERAL5.1. DESCRIPCIÓN GENERALQuQuSI se ha diseñado como un sistema distribuido con una arquitectura client

5.2. APLICACIÓN WEB PARA LAS PREGUNTAS CAPÍTULO 5. ARQUITECTURAExtensibilidad: La modularidad del código permite incorporar nuevas clases sin rea-liza

CAPÍTULO 5. ARQUITECTURA 5.2. APLICACIÓN WEB PARA LAS PREGUNTASDebe ser accesible y fácil de usar.Ha de permitir exportar las preguntas en un formato

ÍNDICE GENERALResumen IAgradecimientos XI1. Introducción 11.1. Concursos televisivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. I

5.2. APLICACIÓN WEB PARA LAS PREGUNTAS CAPÍTULO 5. ARQUITECTURAFigura 5.2: Esquema relacional de la base de datos.Administrador: Es el rol reservado a

CAPÍTULO 5. ARQUITECTURA 5.2. APLICACIÓN WEB PARA LAS PREGUNTASDificultad: La dificultad de la pregunta. En un principio se plantearon cinco nivelesde d

5.2. APLICACIÓN WEB PARA LAS PREGUNTAS CAPÍTULO 5. ARQUITECTURALas preguntas se pueden ordenar y agrupar gracias al método paginate proporcionadopor e

CAPÍTULO 5. ARQUITECTURA 5.2. APLICACIÓN WEB PARA LAS PREGUNTASCakePHP. Cuenta con métodos que traducen las acciones del usuario en la vista aoperacio

5.3. SERVIDOR QUQUSI CAPÍTULO 5. ARQUITECTURA• edit: Se trata de la vista para la edición de un usuario existente.• index: Es la vista en la que se mu

CAPÍTULO 5. ARQUITECTURA 5.3. SERVIDOR QUQUSIGestionar la importación y el uso de las preguntas del concurso, evitando que se repitane informando en c

5.3. SERVIDOR QUQUSI CAPÍTULO 5. ARQUITECTURAGestor de comunicaciones: Es el módulo encargado de gestionar la comunicacióncon el resto de aplicaciones

CAPÍTULO 5. ARQUITECTURA 5.3. SERVIDOR QUQUSILa selección dinámica de preguntas se realiza mediante un algoritmo voraz (capítulo 3)implementado en el

5.3. SERVIDOR QUQUSI CAPÍTULO 5. ARQUITECTURAformateados. La función clearConfig permite vaciar el mapa de parámetros, reiniciandoel módulo a su estad

CAPÍTULO 5. ARQUITECTURA 5.3. SERVIDOR QUQUSIFigura 5.4: Diagrama de clases del módulo de comunicación del servidor QuQuSI.77